Is any familiar with hlbsp errors?
Relic25
Pixel Punk Join Date: 2002-01-24 Member: 39Members, Retired Developer, NS1 Playtester, Contributor
Pixel Punk Join Date: 2002-01-24 Member: 39Members, Retired Developer, NS1 Playtester, Contributor
If this means what I think it means, I'm in deep s**t.
Error: Readsurfs_(Line 1): 19182 > g_numplanes
I can't for the life of me find a definition of g_numplanes anywhere on the net, but I have a bad feeling I know what it means. Can anyone verify?
Also, has anyone else had HLCSG perform an illegal operation consistently? I was getting this until I backed up and deleted a clip brush, then it started happening again after I <i>deleted</i> a couple of brush entities.
I'm going to bed now to have bad dreams. :/
<!--EDIT|Relic25|Feb. 18 2002,22:08-->
Error: Readsurfs_(Line 1): 19182 > g_numplanes
I can't for the life of me find a definition of g_numplanes anywhere on the net, but I have a bad feeling I know what it means. Can anyone verify?
Also, has anyone else had HLCSG perform an illegal operation consistently? I was getting this until I backed up and deleted a clip brush, then it started happening again after I <i>deleted</i> a couple of brush entities.
I'm going to bed now to have bad dreams. :/
<!--EDIT|Relic25|Feb. 18 2002,22:08-->
Comments
I don't like the sounds of that... Not positive, but I'm guessing it means the same thing as you are thinking... Half-Life wasn't meant for this. Flayra, maybe if you ask real nice, Valve will give us the TF2 engine early. <!--emo&;)--><img src="http://www.natural-selection.org/iB_html/non-cgi/emoticons/wink.gif" border="0" valign="absmiddle" alt=';)'><!--endemo-->
Best of luck relic. I really hope that doesn't mean what I think it does. But in all reality, I think the engine is a bit too outdated for all of this. Due to the engine's low poly limits I'm probably going to have to either scrap my own level and start over, or redo some major areas.
I don't think the engine can really handle what we all want to do with it. <!--emo&:(--><img src="http://www.natural-selection.org/iB_html/non-cgi/emoticons/sad.gif" border="0" valign="absmiddle" alt=':('><!--endemo-->
There is a "Readsurfs:xxxx >> numplanes"
It doesn't give any description, and the only thing it says to do about it is: "Recompile"
But this is "g_numplanes"
Possibly the zhlt version of numplanes?
I'm still trying to find some more info here. I do <i>not</i> want this to be happening.
I had this happen once before, using Merl's build on Win2k... HLCSG crashed every time I tried to use a custom .wad configuration. He recoded it, using me as a test subject, and it worked fine after that... I dunno where that .exe file went, though...
think it was about some very advanced brush use... like an error when it tried to slice up the brushes...
I have emailed Zoner about the error, as I couldn't find a single thing written about it either. I hope he can find it in his heart to reply.
A lot of the entities like func_door's, alien_grunt's, and explosions actually use up about 10 or so entities which contribute to your total, but visually they appear to take up one. That may explain why the limit on entities may seem lower than what it really is.
Relic,
This is probably a dumb question, but have you tried recompiling?
Btw, it's not a dumb question. It's always a good idea to try the "D*ick & Jane" stuff first. Sometimes it's easy to overlook such things. <!--emo&;)--><img src="http://www.natural-selection.org/iB_html/non-cgi/emoticons/wink.gif" border="0" valign="absmiddle" alt=';)'><!--endemo-->
*edit* hehe. The auto-censor seems unable to differentiate between names and obscenities.
<!--EDIT|Relic25|Feb. 19 2002,14:33-->
Hehe, alright... Have you used WC's "Check for Problems" feature? Maybe it's just a stupid texture warp or something... (I doubt it.)
As i know he had alot of problems when finalizing the up regime map for uncrossable parallel.
because of the limitations of the engine. <!--emo&:)--><img src="http://www.natural-selection.org/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'><!--endemo-->
1. Make aprox. seventy backup copies of ns_bast.rmf, .map, and .bsp. <!--emo&;)--><img src="http://www.natural-selection.org/iB_html/non-cgi/emoticons/wink.gif" border="0" valign="absmiddle" alt=';)'><!--endemo-->
2. Zoom all the way out in your top-down view in WC, and set your grid to 128.
3. Mentally divide the level (I'm assuming it takes up quite a bit of space on the grid) into 64 different sectors, clearly marked by the larger grid squares.
4. Completely wipe out or delete each sector one at a time, until you can compile again. (I would start near where you have been working most recently.)
5. If it works right away, take one of the backup copies, and delete a totally different sector far away from the previous one.
6. If it works now too, then I'm guessing you've met a certain engine limit.
Of course when deleting sectors, be sure to patch up the big gaping holes you left so you dont get leaks (duh! <!--emo&;)--><img src="http://www.natural-selection.org/iB_html/non-cgi/emoticons/wink.gif" border="0" valign="absmiddle" alt=';)'><!--endemo--> ).
It may be a lot of work but you should be able to narrow it down to the problem area this way.
After infinity's comment, and the fact that you are nowhere near the brush limit, my best guess is that it is just some simple problem with a complex brush or something. I hope so. I'm just afraid of what the compiler was doing.. the way taking some brushes out caused the error, as did adding some. This is supposed to be a <i>good</i> week for NS... not the week bast gets canned.
Best of luck again.
<!--c1--></span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td><b>Code Sample</b> </td></tr><tr><td id="CODE"><!--ec1-->
// upper design bounds
#define MAX_MAP_HULLS 4
// hard limit
#define MAX_MAP_MODELS 400
// variable, but 400 brush entities is very stressful on the engine and network code as it is
#define MAX_MAP_BRUSHES 8192
// arbitrary, but large numbers of brushes generally require more lightmap's than the compiler can handle
#define MAX_ENGINE_ENTITIES 1024
#define MAX_MAP_ENTITIES 2048
// hard limit, in actuallity it is too much, as temporary entities in the game plus static map entities can overflow
#define MAX_MAP_ENTSTRING (512*1024)
// abitrary, 512Kb of string data should be plenty even with TFC FGD's
#define MAX_MAP_PLANES 32767
// (from email): I have been building a rather complicated map, and using your latest
// tools (1.61) it seemed to compile fine. However, in game, the engine was dropping
// a lot of faces from almost every FUNC_WALL, and also caused a strange texture
// phenomenon in software mode (see attached screen shot). When I compiled with v1.41,
// I noticed that it hit the MAX_MAP_PLANES limit of 32k. After deleting some brushes
// I was able to bring the map under the limit, and all of the previous errors went away.
#define MAX_MAP_NODES 32767
// hard limit (negative short's are used as contents values)
#define MAX_MAP_CLIPNODES 32767
// hard limit (negative short's are used as contents values)
#define MAX_MAP_LEAFS 8192
// hard limit (halflife depends on it to setup pvs bits correctly)
#define MAX_MAP_VERTS 65535
#define MAX_MAP_FACES 65535
#define MAX_MAP_MARKSURFACES 65535
// hard limit (data structures store them as unsigned shorts)
#define MAX_MAP_TEXTURES 512
// hard limit (halflife limitation)
#define MAX_MAP_TEXINFO 32767
// hard limit (face.texinfo is signed short)
#define MAX_MAP_EDGES 256000
#define MAX_MAP_SURFEDGES 512000
// arbtirary
#define DEFAULT_MAX_MAP_MIPTEX 0x400000
// 4Mb of textures is enough especially considering the number of people playing the game
// still with voodoo1 and 2 class cards with limited local memory.
#define MAX_MAP_LIGHTING 0x400000
// arbitrary
#define MAX_MAP_VISIBILITY 0x200000
// arbitrary
// these are for entity key:value pairs
#define MAX_KEY 32
#define MAX_VALUE 4096
// quote from yahn: 'probably can raise these values if needed'
// texture size limit
#define MAX_TEXTURE_SIZE ((256 * 256 * sizeof(short) * 3) / 2)
// this is arbitrary, and needs space for the largest realistic texture plus
// room for its mipmaps.' This value is primarily used to catch damanged or invalid textures
// in a wad file
<!--c2--></td></tr></table><span id='postcolor'><!--ec2-->
Anyways, have you tried compiling with -chart and seeing what may be full (or almost full)?
That might shed some light on the problem.
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 0/400 0/25600 ( 0.0)
planes 404/32767 8080/655340 ( 1.2)
vertexes 0/65535 0/786420 ( 0.0)
nodes 0/32767 0/786408 ( 0.0)
texinfos 11658/32767 466320/1310680 (35.6)
faces 0/65535 0/1310700 ( 0.0)
clipnodes 0/32767 0/262136 ( 0.0)
leaves 0/8192 0/229376 ( 0.0)
marksurfaces 0/65535 0/131070 ( 0.0)
surfedges 0/512000 0/2048000 ( 0.0)
edges 0/256000 0/1024000 ( 0.0)
texdata [variable] 0/5242880 ( 0.0)
lightdata [variable] 0/4194304 ( 0.0)
visdata [variable] 0/2097152 ( 0.0)
entdata [variable] 0/524288 ( 0.0)
0 textures referenced
And possibly include them in a sequel, no? <!--emo&:)--><img src="http://www.natural-selection.org/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'><!--endemo-->
Sorry, Relic, but I have to agree with BadMofo here <!--emo&:)--><img src="http://www.natural-selection.org/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'><!--endemo-->
I'm not going to drop out detail, just eliminate a path or two that aren't needed (and that no one has seen screens of yet!<!--emo&;)--><img src="http://www.natural-selection.org/iB_html/non-cgi/emoticons/wink.gif" border="0" valign="absmiddle" alt=';)'><!--endemo-->.