Posts by red51

Quote from Devidian

Dafür könnte man ja ein exposePlugins in die server.properties einfügen was per default false ist. Wenn ich meine Plugins dann entsprechend anpasse, werde ich genau so vorgehen, so war der plan.

Ja, das wäre natürlich möglich Würde das dann aber standardmäßig vmtl. deaktivieren, d.h. ein Admin müsste die Einstellung explizit auf true setzen, damit es funktioniert. Wahrscheinlich würde ich sie dann Plugins_ExposePlugins oder ggf. Server_WebserverExposePlugins nennen. Ich kann das mit dem nächsten Update reinpacken

Quote from Kryssi_79

red51 Gibt es mehr solche versteckten Einstellungen und/oder Konsolenbefehle für Blaupausen?

ich frage für unsere Wiki

Im Prinzip alle Optionen, die in der config.properties sichtbar sind (beginnend mit Game_Blueprints*) Die einzige versteckte Option ist Game_BlueprintsPlaceDelay, womit festgelegt werden kann, wie lange es dauert, bis eine Blaupause platziert ist.

Ansonsten greifen bei Konsolenbefehle diverse Baubefehle (setl, setr, setp, size, gridrotation etc). Spezifische Blaupausen-Befehle sind eigentlich nur blueprints (zum Öffnen der Blaupausen-Übersicht), blueprintinfo <datei> (um Infos zu einer Blaupause anzuzeigen) und undoblueprint (um explizit das letzte Platzieren einer Blaupause rückgängig zu machen). Ggf. könnte man hier noch gamedir blueprints miteinbeziehen, was direkt den Blaupausen-Ordner auf der Festplatte öffnet

Quote from FioO

Dem Video ist eigentlich ganz gut zu entnehmen, dass ich im Singleplayer spiele.👉👈

Stimmt, sorry, dumme Frage, mein Fehler

Quote from FioO

Sie landen halt immer da, wo Sie auch gespawnt sind.

Achso, also ist das immer ihr originaler Spawnpunkt, d.h. kein zufälliger Punkt o.ä? Wie ist das mit dem refreshnpcs Befehl? Im Video hast du ihn zwar eingegeben, aber zu dem Zeitpunkt hatten sie bereits ihre fehlerhafte Position bzw. sie einfach beibehalten (was tatsächlich zu erwarten war). Aber wie ist es, wenn sie an einer Position sind, die nach einem Neuladen der Welt wahrscheinlich wieder zurückgesetzt wird? Wenn du dann den Befehl eingibst, landen sie dann auch wieder an der Spawnposition, oder behalten sie dann erstmal ihre Position bei (die dann erst beim Neuladen zurückgesetzt wird)? Das würde helfen herauszufinden, ob der "Server" (auch im SP läuft quasi ein Server, nur ohne Netzwerk und so) denn die korrekte Position hat, sie nur nicht oder falsch in die Welt-Datenbank geschrieben wird, oder ob es zw. Client und Server eine Abweichung gibt

Kryssi_79 Habe dir per PN geantwortet

Quote from Nebeltrinker

Irgendwo bei 8.5+ fiel mir auf, dass die Zeit in einem Intervall von etwa 5 Ingameminuten einen Rücksprung macht und sich dann wieder nach vorne dreht, bis sich der Vorgang wiederholte

Diese Rücksprünge treten auf, wenn die Zeit zwischen Client und Server zu stark abweicht. Bis zu einem kleinen Maß toleriert das Spiel eine Abweichung (und versucht sie langsam auszugleichen), aber wenn sie zu groß wird, gibts den harten Sprung...

Woher das jedoch genau kommt bzw. in dem Fall kam ist schwer zu sagen... vielleicht war damals auch ein Bug, der das begünstig hat, bin mir da leider nicht mehr sicher

Quote from Nebeltrinker

Nun, wenn ich es über die Konsole mit settimespeed hochschraube wird der Befehl zwar angenommen, jedoch nach einem Relog bzw. längerer Offlinedauer trotz dass der Server noch nicht neugestartet hat wieder auf 60 gesetzt

