hunk_alloc failed in [number] :banghead:
i get this msg from wolfmp.exe when loading my map after a light -fast -fastgrid compile. i had this the first time when i reduced the gridsize value. but now i did nothing to gridsize and i get this again. any ideas? what does it mean anyway? btw i use alread a lightgrid brush
wolfmp 1.41
q3map 2.3.37
HI,
The hunk is where all of the resources, shaders, lightmap, lightgrid etc are loaded into the engine, if any one of these sends the game over it’s default limit of 56MB, it will drop out and report the size of the last block of memory that it tried to allocate. This number won’t really mean much to you because it’s just an abitrary amount which the engine tried to allocate and sent it over the limit.
There are a few things you can do to reduce this data:
gridsize
Use the gridsize key in worldspawn to scale the lightgrid (entity lighting).
I’ve found this to be quite usefull for wide open areas, as you will not usually see a difference with this scaled to low resolution.
It’s value is three numbers representing the scale in X Y Z,
default is 128 128 256
try 256 256 512
_lightmapscale
You can use this on func_groups or even in the worldspawn, if you have a large map, I’d suggest using 2.0 in worldspawn.
COM_HUNKMEGS
If all else fails and you just want to get the damned thing to load, the easiest way is to allow rtcw to allocate more memory for the map by using the com_hunkmegs command with number of meg to use eg:
Goto Console by pressing ~tilde and type
\COM_HUNKMEGS 64
Then restart rtcw and try loading the map again, however it’s not a good idea not to go over 3/4 of your available memory in the system and if you plan on distributing the map to others, this would need to be set on their systems too, which people don’t usually want or know how to do.
edit: I think having fastgrid when you also have light fast, won’t really do anything since light fast should enable fast on the lightgrid by default, I could be wrong tho?
Hope that helps,
Codey
Wolfyv0.2
wow thx for the detailed explanation 
i already made my lightgrid brush smaller(that reduced the grid lightning)… since i have some small hallways i need gridsize 96 96 128. otherwise when i go into one of that small hallways the player models gets dark as hell.
_lightmapscale… i got a lot of places that could have even _lightmapscale 4 and noone would see that something is wrong there. gonna go for that :moo:
_lightmapscale didnt really help. i had to rebuild the small hallways and go up to 128 128 128 gridsize
I was just checking thru some files in my wolf directory when I noticed this file
hunkusage.dat
it lists all the maps you’ve been running in wolf with the amount of memory it’s been using… the largest atm is swf with around 38MB usage (my own SP maps are 21 & 35MB respectively to give you a comparison). If you’ve gone over that size then you can atleast comfirm the memory usage…!
that must be one big ass map…!
You’ve made as much of it as possible into detail flagged brushwork yes, caulking as much of the hidden surfaces as possible?? You could try a test compile on the map (another version) with the ‘waste’ brushwork from the terrain removed and see if that helps (by that I mean you remove the trisouped brushwork you can’t actually see ingame leaving you with an ‘optimised’ terrain mesh - it’s a fiddly operation though this)
actually its not that big. skybox is 13860 9306 4256 but playable area is 8146 x 9280 x 2880(lightgrid brush). i think what makes it such a memory killer is q3map2 with its different way to handle with lightmaps what brought me before wolf 1.4 max_shader_hit error
edit:i made some tests and get some wierd results
maps/natter99_1.bsp 44661088 // gridsize 128 128 128 no lightmapscale blocksize 832
maps/natter99.bsp 43365536 // gridsize 256 256 512 worldspawn _lightmapscale 2 blocksize 832
maps/natter100.bsp 44169888 // gridsize 128 128 128 worldspawn _lightmapscale 2 blocksize 832
maps/natter101.bsp 43305696 // gridsize 128 128 128 worldspawn _lightmapscale 2 blocksize 1024
going from 128 128 128 to 256 256 512 only makes 0.7MB more. and lightmapscale 2 in worldspawn doesnt have either a stong effect. so what is the rest? textures used? sounds?
how many ‘shadered’ textures have you used (textures with shaders)??
Can you post a sceeeny so we can see the general layout of what you’re doing (or mail a couple 600xXXX to my sig address if you don’t want to give too much away to the prols…!)
i made now also a test without lightmaps. did i use too much different tex? too much sounds? what is included in this hunkdata?
maps/natter102_nolm.bsp 42122080
sent a reply back… it looks good and is worth trying to fix. The main thing to me seems to be the terrain mesh, I’ve included some ideas which may or maynot work (hope they do though esp in combination to what Codey posted above)
for anyone else… my terrain has 2119 brushes being 8146x8146x4238. i consider it as “not detailed”. the map has total 16745 brushes. is that an usual count?
:what a bump:
Experiencing the same error. How did this problem finally get solved?
Your map uses too much memory. 
***First, easy, quick and nasty fix to play the map is raising /com_hunkmegs “value”.
***Next step is to check the memory usage with /com_hunkusage. Compare it to fueldump (IIRC about 52 megs).
Nowadays you can go fairly over, because many ppl has higher hunkmegs, but not everyone does. Many maps requires higher (than default) hunkmegs. But I like to keep it slightly under fueldump’s, because it’s fairly easy and has good sides too.
***Third and the last step is to lower the memory usage, or trust that the players use higher hunkmegs. For lowering there are several possible fixes. The hardest way is lowering the size of the bsp (pm me if you want to do that), but usually it’s not needed. Usually you get away the easiest by ripping away some stuff from the pk3 or lowering quality.
The best method is probably to convert tga’s to jpg’s, if that’s not enough, lower the resolutions a bit too. This affects probably the most in most maps, and usually fixes it.
Also if you have many sounds, you can lower their quality. Etc.