MAX_GAMESTATE_CHARS error

(Chruker) #1

Hi

I’ve been looking into the MAX_GAMESTATE_CHARS error and wanted to find out what size the gamestate has in a given map. I tried starting the map with developer 1 and then look for the part looking like this in the output:

Johnny : dropped gamestate, resending
SV_SendClientGameState() for Johnny
Going from CS_CONNECTED to CS_PRIMED for Johnny
Sending 15463 bytes in gamestate to client: 0

Next I wanted to make a simple command that would just print it in the console. However the number I get there is in the range of 8500. To get that number I just print the dataCount in the syscall function, like this in cg_syscalls.c:


void		trap_GetGameState( gameState_t *gamestate ) {
	syscall( CG_GETGAMESTATE, gamestate );

	CG_Printf("DEBUG: Gamestate size: %i
", gamestate->dataCount);
}

Now I’m asking, what better way is there to get the current size of the gamestate?

(bani) #2

CG_GETGAMESTATE refers to only the configstring data at the exact moment in time you queried it. the trap name is misleading :slight_smile:

the ‘Sending 15463 bytes in gamestate to client: 0’ in the server console is the complete gamestate including entity baselines, and that’s the authoritative (correct) value. there’s no way for cgame to get that info.

(Chruker) #3

Can you tell me if the splashdamage has added some ET specific code to SV_SendClientGameState? If not, I could just predict the size by adding the numbers together again, since I’ve got structure of gamestate from the newly released quake3 source code.

(Chruker) #4

Hmm. by adding the numbers together I wasn’t able to get the values that the game reports. The delta entity bit packing got my brain swirling around the room. For now I’ll leave this issue open :slight_smile:

To anybody that reads this post in a search to remedy the ‘MAX_GAMESTATE_CHARS exceeded’ error. The gamestate is made up of the following:

  • Outstanding server commands
  • Configstrings
  • Positions of the entities in the map
  • A few bytes for checksums and etc.

Server admins should reduce the amount of junk text they put into the serverinfo. If they use etpub they should investigate the g_serverInfo cvar, and have it set to generate the smallest serverinfo string. Also the servers MoTD takes up 5 configstrings.

All that said the maps generates the biggest variance in the gamestate requirements. Here are the number reported by the game using developer 1:

Venice      15707   15754
Oasis        8603    8878
Battery     14009   14075
Gold Rush   13952   13840
Radar       10632   10523
Rail Gun     8102    8007
Fuel Dump   16680   16564

First column is first run and second column is the second run.

The fueldump numbers puzzles me a bit, since they are bigger than the MAX_GAMESTATE_CHAR in quake3. bani Has ET upped the MAX_GAMESTATE_CHAR from the 16000 in quake3?

(bani) #5

never mind :slight_smile:

the MAX_GAMESTATE_CHARS error in the engine only refers to the configstrings, so CG_GETGAMESTATE should work for what you want to do.

(Diego) #6

This stupid error is the bane of my mapping. I had to split Praetoria into 2 parts over a two years ago because of this error and other compile problems. Even the final version of Mission One gets it on large servers. This week I finally got the full version of Mission Two ready for testing with all of the objectives in place and this ugly beast popped up with a vengence. I Only had 3 people in the map when it crashed.

I’ve got a few modifications that I can make to try to get past this. But if not, It looks like I might have to split the map in half AGAIN. If that happens, you guys might be beta testing Mission 3 while I figure out how to reintegrate my Tank upgrade objectives into an entirely new map.

(ailmanki) #7

ain’t the names of all serverside loaded pk3’s also in that string?

(TomTom7777) #8

Diego: check your /entitylist. How many entities are there with no players and then with players. Too many entities can blow the server to client gamestate space. Are the highest entity numbers (mostly temp types) increasing regularly or are they making large jumps. I ask after seeing a problem in breakout2 when running both omnibot and fritzbot, (suggestive of a possible memory leak).

(aaa3) #9

[QUOTE=Diego;189786]This week I finally got the full version of Mission Two ready for testing [/QUOTE]:eek::smiley: wow :open_mouth: YAY!

(system) #10

Me too, tell me if there is a server ready where the map is going to be testedd (IF, that is) :slight_smile:
Been waiting for Praetoria 2 since the beginning

(Diego) #11

583 Entities with just me in the game. It doesn’t increase. I noticed that Info_notnulls are listed in there. I use a lot of those as targets for spot lights. If I change those to info_null, are they still counted? What about the spline points?

I was thinking that it was more related to the amount of shit I have going on in this map. It has a tank, at_gun, manual firing gun console, tank upgrader, a tug, 2 cranes, a truck, cp, constructable barriers and a few explosive targets.

It could be related to the amount of .pk3 files we have. That caused us to get that error on Venice a lot but we already removed enough pk3’s to fix it for Venice and Fueldump. I’ll talk to the guy that handles our server database at work and see if he can set me up a test without the other maps in there.

(kamikazee) #12

From the Q3Radiant manual, entities appendix:

(info_nulls are only used by the compiler and need not be “remembered” by the game engine during play).

Guess you are right - it may even help with this problem. If it doesn’t, it shouldn’t hurt as spotlight work just as good.

(TomTom7777) #13

Kamikazee: thx good to know

The number of entities sounds safe enough. Could be something in etmain I suppose (we could all use a tool to identify and compare when maps conflict).

Diego said:

I was thinking that it was more related to the amount of shit I have going on in this map. It has a tank, at_gun, manual firing gun console, tank upgrader, a tug, 2 cranes, a truck, cp, constructable barriers and a few explosive targets.

In your new map; How many of those things have trigger_objective_infos? Too many and ET might leak. 15 seems safe, from 16 to 18 I often see problems develop but it varies map to map as to how many it takes to break ET.

(Diego) #14

I’ve removed some spawn point entities, converted the spotlight’s info_notnulls to info_null, removed the depot defenses and the AT gun as objectives. That has brought my entity count down to about 530. Hoping to test it out this afternoon.

I think I had 9 TOI’s.
Tank
Truck
Tug
AT_gun
2 Depot Defenses
CP
Health and Ammo kit
Gun Controls

I do have other triggers for the tank upgrader and the gun controls, but they are not TOI’s.

I was wondering, do the names of my script blocks affect the gamestate? For instance, if my depot defence script block was named:
axis_construct_depot_defenses_north

instead of something short like this:
axis_ddn

So when they are triggered, does the longer name impact the gamestate?

I also use long descriptive names for my vo sounds as well to help me keep track of things. But once the script is done, I can shorten all of these will a simple search and replace if it will help.

Thanks for that /entitylist command. I didn’t know about that. Any other useful commands that might help here?

(Diego) #15

Tested it out again this afternoon. We had 6 players and the map played pretty well but it did finally crash with the gamestate error just as we were escorting the truck at the end of the map. I think removing the objectives had a better impact than removing the info_notnull entities. So it looks like I’m going to split the map this weekend.

(TomTom7777) #16

[QUOTE=Diego;189840]I
…
I think I had 9 TOI’s. [/QUOTE]

9 TOIs should be no problem.

…
I do have other triggers for the tank upgrader and the gun controls, but they are not TOI’s.

I don’t know what the practical limits are for other trigger entities. Just found the practical limit for TOIs when modding mapscripts.

I was wondering, do the names of my script blocks affect the gamestate? For instance, if my depot defence script block was named:
axis_construct_depot_defenses_north

instead of something short like this:
axis_ddn

So when they are triggered, does the longer name impact the gamestate?

I also use long descriptive names for my vo sounds as well to help me keep track of things. But once the script is done, I can shorten all of these will a simple search and replace if it will help.

Thanks for that /entitylist command. I didn’t know about that. Any other useful commands that might help here?

I can’t think of any reason right now why the client would need to know the scriptname key for any entities. Offhand even the QVM should be able to get by without it. Just the targetname, state and event type may need to be passed around. (and maybe TOI track string …). Basically what you see in /configstrings is what I expect gets passed around along with lots of player and temp entity stuff.

Here’s a shot in the dark. How often do you flush:D. I mean are you using remapshaders and doing a lot of flushing/changing? I’ll have to check but it may go through the same hole…

(Diego) #17

I use remapshaders on the tank and the truck. It flushes after every remap shader change. Mostly it is to make the tank treads and tires rotate, but I am also changing the shaders on the tanks body to give it a green camo instead of the gray snow, and again when the armour gets upgraded.

I built my own models for the train, cranes, and computer consoles. I hit the remapshader limit on those very quickly the first time around so instead of remapping them, I just use changemodel to swap them to a new version.

(TomTom7777) #18

Assuming /configstrings is a guide, the path information of misc_gamemodels, speakers/voiceovers, and remapshaders textures, plus names of voiceovers, trigger_objective_infos and their target fields get thrown into the server to client communication. Now the individual character length may or may not be important (i’ll have to find and decode some of the SDK to see what packing is or is not used). But at the very least I would guess the total number of some of these is a risk factor.

As I recall the remapshader data structure is one part texture names (32 max) and one part indexes. That allows for the same shader to be remapped more than once without duplicating the initial shader name in the structure. I’ll have to search for it again to see if the names were packed for length.

(Diego) #19

/configstrings posted 905 lines. It included Tag information, all of my models for the changemodel commands, sounds for script movers like doors, etc.

Not sure how to interpret it really.

(ailmanki) #20

maybe this helps a bit:
http://www.etpub.org/e107_plugins/forum/forum_viewtopic.php?5747.20

Yeah, that’s not supposed to happen. I’ll take another shot at it.

Did you all get this error when the map loaded, end of warmup, or just in the middle of the map?

I posted in the other thread, you can examine your GAMESTATE string to see if it’s overly large with the csinfo and csdump server commands. The most likely causes of bloat are too many ‘sets’ cvars, or too many pk3 files.

csinfo

this command will print the size of each individual configstring and print the overall length of the GAMESTATE at the end.

csdump 0

This prints out the SERVERINFO string. If you have any worthless ‘sets’ cvars, they will show here. Also see the g_serverInfo cvar for limiting the length of this string.

csdump 1

This will print the SYSTEMINFO string. This config string is special since it can be 8192 chars long instead of 1024 like all the others. The reason for this is it holds checksums for all pk3 files your server is referencing. Having unneeded pk3 files here is the most likely cause of most MAX_GAMESTATE errors.

And jaymod has a special thingy,. .there page is currently being worked on, so here the google cache:

http://209.85.129.132/search?q=cache:o1xxZQ_uCyQJ:www.clanfu.org/jaymod/2.1.5/html/cmd.status.html+"status+displays+critical+server+resources+"&cd=1&hl=de&ct=clnk&gl=ch&client=firefox-a