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?
Posts by red51
A new update (0.9.2) is available now!
Latest Hotfix: 0.9.2.1 (2026-05-13)
Latest Hotfix: 0.9.2.1 (2026-05-13)
-
-
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)?
-
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
-
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
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
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
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
-
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! *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
-
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
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
Ü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!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
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!
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...
...für die weißen streifen kann man ja poster nutzen
Poster sind leider sogar teurer als Bauelemente
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)
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
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
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 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)?
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
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!
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...
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.
