If You've Had Allocblock:full...
KungFuSquirrel
Basher of Muttons Join Date: 2002-01-26 Member: 103Members, NS1 Playtester, Contributor
Basher of Muttons Join Date: 2002-01-26 Member: 103Members, NS1 Playtester, Contributor
<div class="IPBDescription">I need your help</div> I'm doing some testing on a possible cause for allocblock:full specific to NS maps - It's a general error, but I believe that I've found a slight correlation on one possible cause that <i>might</i> make it more common in NS mapping. Consider this an offer to help you fix the problem if you don't like the sound of donating a map to 'research.' <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
PM me or e-mail me (aweldon@planethalflife.com) if you think you can help. I'll be testing some on my own maps (old versions of Eclipse, in particular), but I'll need more info than just that to come to any conclusions.
PM me or e-mail me (aweldon@planethalflife.com) if you think you can help. I'll be testing some on my own maps (old versions of Eclipse, in particular), but I'll need more info than just that to come to any conclusions.
Comments
cost me 2 days to find and fix that.
whenever you get allocblockfull and dont know why, delete some ns_specific entity groups.
I've asked Flay to make info_locations z-axis independent in 1.1, but I'd like to get some more information on this before then. It also appears that there can be some notable .bsp file size reductions with smaller info_location entities (i.e. only 32 units high or something as opposed to 512 or 768+ depending on level layout and size).
First test subject, old build of Eclipse 1.0. I was correct in assuming that it would encounter allocblock:full unchanged. This served as test 1, ns_eclipse_alloctest. ns_eclipse_alloctest2 was an identical version of the map with all info_locations resized to be 32 units tall and placed at ground level of the respective areas (or approximately, in the case of locations with multiple elevations).
ns_eclipse_alloctest failed to load due to allocblock:full. This was expected, and normal. File size was 6,114 kb.
ns_eclipse_alloctest2 loaded perfectly. This was also expected. File size was 5,153 kb, almost an entire megabyte smaller than the first test. This was expected, but <b>not</b> to this extent.
Flayra has told me that he'll get info_locations to be Z-axis independent ASAP in time for 1.1. I would imagine if other official maps are adjusted accordingly that we could see up to 6-7 megs of space optimized, depending on other factors such as textures, entity reduction, additions, etc. I should also note that there was no adverse effect on plane counts in making these adjustments (as the info_locations no longer lined up with each other): the count was equal in both bsps. I plan on further reducing the height of the info_locations to 8 units in Eclipse 1.1, and I would recommend this size as the optimal compromise between small size and ease of manipulation.
ns_eclipse_alloctest:
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 248/400 15872/25600 (62.0%)
planes 18820/32767 376400/655340 (57.4%)
<span style='color:red'>vertexes 21800/65535 261600/786420 (33.3%)</span>
nodes 8692/32767 208608/786408 (26.5%)
texinfos 4181/32767 167240/1310680 (12.8%)
<span style='color:red'>faces 15952/65535 319040/1310700 (24.3%)</span>
clipnodes 23692/32767 189536/262136 (72.3%)
leaves 5091/8192 142548/229376 (62.1%)
<span style='color:red'>marksurfaces 20456/65535 40912/131070 (31.2%)</span>
surfedges 71169/512000 284676/2048000 (13.9%)
<span style='color:red'>edges 37989/256000 151956/1024000 (14.8%)</span>
texdata [variable] 1010016/4194304 (24.1%)
<span style='color:red'>lightdata [variable] 2971869/4194304 (70.9%)</span>
visdata [variable] 65347/2097152 ( 3.1%)
entdata [variable] 54288/524288 (10.4%)
105 textures referenced
<span style='color:red'>=== Total BSP file data space used: 6259908 bytes ===</span>
1496.68 seconds elapsed [24m 56s]<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
ns_eclipse_alloctest2:
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 248/400 15872/25600 (62.0%)
planes 18820/32767 376400/655340 (57.4%)
<span style='color:red'>vertexes 20406/65535 244872/786420 (31.1%)</span>
nodes 8692/32767 208608/786408 (26.5%)
texinfos 4179/32767 167160/1310680 (12.8%)
<span style='color:red'>faces 14575/65535 291500/1310700 (22.2%)</span>
clipnodes 23692/32767 189536/262136 (72.3%)
leaves 5091/8192 142548/229376 (62.1%)
<span style='color:red'>marksurfaces 19079/65535 38158/131070 (29.1%)</span>
surfedges 65627/512000 262508/2048000 (12.8%)
<span style='color:red'>edges 35218/256000 140872/1024000 (13.8%)</span>
texdata [variable] 1010016/4194304 (24.1%)
<span style='color:red'>lightdata [variable] 2068740/4194304 (49.3%)</span>
visdata [variable] 65347/2097152 ( 3.1%)
entdata [variable] 54288/524288 (10.4%)
105 textures referenced
<span style='color:red'>=== Total BSP file data space used: 5276425 bytes ===</span>
860.02 seconds elapsed [14m 20s]<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
The lightdata is a result of erroneous judgement on my part - texturing info_locations with aaatrigger instead of null. Upon talking to Merkaba and seeing these results, that should be a flat-out given that all info_locations be null textured. Most other differences are rather negligible, save for file size.
With the revised changes, you won't have to touch the info_location brushes; you'll just need to be within their x/y coordinates.
a further thought: the info location is usually a block brush of aaatrigger texture.
i have heard stories of scaling/stretching aaatrigger texture (& SKY & {invisible texture) 4x helps reduce allocblock also, i can't see why, but if you want to test it to see if it has any effect also, feel free.
2 questions from this.
1)Does the seethrough texture have any special properties?
2)Should I use the null texture instead?
[EDIT] and on a side note, at one point I had Allocblock:full with hydrosity and I got rid of it by deleting my info_locations
info_locations huh.. Good Job
BTW, while we are on the subject of obscure compile errors, I got MAX_SWITCHED_LIGHTS on hydrosity once and this was with no dynamic lights in the map at all. After a bit of digging I discovered it is a commonish Q3 engine compile error which is caused by dynamic lights in the level (which the Q3 engine can't handle).
But in my case it was caused by <i>the env_custom_particles entity</i> . I managed to fix it by deleting the names of all the env_custom_particles that weren't triggered by anything.
Sounds like something that could easily be done at the tool level, too. My next release of HLCSG will have a config file that contains a list of entity names and target names... if the targetname or classname of an entity is matched to the appropriate section, I'll automatically substitute the null texture for every face on the brush so that the mapper can use whatever texture they want in the editor but still get the benefit of the null texturing in the final map... this will be on a switch.
Initial default classname list to convert (full listing of invisible vanilla HL ents are included as well as NS):
env_bubbles
func_ladder
func_monsterclip
func_mortarfield
trigger_autosave
trigger_cdaudio
trigger_changelevel
trigger_endsection
trigger_gravity
trigger_hurt
trigger_monsterjump
trigger_multiple
trigger_once
trigger_push
trigger_teleport
trigger_transition
-----
func_nobuild
info_join_autoassign
info_join_team
info_location
info_spectate
trigger_presence
If you spot an invisible entity I'm missing or if I've got an entity in there that doesn't belong, let me know. The targetname check would allow things like using a func_illusionary to define the area for an env_custom_particles and have its faces stripped by the tools when its name is matched.
I'll also read from a file named after the map being compiled if you want to customize this on a per-map basis.
EDIT: forgot two of the most common triggers... doh.
ns_eclipse_alloctest:
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->
<snip>
<span style='color:red'>lightdata [variable] 2971869/4194304 (70.9%)
</span><snip>
1496.68 seconds elapsed [24m 56s]<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
ns_eclipse_alloctest2:
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->
<snip>
<span style='color:red'>lightdata [variable] 2068740/4194304 (49.3%)</span>
<snip>
860.02 seconds elapsed [14m 20s]<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--><!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
saved yourself a lot of time by not calculating transfer lists on invisible patches, too...
Did you not notice the fact that we've confirmed one likely cause of it in relation to NS mapping? :X I have no doubt that this is what causes the error to be more common than it should be in regards to NS mapping.
Actually, Cagey, don't implement this part. I can see situations where a func_illusionary might be intended to be visible and be a particle generation source. I'm creating some holographic effects for a computer AI lab, and to save on entities I'm using visible sources create particles.
Focus on the entities that will never ever be visible, specifically the ones with no rendering properties built in.
Focus on the entities that will never ever be visible, specifically the ones with no rendering properties built in. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Actually, that's why I'm allowing exclusion by targetname as well as classname -- by default items like func_illusionary aren't changed... if you specifically add the targetname of the func_illusionary to the file, it will be converted--nothing is going to be hardcoded, so the mapper will have complete control over the effect.
In the particle system example, if the func_illusionary was named "particle2_origin" and the mapper added "particle2_origin" to the list of strings in the input file, it would be converted--otherwise, it would remain untouched. I'm not doing any detection of entity relationships for decision making--as you noted entity relationships alone often don't provide enough information. If a mapper wanted to convert every func_illusionary (not sure why you'd want to do this, but for the sake of illustration humor me <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->), the classname could be used instead of all of the targetnames.
I've actually decided to make this option something that uses a file based switch (-nullify <filename>) rather than using a standard config file because the tools already have two areas to specify information (command line and map entity) and it'd be asking a lot to add a third place for users to check. The file format is simply a newline delimited list of strings that are matched against classname and targetname fields of entities.
I wrote the addition last night--it was a pretty simple item to implement. I'm testing it to make sure it's not causing any unforseen problems, and I'll be releasing it later in the week, possibly with some other CSG enhancements.
I have had a few allocblock:full encounters, so far always when there was a leak to fix. For me switching to software mode allowed the map to load, just so I could look at the pointfile.
STICKY PLEASE, report it to a mod.