Posts by red51

Tatsächlich gibt es mit dem nächsten Update eine optionale, rudimentäre Rohstoffanforderung für Blaupausen Vorgesehen ist, dass im Blaupausen-Menü die benötigten Rohstoffe immer angezeigt werden, aber standardmäßig werden diese Rohstoffe momentan nicht benötigt bzw. verbraucht. Man kann das Feature zwar optional aktivieren (ggf. nur in der config, bin da noch unsicher), birgt bei gewaltigen Blaupausen aber wirklich krasse Anforderungen (schnell mal 100.000 Stein oder mehr). Was noch nicht drin ist ist eine Verwendung der Rohstoffe aus nahgelegenen Kisten, das müsste eigentlich zwingend noch eingebaut werden Ich habe aber auch eine User-Blaupause, die über 30 Mio Stein benötigen würde... das werden schon sehr sehr viele Kisten

Derzeit würde die Bedingung, dass alles im Inventar sein muss, den Survival bei eingeschalteter Option auf kleinere Blaupausen beschränken (Mega-Blaupausen wären dann eher Creative-Content). Wenn die Verwendung naheliegender Kisten es evtl. noch reinschafft würde das deutlich entschärft... ist dann aber nicht 100% optimal: Der Spieler müsste die Kiste(n) vorübergehend dort platzieren, wo die Blaupause ungefähr auch hinsoll.

Die vmtl. bessere Lösung für den Survival-Modus wird sein, dass Blaupausen künftig weiterhin kostenlos sind (bis auf Papier), die Blaupause aber beim Platzieren (falls der Spieler nicht genug Rohstoffe in der Tasche hat) erstmal nur eine Baustelle erzeugt, zu welcher die fehlenden Rohstoffe dann Stück für Stück herangeschafft werden können.

Aktuell ist es übrigens so, dass das Spiel die Rohstoffe wirklich auf die Grundrohstoffe aufbröselt. Ich habe es erstmal anders probiert (dass der Spieler also die tatsächlichen Blöcke haben muss), aber das war besonders bei großen Blaupausen echt schwierig (tausende verschiedene Blockformen und Texturen)...

Den Blaupausentisch würde ich nur ungerne an die moderne Werkbank koppeln oder nur als Loot auffindbar/freischaltbar haben. Das würde manche Spieler von Blaupausen ausschließen (zB die Spieler, die eher aufs Mittelalter fokussiert sind, zumal im Multiplayer bestimmte Objekte auch deaktiviert werden können). Bei Loot gibts auch die Spieler, die wirklich Pech haben und nie eine Blaupause finden. Für manche Spieler sind Blaupausen ja kein reines "nice-to-have" Feature, sondern wirklich wichtig (und manchmal auch aus Datensicherungsgründen gar nicht so verkehrt)

Was hingegen höhere Kosten für die Blaupause selbst angeht: Das stand ja schonmal im Raum und ist durchaus eine schnelle, einfache Lösung, fühlt sich aber auch etwas falsch an (warum brauche ich Gold/Wolfram/Alu usw. um ein Stück Papier herzustellen?). Ich hätte das dann ggf. schöner gefunden, wenn das an Händler gekoppelt wird (sodass man Blaupausen dort kaufen muss - der Händler könnte dann entsprechend viel dafür verlangen). Händler habens aber leider auch noch nicht reingeschafft und momentan sieht es so aus, als würde das Rohstoff-Problem früher gelöst werden als dass Händler dazukommen

The update is indeed still planned for August

Backups are only determined by the world name, so the ingame "Restore Backup" option will only list worlds from the "/Backups/Worlds/" folder with the same name. Unfortunately there is currently no ingame option for restoring a world with a different name.

However, alternatively you can also just copy the World fom the backup folder into your regular Worlds folder (in your case that would be C:\Program Files (x86)\Steam\steamapps\common\RisingWorld\Worlds\). Make sure to rename the world and remove everything that's not part of the world name, i.e if the backup folder is called New World-1776691575-0.9.1_15, rename it to New World after copying it to the Worlds folder

