[QUOTE=TehBigA;15341516]Garry has no control over the engine. Unfortunately only Valve has that.[/QUOTE]
Only because he doesn't compile his own binaries. He could have full control over the engine if he wanted to spend a lot of time compiling and uploading.
Also, while you're at it, can you increase the net_message buffer size please?
I'm pretty sure he can alter the variables without modifying the engine, it can't be that hard right?
[QUOTE=Lexic;15341913]Only because he doesn't compile his own binaries. He could have full control over the engine if he wanted to spend a lot of time compiling and uploading.
Also, while you're at it, [b]can you increase the net_message buffer size[/b] please?[/QUOTE]
100x Support
[QUOTE=maurits150;15344128]I'm pretty sure he can alter the variables without modifying the engine, it can't be that hard right?[/QUOTE]
[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]
Unfortunately not.
[QUOTE=Lexic;15377893]Unfortunately not.[/QUOTE]
Pretty obvious.
---------------
[sp]
//-----------------------------------------------------------------------------
// Purpose:
// Input : id -
// *tableName -
// maxentries -
//-----------------------------------------------------------------------------
CNetworkStringTable::CNetworkStringTable( TABLEID id, const char *tableName, int maxentries )
{
m_id = id;
m_pszTableName = new char[ strlen( tableName ) + 1 ];
assert( m_pszTableName );
assert( tableName );
strcpy( m_pszTableName, tableName );
m_nMaxEntries = maxentries;
m_nEntryBits = Q_log2( m_nMaxEntries );
// Make sure maxentries is power of 2
if ( ( 1 << m_nEntryBits ) != maxentries )
{
Host_Error( "String tables must be powers of two in size!, %i is not a power of 2\n", maxentries );
}
}[/sp]
I think it's very much possible to just modify the m_nMaxEntries at some point.
It'd be cool if we could decache models that we're not using, so if we have a model that we only need for a short amount of time, we can free up some slots on the model precache table.
Just being able to make all gibs clientside would be a bonus as most of the table was taken up with gibs.
[QUOTE=Nerdboy;15380537]It'd be cool if we could decache models that we're not using, so if we have a model that we only need for a short amount of time, we can free up some slots on the model precache table.[/QUOTE]
Agree, there should be something like this.
There is no way at all to remove entries from the modelprecache table and would be pointless to do because you might spawn a model again and then you have the slight lag time.
The answer to this solution has been found in an engine.dll source header under the "common" folder called qlimits.h which defines MAX_MODELS as such
// Resource counts;
#define MAX_MODEL_INDEX_BITS 9 // sent as a short
#define MAX_MODELS (1<<MAX_MODEL_INDEX_BITS)
Now 1<<9 should produce 512 so it seems that this has probably been changed to 10 to be 1024 and a simple change by garry ( and shipping this barely modified engine.dll binary) of MAX_MODEL_INDEX_BITS to 12 would produce a modelprecache table size of 4096 which would be pretty good, or could even be 13 just for that little bit extra boost of model precache storing power.
[QUOTE=nicktelli;15454749]There is no way at all to remove entries from the modelprecache table and would be pointless to do because you might spawn a model again and then you have the slight lag time.
The answer to this solution has been found in an engine.dll source header under the "common" folder called qlimits.h which defines MAX_MODELS as such
// Resource counts;
#define MAX_MODEL_INDEX_BITS 9 // sent as a short
#define MAX_MODELS (1<<MAX_MODEL_INDEX_BITS)
Now 1<<9 should produce 512 so it seems that this has probably been changed to 10 to be 1024 and a simple change by garry ( and shipping this barely modified engine.dll binary) of MAX_MODEL_INDEX_BITS to 12 would produce a modelprecache table size of 4096 which would be pretty good, or could even be 13 just for that little bit extra boost of model precache storing power.[/QUOTE]
What? The default is 1024 not 512
I know, if you read carefully it says that's what the code said but that's from the leak from 2003 so I explained it's probably 10 in the actual code right now.
Nevermind...
Sorry for bumping, but, is there any solution at the moment?
I have lots of crashs due to this problem.
[QUOTE=Euphytose;16885399]Sorry for bumping, but, is there any solution at the moment?
I have lots of crashs due to this problem.[/QUOTE]
[url]http://www.facepunch.com/showthread.php?t=754185[/url]
That's the closest anyone has come. Although not 100% fixed.
[QUOTE=foszor;16888699][url]http://www.facepunch.com/showthread.php?t=754185[/url][/QUOTE]
That doesn't work, we can't increase it clientside so it still crashes clients that try to join.
[QUOTE=maurits150;16888712]That doesn't work, we can't increase it clientside so it still crashes clients that try to join.[/QUOTE]
Right. I didn't say it fixed it, I said its the closets anyone has come.
You can use it to save the server.
[QUOTE=foszor;16888980]Right. I didn't say it fixed it, I said its the closets anyone has come.[/QUOTE]
Yea, so it's not really a solution :xd:
[editline]02:55AM[/editline]
I see you've edited your post though.
Well, if the client crashes, it means that every client will crash, but models will stay, so no one will be able to join...
It's really bad.
Edit :
Why did someone rate me dumb? :/
I mean, if a client crashes, it means that the memory thing is full, for everyone so. So, everyone will crash, but models will stay, so you'll join the server, and your memory will fill up in a second, and you will crash.
[QUOTE=Euphytose;16889491]Well, if the client crashes, it means that every client will crash, but models will stay, so no one will be able to join...
It's really bad.
Edit :
Why did someone rate me dumb? :/
I mean, if a client crashes, it means that the memory thing is full, for everyone so. So, everyone will crash, but models will stay, so you'll join the server, and your memory will fill up in a second, and you will crash.[/QUOTE]
I believe only new clients joining will crash because the actual networking of the table overflows the clients receiver buffer into other memory when it is sent but clients already in the server will only attempt to add a new model to their table but it will just not add because the table is full.
ehm. Well i am actually using that .dll on a server, and if you try running cl_precacheinfo the client table have increasede the size too. Also we only had a few clients crash. But the server is running way more stabile.
Correct me if I'm wrong, but connecting clients will only crash if there are > 1024 different models active on the server. As this crash usually happens over the course of several hours as props are spawned and removed, it's probably not going to affect incoming clients, and clients that crash can just rejoin. An entity cap of 1023 will prevent incoming clients crashing. :>
Ok, I'll install it right now, we'll see, anyways, it can't be worse than now.
Edit : I put all the files like they were, except these " helper scripts ", I let all the rest without touching at anything, I hope it's ok.
Edit 2 : It seems to work.
[QUOTE=Lexic;16895079]Correct me if I'm wrong, but connecting clients will only crash if there are > 1024 different models active on the server. As this crash usually happens over the course of several hours as props are spawned and removed, it's probably not going to affect incoming clients, and clients that crash can just rejoin. An entity cap of 1023 will prevent incoming clients crashing. :>[/QUOTE]
What do you mean by an "entity cap"?
Mmmmh, certain clients tell me that they get a " playermodel = null " when they try to join, it happens with some of them, I don't know why.
But the server is now up for 6 hours, which was impossible before.
Sorry, you need to Log In to post a reply to this thread.