Posts by red51

Quote from Devidian

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)

Quote from Devidian

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

Quote from Devidian

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

Der Orbit ist momentan eher ein kleiner Sonderfall Das ist kein klassischer Spielbereich (wie zB die Hölle), sondern effektiv ist der Spielbereich nach oben hin lediglich nicht begrenzt. Das Spiel rundet das etwas ab mit speziellerer Darstellung der Umgebung (Weltall) und Schwerelosigkeit

Chunks werden da oben leider gar nicht generiert... da ist bei 1024 Schluss. Das Platzieren von Objekten oder Bauelementen ist prinzipiell über die Hintertür gelöst, nämlich sie werden einfach dem höchstmöglichen Chunk zugewiesen. Das ist bei Terrain leider nicht möglich: Um das umzusetzen müssten da oben richtige Chunks generiert werden. Das würde allgemein zu mehr Overhead führen, denn aktuell besteht ein Chunk aus 29 Chunk-Parts, wenn wir jedoch den Orbit abbilden wollen (der ja ca. bei Y 5000 liegt), wären es dann insgesamt mindestens 80-90 Chunk-Parts.

Da der Orbit aber im Survival nur sehr schwer erreichbar ist, ist der Overhead wahrscheinlich etwas unverhältnismäßig... da wäre dann eine richtige Spielmechanik sinnvoll, um auch einfacher in den Orbit zu gelangen. Vielleicht ist das ein Thema für die Zeit nach der 1.0

Quote from FioO

Wenn du Ressourcenrecyeln wie Metall und Holz (Glas) nicht über die vorhanden Werkbänke, sondern über eine neue Werkbank anbieten möchtest wäre dass dann ja eine Art Schrottpresse oder? Muss das neu gewonnene Material dann wieder neu zum Barren geschmolzen (Glas, Metall) werden oder ist es sofort zum Herstellen geeignet?

Wenn es 'ne Art Schrottpresse ist, würde ja erstmal 'nen Trichter, darunter die Presse, darunter der Ausgang reichen. Vielleicht ca. so breit wie der Webstuhl und 'nen ticken höher. Ist das nur für Metall? Könntest uns über ne Kurbel sogar gefühlt minuten lang kurbeln lassen.

Ja, das wäre denkbar. Das Problem ist nur, dass sowas tendenziell eher eine moderne Maschine wäre, sodass es vmtl. kein mittelalterliches Pendant gibt

Quote from Dark Megatron

Klingt gut. Ich bin kein Fan von Gegenständen (Waffen, Rüstungsteilen), welche zwar Existieren, man sie aber nicht selber Herstellen kann. Als Lösung hatte ich mir Schmiedekunst zu Leveln überlegt. Als Anfänger, egal wie hochwertig das Material ist kommt am ende nur rostiger Schrott raus. Als Meister hat man eine Chance von 35%, das das Geschmiedete kein Meisterwerk, sondern ein 10% veredeltes Meisterwerk wird. Da der Schmiedemeister nur immer 10% Veredelung hinbekommt, muss er das 10% veredelte Meisterwerk einschmelzen, um 10% veredelte Eisen/Stahlbarren zu erhalten, mit denen er aber nur ein Chance von 32,5% hat, um ein 20% veredeltes Meisterwerk zu Fertigen. Und wenn ein NPC Schmiedemeister endlich mal ein 100% veredeltes Meisterwerk geschafft hat, dann man es ihm "Abnehmen". Veredelte Barren haben pro 10% Veredelung eine 1,25% Chance, das kein Meisterwerk, sondern die Vorstufe beim Schmieden entsteht.

Skills bzw. ein XP-System stand tatsächlich immer wieder mal zur Debatte und möchte ich auch grundsätzlich gerne einbauen. Bei Items sind für sowas tatsächlich auch bereits die "Modifier" vorgesehen (welche zB ein Schwert besser oder schlechter machen). Wenn Crafting bzw. Schmieden nicht "gelevelt" sind, würde man zB nur Waffen mit negativem Modifier craften können, während mit höherem Level immer bessere Modifier rauskommen.