Hey, that's a good point! Currently the waves are not taken into account, so setPosition() would still work, but it would cause the boat to temporarily hover above water or submerge. The API will provide a method to calculate the wave height at a specific location, but this will only help if you call vehicle.setPosition() very often (providing the final water position which also takes the waves into account)...

We could change the setPosition() method to take waves into account automatically, but I'm not sure if that would be a good idea... right now this method allows you to set an arbitrary position (you can even set a position on land or in the air). Maybe a new "setPositionOnWater()" method would be better in this case?

Or maybe we change setPosition() to teleport a vehicle instantly, and add a new "moveTo()" method (which optionally takes waves into account)? This could be a cleaner solution... IMO the current behaviour isn't very intuitive anyway (I'd expect a vehicle to move to a new position instantly when calling setPosition())... the "moveTo" method could then get a few parameters, e.g. to determine if the boat should automatically adapt to waves or if a player should still be able to take control over the boat. Maybe that would be the best solution?

Sorry for my late response! But thanks a lot for the log Unfortunately I couldn't reproduce this issue on a Steam Deck, so it's apparently not related to SteamOS itself, instead it might be an issue between the graphics card and graphics driver I'd recommend to check if a SteamOS update is available (which would update Mesa/RADV).

But there are also a few other things you could try: Currently the Windows version is running through Proton, you could try to select a different Proton version (e.g "Proton Experimental" and see if that helps). If that doesn't work, you could switch to the native Linux version of the game (select the "Steam Linux Runtime" or disable the Steam Play Compatibility checkbox in the game properties in Steam). Does the issue still occur?

If you want to stay on Proton, you could alternatively force Vulkan by adding the -force-vulkan launch option to the game. Proton will natively use Vulkan (avoiding the DXVK layer), so that might also fix the issue. But unfortunately the Proton/Windows version runs a bit worse under Vulkan...

As a last resort, you can forcefully disable GPU skinning (which might be responsible for this issue). Unfortunately you can only do that manually: To do that, go to the game directory into the "Data" subfolder and open the "boot.config" with a text editor. Set "gpu-skinning" to 0, then save the file. Does it work then?

If you still run into this issue after switching to Vulkan or the native Linux build (or after changing the gpu-skinning option), it would be helpful if you could send another report

Quote from Devidian

fehlt da nicht noch terrain

Messerscharf erkannt

Männliche Frisuren sind derzeit die IDs 50 bis einschl. 68, weibliche Frisuren sind IDs 100 bis einschl. 119.

Ich versuche aber idealerweise auch die SkinDefinitions zu exposen, da das direkte Arbeiten mit IDs immer heikel ist (falls die sich später mal ändern sollten o.ä)

Die Skin-Methoden sind leider nicht sonderlich intuitiv Intern wird eine "SkinDefinition" gesetzt (leider noch nicht in der API exposed), diese jedoch repräsentieren generisch ein Skin-Merkmal (Haarschnitt, Bart, Tattoo usw). D.h. die IDs für Frisuren beginnen nicht bei 1, sondern dort, wo sie in der "skins" Tabelle (in der definitions.db) definiert sind, d.h. männliche Frisuren beginnen bei ID 50, weibliche Frisuren bei ID 100.

Erschwerend kommt hinzu, dass die Methode eine ungültige ID einfach verschluckt. Wäre schöner, wenn sie wenigstens ein Bool zurückgeben würde (das kann ich auf jeden Fall ins nächste Update packen)

Vll macht es Sinn, dass diese Methode die ID je nach Geschlecht ummappt, sodass die ID immer bei 1 beginnt (und bei männlichen Charakteren den ersten männlichen Haarschnitt und bei weiblichen Charakteren entsprechend den ersten weiblichen Haarschnitt gibt)? Wäre allerdings eine Breaking-Change (fraglich jedoch, wieviele Plugins davon bisher wirklich Gebrauch machen)

Quote from Deirdre

Es gab doch für die Npcs mal einen Befehl "edit npc invicible oder invulnerable" . (Java-Version). red51 Funktioniert das nicht mehr?

