Posts by red51

A new update is now available, introducing "Points of interest" and many more changes!
Latest hotfix: 0.9 (2025-11-04)

    In general, an illegal state error occurs if there is some sort of desync between the client and the server. More precisely, the client is acting in a way that's not plausible for the server. In most cases this is either caused by bugs or desync, although it might also be caused by modified game files. The server can set a "threshold" when the client should be kicked ("settings_illegal_state_limit" in the server.properties file).


    We can add a PlayerIllegalStateEvent with the next update, although I'm not sure about cancelling the event. If the event gets cancelled, the client will not be kicked from the server. But a client that is no longer in sync with the server might cause other issues =O

    Das nächsten Update wird ein ganzes Paket an Änderungen und Bugfixes enthalten, damit sollten die meisten Problem aus der Welt geschaffen sein :) Ich würde die Änderungen ja gerne schon jetzt zur Verfügung stellen, aber das Spiel ist derzeit im Zustand "Baustelle" (da wir noch mitten in den NPC Änderungen stecken) sodass wir leider nicht einfach so einen Hotfix rausbringen können :/


    Was die Verbindungsabbrüche angeht, @Deirdre, sieht es leider etwas schwieriger aus :( Wir haben nichts direkt am Netzwerk geändert, d.h. hier muss es irgendwelche anderen Ursachen geben =O Mittelfristig werden wir da definitiv eine Lösungen finden, nämlich komplett auf UDP umsteigen. Das ist zwar vom Grundsatz her nicht ganz für ein Spiel wie RW geeignet, da UDP (im Gegensatz zu TCP) nicht "verlässlich" ist, d.h. Pakete können jederzeit verloren gehen (was zwar bei Dingen wie Spielersynchro egal ist, aber wenn ein Chunk angefordert wird und zwischendurch verloren geht, ist das schon kritischer). UDP ist aber im Gegensatz zu TCP "verbindungslos", d.h. es wird keine richtige Verbindung aufgebaut (selbst wenn also das Internet für ne Sekunde aussetzen würde, wäre das egal, danach kommen einfach die nächsten Pakete wieder an).
    Tatsächlich verwenden die meisten Spiele nur UDP, vermutlich um dem Dilemma mit TCP und Verbindungsabbrüchen aus dem Weg zu gehen. Zwar ist es hier immer schwierig, andere Spiele mit Rising World zu vergleichen, da RW verhältnismäßig viele (wichtige) Daten übertragen muss (Chunks, Bilder etc, häufig auch auf mehrere Pakete aufgeteilt) und hier eher TCP prädestiniert wäre. Aber es sieht so aus, als würde es Seitens der ISP vermehrt Probleme geben (allein schon dieses altbekannte Problem mit den 10-minütigen Disconnects bei manchen Kabelanbietern, also die bewusste Unterbrechung der Verbindung und gleichzeitige Verhinderung, dass direkt eine neue Verbindung aufgebaut wird).
    Ich kann dir leider nicht sagen, wann wir diesen Wechsel genau vollzogen haben werden. Es wird Teil einer wesentlich umfangreicheren Änderung sein, aber falls sich deine Verbindungsabbrüche bis dahin nicht beheben lassen, wird es spätestens dann Besserung geben ;)

    Es hängt nicht mit dem ISP zusammen, das war ein Missverständnis ;) Denn das war nur darauf bezogen, wenn ein Verbindungsverlust auftreten würde (also man landet im Hauptmenü mit der Meldung, dass die Verbindung unterbrochen wurde, bzw. schon während des Spielens kommt die Meldung, dass die Verbindung zum Server verloren geht).


    In dem konkreten Fall ging es aber um einen Absturz des Spiels, was aus Serversicht logischerweise wie ein Verbindungsabbruch aussieht, tatsächlich aber nichts mit der Verbindung bzw. dem Server bzw. dem Netzwerk bzw. dem Provider zutun hat.


    DIe Err datei sagt direkt mal JAVA fehler <X
    wunderts jmd? :cursing:

    Wenn ein Fehler auftritt, also eine Exception geworfen wird, steht darin immer der Verweis auf Java (bzw. genau genommen auf den Namespace, in dem sich "Exception" befindet, nämlich "java.lang"). Das hat nichts mit Java zutun. Wenn das Spiel etwas falsch macht, ist es egal, in welcher Sprache es geschrieben ist (wobei wir bei Java immerhin den Luxus haben, in den meisten Fällen Hinweise darauf zu bekommen, was genau schiefgelaufen ist) ^^
    Bei einem native Crash hingegen (also wenn keine Fehlermeldung angezeigt, sondern lediglich eine hs_err_pid Datei im Spielverzeichnis angelegt wird) trat der Fehler "weiter unten", also irgendwo außerhalb der Kontrolle der JVM auf. Meistens sind das eher Treiberprobleme, aber kann auch durch bestimmte Bugs auftreten.


    Am besten ist es, im Falle eines Fehlers immer die vollständige Log-Datei zu posten (also entweder die hs_err_pid Datei aus dem Spielverzeichnis, oder die Fehlermeldung [falls eine Fehlermeldung auftrat]). Denn auch wenn die meisten Fehler auf dem ersten Blick identisch aussehen (gleiche Überschrift o.ä), sind sie in Wirklichkeit häufig grundlegend verschieden :)

    You can check out the temperature once the computer has rebooted. If the crash was caused by a high temperature, it would still be high after a restart.


    I get the feeling that the Java writes in memory an invalid address and windows is protected

    Well, that would mean that there is a bug in Java, but this is very unlikely, especially since it's widely used and there would be a lot more people suffering from such a blatant bug... and the game itself cannot access memory which was not allocated by the JVM :|

    It's difficult to compare RW with other games, since RW is much more demanding for your hardware due to the procedurally generated world =/ But if the temperatures are fine, it might also be a hardware issue (PSU, memory or something like that) or a driver issue (although driver issues usually result in a BSOD).

    If the computer crashes, it's usually not a software issue, in most cases it's either caused by a hardware issue, a driver issue or a temperature issue. You should check out the GPU and CPU temperature while playing, if it's getting too high, this might be the reason for the crash. High temperatures indicate that there might be a cooling issue (e.g. cooler clogged with dust).

    Oh, sorry für die missverständliche Formulierung! Ich meinte tatsächlich den Internetprovider der User 8|
    Wenn du aber sagst, dass das Spiel der Userin abstürzt, dann ist das kein Verbindungsabbruch in dem Sinne (hat also nichts mit dem Netzwerk oder Internet des Users oder Servers zutun). In dem Falle müsste sich im Spielverzeichnis der Userin eine Datei "hs_err_pid" befinden, vielleicht kann sie uns die ja zukommen lassen (entweder hier im Forum, oder per Mail an support@jiw-games.net).


    Aber auch dieser Absturz hat nichts mit dem Server zutun, sondern entweder mit einem Bug im Spiel, oder aber mit einem technischen Problem auf Userseite (Treiberproblem o.ä.)

    Unfortunately we didn't release an update, this was apparently just Steam updating some dependencies :(
    We're still working on the update. A few days before the update goes live, you will find the usual blue banner in the forums ;)

    mitlerweile kann eine stammspielerin nicht mehr als 1 min auf dem Server sein.
    Sie war sons Stundenlang auf dem Server ohne Probleme und jetzt auf einmal kann sie nur noch ganz kurz auf dem server sein.

    Das ist echt eigenartig =O Wir haben nichts am Netzwerksystem verändert, zumal das letzte Update ja ohnehin etwas her ist... irgendwie kommt es mir langsam so vor, als hätte der Provider etwas geändert (denn alle User, die in letzter Zeit aus heiterem Himmel dieses Problem haben, sind beim gleichen Provider) 8|


    Was passiert denn auf Seite der Userin? Bekommt sie die Meldung "verliere Verbindung", oder stürzt evtl. das Spiel ab oder tritt eine Fehlermeldung auf o.ä? Seit wann hat sie das Problem? Tritt es wirklich erst seit jetzt auf?

    Sorry for the late response! One thing that could result in a GameMismatch exception would be a wrong app id that's provided to the server. There should be a text file called "steam_appid" in the server directory, please open it with a text editor and make sure it contains the app id of the game (324080).



    Maybe you can send me your server ip + port (if you don't want to post it here, just send me a PM)?

    Eine Lösung dafür wäre schön, es ist etwas nervig so zu bauen.

    Ich denke das Problem dürfte mit dem nächsten Update behoben sein ;) Falls es danach weiterhin auftreten sollte, lass es mich bitte wissen.


    das es Probleme gibt beim löschen mit "undoblueprint" oder auch "F7" würde hier ja auch schon mehrfach angesprochen.
    Nun ist es so, dass auch Dinge die einzeln mit der Spitzhacke weggeschlagen würde, auch nicht komplett verschwinden.


    Anscheindend betrifft das alles nur gesetzte Blaupausen.

    Das "undoblueprint" Problem wird ebenfalls mit dem nächsten Update behoben. Ein Bug i.V.m. der Plugin API (auch wenn keine Plugins geladen waren) führte leider zu einer kleinen Desync zwischen Client und Server (auch im Singleplayer, denn technisch gesehen läuft auch hier lediglich ein lokaler privater Server im Hintergrund), wodurch zwar das Gebäude meist beim Client entfernt wurde, nicht aber beim Server (dadurch waren die meisten Sachen nach einem Reconnect oder neu-laden der Chunks wieder da).


    Blueprints waren da. Ja, nur die Felsen auch wieder

    Auf welchem Server spielst du genau? Das abgebaute Felsen wieder auftauchen ist schon eigenartig und würde eher auf andere Probleme hinweisen 8|
    Fehlten die Bauteile des Blueprints auch nach einem Reconnect noch?

    Generell kannst du (zumindest grob) herausfinden, ob es wirklich am Server liegt, wenn du beim Herumfliegen die Debugausgabe (F3) aktivierst und einen Blick auf die 10. Zeile (4. Zeile vom 2. Absatz) wirfst. Dort sind Requested Chunks: x (LOD: x, CA: x) angegeben. Das gibt die Anzahl der Chunks an (die Zahlen hinter LOD und CA sind ebenfalls relevant), die vom Client angefordert, aber noch nicht vom Server geliefert wurden. Unter normalen Bedingungen sollten sich diese Werte - wenn sie größer als 0 sind - rasch wieder reduzieren. Auch wenn es mal 1-2 Sekunden dauert, bis die Zahl "abgearbeitet" werden, ist das i.O. Problematisch wird es aber, wenn sich diese Zahl ewig nicht reduziert.


    Die Serverperformance hängt nicht nur von der CPU um vom RAM ab, sondern auch von der Geschwindigkeit der Festplatte. Es spielt auch eine Rolle, ob SQLite oder MySQL verwendet werden (und im Falle von MySQL spielt die Geschwindigkeit des MySQL Servers eine Rolle). Und natürlich ist auch die Bandbreite von Relevanz, da recht viele Daten übertragen werden müssen (umso mehr, je stärker und detailreicher die Welt bebaut und je mehr Bilder platziert wurden).


    Handelt es sich bei deinem Server um einen eigenen Server (also ein vServer oder Rootserver), oder um einen Gameserver (also zB explizit ein RW Server)? Leider erleben wir bei manchen Gameserver-Hostern (ohne Namen nennen zu wollen) immer wieder, dass die angebotenen RW Server viel zu wenig Leistung bieten. Wir haben schon Fälle gesehen, dass "gute" und relativ teure Gameserver teilweise langsamer waren als so mancher 2€ vServer =O Das betrifft natürlich nicht alle Hoster und ich will damit auch nicht sagen, dass das zwangsläufig auf deinen Hoster zutrifft (ich weiß ja nichtmals, wer dein Hoster ist), aber alleine solche Sachen können schon zu einer Menge Ärger führen...


    Was den RAM Verbrauch angeht: Der RAM, der von Java reserviert wurde, wird - solange der RW Server läuft - nicht mehr für andere Anwendungen freigegeben (auch wenn der reservierte RAM nicht verwendet wird). Von "außerhalb" des RW Servers ist es schwierig, genaue Aussagen über den tatsächlichen RAM Verbrauch zu treffen, da Java direkt von Anfang an - je nach Auslegung des Betriebssystems - mehr RAM reserviert als verwendet wird.
    Um den tatsächlichen RAM Verbrauch festzustellen, kannst du den Ingamebefehl getserverinfo memory verwenden. Dort siehst du bei "Used memory" wieviel RAM in Wirklichkeit verbraucht wird. Ggf. ist es sinnvoll, den Befehl mehrmals hintereinander einzugeben, da sich die Zahl in manchen Fällen zügig ändern kann ;)


    Die Meldung Connection reset by peer besagt prinzipiell nur, dass die Verbindung vom Client unerwartet unterbrochen wurde. In den meisten Fällen wird diese Meldung vmtl. nicht die Ursache, sondern die Folge davon sein, dass der Client den Ladevorgang abgebrochen hat. Wenn der Spieler nicht auf den Server kommt kann das natürlich viele Gründe haben. Wenn der Server scheinbar Probleme mit dem Generieren und dem Senden der Welt hat, kann das sogar schon die Ursache dafür sein...


    Wegen dem Motorboot: Das ist leider ein Bug. Wenn das Motorboot schneller als die Weltgenerierung ist, wird es ungewollterweise nicht an der Stelle "gefreezed", sondern fährt ungehindert weiter und verlässt den Bereich, der eine "Kollision" hat. Als Folge fällt das Boot durch die Welt :S


    Eventuell kannst du mir einen Serverlog zusenden (von einer möglichst langen Spielsession, in welcher die Probleme auftraten)? Entweder hier im Thread posten, oder mir direkt via PN senden. Vielleicht enthält das ein paar weitere Informationen darüber, was da in Wirklichkeit los ist :)

    I've moved your post into a new topic since I'm not sure if it's really related to the other topic ;)


    How do you run your server exactly? Do you use SteamCMD? Or do you run it from your Steam client (or through the start script)? Do you use Windows or Linux?