Posts by red51
-
-
Habe den Beitrag mal in einen separaten Thread verschoben
Jedenfalls wird im Multiplayer die Tagesdauer durch die Einstellung Settings_TimeDuration in der "server.properties" Datei im Spielverzeichnis festgelegt. Standardwert ist 60 (60 Minuten == 1 Ingame Tag), wenn du zB Realtime möchtest, müsstest du 1440 dort eintragen (60 Min * 24 h) 
Allerdings wird die Zeit damit nicht direkt mit der realen Zeit synchronisiert. Möchtest du das, oder gehts dir nur um die Tagesdauer?
-
Danke für die Rückmeldung, eigentlich hätte ja sonst wieder ein Crash sein müssen? Dann wird es wohl wirklich an der SATB-Queue liegen... ich arbeite noch an einer Lösung
-
Aber die Npcs die sich bewegen haben auch definitiv den Statisch Flag, d.h. auch nach Spielstart ist der noch da, oder?
-
red51 wäre es evtl möglich über den integrierten webserver plugindaten bereitzustellen? Ich überlege gerade wie es möglich wäre z.b. die karten-oberflächendaten bereitzustellen ohne das man zusätzlich noch mein nodejs backend auf dem server installiert haben muss. Das ist in den meisten Fällen wahrscheinlich eh nicht so ohne weiteres möglich. Es würde reichen wenn ich über ein plugin eine Datei erstellen kann, z.b. json und die dann so speichern kann das es über den webserver abrufbar ist. Gut für die Oberflächendaten wäre wahrscheinlich eine sqlite kopie sinnvoller aber war ja auch nur ein beispiel, obs jetzt eine json Datei oder eine db Datei ist kommt aufs selbe raus. Jedenfalls muss es kein route handler sein der auf anfragen reagiert oder sowas.
Ja, das müsste möglich sein
Wahrscheinlich wäre es sogar am einfachsten, wenn das Plugin einen eigenen Route-Handler registriert. Vll wäre dann ein API-Event HttpRequestReceived o.ä. am sinnvollsten, wo du die Http-Methode (GET, POST, PATCH etc) bekommst sowie den Header, und du dann über das Event die Response festlegen kannst. Würde das so passen? -
Sorry für die späte Antwort! Das ist echt merkwürdig, denn spätestens mit dem Static bzw. Statisch Flag sollten Npcs sich nicht mehr bewegen
Wenn dieser Flag aktiv ist sollten Dinge wie Kollision usw. keine Rolle mehr spielen. Wann genau ändern sich die Positionen denn? Immer nach einem Spielstart? Was passiert wenn du den Befehl refreshnpcs eingibt (damit werden alle Npcs neu geladen), ändern sie dabei auch ihre Position? -
Danke für die Logs übrigens! Ist das mit dem Port immer so? Also auch wenn du nach einem Start zB direkt neustartest? Oder nur gelegentlich?
-
Hmm da durch meine Shop und Marketplace viele assets aus dem spiel geladen werden vielleicht? (also Case 2) Discord Connect lief ja schon länger ohne Probleme vorher, klar kann das ein zusätzlicher Faktor sein aber zuletzt kamen Shop und MArketplace dazu, die haben eigentlich keine Threads, höchstens ein paar Timer im Shop für den refill, aber der dürfte planmäßig nur einmal die Stunde laufen. Bin mir gerade nicht sicher ob er da einen eigenen Thread für macht. Laut KI jedenfalls nicht.
Also wenn die Assets aus dem Spiel geladen werden, dann werden da eigentlich keine Daten ausgetauscht, zumindest nicht über den Webserver
Die sollten diesen Bug also eigentlich nicht triggern... nur normale Assets, die auch tatsächlich vom Server heruntergeladen werden (aber auch hier ist das eher bei neuen Spieler relevant, da nach dem Download die Assets lokal gecached werden).Timer verwenden auch keine Threads, auch die Plugin-Funktionen executeDelayed() oder enqueue() verwenden keine Threads.
Aber ich werde mit der nächsten Gelegenheit eine Änderung einbauen, mit welcher die "Create new JNIEnv" (zumindest bei aktivierten Debug-Optionen) zusätzlich auch einen Stacktrace ausgibt (für C# und Java), dann würde man sofort sehen, woher die Threads tatsächlich kommen
Aber idealerweise ist der Bug mit den leakenden JNIEnvs (was letztenendes den SATB-Crash verursacht) bis zum nächsten Update auch sowieso behoben 
kann ich den Xms wert eigentlich auch über eine server property steuern oder muss ich den mit Plugins_VMOptions überschreiben? Die KI meint der Wert wäre etwas niedrig gewählt
Sorry, ich habe die Frage oben übersehen
Aber ja, auch dafür gibts eine Einstellung, leider aber versteckt. Du musst dafür Plugins_InitialMemory zur server.properties hinzufügen, also zB Plugins_InitialMemory=512 für 512 MB Startmemory. Standardmäßig ist das nur auf 32 gesetzt (was wir vll tatsächlich etwas anheben könnten) -
Die chunk x z Ausgabe findet hier statt: https://github.com/Devidian/rw…dMapChunkCapture.java#L30
Oh, vielen Dank für den Link! Auf dem ersten Blick sehe ich tatsächlich keine Threads, die da erzeugt werden.. auch der native Code, der dort aufgerufen wird, läuft komplett synchron, also auch hier keine Extrathreads o.ä
Habe noch etwas tiefer gegraben und denke nicht, dass die AdminUtils relevant sind... die häufigen JNIEnv-Ausgaben bzw. die scheinbar häufigen Threads scheinen stattdessen 2 Ursachen zu haben:
1. DiscordConnect bzw. JDA: Die Umstellung von Javacord auf JDA ist auf jeden Fall hilfreich und führt auch zu deutlich weniger Threads, aber in ForkJoinPool und OkHttp sind weiterhin Threads, die sterben bzw. kurzlebig sind.
2. Aber auch der Asset-Download des Servers, was (um das Netzwerksystem bei großen Daten nicht zu überlasten) über den Webserver läuft. Das ist tatsächlich die eine Stelle im Server (genau genommen der darunterliegende HttpListener), die ebenfalls Threads verwendet, die sterben.
Was genau die Crashes verursacht ist schwer zu sagen, aufgrund der Häufigket würde ich zu 1 tendieren, aber sowohl 1 als auch 2 haben das Potenzial dazu.
Nichtsdestotrotz ist das so oder so ein Bug in der API. D.h. das Plugin macht definitiv nichts "falsch", denn auch mit sterbenden bzw. kurzlebigen Threads muss die API umgehen können
Die Session lief bis zum geplanten Neustart einwandfrei durch und es waren einige Spieler aktiv
Freut mich, wenn der andere GC geholfen hat!
Das würde die ganze obige Theorie mit der SATB Queue und den JNIEnvs tatsächlich bestätigen. Ich schaue aber trotzdem weiter nach einer robusten Lösung, damit die API mit kurzlebigen Threads umgehen kann. Und Punkt 2 oben ist ohnehin relativ einfach zu beheben (auch wenn ich nicht glaube, dass das die häufigen Crashes in diesem Fall verursacht, ist es trotzdem ein potenzieller Kandidat für solche Crashes)^^interessant ist hier das er shutdown macht aber danach 5 mal neustarten muss weil er das problem mit dem port hat. Du hattest mal gesagt das man in den settings Server_RestartEnabled=False verwenden soll, aber geholfen hat es nicht
Hast du evtl. einen Log vom Start (wegen dem blockierten Port)?
komisch - seit gestern erhalte ich wieder hs-err-pid Dateien und deswegen hab ich heute direkt mal auf den ParallelGC gewechselt (nicht, dass das wieder zur Gewohnheit wird)
Danke für die beiden hs_err_pid Dateien! Traten denn mit dem ParallelGC auch weiterhin Crashes auf? Rein auf den ersten Blick scheinen die Crashes tatsächlich die gleiche oder zumindest eine ähnliche Ursache zu haben: Hier scheint es auch kurzlebige Threads zu geben (konnte aber keinen Anhaltspunkt zu DiscordConnect oder OkHttp o.ä finden, daher wohl eine andere Quelle, die die Threads erzeugt). Sieht nach Java Threads aus, kann aber nicht ausschließen, dass es vll auch vom AssetDownload bzw. Webserver kommt.
In jedem Fall müsste aber der ParallelGC auch hier helfen.
Bitte sage mir nicht, dass es mit ParallelGC weiterhin crasht, denn dann würde das Kartenhaus schnell in sich zusammenfallen
(in dem Fall aber bitte gerne eine neue hs_err_pid)warum bekommst du hs_err_pid dateien aber ich nicht 😢😅
Ich könnte mir vorstellen, dass es evtl. mit Linux und Docker zusammenhängt
Unter Linux wird der Crash anders behandelt und lt. Log wird das auch tatsächlich an Unity weitergegeben bzw. von Unity ausgegeben. Unter Windows behandelt die JVM die Crashes anders.Wahrscheinlich könnte aber auch Docker eine Rolle spielen... vll könnte es helfen, einen festen Pfad für die hs_err_pid Datei zu vergeben. Das kann mit der JVM Option -XX:ErrorFile= gemacht werden (zB -XX:ErrorFile=/Logs/hs_err_pid_%p.log). Du kannst in der server.properties mehrere JVM Options mit Semikolon getrennt angeben. KA ob das wirklich hilft...
-
Vielen Dank für die neuen Logs! Die Crashes treten an der selben Stelle auf, da liegt also offensichtlich die selbe Ursache zugrunde... ich vermute stark es hängt mit der Ausgabe Create new JNIEnv zusammen, was einfach auffallend häufig vorkommt. Verdächtig ist, dass es meist kurz nach der Ausgabe [Java] [OZ.AdminUtils] chunk xx xx updated kommt. AdminUtils erzeugt aber keine neuen Threads, oder? Welche Methoden ruft diese Stelle auf? Ist das evtl. die Screenshot Funktion? Kannst du mir diesen Code sonst evtl. mal senden (gerne auch per PN)?
Das mit den Blueprints könnte reiner Zufall sein (oder lauscht du zufällig auf die entsprechenden Events und machst da etwas spezielles)?
Wenn im Plugin sonst aber wirklich keine neuen Threads erstellt werden, vermute ich, dass es wohl irgendwie mit den Callbacks zusammenhängt, dass immer neue JNIEnvs erzeugt werden. Ich gehe auch stark davon aus, dass das für die Crashes verantwortlich ist, denn JNIEnvs werden nicht automatisch aufgeräumt oder detached. Sie werden aber trotzdem vom GC geprüft. Wenn sie nun von OS-Seite sterben und implizit aufgeräumt werden, könnte das unter Umständen den Crash erklären (da JNI weiterhin die Referenz hält).
Eine potenzielle Lösung für das Problem: Einen anderen Garbage Collector verwenden. Das Concurrent-Marking verursacht das Problem, d.h. ein anderer GC ohne SATB-Buffer würde wahrscheinlich keinen Crash verursachen. Du könntest testweise die server.properties Datei öffnen und unter Plugins_VMOptions mal -XX:+UseParallelGC eintragen, also:
Das sollte einen anderen GC verwenden, der keine SATB Buffer benutzt. Ist natürlich keine richtige Lösung für das Problem (da es möglicherweise etwas die Performance schmälert), wäre aber testweise mal interessant zu wissen, ob die Crashes dann weiterhin auftreten. Falls es dann sauber läuft, würde es höchstwahrscheinlich wirklich an obiger Theorie liegen.
-
Danke für die neuen Logs! Die Optionen sind da tatsächlich korrekt gesetzt. Ich stelle aber gerade fest, dass die Zusatz-JNI Ausgaben leider nicht von der Log-Datei erfasst werden
Dem muss ich auch noch einmal auf den Grund gehen... denn bereits beim Start bzw. Laden der ersten Plugins müssten bei den gesetzten Einstellungen mehrere [debug][jni,resolve] Ausgaben auftauchen.Kannst du den Server evtl. so starten, dass der Prozess von sich aus alle Ausgaben umleitet? Also dass stdout und stderr in eine Datei umgeleitet werden (müsste mit RisingWorldServer > rwserver.log 2>&1 klappen). Das dürfte dann endlich mehr Informationen ausspucken
-
Hmm... unfortunately it's hard to tell why the horse died
Maybe I can add a way to find out the reason of death for an animal (that might help to find out if it was killed by a player or died due to damage etc).Right now horses can only die in these cases:
- Player hits/attacks the horse
- Projectile hits the horse
- Horse is close to an explosion
- Fall damage (>5 blocks, always deadly if >= 30 blocks)
- Horse touches fire
- Horse touches lava (hell)
- Horse steps into a trap (bear trap)
- Horse drowns in water
- Horse gets stuck in terrain for too long
If there wasn't another player who killed the horse, I can only imagine that fall damage was responsible for that (or the horse got stuck in terrain, or more precisely, below terain for too long, but that's a bit unlikely)...
Okay—if that really is my stable building, the floor surface poses a problem for the horses. When they try to enter the stable, they are instantly teleported onto the roof and can't get back down.
This is unfortunately a bug... this already happened before, but got worse with the last update (especially affecting horses)
Maybe that's the reason why the horse died (i.e maybe it fell off the roof)? Anyway, this bug will be fixed with the next update -
I don't know if is easy/performant to implement but will be wonderful to have some event like
Oh, sure, I can add a new PlayerEnterBiomeEvent with the next update (it will work similar to the PlayerEnterSectorEvent)
-
Gerade geprüft auf meinem dev server ist das sogar beides true schon
Hmm... hast du das kürzlich erst aktiviert?
Laut den prod-crash.log sind die Optionen nicht aktiv, also die nöten Argumente werden nicht an die JVM übergeben... ist das ein anderer Server oder waren sie da noch nicht aktiv? Sonst ist es möglicherweise auch ein Bug -
Do livestock have life span now? I have a person that lost two male horses now.
No, that hasn't been added yet (animals have an age, but this has no impact, so they will never die of old age). If a player cannot find their horse anymore, they can try the findmount console command - it will highlight the position of the last used mount
-
Hmm... basically horses (or other animals) should not die of old age... they can only die if they get damage (fall damage, touching fire, getting attacked by a player etc)
If there is a cave right below the horses, are they maybe there (just in case they fell through the ground for some reason)?
Otherwise you could also try the findmount console command (you can open the console by pressing ` or ~). This will highlight the position of the last mount (but this only worked if you didn't use another mount in the meantime)
-
Der Befehlt ließe sich schon deaktivieren aber der ist so alt, den gabs schon in der Java version und bisher hat er nie Probleme gemacht 😅, wenn dann ist es eher mit der Anzahl der Plugins als Nebenerscheinung dazu gekommen.
Naja, in der Java Version war alles wirklich pures Java, kein fragiles Bindeglied (JNI) zw. API und Spiel. Die meisten API-Objekte (zB "Player") waren die tatsächlichen spielseitigen Objekte (nur halt mit Zusatzfunktionen, die für die API bereitgestellt werden). Da war das Risiko für solche Crashes ohne Exception oder konkrete Fehlermeldung wirklich nahe 0
JNI ist hingegen leider schon sehr pingelig und gleichzeitig gnadenlos. Jeder Fehler auf nativer Seite (während des API-Aufrufs) führt unweigerlich zu einem SIGSEGV oder stillen Crash (und da ist dann meist sehr schwer abzuleiten, wo genau der Crash entsteht). Darüberhinaus können Objekte nicht so leicht zwischen nativer und Java Seite ausgetauscht werden (sondern müssen als spezielle Referenzen registriert werden, davon jedoch gibts auch Limits usw)... es ist leider eine sehr breite Fehleranfälligkeit gegeben
---
Bei genauerer Betrachtung der Screenshot-Funktion könnte ich mir aber eine potenzielle Fehlerquelle vorstellen: Da hier das Objekt in einem Callback erzeugt wird, also nicht direkt Teil des Rückgabewertes ist, wird die Referenz darauf nicht automatisch von JNI aufgeräumt, sondern muss manuell freigegeben werden (was das Spiel an der Stelle nicht macht). JNI kann automatisch nur 16 lokale Referenzen handeln. Zwar sollte es danach nicht crashen, aber da hier auch relativ große Objekte dran gekoppelt sind (BufferedImage) die nicht freigegeben werden können könnte ich mir potenziell vorstellen, dass ein GC beim Durchlauf vll auf Probleme stößt (weshalb der Crash meist später beim GC passiert). Ist nur eine Vermutung, aber ich werde diesen Bug auf jeden Fall mit dem nächsten Update beheben. Und ich werde auch alle anderen Stellen, an denen das Spiel mit Callbacks arbeitet, einmal prüfen, da hier theoretisch dasselbe Problem vorliegen könnte (wobei die Screenshot-Funktion vmtl. aufgrund der großen Daten am problematischsten ist)
Hmm spontan wüsste ich nicht welches Plugin öfter neue Threads generieren sollte. In einem log von vorgestern wo es zwischen den Neustarts (3:00-17:00 GMT) kein crash war, ist Create new JNIEnv 192 mal zu finden.
Das ist schon auffällig viel
Die Meldung kommt aber immer dann, wenn ein neuer Thread eine JNIEnv benötigt... es gibt da eigentlich auch keinen Mechanismus, wodurch ein Thread "vergessen" wird o.ä. (die Thread ID ist ja auch immer eine andere).Ich schaue mal, ob ich da evtl. mehr Debug-Möglichkeiten einbauen kann (damit man evtl. sieht, welcher Thread das jeweils ist).
Ja es ist schwierig herauszufinden, ich hab schon alles an logging aktiviert aber es kommt kein hint auf den Verursacher.
Du könntest evtl. zusätzlich auch einmal folgende Einstellung zur server.properties hinzufügen:
Plugins_JNIVerbose=True
Dann werden zusätzliche Meldungen ausgegeben (gerade auch in dem oben genannten Fall, also wenn zu viele Local Refs vorhanden sind, müsste JNI dann eigentlich was ausgeben). Könnte den Log aber etwas zuspammen.
Ggf. könntest du auch Plugins_JNIXcheck=True hinzufügen, das könnte aber etwas Overhead mit sich bringen. Damit führt Java zusätzliche Validierungen und Prüfungen durch. Wichtiger wäre aber vmtl. obige JNIVerbose Einstellung
-
Ja, das ist leider ein Bug... es sah im Code aber so aus, als wenn man den noch nie aufheben konnte
Jedenfall wird das mit dem nächsten Update behoben -
Basically the only reason why the game does not expose the biome or region is that there is no object in the API representing the biome/region definition
But I think I can add them with the next update. Then I can also add a getBiome() and getRegion() method to the player -
Sorry für die späte Antwort! Leider ist ohne hs_err_pid schwer echt zu sagen, wo der Crash herkommt bzw. was ihn verursachen könnte
Da wäre naheliegend, dass es kein direkter API-Aufruf den Crash verursacht hat... lt. Stacktrace besteht aber scheinbar ein Zusammenhang mit der API.Da der Crash offenbar sehr sporadisch auftritt ist es wahrscheinlich schwierig, das auf ein bestimmtes Plugin einzugrenzen, oder?
Die Meldung Create new JNIEnv tritt grundsätzlich immer auf, wenn ein neuer Thread eine API-Methode verwendet (da jeder Thread seine eigene JNIEnv-Instanz benötigt). Gibt es ein Plugin, welches viele oder immer neue Threads spawnt? 56 ist schon ein bisschen was... meiner Meinung nach sollte das aber eigentlich kein größeres Problem darstellen
Oben war ja zwischendurch der Screenshot-Befehl grob im Verdacht? Welchen Befehl oder welche Methode verwendest du denn genau? Ist es sonst möglich, testweise Screenshots ganz zu deaktivieren (um zu sehen ob es dann auch Crashes gibt)?
Du wolltest oben ja Items aus dem Shop entfernen, danach ist es aber trotzdem wieder gecrashed (oder waren die Items zu dem Zeitpunkt wieder drin)?