Das kann entweder über das editnpc Fenster gesetzt werden (eine Checkbox unten) oder alternativ wäre der Befehl edit attribute invincible. Ist allerdings für die Plugin API so nicht zugänglich, da gibt es eigene Methoden, um Npcs unverwundbar zu machen

Achso, ja also die Hashes kann ich auf jeden Fall auch noch reinpacken (neben CreatorUID und -Name). Würde dann vmtl. FNV nehmen. Wäre allerdings nicht kollisionsfrei, d.h. es besteht eine (extrem) geringe Chance, dass ein gänzlich anderer Blueprint denselben Hash hätte. Ich könnte separate Hashes für Constructions, Objects und Plants reinpacken, dann ist das Kollisionsrisiko schon höchst unwahrscheinlich

Quote from Devidian

Ich hatte ja auch mal überlegt einen Blaupausenhandel zu ermöglichen bei dem man Blaupausen auf dem server von anderen kaufen kann, aber dazu müßte es möglich sein blaupausen hoch und runter zu laden nur das du das evtl bei der mittelfristigen Überarbeitung im Hinterkopf hast

Ja, sowas wäre tatsächlich nicht schlecht Ich behalte das auf jeden Fall mal im Hinterkopf!

Das Problem ist, dass die Blaupause nur bedingt serverseitig repräsentiert wird. Der Server kennt zwar die Metadaten der Blaupause, aber die einzelnen Elemente werden erst im Zuge des Platzierens an den Server gesendet (auf viele Pakete verteilt, die erst gesendet werden, wenn die Place-Events grünes Licht geben)

Ich möchte mittelfristig die Blaupausen mal überarbeiten, dann könnten die Daten auch im Event übergeben werden, das wird aber vmtl. noch etwas dauern...

Dinge die die CreatorID könnten relativ problemlos eingebaut werden. Was würdest du noch benötigen? Wie meinst du das mit den Hashes, meinst du ein Hash der alle Bauelemente beschreibt (um zu prüfen, ob zwei Blaupausen inhaltlich identisch sind, also dieselben Elemente enthalten)?

Quote from SonoBionda

seltsam - Steam Client funktionieren alle Enter Tasten bei mir. Einzelspiel und Server. Mit Proton experimental. Hingegen die Standalone nutzt ja "weiß ich nicht was" (irgendwas aus dem Betriebsystem?)

Mit Proton wird die Windows-Version verwendet. Dabei werden auch alle Windows-spezifischen Dinge von Proton emuliert (DirectX usw), d.h. unterm Strich ist es dann so, als würde man unter Windows spielen. Und da mit Proton auch tatsächlich die Windows-Version ausgeführt wird (und nicht mehr die Linux-Version des Spiels) treten Linux-spezifische Bugs meist nicht mehr auf

Die Standalone hingegen läuft ganz klassisch nativ unter Linux.

Spielst du unter Linux Desmagu ? Du SonoBionda spielst ja unter Linux, oder? Das Problem wurde unter Linux tatsächlich schon beim letzten Update gemeldet. Es ist leider ein Bug in Unity bzw. UI Toolkit (es wird nur nach eingegebenem Character geprüft und nicht nach gedrückter Taste, obwohl im selben Code ein paar Zeilen vorher bei Tab-Eingabe sogar noch eine Warnung steht, dass explizit unter Linux nicht nach dem Character geprüft werden soll -.-). Meine Hoffnung war eigentlich, dass mit einer neueren Unity Version das Problem behoben ist, sieht aber schlecht aus...

Ich werde versuchen, mit dem nächsten Update einen Workaround dafür einzubauen. Kurz noch ein paar Rückfragen: Was passiert, wenn du Enter drückst? Gar nichts, oder wandert der Cursor zum Zeilenanfang? Und funktioniert Numpad-Enter?

Sorry for my late response! Apparently all skinned mesh renderers are affected (i.e every model that is animated)... this very much sounds like an issue with the graphics driver (AFAIK SteamOS uses Mesa/RADV) Ideally send a report, it will most likely contain more information about what's going on. To do that, please load a world, go to an invisible npc (or just make sure something invisible is on the screen^^), then press ESC and hit the red report button

