So my community is running a few servers, we only have a problem where the server crashes often with the error message:
[code]Warning: Table modelprecache is full, can't add models/props_junk/Wheebarrow01a
.mdl --This problem has nothing todo with the model, this is simply the model that got spawned when the table got full.[/code]
First of all I thought that the servers RAM was full, which made it impossible to precache the model, but it appeared that the ram was only at 1.5GB out of the total 4GB available.
So is there a way to increase the modelprecache table with lua or possibly a module? Could someone point me in the right direction when a module will be neccesairy?
That's distressing, dumpstringtables to see what's taking up all the space in the modelprecache table.
[QUOTE=AzuiSleet;14976166]That's distressing, dumpstringtables to see what's taking up all the space in the modelprecache table.[/QUOTE]
You only get that error when the server's crashed and waiting for you to do something about it - you can't input any more commands. I get this occasionally.
Edit: I just tried it on a running server and it dumped more than the scrollback length. Any way to dump it to file?
[QUOTE=Lexic;14976309]You only get that error when the server's crashed and waiting for you to do something about it - you can't input any more commands. I get this occasionally.
Edit: I just tried it on a running server and it dumped more than the scrollback length. Any way to dump it to file?[/QUOTE]
con_logfile
The issue seems to be the map and gibs. I'm fairly certain the *1 etc entries are the brushes on the map.
This table really needs to be way higher then 1024. The growing amount of model packs and other mounted content means more models => more precached models when spawned. This is a serious problem because servers won't automaticly restart unless you press the stupid [OK] button.
Eventually there should be an option that allows us to uncache models/sounds/ect.
[QUOTE=AzuiSleet;14976482]The issue seems to be the map and gibs. I'm fairly certain the *1 etc entries are the brushes on the map.[/QUOTE]
Yes you're right.
These should be adjustable. Some tables have huge amounts of space that don't look like they're going to fill up at any point and more important looking ones have quite a lot less.
[code]Table downloadables
436/8192 items
Table modelprecache
605/1024 items
Table genericprecache
1/512 items
Table soundprecache
331/8192 items
Table decalprecache
219/512 items
Table instancebaseline
31/1024 items
Table lightstyles
64/64 items
Table userinfo
255/256 items
Table server_query_info
1/4 items
Table ParticleEffectNames
15/1024 items
Table EffectDispatch
20/1024 items
Table VguiScreen
0/256 items
Table Materials
19/1024 items
Table InfoPanel
0/128 items
Table Scenes
0/4096 items
Table LuaFilenames
219/4096 items
Table GameRulesCreation
1/1 items
Table LuaStringTable
195/2048 items[/code]
[QUOTE=AzuiSleet;14976482]I'm fairly certain the *1 etc entries are the brushes on the map.[/QUOTE]
This is correct.
The map has over 200 brushes which fill the table.
What reason is there for this to be capped at just 1024?
[QUOTE=aVoN;14976706]This is correct.
The map has over 200 brushes which fill the table.[/QUOTE]
Brush entities surely - Evocity has over 200 brushes in the government building alone.
[QUOTE=AzuiSleet;14976482]The issue seems to be the map and gibs. I'm fairly certain the *1 etc entries are the brushes on the map.[/QUOTE]
a model with a * tells the engine to look at the model array in the bsp which contains models made from brushes
the number being the index
So is there any solution to this problem? (Garry???)
No. It's an engine thing.. I can ask Valve to increase the size of the table I guess - that's if they don't have a reason for it being small (for gmod).
Or garry can find all such limits like this and simply multiply them by 10 considering he has full source engine source code and can do whatever he wants but seems too lazy to ever do so.
Look, the source engine was basically done around 2004 when HL2 came out and valve has only added new stuff and never upped limits like these for NO REAL REASON despite the fact that our computers and gpus are MUCH faster and more capable of having much higher limits.
There is NO reason why all of these limitations can't be raised dramatically or removed altogether in gmod, even by garry and not even needing valve.
One thing garry does need to remove, however, is his rubbish "anti-infinite-loop" mechanism. It is up to developers to produce scripts that don't infinite loop and it was completely rubbish to remove the convar that allowed competent people to be able to make a much higher limit when testing new concepts that require more than an unknown amount of loops.
[QUOTE=garry;14987749]No. It's an engine thing.. I can ask Valve to increase the size of the table I guess - that's if they don't have a reason for it being small (for gmod).[/QUOTE]
Wait, what?
I thought you had full engine access; you could do whatever the fuck you wanted with Source?
I'm just guessing but perhaps it makes it harder for Garry to merge his code with engine updates Valve release.
[QUOTE=nicktelli;15004526]One thing garry does need to remove, however, is his rubbish "anti-infinite-loop" mechanism. It is up to developers to produce scripts that don't infinite loop and it was completely rubbish to remove the convar that allowed competent people to be able to make a much higher limit when testing new concepts that require more than an unknown amount of loops.[/QUOTE]
If you really need a loop with that many iterations you need to reconsider what you're doing. The game server is time critical, you can't have it waiting for 5 seconds to process something, everyone will see the game pause while the server is working.
[QUOTE=Lyoko774;15004667]Wait, what?
I thought you had full engine access; you could do whatever the fuck you wanted with Source?[/QUOTE]
I don't ship the engine binaries, I only ship server and client dlls. The engine is shared amongst all orangebox games.
[QUOTE=AzuiSleet;15005310]If you really need a loop with that many iterations you need to reconsider what you're doing. The game server is time critical, you can't have it waiting for 5 seconds to process something, everyone will see the game pause while the server is working.[/QUOTE]
I'm not talking about something live with other people, I've just had random uses off hand where I've hit the limit while trying to stress test something or do something to do with random numbers or something, it's just really stupid to limit people in something called a "sandbox".
[QUOTE=garry;15005887]I don't ship the engine binaries, I only ship server and client dlls. The engine is shared amongst all orangebox games.[/QUOTE]
I realize that.
But I thought you could..Ah, nevermind.
It would be nice if this could be fixed, though.
[QUOTE=garry;14987749]No. It's an engine thing.. I can ask Valve to increase the size of the table I guess - that's if they don't have a reason for it being small (for gmod).[/QUOTE]
Did anything ever come of this?
I bet it's not going to happen..
Wow I never realized this, I hope Valve allows the increase.
[QUOTE=TehBigA;15322759]Wow I never realized this, I hope Valve allows the increase.[/QUOTE]
Why not? it should not effect any other games right?
Most likely not but Valve never intended for a game to have more than 1024 models to need to be precached, let alone think a game like GMod would be on their engine.
I think it's retarded that it causes the server to stop... I rather them make clients have to load them on the fly after then join...
or it could just empty the table and start at the beginning
Hopefully garry can get valve to increase it for gmod or make it a command-line thing for gmod like -tickrate
I always wondered why my server kept crashing on freespaces, while it worked fine on gm_construct. This may be the problem, so please fix this as soon as possible.
[QUOTE=DarKSunrise;15341073]I always wondered why my server kept crashing on freespaces, while it worked fine on gm_construct. This may be the problem, so please fix this as soon as possible.[/QUOTE]
Garry has no control over the engine. Unfortunately only Valve has that.
Sorry, you need to Log In to post a reply to this thread.
