My Maps Square Feet Keeps Changing
Coroner
Join Date: 2003-09-18 Member: 20994Members
Join Date: 2003-09-18 Member: 20994Members
<div class="IPBDescription">and I make no additions to its size</div> Last night (and now) im having trouble with an allocbloc:full error. I keep beating it down but it wont go away, it keeps comming back. To compile my map I have to remove my info_locations it seems, not sure how thats even related but anyways, I noticed something. When I compile my map and get the error, the map is 1,400,000 square feet. When it does not crash, it is 940,000 square feet. I tried some tests, and it changes between those two numbers with or without the info_locations. Now I know it may add or remove a few square feet between compiles due to things like rounding or a different calculation here and there, but that to me is a massive fluctuation. I know allocbloc:full is caused by alot of things and I know a big map is one of them. Any ideas why my square feet would jump so much? Also, it adds about 50 more minutes to my compile time when it makes the jump.
Comments
This error is a result with a custom map being made. Scaling textures up solves it.
The textures on every brush face in the map count, not just those that the player
will see once compiled, so scale textures up (to at least x10 y10) on as many brush
faces as possible. This is only good for the map creators, not players.
<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
In this case I would suggest nulling the faces. As for why your map is expanding randomly, I have no idea. I hope this helps, allockblock: full is a ****. Good luck!
To see if this helps fix the allockblock, try this, it's faster and will give you immediate feedback as to wether scaling textures up helps or not. Go to Edit > Select All, now open the texture editor. Change X to 10.00 and Y to 10.00. Save as: ns_mymap[10.00].rmf. If that does not resolve the error then try changing all textures to 1.00 (X) by 1.00 (Y). (Note that this will also solve "Bad Surface Extents" errors. BSE is caused by about the same thing as AllockBlock: Full. AllockBlock: Full means quite simply, you have run out of memory. BSE means a texture has been mangled to a very small scale. (I.E. 0.01 by 0.01)
You usually get AllockBlock when you have a large face with a texture scaled to 0.01 (or just low, many times it gets nowhere near 0.01 but anything low can mess the face up bad.) The reason is because the engine is trying to build leafs too small on that face... well wait, either leafs or patches... I don't know, can't remember. Basically the compiler is breaking up that wall a million times over. Though I believe this has to do with lighting so it shouldn't do that if it's on the outside of the world.
Oh well, I've rambled enough really, I presented a picture for you. Shows how texture scaling works with lighting.
~ DarkATi
Bad Surface Extents, MAX_LEAF_FACES, and AllockBlock: Full have very much in common, check your textures!
Pic 1: Normal Flashlight hitting a normal 1.00 scaled face.
Pic2: Face scaled to 10.0, flashlight upon it.
Pic 3: Face scaled to 0.10, f;ashlight on it, so small I had to put an arrow next to the small speck of light that is your flashlight.
(I've been in a picture makin' mood lately... <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->)
amckern
amckern <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
The extra area would be the surface area of the info_location brushes; the extra compile time is due to the fact that it's trying to light all of the surfaces in those info_locations even though they're not displayed in game (the compiler isn't smart enough to know what brush entities are and aren't visible; it lights everything unless the texture specifies otherwise).
The best solution is to use NULL on your info_location brushes--their faces will be removed before the lighting stage, and won't contribute to the surface area or the compile time. You should also make sure that your info_locations are about 8 units tall and shaped like simple rectangular prisms; the code only looks at the X and Y coordinates of the bounding box so any extra detail in the brushwork is ignored.
If you decide you want to keep the faces on the brushes (there's no reason to unless you want to use a BSP viewer some time in the future), use AAATrigger instead of a standard texture--RAD is hardcoded to skip that particular texture (along with liquid textures and sky) when it lights the level.
Then CSG will automatically texture all the entities that don't have rendering properties with NULL. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
what version of nems bc is this for? becuase i still use 1.14 - hate the lattest build's ui
amckern
Does 1.14 have the ability to append raw text to the command line? It wouldn't be supported otherwise since the nullfile switch is only 6 months old.
Nem's released a 2.0 spec file with P series support on <a href='http://countermap.counter-strike.net/Nemesis/index.php?p=4' target='_blank'>his site</a> (select the OptPlns link at the bottom of the page).
You'll also need ZHLT1.7p7 or later--not sure what version you're running.
I also run your 110 tools
amckern