Yes, the Java version has indeed much lower requirements, but it's basically an entirely different game (but playing together works the same way). For the standalone, the Java version has a separate launcher (so you have to put it into a separate folder on your hard drive). But I realized that the Java launcher is missing from the download section for some reason I've fixed that now, but you can also find it here

Quote from FioO

Und ich würde am liebsten bis zum nächsten Update/Release garnicht' s von Entwicklung und Entwicklern hören. Und dann einfach überrascht werden, wenn was am Start ist. Das fände ich um einiges Besser.👉👈

Hehe, naja, ich fürchte damit wären viele aber auch nicht einverstanden (und zugegebenermaßen wirkt es auch etwas abschreckend, wenn es wirklich gar keine Infos gibt)

Quote from Deirdre

Für solche Updates müsste es keine Vorankündigung geben. Ein paar Worte wie - Bug xxx wurde geändert, Anpassung von xy ist jetzt möglich etc. - reichen doch.

In der Hotfix-Phase schreibe ich ja eigentlich keine (oder nur sehr selten) Vorankündigungen. Bei Updates, bei denen jedoch etwas Zeit dazwischen lag, versuche ich das möglichst schon zu machen, damit sich zB Serveradmins darauf einstellen können. Die Vorankündigung ist aber keinesfalls der Punkt, der zeitfressend ist, ebensowenig die Ankündigung selber (naja, vll ein bisschen, bei kleineren Änderungen aber eher weniger). Es ist der Release selber (Vorbereiten der Release-Version, der Deploy auf Steam, Testen, ggf. nötige Hotfixes usw).

Das Builden der neuen Version für alle Plattformen dauert ca. 2-3 Stunden (+ ca. 20-30 Minuten Upload), sodass gravierende Probleme in einem Update ein echter Albtraum sind, da ich nicht so schnell einen Hotfix nachliefern kann (anders als in der Java Version, wo der Build gerade mal knapp 10 Minuten dauerte)

Wo wir aber von Ankündigungen reden: Ich persönlich (rein persönliche Meinung als Spieler) bin eigentlich kein Fan davon, wenn die News- bzw. Update-Sektion von haufenweise 1-Zeilern oder "bedeutungslosen" Updates überschwemmt ist, und nur jede 5. oder 10. Ankündigung wirklich Content liefert (für die Mehrheit der Spieler als wirklich nennenswert ist). Ist wirklich reine Geschmackssache. Hier im Forum könnten wir zwar entgegenwirken (zB eigene Rubrik für Bugfixes oder nicht-angepinnte Threads), bei Steam hingegen ist das nicht möglich, sondern jeder Mini-Hotfix ist auf der News-Seite genauso prominent wie ein Riesen-Update

Quote from Deirdre

Ein Download von 1-2 GB (für RW) dauert 1-2 Minuten selbst bei Steam.

Ich habe damit auch keine Probleme, aber es gibt immer wieder mal User, die das (bislang immer sehr freundlich [das sage ich wirklich unironisch]) kritisieren.

Quote from Deirdre

Bei Nachfragen - warum nur Bugfixes - könnte man einen Standardtext per Makro einfügen.

Nee, sorry, ich will nicht dazu verkommen, Leuten nur noch mit Copy-Paste-Konserven zu antworten

Quote from Deirdre

Möglicherweise könnten kleine Updates die Nachfrage nach größeren Updates reduzieren.

Meine Erfahrung ist bisher eher gewesen (vmtl. aber auch mit gewissem Bias), dass häufigere, kleinere Updates (die keinen besonderen Content ins Spiel bringen) eher nicht so die große Resonanz bringen. Tendenziell triggern häufigere, kleinere Updates sogar eher die Hater. Und wenn zu viele User der Meinung sind, ein Update bringe unnötigen Content (während vermeintlich wichtigere Baustellen offen bleiben), resultiert das leider auch eher in viel Negativität.