Das auf andere Dinge wie Barren ausweiten wäre eine Überlegung (also eine Art Veredelung zu haben). Dazu mache ich mir mal Gedanken

Quote from Avanar

Thema recyclen. Wie wäre es, wenn ein schwert nicht einfach aus einem barren Eisen besteht, sondern aus griff, parierstange und klinge.

Vor Ewigkeiten war das ja sogar schonmal ansatzweise so (ich glaube bis Ende 2017), zumindest hatte jedes Schwert eine separate Klinge, die gecrafted werden musste (bzw. jedes Tool auch einen passenden Werkzeugkopf). Das ist leider rausgeflogen, als das Spiel insgesamt wesentlich mehr Items erhalten hat. Allerdings gab es auch Leute, die das alte System als unnötig kompliziert empfunden haben (bzw. sich darüber geändert haben, dass man für ein Schwert erst eine Klinge craften muss statt direkt einen Eisenbarren zu verwenden), deswegen ist es dann auch nie mehr zurückgekehrt Wobei das trotzdem etwas ist, was ich nicht ganz abschreiben würde bzw. was man evtl. nochmal überdenken könnte.

Beim Recyceln würde ich persönlich aber vmtl. eher dazu übergehen, dass man Schrott erhält, den man erst wieder einschmelzen müsste, statt direkt die Grundrohstoffe für ein neues Item zu erhalten

Quote from SUF

Gibt es irgendwo die Möglichkeit, die Tastenbelegung am Gamepad manuell zu ändern? Nachdem ich jetzt die Steam-Steuerung für den Controller in Rising World abgeschaltet habe, lässt es sich deutlich besser damit umgehen, danke für die Hinweise dazu.

Ja, das ist möglich Allerdings leider nur über die config.properties im Spielverzeichnis... das "Hochfliegen" ist derzeit fest ans Springen gekoppelt, d.h. dafür müsstest du Springen umbelegen. In der config.properties Datei ist das der Eintrag Input_Jump. Standardmäßig ist das an key_space, gamepad_buttonSouth gebunden (also Leertaste und beim Gamepad A). Um das zB auf den linken Trigger zu legen müsstest du gamepad_buttonSouth durch gamepad_leftTrigger ersetzen (oder gamepad_leftShoulder für die Schultertaste).

Das herabsinken bzw. runterfliegen ist hingegen an Input_Crouch und Input_CrouchToggle gekoppelt (im Falle des Gamepads wird CrouchToggle verwendet). Standardwert ist hier gamepad_buttonEast (also B).

Nach den Änderungen musst du die Datei speichern und das Spiel neustarten. Wenn das Spiel hingegen läuft müsste aber eigentlich auch der Konsolenbefehl reloadoptions reichen, um die config neu einzulesen

