Allocblock Error

crode · May 2003

Hey ive stumbled into a large problem

I recently added detail to an existing room and after compiling through fine, I recieve the allocblock error in NS. Now ive found out that the problem isnt the new parts I just added to the map. Now, if I hide ANY section of the map it works fine in NS. Is there some sort of maximum limit I have hit in terms of total brushes or maybe something to do with maximum open space of the map, or maximum breakables? I have not reached the limit in entites or textures, and I have checked the normal possible solution such as an entity with a bad names etc.

One thing I will be trying to fix now is I have 3 leaf portal saw into leaf errors. So far this hasnt caused any problems with compiling or playing the map previously. This might be related to the problem or maybe not. Any thoughts, experiences with this please speak up.

Crode

Heres the tail end of my last compile log. Also I must say that this has turned into a huge map

Texture usage is at 3.61 mb (of 4.00 mb MAX)

Warning: Leaf portals saw into leaf
Problem at portal between leaves 1404 and 1407:
(-992.000 1916.000 232.000)
(-992.000 1900.000 232.000)
(-992.000 1900.000 232.000)
(-984.000 1908.000 224.000)

Warning: Leaf portals saw into leaf
Problem at portal between leaves 1459 and 1477:
(-3585.333 3725.334 1880.000)
(-3584.000 3728.000 1881.600)
(-3552.000 3728.000 1920.000)
(-3552.000 3360.000 1920.000)
(-3585.333 3433.333 1880.000)

Warning: Leaf portals saw into leaf
Problem at portal between leaves 1647 and 1646:
(-3264.000 3472.000 1868.000)
(-3168.000 3216.000 1868.000)
(-3168.001 3215.999 1868.002)
(-3113.456 3270.544 1793.003)
(-3186.101 3472.000 1790.101)

average leafs visible: 217
g_visdatasize:200722 compressed from 1445000

Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 206/400 13184/25600 (51.5%)
planes 38870/65535 777400/1310700 (59.3%)
vertexes 27810/65535 333720/786420 (42.4%)
nodes 11094/32767 266256/786408 (33.9%)
texinfos 7791/32767 311640/1310680 (23.8%)
faces 18239/65535 364780/1310700 (27.8%)
clipnodes 23841/32767 190728/262136 (72.8%)
leaves 7183/8192 201124/229376 (87.7%)
marksurfaces 24984/65535 49968/131070 (38.1%)
surfedges 86286/512000 345144/2048000 (16.9%)
edges 46992/256000 187968/1024000 (18.4%)
texdata [variable] 3128/4194304 ( 0.1%)
lightdata [variable] 0/6291456 ( 0.0%)
visdata [variable] 200722/2097152 ( 9.6%)
entdata [variable] 47014/524288 ( 9.0%)
71 textures referenced
=== Total BSP file data space used: 3292776 bytes ===
6115.83 seconds elapsed [1h 41m 55s]

amckern · May 2003

ok

step 1
click link in sig

step 2
make your info_loction brushes smaller, much smaller, or remove ones that have no effect on the loction - though -
keep hive brushes
keep the marine spawn brush

i got this error in edan, and found the only way to fix it was to reomve some info_loctions

amckern

crode · May 2003

heh funny thing is, i have 0 info_locations in my map as of yet. Cagey thinks the saw though leaf might be the most likely problem, ill work on it tomorrow. Long day today

Lextalionis · June 2003

I've encountered a similar problem (perhaps the same) in attempting to run my map. Like yours, it's big, taking up the entire y-axis and most of the x. Like yours, it compiles fine and is well under individual resource limits. And like yours, it causes an "alloc block: full" error when run in NS.

I've spent the last week or so trying out various fixes suggested by community guides, and eventually turned to trial and error in hopes of solving this. Here's what I know:

1.) Hiding any sizeable part of the map circumvents the error.

2.) Removing all but NS-required entities also avoids the error.

3.) No individual entity appears to be causing the error.

4.) I have a lot of surface area. HLRAD gave me a MAX_PATCHES error when testing out a theory for the error.

5.) The error appeared after adding a new moderately detailed area to the map.

6.) My compile log is in the next post, clean as a whistle.

7.) To my knowledge, there are no bad entity names (though I've had trouble tracking down the naming conventions).

8.) No particle systems or breakables, so some overflow of that kind can't be the solution.

