memory allocation problem

Alright, I am having a hard time figureing out what this out of memory error is all about, i have no leafs cutting into anything and i just defraged mh HD and i have plenty of space. The only thing left is ram and i have 128mb and never have I had a problem with it. It seems to run fine until it gets to make scales. Here is the compiler notes:

** Executing...
** Command: Change Directory
** Parameters: C:\SIERRA\Half-Life

** Executing...
** Command: Copy File
** Parameters: "C:\SIERRA\Half-Life\valve\op4_forest_v2.map" "C:\SIERRA\Half-Life\valve\maps\op4_forest_v2.map"

** Executing...
** Command: C:\PROGRA~1\AZoner\hlcsg.exe
** Parameters: "C:\SIERRA\Half-Life\valve\maps\op4_forest_v2"

hlcsg v2.5.3 rel Custom Build 1.7 (Dec 9 2002)
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 (merlinis@bigpond.net.au)
----- BEGIN hlcsg -----
Command line: C:\PROGRA~1\AZoner\hlcsg.exe C:\SIERRA\Half-Life\valve\maps\op4_forest_v2
Entering C:\SIERRA\Half-Life\valve\maps\op4_forest_v2.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 ]
onlyents [ off ] [ off ]
wadtextures [ on ] [ on ]
skyclip [ on ] [ on ]
hullfile [ None ] [ None ]
min surface area [ 0.500 ] [ 0.500 ]
brush union threshold [ 0.000 ] [ 0.000 ]

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

106 brushes (totalling 637 sides) discarded from clipping hulls
CreateBrush:
10%...20%...30%...40%...50%...60%...70%...80%...90%... (1.56 seconds)
SetModelCenters:
10%...20%...30%...40%...50%...60%...70%...80%...90%... (0.00 seconds)
CSGBrush:
10%...20%...30%...40%...50%...60%...70%...80%...90%... (1.17 seconds)

Using Wadfile: \sierra\half-life\valve\opfor.wad
- Contains 2 used textures, 3.17 percent of map (332 textures in wad)
Using Wadfile: \sierra\half-life\valve\halflife.wad
- Contains 61 used textures, 96.83 percent of map (3116 textures in wad)
Using Wadfile: \sierra\half-life\valve\xtree.wad
- Contains 0 used textures, 0.00 percent of map (32 textures in wad)

added 9 additional animating textures.
Texture usage is at 0.99 mb (of 4.00 mb MAX)
3.77 seconds elapsed

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

** Executing...
** Command: C:\PROGRA~1\AZoner\hlbsp.exe
** Parameters: "C:\SIERRA\Half-Life\valve\maps\op4_forest_v2"

hlbsp v2.5.3 rel Custom Build 1.7 (Dec 9 2002)
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 (merlinis@bigpond.net.au)
----- BEGIN hlbsp -----
Command line: C:\PROGRA~1\AZoner\hlbsp.exe C:\SIERRA\Half-Life\valve\maps\op4_forest_v2

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:\SIERRA\Half-Life\valve\maps\op4_forest_v2.prt'
3.58 seconds elapsed

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

** Executing...
** Command: C:\PROGRA~1\AZoner\hlvis.exe
** Parameters: -fast "C:\SIERRA\Half-Life\valve\maps\op4_forest_v2"

g_fastvis = true
hlvis v2.5.3 rel Custom Build 1.7 (Dec 9 2002)
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 (merlinis@bigpond.net.au)
----- BEGIN hlvis -----
Command line: C:\PROGRA~1\AZoner\hlvis.exe -fast C:\SIERRA\Half-Life\valve\maps\op4_forest_v2
821 portalleafs
2958 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 [ on ] [ off ]
full vis [ off ] [ off ]

BasePortalVis:
10%...20%...30%...40%...50%...60%...70%...80%...90%... (4.01 seconds)
average leafs visible: 481
g_visdatasize:81828 compressed from 84563
4.16 seconds elapsed

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

** Executing...
** Command: C:\PROGRA~1\AZoner\hlrad.exe
** Parameters: "C:\SIERRA\Half-Life\valve\maps\op4_forest_v2"