Was hingegen wirklich was bringt sind die Updates, die auch interessanten Content ins Spiel bringen, die vielen Spielern einen Grund liefern, das Spiel wieder anzuschmeißen (und vll mehr als nur 5 Minuten reinzuschauen). Problem hierbei ist nur, dass der interessante Content meist auch am zeitaufwändigsten ist

Was ich mir hingegen eher vorstellen könnte wäre ein separater Update-Branch, wo häufiger mal Releases landen. Den müsste man explizit aktivieren, würde dann häufigere Bugfixes und Änderungen erhalten, gleichzeitig aber auch eher das Risiko besteht, dass neue Fehler eingeführt werden oder etwas mal nicht auf Anhieb rund läuft (was dann natürlich trotzdem zügig behoben wird). Das würde keine Update-Ankündigung erhalten (hingegen vmtl. eher ein angepinnter Thread irgendwo, der die Changelogs erfasst) und ist damit für die breite Masse wahrscheinlich auch eher unsichtbar. Für Multiplayer-Spieler leider eher problematisch (weil der Server dann auch aktuell sein muss, was dann aber die Spieler, die auf dem normalen Public-Branch sind, wieder ausschließt), wäre daher vmtl. eher für Singleplayer- und Coop-Spieler

It's indeed necessary to have a separate license per player. But the Steam- and Standalone version are compatible with each other. Basically just the Steam-features are missing from the Standalone (e.g Steam Cloud). But the main difference: the Steam version has a "Play with Friends" option which is exclusive to Steam (because it uses Steams relay servers). This option enables you to play with a friend from your Steam friends list (very much like a LAN game, but with no additional requirements).

If a Steam player and Standalone player want to play with each other, it's necessary to host a classic LAN game instead. It's the default option in the Standalone (so the easiest way is if the Standalone hosts the game). In the Steam version, however, it's hidden by default (it requires a right-click on the "Play with Friends" button)

About the launcher options, basically these are optional arguments which can be passed to the game. This is mainly for technical reason (e.g if you want to force the game to run with Vulkan instead of DX11 etc)

Meint ihr das jetzt eher auf Bugfixes bezogen, oder auf richtige Updates, die neuen Content reinbringen? Falls es eher um Bugfixes geht: Das ist nicht unmöglich, aber leider auch mehr Aufwand. Das würde die Entwicklung insgesamt wohl eher verlangsamen... wir arbeiten ja dann bereits an neuen Features und die Codebasis hat sich dann schon mehr oder weniger stark verändert. Das ist ein absolut lösbares Problem (d.h. man würde in der Praxis einfach auf den alten Code-Stand zurückspringen, einen Hotfix vorbereiten + veröffentlichen, und die Änderungen dann anschließend in den aktuellen Code-Stand einpflegen), das kann gleichzeitig aber auch wieder neue Bugs oder Regressions reinbringen. Ohne ausreichend zu testen ist das echt etwas heikel...

Das nächste Problem ist aber auch, dass Updates trotzdem automatisch Erwartungen schüren - wenn dann aber die Feststellung kommt, dass das Update ja gar keinen Content bringt, sondern nur ein paar kleinere Bugs behebt, führt das schnell mal zu Enttäuschungen.

Wenn wir das sogar ausweiten und nicht nur Bugfixes, sondern auch Änderungen oder kleinere Neuerungen zwischendurch mal reinbringen, wird die Enttäuschung möglicherweise umso größer sein. Manche Spieler werden das leider schnell auf ein "ihr habt 4 Wochen nur an einer kleinen Textänderung gearbeitet?!" reduzieren. Jeder möchte (verständlicherweise) häufigere Updates, aber gleichzeitig wollen die meisten, dass das auch einigermaßen bedeutsame Updates sind.

Gleichzeitig gibts noch ein kleineres Problem, dass manche Spieler not amused sind, wenn häufig kleine Updates erscheinen, die aber größere Downloadmengen bedeuten. In der neuen Version kann es schnell vorkommen, dass selbst kleinere Änderungen 1-2+ GB Downloadgröße verursachen. Ich versuche daher die Updates möglichst zusammenzupacken. Das gilt aber auch eher für reine Bugfixes.

