Item limits

Host_Error: PF_precache_model_I: Model 'sprites/mapsprites/caparea.spr' failed to precache because the item count is over the 512 limit.
Reduce the number of brush models and/or regular models in the map to correct this.

So what all counts towards this limit? I have not increased the number of models in the map between this compile and the last one, yet I now get this error. The only entity changes I have made is the addition of a couple of ladders and a few func_ilusionary brushes.

Map info:

Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 315/400 20160/25600 (78.8%)
planes 7258/32768 145160/655360 (22.1%)
vertexes 19406/65535 232872/786420 (29.6%)
nodes 10024/32767 240576/786408 (30.6%)
texinfos 5914/32767 236560/1310680 (18.0%)
faces 15858/65535 317160/1310700 (24.2%)
clipnodes 19740/32767 157920/262136 (60.2%)
leaves 5895/8192 165060/229376 (72.0%)
marksurfaces 18811/65535 37622/131070 (28.7%)
surfedges 71210/512000 284840/2048000 (13.9%)
edges 36373/256000 145492/1024000 (14.2%)
texdata [variable] 32896/8388608 ( 0.4%)
lightdata [variable] 1404135/6291456 (22.3%)
visdata [variable] 257761/2097152 (12.3%)
entdata [variable] 74939/524288 (14.3%)

Somthing odd did happen durring this compile but I do not see how it could be related. I expanded the map slightly and I went from 96% on clipnodes to what you see. I also used the "-cliptype precise" switch which might account for it, but I thought it worth mentioning.

Tracer Bullet said:
[color=white]Reduce the number of brush models and/or regular models [/color]in the map to correct this.

brush models would be any func_brush. so your func_ladder will add to the count, and if you've goe with a standard setup, so will the {func_wall that looks like the ladder.

So are you thinking any visable entity will contribute this? that's what it seems like since the entity listed in the error is actualy a hud sprite.

i'm thinking that the entity doesn't even need to be visible.

Tracer Bullet said:
So are you thinking any visable entity will contribute this? that's what it seems like since the entity listed in the error is actualy a hud sprite.

Any entity, wheter visible or not. Just because the player cant see it, doesnt mean the engine cant see it.

I think there's an "active" entity limit, such as any entity that is accessed during the game or something. So like func_doors, func_walls, path_corners, etc. But not info_nodes or info_nulls (discarded during compile, I believe). Good amount of documentation on this with NS mapping, since NS used a lot of temporary entities for effects and such - that way, maps were limited with how many runtime entities they could use.

Just reducing the amount of unique func_walls and func_illusionaries should solve the problem, I think. Also advise trying a compile on MHLT instead of the XP Cagey stuff and see how that works out. Plus I don't think -cliptype precise is needed if you have good use of clip brushes.

Thanks for the help guys. I just consolidated a bunch of solid entities and got rid of some func_illusionarys, so problem solved.

At least for CSG and BSP I have to use the XP-Cagey tools. I'm at about 166% on the planes limit. I've also found that "-cliptype precise" is really great. It eliminates "sticky" places that even clip brushes can't fix, and lowers my clipnodes by ~15-20%. Well worth a little extra time on CSG!

Make your answer yellow CJ, and I'll mark it correct since it seems to be the one with the most complete info.

I've not come across this particular limit before, but it may be a sub-limit of the edict limit - that is, the limit of actual entity "slots" in the game, including temporary entities. Many entities use 2 or more edicts; the total limit is 2048 edicts. If this is passed at any point during play, the game will crash.

Anyway, it's somewhat academic now that the map works :smile:

You would have thought that instead of having the game just crash on number 2049, it could remove the oldest of the temporary ones? Or not let you make any more and give some dev message?

Tracer Bullet said:
Thanks for the help guys. I just consolidated a bunch of solid entities and got rid of some func_illusionarys, so problem solved.

At least for CSG and BSP I have to use the XP-Cagey tools. I'm at about 166% on the planes limit. I've also found that "-cliptype precise" is really great. It eliminates "sticky" places that even clip brushes can't fix, and lowers my clipnodes by ~15-20%. Well worth a little extra time on CSG!

Make your answer yellow CJ, and I'll mark it correct since it seems to be the one with the most complete info.

Last time I did precise the entire map was pretty sticky, going against a wall made the player slooow down. I do use the plane tool though, I quite enjoy the effectiveness of that combined with Merl's tools.

scary_jeff said:
You would have thought that instead of having the game just crash on number 2049, it could remove the oldest of the temporary ones? Or not let you make any more and give some dev message?

I'm sure it would be quite easy to fix, if you had the full engine sourcecode and were familiar with it. But the limits were never a problem for Valve, or indeed most community mappers, so the problem never received attention.

Gollum said:

scary_jeff said:
You would have thought that instead of having the game just crash on number 2049, it could remove the oldest of the temporary ones? Or not let you make any more and give some dev message?

I'm sure it would be quite easy to fix, if you had the full engine sourcecode and were familiar with it. But the limits were never a problem for Valve, or indeed most community mappers, so the problem never received attention.

I wonder what it would take to alter the source code so HL could render more polys, and could handel more objects... (thank God I'm studying C++ )

G.Ballblue said:
I wonder what it would take to alter the source code so HL could render more polys, and could handel more objects... (thank God I'm studying C++ )

I can't even guess - my programming knowledge is very poor - but you would need source code that is not available to the public.