hlrad v2.5.3 rel Custom Build 1.7 (Dec 9 2002)
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 (merlinis@bigpond.net.au)
----- BEGIN hlrad -----
Command line: C:\PROGRA~1\AZoner\hlrad.exe C:\SIERRA\Half-Life\valve\maps\op4_forest_v2

-= 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 [ 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 [ 64.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\AZoner\lights.rad']
[48 texlights parsed from 'C:\PROGRA~1\AZoner\lights.rad']

7235 faces
Create Patches : 64861 base patches
0 opaque faces
1534249 square feet [220931968.00 square inches]
11 direct lights

BuildFacelights:
10%...20%...30%...40%...50%...60%...70%...80%...90%... (174.53 seconds)
visibility matrix : 250.8 megs
BuildVisLeafs:
10%...20%...30%...40%...50%...60%...70%...80%...90%... (722.22 seconds)
MakeScales:

Don't run a -fast VIS, for a start. Never ever run a -fast VIS in fact, seems to be the most pointless compile parameter ever invented.

is it actually giving you an error? If it is freezing up when it gets to makescales that normally means you have run out of ram and your computer has switched to virtual memory. This basically means your computer is using your hard drive as ram which is much slower than real ram and you'll have to wait a bit longer on your compile.

250mb for the visibility matrix is pretty big, you could try running RAD with the -sparse option to reduce the memory overhead, it'll increase the compile time tho'

And upping the -chop value should help in reducing the memory load, try 96 or higher. The lighting will get cruddier the higher the value tho' :sad:

Ronin said:
The only thing left is ram and i have 128mb and never have I had a problem with it.

The reason why you never had a problem before is probably because you've never compiled on high peramiters before...... GET SOME MORE RAM, 256 has a significant advantage over 128, it really does, and plus it increases the performance on your computer (besides 128 more isnt that much $). As for the actual problem the make scales take a long time, Its hard for the computer to transfer information between RAM space and HD space, that is what swap transfers is after make scales (transfering info on the HD back to WC), so in short get some more ram, even if it is very little, I noticed a big significant difference when I started compiling on a 256 computer over a 128 computer.

Leperous said:
Don't run a -fast VIS, for a start. Never ever run a -fast VIS in fact, seems to be the most pointless compile parameter ever invented.

I use it all the time actually. It's really useful if you want a general idea of what your lighting is like, but don't want to wait around for an actual VIS. But for all public betas and such, definately use regular.

I think the problem is linked to the fact that you have 64000+ patches (which is a lot). Consider -sparse, reducing map size, scaling up -chop size (or -texchop size). But definately the best solution would be -sparse on HLRAD. Also, there's always the option of external remote compiles on superior computers ( http://www.seascape.uk.net/rcs/ ). :smile:

Thanks a lot guys! I tried compiling again and the error seems to be with my computer. My virtual memory is too low and i get a warring from windows, then RAD crashed and just doesnt finish compiling. I will try it with the -sparse and -chop. If that doesnt work I will have to move it to a new computer and compile.

You can also run a memory free tool (if you do this, remember to close the thing otherwise your computer will be slow as hell, taking that it keeps freeing all your memory!), up your VMM size, or restart your computer. Shutting down programs that run in the background will help immensly as well.

Just to let you know though, your computer 'switches' to VMM very quickly. basically all the crap you have running which is in the least used state gets shoved in VMM area first, I believe. It's all in how Windows deals with it, it actually changes from OS to OS.

If your willing to trust some one i have a amd 2400 clocked at 2.00 ghz and 512 MB of ram. I can compile it for you, shoude not take long.

lol, well i dont think anyone would want to copy this map, its alright, but its not professional. I just make them so that my friends and I can play them on the LAN

As a side note, if you are not short on disk space, set your swap file minimum and maximum sizes to be the same. This ends up faster as windows never has to think about resizing it. It's also faster to have the swap file on a different drive.

Couple of things you might find interesting:

Max number of patches you can have without -sparse is 65535.

Compiling a map will use up a maximum of 384mb RAM. Which basically means, to compile a big map (approaching 65535 patches) youll need 512mb ram. I've never had a map take more than a couple hours since I got 512 (and back when I had 128... more than 6 hours).