MAX_GAMESTATE_CHARS_EXCEEDED

[TheJester]

Moin,

ich mach hier mal nen Thread auf mit dem was ich bislang gefunden habe. Die Beste erklärung bislang hab ich im Dark Alchemy Forum gefunden :

http://www.dark-alchemy.com/modules.php?name=Forums&file=viewtopic&t=4011&start=0&postdays=0&postorder=asc&highlight=

The server have to track all clients informations, then a buffer is used to send these informations to the clients usually called: "CONFIG STRINGS".

The server keep an eye and tracks the value of all 1024 strings of the game state in order to send such informations to all clients. Vanilla ET never use all 1024 strings, so ET doesnt have this problem.

With new mods like ETPUB or NQ, they added so many new features and the server need to send to all clients more informations which increases the size of the config strings, the consequence is that every client need to receive more informations through this config string.
AS more the strings are long as more bytes are needed for that gamestate string.

But then what happens when the string goes over the maximum limit which is 16000? In the instant that a client receive these informations which exceed 16000 bytes the CLIENT crash with the error "MAX GAMESTATE CHARS exceeded", but the server doesn't crash.

The only way to fix it is that mod developers makes some optimizations in their mod codes, like NQ team is doing just last times. And server admins try to disable unneeded features as more they can, reducing text strings lenght and the number of the maps if they runs a campaign.

Es ist also wirklich der Client der da abstürzt, weil NoQuarter zuviele Statusdaten generiert, und der Client die aufgrund eine 16000 byte buffers nicht mehr zwischenspeichern kann. Bislang sieht es so aus als könnte man nur auf dem Server features abstellen damit das besser läuft. Oder den Client neu Compilieren

tbc

[jomu78]

Moin,

aus der q_shared.h:
#define   MAX_GAMESTATE_CHARS   16000

Stelle schonmal gefunden... Ist blöderweise nur der 2.56 source code

[jomu78]

Der Quelltext liegt unter: ftp://ftp.idsoftware.com/idstuff/et/sdk/ (wie bekomme ich denn hier einen FTP URL hin?)
Hat jemand MacOS und kann mal nen diff zwischen dem MacOS 2.60c und dem Linux / Windows 2.6 machen?

[x3t0]

server konnte nicht gefunden werden

[jomu78]

Anbei mal die Linux Libs mit 32k Puffer - jetzt muss ich nur noch den mingw32 cross compile Quatsch ans laufen kriegen, dann kommen auch win DLLs raus. Jemand Erfahrungen?

BTW: aus dem Changelog von NQ 1.2.7
    * Configstring CS - fix of MAX_GAMESTATE error

[jomu78]

@X3T0: ja - ist ein FTP link - aber dieses Forum schreibt vor jede URL die ich einfüge "http://"
Wenn du nicht auf den Link klickst sondern per Copy / Paste aus dem Text arbeitest, dann gehts.

[x3t0]

aaahh ... sry, nicht drauf geachtet ^^

[TheJester]

@jomu: ich glaube du musst das über das Url Tag machen, dann gehts auch mit ftp.

Naja, wenn 1.2.7 da nicht so exzessiv mit den Config Vars ist können wir ja mal darauf warten. Ansonsten hab ich irgendwo noch eine VM Mit Mingw und ms visual studio 2005 liegen, mal sehen ob das sich so übersetzen lässt.

Könnte alllerdings sein dass uns dann der PB dazwischen funkt. Ich weiss nicht genau was der alles prüft.

[jomu78]

VS 2005 kompiliert das bei mir nicht - gibts ja als free Version. Es liegt aber unter Linux ein scons-cross compile Script bei - das tut bei mir aber nicht (irgendwie raffe ich nicht, auf welche Pfade ich das stellen muss).

1.2.7 ist aber raus - brauchen wir also net mehr warten. Ich hab zufällig gesehen, als ich mit meinem neue kompilierten Client gegen den Bunker2 verbunden habe.
http://shitstorm.org/noquarter/wiki/index.php?title=No_Quarter_Mod
http://wolfmap.de/details.php?file_id=3479

[TheJester]

Prima, ich bau das 1.2.7 mal ein, vielleicht ists dann ja weg.

Die letzte Crosscompile Umgebung hab ich vor 5 Jahren aufgesetzt..naja mal sehen vielleicht klappt das ja noch Ich stecke den ET Source mal in ein hg repo auf hg.timelord.de

[x3t0]

haben die denn das array gefixed in der neuen version? ... es ist ja eher davon auszugehen, dass das immernoch die standardgrösse hat und sie trotzdem weitere cvars hinzugefügt haben, was das problem ja eher noch verstärken würde.

ich hab hier nen vs2005 pro, ich probiers damit mal. Die freeversion macht so einige dinge nicht leider, hatten wir im labor schon öfter probleme mit

[TheJester]

Sie können ja maximal die Serverseite ändern. Also ich vermute mal dass sie entweder ihre Entities beschränkt haben oder irgendwie die Ausgabe der Statusvariablen auf 16k einschränken.

Das Problem hätten wir eh, auch wenn wir den Client neu übersetzen, jeder müsste den auch benutzen. Also imho würde das nur sinn machen wenn wir wirklich die Zeit haben und unsere "eigene" ET Distribution verteilen wollen. Compilieren tut das ganze praktisch out of the box. Connecten hab ich noch nicht versucht, dazu muss man das Binary ja auch noch mit dem Content (pak0 etc) versehen.

Das NQ liegt schon auf dem Server, ist aber noch nicht installiert. Ich werds erstmal einfach ausprobieren, als fix sollte das ja reichen, wenn es läuft.

[jomu78]

Ich habs so verstanden, dass sie aufgeräumt haben und unbenutze CVARs rausgeworfen haben. Außerdem gabs wohl irgendwas was nicht freigegeben worden ist - und das führt dann zu dem Buffer Problem

[jomu78]

Server ist aktualisiert - wir haben jetzt NoQuarter 1.2.7 und damit hoffentlich wieder Ruhe.
Fürs Admin Protokoll:

• Das Installationsverzeichnis von Noquarter hat sich auf nq geändert - noquarter liegt im nq verzeichnis
• in der etded.sh von +set fs_game noquarter auf +set fs_game nq umgestellt
• ich habe das noquarter im .etwolf sicherheitshalber weggesichert und gelöscht
• backups liegen im Verzeich is ~/backup

Für die User: einfach connecten, NQ 1.2.7 ziehen und dann hoffentlich ruhe was den MAX_GAMESTATE_CHARS_EXCEEDED Fehler betrifft.

Gruß
jomu aka aushilfsadmin

[x3t0]

sehr nice jomu danke