Sorry für die späte Rückmeldung! Tut mir Leid zu hören, dass die Probleme weiterhin auftreten... offensichtlich liegt es nicht am Plugin. Es sieht trotzdem so aus, als wäre irgendwo eine Endlosschleife o.ä. Der Server verwendet mehrere Threads, und einer der Threads hängt offenbar fest - darum läuft zwar der Server an sich noch weiter (mit Speicherausgaben), aber niemand kann mehr connecten 
Um wirklich herausfinden zu können, was da überhaupt hängt, bräuchten wir das nächste Update, was explizit ein Monitoring dafür haben wird... das nächste Update war eigentlich zusammen mit dem Storepage-Update geplant, aber evtl. ziehen wir es etwas vor. Das könnte etwas Licht ins Dunkel bringen.
Gibt es denn irgendeine Aktion, die das Verhalten hervorruft (also den Verbindungsverlust)? Wenn der betreffende Spieler rausfliegt (und du zufällig [noch] online bist), kannst du ggf. einmal serverinfo network in die Konsole eingeben? Die Ausgabe davon könnte interessant sein... du könntest dann vll entweder einen Screenshot hier posten oder alternativ einen Report danach senden (einfach anschließend report in die Konsole eingeben) 
Mir waren in den Log-Files Warnungen aufgefallen, die sich auf fehlende Permission-Keys bezogen:
Diese Permission Keys gibt es tatsächlich nicht. Statt chatcolor_chatnamecolor ist vmtl. info_chatnamecolor gemeint. Auch ein chatcolor_deny gibt es nicht, vmtl. war info_chat gemeint (womit der Chat generell erlaubt/verboten werden kann)?
Anschließend habe ich eine neue Permission-Gruppe mit dem Namen "player" erstellt und versucht diese dem betroffenen Spieler zuzuweisen. Dabei ist es zu einer Fehlermeldung gekommen, ohne Absturz des Servers:
Danke für den Hinweis, das ist tatsächlich ein kleiner Bug! Allerdings ist der harmlos und hat keine Auswirkung auf den Server, der Befehl wird auch trotzdem ausgeführt - nur bekommt man in der Konsole keine Rückantwort durch diesen Bug 
Allerdings wurde gleichzeitig bis zum Morgen alle 2 Minuten erfolglos versucht den Server erneut zu starten, wie die Log-Files zeigen.
[...]Am Morgen habe ich den Server manuell gestoppt und wieder gestartet. Danach war wieder alles in Ordnung. Vermutlich hängt das irgendwie mit dem Scheduler zusammen
Das Problem ist, dass Steam einen Port nicht freigibt (4254 UDP)... die Situation scheint sich neuerdings leider etwas verschärft zu haben und der Port zu lange blockiert bleibt. Vor allem wenn der Server nicht ordnungsgemäß heruntergefahren wird.
Wahrscheinlich ist der Port aber effektiv gar nicht mehr unbedingt blockiert, sodass wir die Prüfung für den Steam-Port vmtl. einfach entfernen können. Das Problem können wir also evtl. mit dem nächsten Update fixen.
"Du wurdest vom Server gekicked! Illegale State-Limite überschritten! Bitte überprüfe deine Internetverbindung und stelle sicher, keine modifizierten Spieldaten zu verwenden."
Ein "Illegal State" tritt auf, wenn der Server irgendwas feststellt, was für ihn nicht plausibel ist. Grundsätzlich ist es so, dass fast alle Aktionen des Clients vom Server nochmal verifiziert werden. ZB dass beim Aufheben von Items oder Zerstören von Bauteilen der Spieler nicht zu weit entfernt ist. Wenn zu viele "Illegal States" auftreten, wird der entsprechende Spieler gekicked.
In dem konkreten Fall wurde versucht, Bauteile zu entfernen, doch der Spieler war lt. Server zu weit davon entfernt (die erste Koordinate ist die Position, wo das Bauteil geschlagen wurde, und die zweite Koordinate ist die Position des Bauteils selbst).
Wie das in dem Fall zustande kam ist nachträglich leider schwer zu sagen... das kann mit Desync zusammenhängen (dass neue Spielerpositionen nicht beim Server ankamen), oder aber natürlich kann auch ein Bug dafür verantwortlich sein. In der Vergangenheit gab es das Problem häufig bei besonders großen Bauteilen (das ist aber *eigentlich* gefixed). Waren in dem Fall evtl. extrem große Bauteile involviert?
Neues zum Scheduler!
Heute Nacht ist der gleiche Effekt aufgetreten, wie in der Nacht zuvor:
- Der Scheduler arbeitete wie vorgesehen und restartete den Server erfolgreich und dauerhaft.- Gleichzeitig versucht er wohl im Hintergrund, alle zwei Minuten, eine zweite Server-Instanz zu starten, was aber zu einem Fehler führt. Übrig bleibt ein weiteres Log-File.
Am Morgen konnte ich mich problemlos auf dem Server anmelden, während weiterhin versucht wurde den Server ein zweites Mal zu starten. Aus dem Spiel heraus habe ich mittels Konsoleneingabe einen Shutdown ausgeführt. Daraufhin konnte der Prozess im Hintergrund den Server erfolgreich nachstarten. Danach wurden keine weiteren Start-Versuche mehr unternommen.
Hmm... aus den Log-Dateien geht das leider nicht direkt hervor Lt. 2024-10-22-11-02-29.log wird der Server nach exakt 12 Stunden (wie im Scheduler eingestellt) neugestartet (mit dem Hinweis "R E S T A R T S E R V E R" ganz am Ende). Soweit alles wie erwartet. Lt. 2024-10-22-23-02-34.log startet der Server dann korrekt neu (und erkennt auch, dass es ein Restart war). Nach dann aber knapp 11 Stunden wird der Server beendet ohne Hinweis auf einen Restart. Da der Server scheinbar nicht ordnungsgemäß beendet wurde, bleibt der Port blockiert (weshalb der Neustart fehlschlägt).
Auf mich wirkt es so, dass der 2. Restart extern durchgeführt wurde, also nicht vom Server selbst... denn es deutet nichts darauf hin, dass der Server den Restart initiiert hätte (und auch der Zeitpunkt stimmt wie gesagt nicht). Hat der Hoster vll so eine Mechanik?
Allerdings kann das eigentlich nicht durch den Scheduler-Restart verursacht werden 
Wenn der Server sich selbst neustartet, wird ausnahmslos immer ein -wasrestarted Parameter mitgegeben (und wenn dieser vorhanden ist, gibt der Server beim Start die Ausgabe Server was restarted before... aus). Es gibt nur eine zentrale Stelle für einen Restart (hier kann eigentlich nichts durcheinanderkommen oder dazwischenfunken). Das OS wird angewiesen, den bestehenden Prozess durch den neuen Serverprozess zu ersetzen (wenn das aus irgendeinem Grund OS-seitig nicht funktioniert, dann dürfte der Restart niemals korrekt funktionieren).
