so im just finishing off my map adrenalin4, have a playtest with 14 of my mates, find a few bugs. so afterwards, right, im fixing up or replacing a few misaligned textures, adding some spawn camping warnings, and i never touched a single model at all. i go to compile and get this whacked error.

"Host_Error: PF_precache_model_l: "models/mapmodels/sandbags.mdl' overflow

i do some research, search these boards, its happened before, andwhile a linked tuturial wasnt very informative (i speak english, not hammer) i just replaced the 4 sandbag models with new ones.

recompile. success. the sandbags arent a problem, instead its the panzer.mdl on the other side of the map. so i replace that, and its another model, then its a func_breakable, im doing a wild goose chase untill i get this one. glassgibs.mdl. hmmm. i dont have that placed anywhere in my map, but i do have some glass. wat am i supposed to do, delete every freakin entity and start again? i was planning to release the map this week but its pissing me off.

enclosed is a picture of 2 screenshots of the error in console, with different models. wat the hell is going on here, and can somebody please help me, sparing the hammer mumbo jumbo.

i cant remeber for sure.. i think precache overflows normally mean you have gone over one of the maps limits - ie planes.. do some www.google.com searching for info on the error :)

yep...

this means you reached the max. model limit...

i dont know if im right, but normaly you get this message only if you have sturmbot also installed... coz sturmbot loads some models too! so you reach fast the model limit by some maps... ie
dod_june or dod_normandy does not run with sturmbot coz of this model problem.

so if you run sturmbot, then deinstall it and try again..

hope this helps?! :confused:

nup. dont have sturmbot installed. but its weird because i didnt add or change any models or anything, only a few textures, and a couple of brushes. ive now deleted a whole bunch of lightbulb models in the interiors, and still get the error.

a few more questions:
1. what is the 'maximum' amount of models allowed
2. is it simply a matter of having too many models in an area, or more about how they are placed?
3. why doesnt forest have this error? :confused:

i think im gonna have to delete all the models and compile, and then start all over again.

Have you seen this:

http://www.slackiller.com/tommy14/errors.htm#precache

Might help you find your problem.

Use -chart parameter in VIS and Rad. You'll get the maximum memory that can be used for all sections. And the rate.
Note that going beyond a limit will give some weird errors where there are no problems (we know, you like me, that sandbags.mdl is a valid one). In other words, the engine will tell you it has a model problem, but it is probably a maxplanes or maxnodes error.

If you can't find the real reason, remove things, starting by entities. Once there's no problem anymore add things again. Cautiously.

You have too many models and/or func_walls and/or func_illusionaries in your map. It shows the first one to overflow, so you can make some fixes and then see it throw a different model ..

The fix is to not have so many of those things, and a good trick is to combine multiple func_wall entities *IN THE SAME PVS* into one big func wall entity that encompasses multiple func_walls.

Note that the more func_walls and animating models you have, the slower your map will run when full of players.

I thought that func_walls helped to improve FPS and play ability?

-Eagle

Not always true...what they do is allow you to either create see-thru textures like hedges or fences or to create regular brushes that you don't want to cause brush splitting...an example would be the rubble in ava...if you spectate in ava and fly up out of the map watch how many things disappear...those are all entities (func_wall, env_model, etc). The problem is when you have too many. I'm not sure what "too many" is but the more func_walls the more the engine has to draw them so CPU cycles are used.

As to this particular map...what you can do is select a bunch of the same func_walls in one area of the map and make them all one func_wall...this will reduce the actual number of entites in your map. A rule of thumb is to keep your entire entity count (point plus brush) under 500. Another thing you can do to reduce CPU time is to NOT name any of your entities unless you have too...something about naming them reduces the CPU cycles becase if they are named the engine needs to "see" them all the time (I butchered that...Mugs can offer a better answer than me) Good luck.

Originally posted by Eagle
I thought that func_walls helped to improve FPS and play ability?

-Eagle

They can help improve FPS because they don't chop up solids. I'm not sure if you already know how it works but type gl_wireframe 1 in console while testing a map you have made (map must be loaded directly from console and not in lan game/online - type developer 2 as well). It will show the polygons on surfaces. Make it 2 and you will see all the polygons the engine is rendering.

Make a test map with just a box and place a 12 sided cylinder on the floor, make sure it touches. Load the map up and turn on wireframe, you will see how many extra polygons it has made because it cookie cuts the floor. Now, there is two ways to fix it.

a) raise the cylinder 1 unit off the ground. This works if the player can never make eye contact with the object. If they can (IE de_cbble crates in courtyard), it gets abused by snipers who have enough room to shoot the feet of other players in that 1 unit gap.

b) make it a func_wall and don't raise it 1 unit. Func_wall's do NOT cookie cut (Chop) up solids. This is handy if you are burrying something into a solid where it would be impossible to raise it 1 unit away from it. Func_wall's also have there other uses but this is just one example on how it DOES save fps by lowering r_speeds.

You can save a LOT of wpoly by going around and raising objects one unit off the ground and applying null to the bottom surface. Sometimes it won't look right or it will cause problems so thats when you go func_wall, you can always turn on the func_wall shadow cast if required but it does take more rad time to do this, so use -nopaque in RAD command parms to turn it off for tests.