Oh, I see, yes that's indeed a good point! Maybe a separate layer for these elements, i.e a layer that automatically blocks input if attached (similar to how the inventory works) and that also closes when pressing ESC, isn't a bad idea... I will take a closer look at this. Probably the UI element still needs a callback or event for this (i.e when it was closed via ESC)... pressing ESC would detach the modal layer and also remove all elements from it (so if you want to show your UI again, it would be necessary to register it to the player again with Player.addUIElement()

As a workaround, I would suggest disabling the ESC key ("Key.Escape" via Player.disableClientsideKeys()) while the UI is active... but that method is a bit limited because it listens to a specific key only (so that approach wouldn't work with gamepads, for example)... I'll also add a new Player.disableClientsideInput() method which enables you to disable certain input actions (independently of the actual key binding). This might be useful in other situations, too

Quote from SonoBionda

red51 Perhaps we can still get a Audio-Snippet of the Christmas theme on vinyl ? That would fit right into a church—and it’s practically already part of the game, in the soundtrack.

It's a crime that the Christmas theme is still not available for the gramophone I will change that with the next update!

Quote from Devidian

*loud thinking* a plugin would be nice to have own vinyl sounds by just uploading mp3 as admin.

The API should be capable of doing that, maybe it's about time to update the old Jukebox plugin to the new version

Quote from Avanar

red51 Ja, ich glaub da wären einige Leute frustriert, wenn ihre Tierchen einfach wegsterben. Kannst du die bestehenden Tiere nicht aussparen? Oder deren Alter zurücksetzen?

Ja, definitiv. Bei bestehenden Tieren wäre es sinnvoll sie entweder auszusparen, oder zumindest das Alter zurückzusetzen

Quote from Forscherdrang

Am besten für alles einen Ausschalter mit einbauen. Bei mir sind ca. 80% aller NPC, egal ob Mensch oder Tier festgesetzt. Da brauche ich weder Hunger noch Schwangerschaften & schon gar keine plötzlichen Todesfälle

Evtl. wäre es überlegenswert, dass Tiere, die schonmal Umgang mit dem Spieler hatten, unsterblich werden (sofern später auch Bedürfnisse erfüllt werden, zB Futter etc)...

Eine Option wäre auf jeden Fall möglich, aber idealerweise sollte auch der Standardzustand möglichst frustrationsarm sein

Quote from Forscherdrang

Übrigens funktionieren die Satteltaschen, welche mit editnpc ausgerüstet wurden nicht. Beim öffnen steht kaputt & entfernen lassen sie sich auch nur wieder über den Befehl

Ja, leider wird kein Storage erzeugt, wenn die Satteltaschen per Befehl erzeugt werden... idealerweise wäre es wahrscheinlich so, dass das Spiel spätestens beim Zugriff auf eine Kiste (oder Satteltasche), denen die Storage fehlt, eine erzeugt wird Ich mache mir dazu mal Gedanken!

Quote from SonoBionda

wie wäre es mit nem Flag "altern verhindern" beim editieren von NPC - denn das sind sie doch - editiert

Das macht Sinn. Also genau genommen der Flag, mit welchem das Wachstum ausgeschaltet wird (was effektiv denselben Effekt hat wie "DisableGrowth", auch wenn der Name etwas irreführend ist). Der Flag kann durchaus allen Npcs hinzugefügt werden mit dem Befehl edit flag disablegrowth (beim Betrachten des Npc), aber es wäre sinnvoll, den einerseits umzubenennen und andererseits dann auch für alle Npcs im Edit-Fenster anzuzeigen

Quote from FioO

Zu dem Mahlwerk allgemein noch, fände ich es letztlich genial, wenn man am Ende einfach ALLES reinschmeißen könnt und es dann halt zermahlen, zerquetscht, zerbrochen wird.

Beim Ofen gilt dasselbe. Hier könnte der Spieler sogar bestraft werden, wenn er Blödsinn macht. Versucht er zum Beispiel Gummienten im Ofen zu schmelzen gelingt es zwar und er bekommt eine geschmolzene Masse Plastik aber der Ofen wird für den weiteren, normalen Gebrauch unbrauchbar und muss ersetzt werden.

Beim Ofen (sowie Lagerfeuer etc) ist das tatsächlich geplant, also dass Items, die dort einfach nur reingeworfen werden, verbrennen (derzeit gibt es leider noch keinen "Verbrannt" Status)

Beim Mahlwerk ist das etwas schwieriger umzusetzen... ich mache mir dazu mal Gedanken!

Quote from Thaya2016

huhu...hätte da auch noch eine Idee...was Blöcke sparen könnte...wie wäre es wenn man die Textur für die Straßen bekäm? dann braucht man nicht zwingend den Asphalt malen würde zumindest bei Landstraßen richtig Sinn machen.lg

Mehr Texturen sind auf jeden Fall geplant, halte mich momentan aber etwas zurück damit, weil das den VRAM Verbrauch generell erhöht (und es bei manchen Spielern bereits am Limit ist)

Aber natürlich können wir das auch nicht ewig vor uns herschieben...

Quote from Thaya2016

...für die weißen streifen kann man ja poster nutzen

Poster sind leider sogar teurer als Bauelemente

Quote from Bogus

Ich buddel mich grade durch einen Berg und da ist mir in den Sinn gekommen, was so Fahrzeuge angeht. Glaube es war doch mal im Gespräch, das es so schienennetz geben soll oder ? Ist da schon was in Planung ?

Ja, Züge sind auf jeden Fall geplant (was Schienen natürlich auch umfasst)

Quote from Bogus

Falls so schienenfahrzeuge geplant sind, dann könnte man so als Anfang, weiss ncht wie die heissen, aber es gibt so mit einer Kurbel oder kurbelwippe ?

Du meinst eine Draisine bzw. die Handhebeldraisine? Die ist tatsächlich fest eingeplant

Quote from Bogus

Ach noch eine Sache, nämlich könnte man bei Hartbarkeit von Items nicht so Prozentangabe machen, in wieweit diese Hartbar noch sind ? Das wäre glaube sehr von Vorteil ;D

Ursprünglich war es eigentlich gewollt, dass bei der Haltbarkeit nur eine grobe Einschätzung gegeben wird, und nicht der exakte Prozentwert

Quote from Dark Megatron

Ich hätte gern am Amboss Rezepte, um aus Metallsachen (rostige Schwerter) Metallschrottklumpen zu fertigen, welche man zu Eisenbarren einschmelzen kann (Recyceln).

Ein Weg zum Recyceln von Items ist auf jeden Fall geplant, ich bin mir allerdings noch nicht ganz sicher, wie so eine Werkbank aussehen könnte... ein einfaches "Crafting-Rezept" am Amboss wäre denkbar (also dass "Metallschrott" ein eigenes Rezept ist, was zB rostige Schwerter benötgit). Allerdings ist hier das Problem, dass wir unterschiedliche Items nicht gut abbilden können (ein Langschwert sollte zB beim Recyceln mehr Metall geben als ein kurzes Schwert usw). Eine andere Lösung würde ich daher wahrscheinlich bevorzugen (zB eigenständige Werkbank) Bin mir aber echt noch nicht sicher, wie die aussehen würde... bin da für Vorschläge offen

Quote from FioO

Vielleicht kann man für die Tanzanimationen irgendwann 'ne Reihenfolge festlegen. Also so das NPC A die Animationen 3,2,1 hintereinander abspielen kann als Beispiel.♥

Schwierig... momentan ist nur eine einzelne Animation vorgesehen. Das könnte man zwar theoretisch ändern, aber mit etwas Aufwand (und Tanzen scheint die einzige Animation zu sein, wo sowas überhaupt sinnvoll wäre)

Ist denn eine bestimmte Reihenfolge notwendig, oder würde es reichen, wenn das Spiel sonst zufällige Tanz-Animationen wählt (bzw. das Spiel könnte "Zufall" als weitere Tanz-Animation anbieten)?

Quote from room6675

ich fände es sinnvoll wenn man in Blaupausen auch platzierte Items sowie Texte von Schildern und Plakaten speichern kann - wenn man dazu einen Haken setzen muß - so wie bei Terrain, Pflanzen, ... - ist das vollkommen okay.

Das ist auf jeden Fall geplant. Eventuell wird das mit dem nächsten oder übernächsten Update dazukommen

Quote from room6675

achja, bei den Kanaldeckeln fehlt noch der Pfeil in welche Richtung sich die Deckel/Abdeckungen öffnen - so wie bei den Türen

Danke für die Info, das macht Sinn, das füge ich noch hinzu!

Quote from room6675

Und wollte red51 die Funktion der Zugbrücke nicht noch anpassen so das man sie mit Blick auf die Klappe öffnen kann? Derzeit läßt sich die Zugbrücke ja nur über das Drehrad bedienen.

Ich erinnere mich noch an die Diskussion, aber sie war glaube ich etwas ergebnislos, oder? Es gab ja Vorschläge wie zB das Öffnen von der anderen Seite mit einem weiteren Drehrad (was aber eine komplizierte Ketten-Mechanik bedeuten würde)

Ein Öffnen durch das Anvisieren der Zugbrücke selbst ist hingegen möglich, nur leider ist der aktuelle Interaktionsbereich des Spielers zu klein, um die Zugbrücke auch über einen Abgrund hinweg anzuvisieren...

Quote from Hintzi

Vielleicht wäre schön zu sehen wenn man es anschaut, das dort steht wie alt es ist und im Journal steht hinterlegt wie alt welche Tiere im Schnitt werden oder so.

Die Info wäre wahrscheinlich gar nicht so schlecht... es fehlen generell noch ein paar Infos im Journal. Ich packe das mal mit auf die Liste

Danke für die Rückmeldung! Das ist etwas eigenartig, eigentlich sollte vom Spiel aus kein SIGABRT geraised werden, wenn die Einstellung auf True ist   Ursprünglich war das auch nur mal eingebaut, weil es damals in Unity den Bug gab, dass der Prozess beim Beenden nicht wirklich beendet wurde. Dann wars mal behoben, mit der nächsten Engine-Version aber wieder drin usw, weshalb das Spiel bzw. der Server den Prozess zwangsweise mit dem SIGABRT killt^^

Derzeit wird der SIGABRT vom Spiel eigentlich nur ausgelöst, wenn die Einstellung entweder auf False steht (oder gar nicht erst gesetzt ist), oder wenn beim Command fürs Beenden ein now oder force angehängt wird (also zB shutdown now oder quit force etc).

Ich werde es nochmal unter Linux testen (vll i.V.m. mit dem LinuxGSM) und schauen, ob ich das Verhalten reproduzieren kann.

Der SIGABRT könnte den dump verursachen... hast du mal probiert, in der server.properties den Eintrag Server_NoAbort=True hinzuzufügen (wie oben erwähnt)?

What are you trying to achieve exactly? Not sure if a layer could be a bit too limited... it also raises a few other issues (like the order of the layer - should it appear in front or behind certain other layers?).

When saying that a native implementation would be smoother, do you mean it would be easier to use, or "smoother" in terms of responsiveness etc?

Das ist eigenartig Beziehst du dich denn auf den RAM Verbrauch, oder den Speicherbedarf auf der Festplatte? Der größte Speicherbedarf (RAM+Festplatte) des Servers selber sind einerseits Plugins (die in dem Fall ja wegfallen) und die Welt. Die geladene Welt (also im RAM) kann größer sein als die auf der Festplatte gespeicherte Welt, allerdings wird normalerweise nie die gesamte Welt geladen, sondern nur die Chunks, die auch wirklich benötigt werden (d.h. die Chunks wo derzeit Spieler unterwegs sind und bauen).

Wo fließen die restlichen 45-46 GB auf der Festplatte denn hin? Wie häufig wird der Server neugestartet?

Die "coredump" Dateien werden übrigens nicht vom Server angelegt oder verwendet (die kannst du also löschen). Wieviele dieser Dateien hast du denn? Wird jedes Mal beim Beenden eine neue Datei angelegt? In dem Fall öffne evtl. mal die server.properties und füge dort irgendwo diesen Eintrag hinzu: Server_NoAbort=True, dann starte den Server erneut. Wird weiterhin eine dump Datei beim Beenden erzeugt?

Im Zweifelsfall kannst du den Server sonst neu installieren, sichere dafür nur die Ordner Worlds, Permissions, ggf. Plugins und falls erwünscht Logs. Zusätzlich noch die Dateien server.properties (Servereinstellungen) sowie optional scheduler.txt sichern (sowie alle Dateien und Ordner, die du selber explizit angelegt hast).

Alles klar! Ich kann dann mit dem nächsten Update eine allgemeine Server.getLocalizedString() Methode einbauen (die Sprache und den Key als Parameter annimmt), um einen beliebigen Wert aus der Sprachdatei (die .json Datei) einzulesen. Zusätzlich kann ich der Item Klasse noch eine getLocalizedName() verpassen, womit direkt der lokalisierte Item-Name ausgegeben wird, abhängig von der als Parameter übergebenden Sprache Auch die jeweiligen Definitions (ItemDefinition, ObjectDefinition, VehicleDefinition etc) können so eine Methode erhalten.

Die Spiel-Sprache eines Spielers kann zB mit Player.getLanguage() ausgelesen werden.

Quote from Devidian

- is there any way to have "tooltips" on custom UI elements? Im mean element.onHoverShowText("Something like that")

Unfortunately there is no clean way to achieve that, but I can add a method to show a text tooltip with the next update (e.g element.setTextTooltip("Tooltip"), optionally with a way to change the background color, offset etc

Quote from Devidian

- any chance we get a new UI Layer next to the defaults with a CUSTOM_ prefix, so if escape is hit they close? Im currently implementing a workaround by listening to escape key but native would be much smoother. Or Maybe im just thinking the wrong way here and a custom layer wont help.

Not sure if I understood this correctly... this means you want a separate layer (similar to the hud or inventory layer) that closes automatically when pressing ESC?

Ich habe mir das mal genauer angeschaut: Ein kleines Problemchen ist, dass das Spiel die Übersetzung natürlich abhängig von der beim Spieler eingestellten Sprache wählt, damit zB der String "item.pickaxe.name" (entsprechend des Aufbaus in der json Datei) bei einem deutschen Spieler "Spitzhacke" und bei einem englischen Spieler "Pickaxe" zurückgibt.

Im Falle des Servers wäre es so, dass hier automatisch die Serversprache verwendet werden würde (also die Systemsprache). Ich könnte sonst aber auch anbieten, dass man beim Auslesen des lokalisierten Strings auch die Sprache angeben kann. Würde das helfen?

Quote from Devidian

Wäre schon nice, ich habe hier gerade den fall das ich für ein bett genau wie für eine Piratenkiste nur objectkit angezeigt bekomme

In dem Fall würde die Lokalisierung leider nicht helfen... "objectkit" ist der interne Name des Items, welches Objekte repräsentiert. Der lokalisierte String für dieses Item ist "Object kit" (Englisch) oder "Objekt-Kit" (Deutsch), also nicht das, was du suchst

Bei diesem Item müsstest du hingegen "ObjectItem" verwenden (welches von "Item" abgeleitet ist). Die enthält eine getObjectDefinition() Methode, mit welcher du die ObjectDefinition erhälst (die wiederum als "name" den internen Objektnamen zurückgibt, zB "workbench", "chest1" etc). Oder alternativ auch getObjectName(). Der Code wäre dann quasi so:

Item item = ...;

//Check if item represents an object
if (item instanceof Item.ObjectItem object) {
    String name = object.getObjectName();
}

You mean the small red lantern? Or the black/grey square lantern? Does that mean you want to change the color of the flame?

Unfortunately there is currently no way to rotate areas They're always aligned to the fixed world grid... but changing this is on my to-do list

Yes, for most areas types this is supported (e.g for the creative mode removal or edit tool). But you can only rotate it around the Y axis. To do that, just hold CTRL and use the arrow left/right keys to rotate it (to reset rotation, press CTRL+Backspace)

"Zombie" is a peer state indicating that a client is not properly disconnected. But it's nothing to worry about in this case, considering the client actually disconnected right after that