9.) It runs in software mode, but not OpenGL.

10.) I started using XP-Cagey's optimizer and Merl's 1.7 build of the compile tools in hopes it would help resolve the situation, but that turned up little more than the knowledge that they're really cool.

I can supply more information, but I'm not sure what else to add. If somebody'd like to take a look at the rmf itself, let me know.

It seems "Alloc Block: full" errors are largely a mystery to the mapping community, but if anyone has any advice, suggestions, theories, questions, or input, I'd really appreciate it. I'd hate to see all my hard work wasted. And if this doesn't get resolved, Crode, at least know you're not alone in this.

I hope we figure this out,

Lextalionis

Lextalionis · June 2003

Here's the compile log. I almost wish there was an error...

hlcsg v2.5.3 rel Custom Build 1.7p10 (May 8 2003)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (webmaster@xp-cagey.com)
----- BEGIN hlcsg -----
Command line: C:\PROGRA~1\VALVEH~1\TOOLS\HLCSG.EXE c:\PROGRA~1\VALVEH~1\TOOLS\CARGO4
Entering c:\PROGRA~1\VALVEH~1\TOOLS\CARGO4.map

Current hlcsg Settings
Name | Setting | Default
---------------------|-----------|-------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
priority [ Normal ] [ Normal ]

noclip [ off ] [ off ]
null texture stripping[ on ] [ on ]
clipnode economy mode [ on ] [ on ]
clip hull type [ legacy ] [ legacy ]
onlyents [ off ] [ off ]
wadtextures [ on ] [ on ]
skyclip [ on ] [ on ]
hullfile [ None ] [ None ]
nullfile [ None ] [ None ]
min surface area [ 0.500 ] [ 0.500 ]
brush union threshold [ 0.000 ] [ 0.000 ]

Using mapfile wad configuration
Wadinclude list :
[zhlt.wad]

0 brushes (totalling 0 sides) discarded from clipping hulls
CreateBrush:
(23.40 seconds)
SetModelCenters:
(0.00 seconds)
CSGBrush:
(24.33 seconds)

Using Wadfile: \sierra\half-life\valve\halflife.wad
- Contains 12 used textures, 29.27 percent of map (3116 textures in wad)
Using Wadfile: \sierra\half-life\ns\ns.wad
- Contains 29 used textures, 70.73 percent of map (578 textures in wad)

added 7 additional animating textures.
Texture usage is at 1.85 mb (of 4.00 mb MAX)
50.20 seconds elapsed

----- END hlcsg -----

hlbsp v2.5.3 rel Custom Build 1.7p10 (May 8 2003)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (webmaster@xp-cagey.com)
----- BEGIN hlbsp -----
Command line: C:\PROGRA~1\VALVEH~1\TOOLS\HLBSP.EXE c:\PROGRA~1\VALVEH~1\TOOLS\CARGO4

Current hlbsp Settings
Name | Setting | Default
-------------------|-----------|-------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
priority [ Normal ] [ Normal ]

noclip [ off ] [ off ]
nofill [ off ] [ off ]
null tex. stripping [ on ] [ on ]
notjunc [ off ] [ off ]
subdivide size [ 240 ] [ 240 ] (Min 64) (Max 512)
max node size [ 1024 ] [ 1024 ] (Min 64) (Max 4096)

BSP generation successful, writing portal file 'c:\PROGRA~1\VALVEH~1\TOOLS\CARGO4.prt'
40.92 seconds elapsed

----- END hlbsp -----

hlvis v2.5.3 rel Custom Build 1.7p10 (May 8 2003)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (webmaster@xp-cagey.com)
----- BEGIN hlvis -----
Command line: C:\PROGRA~1\VALVEH~1\TOOLS\HLVIS.EXE c:\PROGRA~1\VALVEH~1\TOOLS\CARGO4 -full
2205 portalleafs
6063 numportals

-= Current hlvis Settings =-
Name | Setting | Default
-------------------|-----------|-------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
max vis distance [ 0 ] [ 0 ]
priority [ Normal ] [ Normal ]

fast vis [ off ] [ off ]
full vis [ on ] [ off ]

BasePortalVis:
(74.86 seconds)
LeafThread:
(388.16 seconds)
average leafs visible: 124
g_visdatasize:82121 compressed from 608580
463.79 seconds elapsed [7m 43s]

----- END hlvis -----