Ja, der Konsolenbefehl ist leider nur für die Session gültig, d.h. nach einem Neustart des Servers ist es wieder zurückgesetzt

Quote from Nebeltrinker

Irgendwas um den Dreh bei 50000-60000 rum wurden wieder die 60 genommen, aber die 50000 blieben eingetragen. Alles unter ~50000 ging, aber nach einigen Sessions waren nach jedem Serverneustart wieder die 60 aktiv, ich glaube es gab dazwischen keinen Fix oder Patch.

Also der theoretisch höchstmögliche Wert wäre 2147483647 (max. Wert eines vorzeichenbehafteten ints)... das Spiel setzt an der Stelle auch keinen künstlichen Höchstwert an. Bei so dermaßen hohen Werten kann es aber sein, dass die Zeit effektiv nicht voranschreitet (aufgrund von Rundungsfehlern). Da ist es dann sinnvoll, die Zeit generell auszuschalten (einfach Wert 0 eintragen)... allerdings bleibt sie dann auch wirklich stehen.

Für Realtime wäre der sauberste Weg wirklich 1440 einzutragen. Nur leider bedeutet das wirklich nur, dass ein Ingame-Tag 24 Stunden dauert. Damit wird die Zeit nicht automatisch an die Systemzeit angepasst (dafür wäre wiederum ein Plugin nötig).

Funktioniert das denn weiterhin nicht, wenn du diesen Wert in die server.properties einträgst? Bzw. gibt es in dem Fall weiterhin Probleme mit springenden Schatten o.ä?

Vielen Dank für das Video! Also das ist ja ein merkwürdiges Phänomen Ist das im Multiplayer oder Singleplayer? Verwendest du Plugins?

Ich konnte es bei mir leider bisher nicht reproduzieren... hast du von deiner Seite einen Weg das zu reproduzieren bzw. ist dir etwas aufgefallen, unter welchen Umständen die Npcs ihre Position verlieren?

Alles klar! Die Plugin-Klasse selbst erhält dann die Möglichkeit eine Route zu registrieren (zB registerWebserverHandler()), bei welcher der Pfad angegeben werden kann sowie optional auch ein Handler für die Requests. Die Route wird dann (um Kollisionen zu vermeiden) immer "/plugins/pluginname/<pfad>" sein. Zusätzlich zum Handler gibts aber dann auch ein neues HttpRequestEvent, aus welchem du die Http-Methode (GET, POST, PUT etc), den Pfad, Query Parameter, Header, Body (byte[] sowie String) und Remote-Adresse erhalten kannst. Für die Response kannst du dann den Response-Code, ContentType, Response-Header sowie -Body setzen

Quote from Devidian

vielleicht könntest du auch noch eine route integrieren die auch ohne plugins funktioniert /pluginlist die eine liste der installierten plugins + version zurück gibt? Das würde nativ wahrscheinlich mehr sinn machen, könnte man auch für andere consumer verwenden.

Sowas war mal vorgesehen, allerdings haben wir das erstmal nicht reingepackt, damit von außen nicht ersichtlich ist, welche Plugins ein Server explizit verwendet... kA ob es überhaupt sinnvoll ist, aus sowas ein Geheimnis zu machen, bzw. ob manche Server-Admins evtl. nicht wollen, dass ihre Plugins preisgegeben werden?

Sorry for my late response, but yes, the Player has a method setInvisible() that should make him invisible for other players

But unfortunately there is no direct way to load a custom model for the player... only thing you could do is load a custom Prefab and sync it manually with the player position. That should work well enough for other players.

Yeah, unfortunately there is only one foal variant atm But I'm currently working on more variants, maybe they will be ready with the next update

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?

Quote from Devidian

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?

Quote from Devidian

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

Quote from Devidian

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)

Quote from Devidian

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

Quote from Devidian

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)^^

Quote from Devidian

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)?

Quote from SonoBionda

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)

Quote from Devidian

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:

Plugins_VMOptions=-XX:+UseParallelGC

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)...

Quote from SonoBionda

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