Allocblock: full

PlaguebearerPlaguebearer Join Date: 2002-03-21 Member: 338Members, NS1 Playtester, Contributor
in Mapping Forum
<div class="IPBDescription">Grrrr</div>Anyone have a fix for this?
Off Topic Disagree Agree Awesome

Comments

  • PlaguebearerPlaguebearer Join Date: 2002-03-21 Member: 338Members, NS1 Playtester, Contributor
    Oh, well.  I guess not.  Another map in the trash, I guess.
    Off Topic Disagree Agree Awesome
  • realityisdeadrealityisdead Employed by Raven Software after making ns_nothing Join Date: 2002-01-26 Member: 94Members, NS1 Playtester, Contributor
    That was a rather hasty decision... there's no way you're going to trow away all that progress! I'm sure there's a solution somewhere... Even if it means removing "excess" map space.

    At any rate, don't scrap this! I was really looking forward to seeing your level take form and finish up.

    You've been doing a wonderful job, and I'd hate to see it all go.

    Best of luck to you either way though... do as you see fit. :/



    <!--EDIT|ken20banks|June 10 2002,00:55-->
    Off Topic Disagree Agree Awesome
  • FlayraFlayra Game Director, Unknown Worlds Entertainment San Francisco Join Date: 2002-01-22 Member: 3Super Administrators, NS2 Developer, Subnautica Developer
    I'm sure someone around here can help.  If not, you could try deleting some areas and trying to figure out which piece of the geometry is causing it (or deciding that it's a limit that's being hit).
    Off Topic Disagree Agree Awesome
  • WolvWolv Join Date: 2002-01-25 Member: 56Members
    From the <a href="http://forums.gamedesign.net/" target="_blank">Rust forum</a>:

    <!--QuoteBegin--Merl+June 10 2002,07:27--></span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td><b>Quote</b> (Merl @ June 10 2002,07:27)</td></tr><tr><td id="QUOTE"><!--QuoteEBegin-->The hard coded absoloute maximum is actually 1024. And whether its counter-strike or TFC or normal Half-Life is irrelevant,its still running the same engine core.

    Someone mentioned 900? well, they'd be wrong. There are maps with more than 900 entities (albeit bad maps, mind you ). But just beacause the maximum is 1024 does not mean you can place exacytly 1024 light entities in Worldcraft, or 1024 monster_hgrunts or whatever. You have to also take into account not only the temporary entities generated by the Half-Life engine itself in-game or miscellaneous effects and other crap like that (if you want a good example of the engine generating entities, see op4's env_rope "entity". Its only one point-based measly little thing in WC, but it eats up (2 * no. of rope segments) + 1 entities in game.), but also the memory of the computer system its running on. Theres just too many variables to state a definate maximum, but you'd probably want to start cutting back on entity usage when you hit around 800 or so.

    Thats where the allocblock:full error comes from, running out of memory when attempting to allocate blocks of memory for entities (to store their keyvalues and other miscellaneous crap they need).<!--QuoteEnd--></td></tr></table><span id='postcolor'><!--QuoteEEnd-->

    So basicaly it seems you've got too many entities.

    You can add -chart to any of the compile tools to keep track of exactly how many you're using.
    Off Topic Disagree Agree Awesome
  • nrbynrby Join Date: 2002-03-05 Member: 270Members
    allocblock:full
    A tough one 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 - 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.
    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.
    Off Topic Disagree Agree Awesome
  • nrbynrby Join Date: 2002-03-05 Member: 270Members
    "AllocBlock: full"

    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
    Off Topic Disagree Agree Awesome
  • PlaguebearerPlaguebearer Join Date: 2002-03-21 Member: 338Members, NS1 Playtester, Contributor
    It's not too many entities.  I have 25o-ish brush entities, and nowhere even resembling a thousand pointents (think more along the lines of 300).

    (These numbers are vague because I'm excluding sections of the map, compiling, failing to run, going back and excluding another section, etc.)

    I was excessively careful in the realm of texture scaling, because my last map died due to allocblock:full, and I suspected it was the texture issue, and this walked on eggs when it came to texture scaling this time.

    My layout is so packed, even if I do find a room that is a culprit, I don't know what I'll do to fix the layout.

    The only good thing is that, for the most part, each room was designed as a plug-in piece and set aside in Quark's tree as a stand alone object... so I should be able to build a new map out of these rooms.

    What frustrates me is that there's no single straight answer about what this bloody error means.
    Off Topic Disagree Agree Awesome
  • nrbynrby Join Date: 2002-03-05 Member: 270Members
    It means something has caused the memory to become full. You have too much of something
    Off Topic Disagree Agree Awesome
  • KilltoyKilltoy Join Date: 2002-03-28 Member: 358Members
    Could SHODAN be a solution here?
    Off Topic Disagree Agree Awesome
  • nrbynrby Join Date: 2002-03-05 Member: 270Members
    nothing to do with the compiler, its a problem in the map
    Off Topic Disagree Agree Awesome
  • RhoadsToNowhereRhoadsToNowhere i r 8 Join Date: 2002-01-24 Member: 33Members
    Most of the time when I've gotten allocblock:full, it's occured when I've actually tried to run the map.  Half-life crashes on map load, even though the map compiles perfectly.  So I doubt that SHODAN is gonna help at all.

    I've seen this error happen because of a leak in the map -- any faces outside of the map aren't able to be removed because of the leak, so Half-life winds up using more memory than it needs to for the map.  I doubt this is your problem but it has happened.
    Off Topic Disagree Agree Awesome
  • PlaguebearerPlaguebearer Join Date: 2002-03-21 Member: 338Members, NS1 Playtester, Contributor
    Yes, I've had that happen, too.  You're right, though, it's not the case this time: there's no leak.

    I've gone through the map with a chainsaw, and cut about a third of the rooms and probably half the halls out.  I'm about to compile this smaller version now, and hopefully it will be able to run in the engine...

    Wish me luck!
    Off Topic Disagree Agree Awesome
  • WolvWolv Join Date: 2002-01-25 Member: 56Members
    Good luck getting your map working.

    And some more tips:

    - Have you tried adding -chart to the hlrad command line yet? It can be a great tool for finding what exactly is nearing fulness (>90%).
    - Are you using the latest version of QuArK, wich supposedly helps fix slightly-off-grid-vertices? Maybe doing so will help you make a more optimized map.
    Off Topic Disagree Agree Awesome
  • PlaguebearerPlaguebearer Join Date: 2002-03-21 Member: 338Members, NS1 Playtester, Contributor
    I always -chart.  The only thing that was near full was clipnodes, at 95%...  As for Quark, I never manipulate vertices at a grid lower than 4, and I always snap them to grid afterwards just in case.  Yeah, I'm paranoid <!--emo&:)--><img src="http://www.natural-selection.org/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'><!--endemo-->
    Off Topic Disagree Agree Awesome
  • BiomechanoidBiomechanoid Join Date: 2002-02-12 Member: 203Members
    Off the wall suggestion: have you tried porting from quark to WC (or VHE)? This helped me solve a problem of having a perfectly square hall with a wierd invisible pole in the center that you would run into. I didn't put any brushes there, and I could not get rid of the pole, so I installed WC and tried to see if that would fix it. perhaps putting your map in WC and setting WC up to run the various zoner's tools could help you.  <!--emo&???--><img src="http://www.natural-selection.org/iB_html/non-cgi/emoticons/confused.gif" border="0" valign="absmiddle" alt='???'><!--endemo-->

    Wish I knew more how to help you
    Off Topic Disagree Agree Awesome
  • F4WNF4WN Join Date: 2002-04-01 Member: 372Members
    I searched around and found a few reasons why people got "Allocblock: full" errors.

    <!--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-->The error was due to a temporary innatention of my colleague who had not realized that HLRAD gave an error... Once this corrected error and rad started again successfully, any walk correctly.<!--QuoteEnd--></td></tr></table><span id='postcolor'><!--QuoteEEnd-->

    <!--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-->Warning: === LEAK in hull 0 ===
    Entity func_rotating @ (1248,-2096,-1102)<!--QuoteEnd--></td></tr></table><span id='postcolor'><!--QuoteEEnd-->

    <!--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-->Well it now works. It had to do with the number of patches. I scaled up textures by 3x which allowed me to lower the -chop value to 100. So I guess Half-Life doesn't like such a high chop value.<!--QuoteEnd--></td></tr></table><span id='postcolor'><!--QuoteEEnd-->

    My advice is to check HLRAD and make sure there aren't any errors or leaks. If there are no visable problems in the compile log, try scaling up the textures by three and changing the chop value to "-chop 100".
    Off Topic Disagree Agree Awesome
  • JasonBostwickJasonBostwick Blossom Join Date: 2002-04-14 Member: 444Members, NS1 Playtester
    Just an update for you guys, he deleted about a third and it successfully compiled. He has yet to bother running a full RAD, so it isn't quite screenshot worthy, although it still looks quite nice.
    I guess the information would be nice though, were he to retry making the full map work.
    Off Topic Disagree Agree Awesome
  • fadiz99fadiz99 Join Date: 2009-02-18 Member: 66466Members
    well i know that AllocBlock: full means that thers memory limit exceed some where and using - chart will help to determine it , but im confused with my compile logs :S since " lightdata 72.5% " under RAD log , its the only object high within others ,,,, is it possible lightdata is causing hl to crash while loading and alert AllocBlock !!! really im lost """ and if it does >> how do i have to reduce that " llightdata " ... im stuck here foe about a week trying to solve it :S .. my complie log dsnt contain any error and here's chart :

    ----- BEGIN hlcsg -----
    ...
    ..
    0 brushes (totalling 0 sides) discarded from clipping hulls
    CreateBrush:
    (0.31 seconds)
    SetModelCenters:
    (0.00 seconds)
    CSGBrush:
    (0.79 seconds)

    Object names Objects/Maxobjs Memory / Maxmem Fullness
    ------------ --------------- --------------- --------
    models 0/400 0/25600 ( 0.0%)
    planes 5670/32767 113400/655340 (17.3%)
    vertexes 0/65535 0/786420 ( 0.0%)
    nodes 0/32767 0/786408 ( 0.0%)
    texinfos 698/32767 27920/1310680 ( 2.1%)
    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/4194304 ( 0.0%)
    lightdata [variable] 0/4194304 ( 0.0%)
    visdata [variable] 0/2097152 ( 0.0%)
    entdata [variable] 0/524288 ( 0.0%)
    0 textures referenced
    === Total BSP file data space used: 141320 bytes ===

    ----- BEGIN hlbsp -----
    Command line: hlbsp -chart bau

    Current hlbsp Settings
    Name | Setting | Default
    -------------------|-----------|-------------------------
    threads [ 2 ] [ Varies ]
    verbose [ off ] [ off ]
    log [ on ] [ on ]
    developer [ 0 ] [ 0 ]
    chart [ on ] [ 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 'bau.prt'

    Object names Objects/Maxobjs Memory / Maxmem Fullness
    ------------ --------------- --------------- --------
    models 9/400 576/25600 ( 2.3%)
    planes 5670/32767 113400/655340 (17.3%)
    vertexes 9924/65535 119088/786420 (15.1%)
    nodes 1652/32767 39648/786408 ( 5.0%)
    texinfos 698/32767 27920/1310680 ( 2.1%)
    faces 7514/65535 150280/1310700 (11.5%)
    clipnodes 5062/32767 40496/262136 (15.4%)
    leaves 908/8192 25424/229376 (11.1%)
    marksurfaces 9061/65535 18122/131070 (13.8%)
    surfedges 34748/512000 138992/2048000 ( 6.8%)
    edges 17575/256000 70300/1024000 ( 6.9%)
    texdata [variable] 709656/4194304 (16.9%)
    lightdata [variable] 0/4194304 ( 0.0%)
    visdata [variable] 0/2097152 ( 0.0%)
    entdata [variable] 6164/524288 ( 1.2%)
    24 textures referenced
    === Total BSP file data space used: 1460066 bytes ===
    3.01 seconds elapsed

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

    ----- BEGIN hlvis -----
    Command line: hlvis -chart bau
    859 portalleafs
    2302 numportals

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

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


    BasePortalVis:
    (0.56 seconds)
    LeafThread:
    (10.08 seconds)
    average leafs visible: 122
    g_visdatasize:49503 compressed from 92772

    Object names Objects/Maxobjs Memory / Maxmem Fullness
    ------------ --------------- --------------- --------
    models 9/400 576/25600 ( 2.3%)
    planes 5670/32767 113400/655340 (17.3%)
    vertexes 9924/65535 119088/786420 (15.1%)
    nodes 1652/32767 39648/786408 ( 5.0%)
    texinfos 698/32767 27920/1310680 ( 2.1%)
    faces 7514/65535 150280/1310700 (11.5%)
    clipnodes 5062/32767 40496/262136 (15.4%)
    leaves 908/8192 25424/229376 (11.1%)
    marksurfaces 9061/65535 18122/131070 (13.8%)
    surfedges 34748/512000 138992/2048000 ( 6.8%)
    edges 17575/256000 70300/1024000 ( 6.9%)
    texdata [variable] 709656/4194304 (16.9%)
    lightdata [variable] 0/4194304 ( 0.0%)
    visdata [variable] 49503/2097152 ( 2.4%)
    entdata [variable] 6164/524288 ( 1.2%)
    24 textures referenced
    === Total BSP file data space used: 1509569 bytes ===
    10.76 seconds elapsed

    ----- END hlvis -----
    ----- BEGIN hlrad -----
    Command line: hlrad -chop 100 -chart bau

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

    vismatrix algorithm [ Original ] [ 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 [ 100.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 ]


    7514 faces
    Create Patches : 27044 base patches
    0 opaque faces
    444199 square feet [63964788.00 square inches]
    57 direct lights

    BuildFacelights:
    (19.95 seconds)
    visibility matrix : 43.6 megs
    BuildVisLeafs:
    (54.55 seconds)
    MakeScales:
    (27.03 seconds)
    SwapTransfers:
    (9.40 seconds)
    Transfer Lists : 53399130 : 53.40M transfers
    Indices : 13295848 : 12.68M bytes
    Data : 213596520 : 203.70M bytes
    GatherLight:
    (2.84 seconds)
    FinalLightFace:
    (1.75 seconds)

    Object names Objects/Maxobjs Memory / Maxmem Fullness
    ------------ --------------- --------------- --------
    models 9/400 576/25600 ( 2.3%)
    planes 5670/32767 113400/655340 (17.3%)
    vertexes 9924/65535 119088/786420 (15.1%)
    nodes 1652/32767 39648/786408 ( 5.0%)
    texinfos 698/32767 27920/1310680 ( 2.1%)
    faces 7514/65535 150280/1310700 (11.5%)
    clipnodes 5062/32767 40496/262136 (15.4%)
    leaves 908/8192 25424/229376 (11.1%)
    marksurfaces 9061/65535 18122/131070 (13.8%)
    surfedges 34748/512000 138992/2048000 ( 6.8%)
    edges 17575/256000 70300/1024000 ( 6.9%)
    texdata [variable] 709656/4194304 (16.9%)
    lightdata [variable] 3040752/4194304 (72.5%)
    visdata [variable] 49503/2097152 ( 2.4%)
    entdata [variable] 6164/524288 ( 1.2%)
    24 textures referenced
    === Total BSP file data space used: 4550321 bytes ===
    116.04 seconds elapsed [1m 56s]

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



    so ,anybody can help !?, atleast with a hint <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
    Off Topic Disagree Agree Awesome
  • Kouji_SanKouji_San Sr. Hινε Uρкεερεг - EUPT Deputy The Netherlands Join Date: 2003-05-13 Member: 16271Members, NS2 Playtester, Squad Five Blue
    Two things.

    1. I'm not sure, but it looks like you're not using "-sparse" on the rad compiler (this parameter will increase the max light data). However I fail to see how this would involve this hl crash, you're still far enough from the maximum.


    2. Are you using zhlt3.4 or perhaps even a previous version called zhl-p15? Older versions of the compile tend to make hl comit suicide when trying to run ns <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
    Off Topic Disagree Agree Awesome
  • pSyk0mAnpSyk0mAn Nerdish by Nature Germany Join Date: 2003-08-07 Member: 19166Members, NS2 Playtester, Squad Five Silver, NS2 Community Developer
    edited February 2009
    Don't bother with -sparse unless you are low on memory (unlikely) or exceed the max_patches limit (65k).

    Old compile tools is a good guess, but judging from some compile options available it's probably not the problem.

    Have you many/complex entities in your map or something in that direction?
    Maybe try to delete all entities adding only visual detail for a test-compile and -run and if it works then, you'll know at least the area causing the problem.

    Ninjaedit: TRY THIS FIRST:
    You are probably scaling down textures on some walls and this also effects lighting,
    so try hlrad -notexscale (you can see "texscale [on]" in your compile log at the moment)

    I just hope you don't use very low scales to achieve some crazy shadow effects via hlrad, which then will be screwed <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />


    (These insanely fast compile times make me sad, btw :/ ..screw my machine)
    Off Topic Disagree Agree Awesome
  • StixNStonzStixNStonz Join Date: 2006-11-06 Member: 58439Members, Reinforced - Shadow
    Get the batch compiler (or you might have it already). In HLFix, set the Epsilon value to very very small. It starts at 1 (if memory serves me), so set it to 0.0000001, then run HLFix.

    Bet you'll find dozens, if not hundreds, of tiny errors that are overfilling your budget.
    Off Topic Disagree Agree Awesome
Sign In or Register to comment.