hlrad v2.5.3 rel Custom Build 1.7p10 (May 8 2003)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (webmaster@xp-cagey.com)
----- BEGIN hlrad -----
Command line: C:\PROGRA~1\VALVEH~1\TOOLS\HLRAD.EXE c:\PROGRA~1\VALVEH~1\TOOLS\CARGO4 -sparse -chop 128

-= Current hlrad Settings =-
Name | Setting | Default
--------------------|---------------------|-------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
priority [ Normal ] [ Normal ]

vismatrix algorithm [ Sparse ] [ Original ]
oversampling (-extra)[ off ] [ off ]
bounces [ 1 ] [ 1 ]
ambient light [ 0.000 0.000 0.000 ] [ 0.000 0.000 0.000 ]
maximum light [ 255.000 ] [ 256.000 ]
circus mode [ off ] [ off ]

smoothing threshold [ 50.000 ] [ 50.000 ]
direct threshold [ 25.000 ] [ 25.000 ]
direct light scale [ 2.000 ] [ 2.000 ]
coring threshold [ 1.000 ] [ 1.000 ]
patch interpolation [ on ] [ on ]

texscale [ on ] [ on ]
patch subdividing [ on ] [ on ]
chop value [ 128.000 ] [ 64.000 ]
texchop value [ 32.000 ] [ 32.000 ]

global fade [ 1.000 ] [ 1.000 ]
global falloff [ 2 ] [ 2 ]
global light scale [ 1.000 1.000 1.000 ] [ 1.000 1.000 1.000 ]
global gamma [ 0.500 0.500 0.500 ] [ 0.500 0.500 0.500 ]
global light scale [ 1.000 ] [ 1.000 ]
global sky diffusion [ 1.000 ] [ 1.000 ]

opaque entities [ on ] [ on ]
sky lighting fix [ on ] [ on ]
incremental [ off ] [ off ]
dump [ off ] [ off ]

colour jitter [ 0.0 0.0 0.0 ] [ 0.0 0.0 0.0 ]
monochromatic jitter [ 0.0 0.0 0.0 ] [ 0.0 0.0 0.0 ]
softlight hack [ 0.0 0.0 0.0 0.0 ] [ 0.0 0.0 0.0 0.0 ]
diffuse hack [ on ] [ on ]
spotlight points [ on ] [ on ]

custom shadows with bounce light
[ off ] [ off ]
rgb transfers [ off ] [ off ]

[Reading texlights from 'c:\PROGRA~1\VALVEH~1\TOOLS\lights.rad']
[1 texlights parsed from 'c:\PROGRA~1\VALVEH~1\TOOLS\lights.rad']

11957 faces
Create Patches : 35910 base patches
0 opaque faces
1208602 square feet [174038784.00 square inches]
18 direct lights

BuildFacelights:
(333.57 seconds)
BuildVisLeafs:
(161.97 seconds)
visibility matrix : 7.2 megs
MakeScales:
(402.66 seconds)
SwapTransfers:
(13.46 seconds)
Transfer Lists : 16551402 : 16.55M transfers
Indices : 11565264 : 11.03M bytes
Data : 66205608 : 63.14M bytes
GatherLight:
(3.46 seconds)
FinalLightFace:
(9.01 seconds)
928.02 seconds elapsed [15m 28s]

----- END hlrad -----

devilblocks · June 2003

This is the worst error you can ever get. It basically equates to "general protection fault" crap and means you ran out of memory somewhere at a non-specific part of the map. You can be well under all your limits and have solid brushwork and still get it. You're only real solution is a bunch of guess work and working backwards to simplify / remove whatever you added since your last working compile.

quazilin · June 2003

I don´t quite remember but I think I had the same problem about 6 months ago. Well here is some info about it hope it helps.

"allocblock:full
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. "

Credits to Tommy 14

devilblocks · June 2003