Bislang versuche ich mich die ersten 1-3 Wochen nach einem Release generell komplett auf Hotfixes zu konzentrieren (die durchaus aber auch mal kleinere Neuerungen mitbringen können). In der Zeit fange ich meist noch nicht an, an größeren Sachen zu arbeiten. Manchmal brauchen Bugfixes aber auch etwas länger, gerade wenn es komplexere Probleme sind - dann kann es passieren, dass es der Fix nicht mehr in dieses 1-3 Wochen Fenster schafft.

Wenn aber wirklich gravierende Probleme bestehen versuche ich eigentlich auch ein Zwischenupdate rauszubringen. Die derzeitigen Bugs sind definitiv nervig, aber für die meisten Spieler nicht unbedingt Game-breaking. Eigentlich wollte ich diesmal sogar noch ein Zwischenupdate rausbringen, was noch ein paar Probleme behoben hätte, habs aber vermasselt

Leider fehlt noch eine setEquippedItem() Methode bei NPCs, ich kann die aber mit dem nächsten Update noch reinpacken

Was den Modifier oder die Durability angeht, die werden beim Droppen dummerweise fest verdrahtet (daher ignoriert das deine Änderungen)... das muss aber nicht sein, daher kann ich das auch mit dem nächsten Update anpassen. Leider gibts aktuell keinen direkten Workaround (außer höchstens "Settings_NpcDropEquippedItem" in der server.properties zu deaktivieren und stattdessen selbst das Item zu spawnen beim Tod es Npc)

Danke für den Hinweis! Die Methode ist leider nicht korrekt verdrahtet, daher funktioniert sie nicht (ist also tatsächlich ein Bug) Ich werde das aber mit dem nächsten Update beheben! Ich werde auch nochmal andere API-Funktionen durchgehen und schauen, ob da irgendwas schief sitzt.

Danke für die Permissions! Sorry dass es etwas länger dauerte, aber ich kann bestätigen, dass hier etwas faul ist Es gibt manche Prüfungen, bei denen die Area-Permission tatsächlich auf die default.json zurückfällt. Das betrifft zwar nicht den Spieler direkt, d.h. beim direkten Setzen der Spielerpermission wird das korrekt übernommen, aber bei positionsbezogenen Prüfungen ist das problematisch (zumindest bei manchen Permissions).

Mir ist das vorher leider nicht aufgefallen, da Fliegen davon nicht betroffen ist, und bei den Vehicle-Permissions muss ich editownvehicles wohl doch übersehen haben (obwohl ich das ja extra erwähnte), sodass ich mein Fahrzeug trotzdem editieren konnte Clientseitig werden die Permissions übrigens korrekt gesetzt (deshalb tauchen sie in der Permission-Liste als positiv auf), aber die Entscheidungen werden in den meisten Fällen vom Server getroffen, wodurch der Bug verschleiert blieb.

Ich werde das mit dem nächsten Update beheben, danke nochmal fürs Nachhaken! Als schnelle Lösung könntest du entweder die gewünschten Werte direkt in der Area-Permission setzen (diese Problematik taucht nur bei den Permissions auf, die nicht von der Area-Permission überschrieben werden), oder alternativ (um zumindest die Fahrzeug-Problematik zu beheben) in der default.json editownvehicles löschen (der Standardwert dafür ist ohnehin true, d.h. der Spieler wird dann seine eigenen Vehicles weiterhin bearbeiten können).

Quote from SonoBionda

was ich grad nicht schnalle - bezieht sich das wirklich auf eine Gruppenberechtigung, oder ist das im Grunde nicht nur eine umbenannte Standardberechtigung die ebenfalls im Hauptordner liegt?

Ja, das ist eine Gruppenberechtigung, d.h. neue Spieler werden automatisch dieser Gruppe zugewiesen. Prinzipiell dasselbe als wäre der Admin immer da und würde den neuen Spieler manuell der Gruppe zuweisen

Die default.json bleibt davon unberührt.