Allocblock: Full

Lord_Requiem

<div class="IPBDescription">I've seen it before, but not like this:</div> No explanation this time. The log complete with -chart (as I always do) has no indicator what could be the cause. The compile last night (2nd to last one before beta, at least I had planned it that way) to finalize the lighting, ran perfectly and completed in the usual 6 hoursish time limit, but the bsp won't load because of the allocblock: full error once you start it up.

Anyone have any tips on this, I've run into this error a few times in the past but I always knew where to look to find fixes. Not this time since my usual fixes are already fixed.

Plane count is fine (about 95 percent) and I run rad with "-extra -smooth 80 -sparse -texdata 12298" every time.

Lord_Requiem

Whats the limit of pathnames, and does it only affect corner_paths?

Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 0/400 0/25600 ( 0.0)
planes 31756/32767 635120/655340 (96.9)
vertexes 0/65535 0/786420 ( 0.0)
nodes 0/32767 0/786408 ( 0.0)
texinfos 4144/32767 165760/1310680 (12.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/12593152 ( 0.0)
lightdata [variable] 0/4194304 ( 0.0)
visdata [variable] 0/2097152 ( 0.0)
entdata [variable] 0/524288 ( 0.0)

humb1ed

obviously the more planes and clipnodes you have the closer you will be to an allocblock full error, but as long as you keep them under 100% you can still compile fine, these % are from cilrais_1229...
planes 32294/32767 645880/655340 (98.6)
clipnodes 32676/32767 261408/262136 (99.7)

KungFuSquirrel

Eclipse hit allocblock:full 3 times in development despite never reaching more than 70% of any given limit. One of the times the culprit was an info_location I had resized by about 8 units. I only discovered that randomly after I shredded area after area. :X Good luck. D:

Lord_Requiem

Babs: Yes it is, but i think the -chart is screwing up. I'm fairly certain I have more than 1 brush entity too. ^ _ ^

RhoadsToNowhere

Well, if you take the chart from after running HLCSG, only planes and texinfos can be calculated, since the compiler hasn't gotten around to calculating anything else. <!--emo&:0--><img src='http://www.unknownworlds.com/forums/html/emoticons/wow.gif' border='0' valign='absmiddle' alt='wow.gif'><!--endemo-->

Lord_Requiem

ahh so to get a complete chart I have to -chart hlrad?

tommy14

<b>allocblock:full</b>

A tough one to figure out, vague error that usually shows up when you start the game or during compile, or even when WC/Hammer starts up - you have gone over the memory limit somewhere for some reason. It can be too little RAM (128M is about minimum), a leaf saw into leaf error, too long pathnames, too many textures, too big a level, too big or too many model/sprites, too big a wav sound file - or it could be that old "too many wads" mistake, a huge "noob" brush around the map to prevent leaks, too many SKY faces on hidden brush faces in the level - or even something else.
If it happens during compile, do not use WC/Hammer to "run" the map, but use a front end or batch file to compile with. You could also get more RAM.

<i>(The following may still be handy, however be aware that Software mode allocates memory dynamicly, so it may automaticly seem to "fix" any error. Therefore the following info MAY lead you into a dead end:
Some brush-based entities have rendering properties that, when they interact in OpenGL/D3D video cards, they crash. Switch Half-Life to Software mode first, then load the map. If it loads you now know it is something that is handle different in software, then for Opengl/d3d check water, glows, additive, sprites, transparencies (illusionaries, windows, ect.), env_beams and so on.)</i>

If it happens in opening a level in WC, it may be you have an animating model showing in one view. You must switch to single view instead of multiple, and try different ones until you get past it.

Lord_Requiem

BSP Chart, I havent run rad so no chart for it yet.


Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 250/400 16000/25600 (62.5)
planes 32234/32767 644680/655340 (98.4)
vertexes 31156/65535 373872/786420 (47.5)
nodes 10147/32767 243528/786408 (31.0)
texinfos 4303/32767 172120/1310680 (13.1)
faces 22615/65535 452300/1310700 (34.5)
clipnodes 26856/32767 214848/262136 (82.0)
leaves 6811/8192 190708/229376 (83.1)
marksurfaces 26528/65535 53056/131070 (40.5)
surfedges 106092/512000 424368/2048000 (20.7)
edges 54362/256000 217448/1024000 (21.2)
texdata [variable] 13512/12593152 ( 0.1)
lightdata [variable] 0/4194304 ( 0.0)
visdata [variable] 0/2097152 ( 0.0)
entdata [variable] 44317/524288 ( 8.5)
307 textures referenced
=== Total BSP file data space used: 3060757 bytes ===
59.27 seconds elapsed

Lord_Requiem

Oh and I have 768mb of ram, and I ALWAYS use a front end batch file for compiling.

Lord_Requiem

No it was fine at 99.5 planes before i trimmed a few things down and added a few other things, it has to be something else.

evoLvingeviL

As KFS said, something as trivial as an 8-unit stretch can bring up an error. After all, not only is the HL engine old and obselete, its also very 'quirky'.

I once kept getting a leak error that had me slicing and dicing a map, only to discover that a 8x8x16 brush stuck in one corner fixed it (and it didn't cover a leak, I know, its strange!)

Killer_Chalupa1

Sorry to get WAY off topic, but how do you resize an entity like info_location? I'm a super n00b mapper that has never actually finished anything

Lord_Requiem

Its a brush entity. You create a block or wedge or whatever and entity that into an info_location.

Yamazaki

Sometimes you'll get leaks through the seams of solid brushes, just because the compile's floating point calculations were off by just enough that the seam became wide enough for a leak. In these cases you have to elongate the back ends of the brushes so that the two brushes touch at more than one vertex, just to slap CSG/BSP up the side of the head and wake them up. Or slip an extra brush in as filler.

And I've only encountered allocblock:full once, that was when trying to play a huge map that had not been properly VIS/RAD'ed, so that doesn't count.