Bad Surface extents problem Created 15 years ago2009-06-25 11:20:10 UTC by atomen

Hello!

I'm working on a surf map and it's nearly finished. Right now It's around 71 000 base patches so I'm running the compiler with the "-sparse" setting, so I'm afraid that the problem is caused because I'm exceeding 65535 patches. Though I'm not sure, and that's why I'm asking for you expertise!

I can compile my map successfully without any errors but when I create a server and run the map on CS I receive the "bad surface extents" error. "Bad surface extents 640/0 at position (72, -2480, 2312)" to be exact. I've located the position in Nem's bspviewer and It seems that the error is occurs where the texture isn't rendered.

To explain the phrase "isn't rendered" I have a screenshot to demonstrate the error:

http://data.fuskbugg.se/skalman01/-error.bmp

These are my compiler settings:

hlcsg.exe" -wadautodetect -wadinclude custom.wad -high
hlbsp.exe" -high
hlvis.exe" -fast -estimate -high
hlrad.exe" -estimate -nomatrix -sparse -high

And for your notice: there aren't any problems with the wads, all textures are included so the problem probably lies in the hlrad process.

Search for textures with the scale less than 0.1 ( ex : 0.04,0.003 etc ...).
It's a common mistake by using the "fit" option on small brushes using big textures.

No, that's definitely not the problem. It is and old map which I resumed working on just a few days ago. Back when I made it I didn't even know about the text tool. And the blocks which aren't rendered are all using the aaatrigger texture. I've definitely not resized its scale since it's useless because all entities are invisible...

Um.. is the trigger teleport the only floor you have in the map? because anything turned into a trigger teleport isnt rendered. so put a floor beneath the teleport if there isnt one there already
As for the AAA trigger, what is it supossed to be?

And bad surface contents can be a lot of things... It could be 2 different material types applied to the same brush (ex: solid / liquid)
If you vertex manipulate at all, you might've turned a solid inside out.
Does Alt+P show anything? (Check for errors)

And if you could, post up your compile log, maybe that has any clues.

Beneath the trigger_teleport there is a 'sky' bottom.

I'm not sure that I understand what you mean, but it's supposed to be a texture which indicates that this object is a trigger/function...

In-game, yes, triggers aren't rendered, but in BSPViewer they are. The triggers/functions which aren't rendered/textured in BSPViewer are the ones which receives the 'bad surface extents' error. So I'm sure the error lies there unless CS specify wrong coordinates.

And yes I've checked with ALT+P but I'll try to get the compile log asap.

Well just make sure all your triggers have only one texture on them basically. Else it can cause errors. (You usually want to use the AAA trigger anyway for triggers)
And what is the brush with the AAA trigger on it that's getting rendered... What's its function?

trigger_push, but now when you mention it... I think maybe all trigger_teleports aren't rendered. I can make a list:
1 func_buyzone isn't rendered
7 trigger_teleports aren't rendered
2 func_ladders aren't rendered

So you WANT the trigger teleport to be rendered?
If that's the case, then just make another brush and tie it to a func_illusionary. It won't cut vis at all, nor will it make any clipnodes, and you can see it, but you can walk right through it.

The teleport itself wont be rendered, but when you hit the illusionary you'll be teleported anyway.

No, that's now what I meant. The hl engine turns all functions and triggers invisible when you run a map. But in the bsp itself the functions and triggers are rendered. If the triggers/fucntions aren't rendered you will receive 'bad surface extents' error since they don't have a texture, they are completely white. And I want to find the reason why the triggers aren't rendered in the bsp which thereafter causes this error.

Ok, I've kept troubleshooting and I think I've come up with something. It's not the hlrad process that's screwed up it's the hlvis process. If I compile the map without hlrad, the objects which aren't rendered doesn't even exists if I skip hlrad. So I think the error lies in the '-fast' hlvis option. But I still hate compiling without the '-fast' command if I just want to test the map, does anyone have any solutions to that?

If you want to test the map with lighting, you're gonna have to run vis and rad. Just take off the -fast command, it wont be THAT bad.
Not as bad as -full, anyway.