With a bit of forum searching, KFS was doing some experimenting a bit back and it seems that NS has this problem a bit more often than say your standard HL map, specifically, the NS ents. Try shrinking down your loc ents (making them smaller in the Z axis, as that seemed to work for KFS in 1 build.

crode · June 2003

Hey all thanks for the replies. I solved the error earlier this week. It wasnt entity related, it was because i hit some sort of limit on total maximum viewable textured faces. I solved the error by stretching a few textures out where it covered some large ceilings. Here is what I posted under Cageys webbed thread. btw I havnt heard from Cagey about this yet <img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'>

Cagey, i need to talk to you soon. Im still dealing with this allocblock full issue. From what i can tell its from either having over 4000 brushes, too many func_illusionary brushes or something similar to this

please find me soon. Ill be on gamesnet irc #clan-cis or #nsmapping

UPDATE
Ive narrowed it down to this:
If I texture a few more brushes I get the allocblock:full error (been confirmed on another PC)
If I null a few brushes I dont get the error

This leads me to believe there is a cap on the viewable textured faces in the map. I would like to solve this without deleting a bunch of area. Ive worked on this map for 6 months now it would be a real shame to hack parts away.

devilblocks · June 2003

One thing you could consider doing is hacking away at your Ready Room if you don't want to sacrifice more of your map.

OneEyed · June 2003

Guys alloc block error means that you have to many MAX PATCHES, the textures you are using are WAY Beyond small and you surpass the 65335 limit, or whatever, anyways, to fix this, any texture you do not see inside your map try to increase it to a size of y5 x5 on the scale, and try not to go under .3 on the scale!

devilblocks · June 2003

^^ No it doesn't. It just means you ran out of memory somewhere.

OneEyed · June 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (devilblocks @ Jun 9 2003, 06:30 PM)</td></tr><tr><td id='QUOTE'> ^^ No it doesn't. It just means you ran out of memory somewhere.  </td></tr></table><span class='postcolor'> 
trust me i am right, i did everything possible to make it compile and work without retexturizing, i changed my swap file to a VERY large size, i use the -sparse command, messed with my virtual memory, even had it compiled by another computer thats almost like a super computer, its nothing of the compiler its the texture sizes, he has gone way over 65335 seeing as how his map is the entire x/y/z axis... unless he readjusts his textures to be bigger he will never see his map ingame, i use to make concmaps, for tfc, and they are very huge, i had this problem occassionally, and spent 1 full day finding the answer, and i did. <-period

crode · June 2003

if we had exceeded the max patches the compile tools would have said something. and in these cases it doesnt.
It is related to the scale and # of textured faces, why isnt there a status line for this?

OneEyed · June 2003

max patches means the same thing almost, just rescale ur textures to a good size and when you compile make sure where it says "Create Patches : xxx Patches" that it doesnt exceed 65335, if it does, ur textures are too small and too many, the -sparse is suppose to fix that, but it doesnt.

devilblocks · June 2003

Look OneEye, just because you ran out of memory at point A and did B to fix it, doesn't mean it will be the same for anyone else. That's like saying "Well I fixed my General Protection Fault by doing this so that's what it is" Ask Valve if you don't believe me. Allocbloc error is a generic statement saying you ran out of memory SOMEWHERE it is NOT specific AT ALL. KFS solved his by shrinking some info entities, I've had some disappear by moving a room. Maxpatches can be fixed (which is entirely different) by upping your chop.

OneEyed · June 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (devilblocks @ Jun 9 2003, 09:03 PM)</td></tr><tr><td id='QUOTE'> KFS solved his by shrinking some info entities </td></tr></table><span class='postcolor'>
if ur using a brush based entity and you have it textured with, null, sky, aaatrigger, whatever, just because its solid doesnt mean it dont uses patches, its the same error, always, =p , i always always made the size of my null, skys and aaatrigger or whatever thats invisible to 6x 6y, it decreases the patches by far, and also cuts compiling time by more than half.

there is even a link to prove ur butt wrong.. ill get it in a sec.

crode · June 2003

ok this specific cause of the allockblock error has nothing to do with any entity.

Now, at what point does it work out the patches. durring RAD? Beucase if i do csg and bsp, there still was that error

Shadowics · June 2003

Yes crode, it doesn't calculate the patches until the rad. If you get that error during the csg/bsp it's probably because your map's too big. Looking at the log you posted you're only up to 60% on the planes and 28% faces, so it's probably only medium size. But you're up to 73% clipnodes and 88% leaves so I'm guessing you've got a lot of details. You said in a previous post you have over 4000 brushes. How much over? There's a hard limit in the HL engine of 4096 brushes. That could be the problem.

CoolCookieCooks · June 2003

when i did the -sparse thing it stopped my lighting from working so it was really bright and when i looked around it crashed in the first 5 seconds <img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'>

Allocblock Error

Comments