Posts by red51

Achso, ja diese Art von "selfclaim" ist auch geplant Grundsätzlich werden Admins wählen können, ob sie entweder selber Areas vordefinieren wollen (die dann "claimable" sind), oder ob ein Spieler eigene Areas erstellen darf, d.h. er kann sein "Claim-Objekt" platzieren und dort herum eine Area definieren (die dann natürlich nicht mit anderen Areas kollidieren darf)

Quote from Bamse

About error from log when i use custom events? It seems is just a wrong message for custom events. All event are fired and work correctly.

Sorry, missed that part This message indeed occurs for all events which are unknown to the native side (originally it was mainly added as a reminder that a particular event does not yet have a native representation). You can ignore this message (it won't cause any trouble), but I will also fix this with the next update

Freut mich, dass es jetzt wieder klappt! Beim Kopieren von Welten kann leider immer was schiefgehen, aber es ist auf jeden Fall wichtig, dass das Spiel bzw. der Server währenddessen nicht läuft (da sonst eine der Dateien während des Schreibvorgangs kopiert werden könnte, was dann zu beschädigten Daten führt) Dabei muss entweder der Server bzw. das Spiel beendet werden (oder ins Hauptmenü zurückkehren), oder alternativ kann auch der Konsolenbefehl worldbackup benutzt werden, womit von der aktuellen Welt ein Backup erstellt wird

Das ist tatsächlich für "selfclaim" vorgesehen, aber leider ist das bisher noch nicht implementiert, daher hat das aktuell noch keine Wirkung... sobald das aber implementiert ist, werden alle Areas, die zuvor auf "claimable" gesetzt wurden, für einen Spieler für "selfclaim" verfügbar

Quote from SonoBionda

Aber irgendwie kann es das nicht sein ... das würde ja noch sehr viel mehr erfordern

Das geplante "selfclaim" System wird so aussehen, dass ein Spieler ein spezielles "Claim-Objekt" haben wird und das dann in "claimable" Areas platzieren kann, um sie für sich zu beanspruchen Was meinst du genau damit, dass das noch viel mehr erfordern würde?

Das war grundsätzlich sogar vorgesehen Doch das Problem ist leider, dass es derzeit für den Spieler noch keinen Weg gibt, Metadaten für Objekte zu speichern (zB Spawnchance, Ausrichtung zum Boden, Abhängigkeiten usw)... es müsste also noch irgendein Weg vorgesehen werden, um diese Daten pro Objekt festzulegen

Was Workshop und mod.io angeht: Ursprünglich wollten wir uns tatsächlich auf mod.io konzentrieren, damit auch die Standalone Zugang zu Mods hat. Und wir langfristig das Spiel ggf. auch in anderen Stores anbieten wollen. Von der Idee beides anzubieten (Workshop + mod.io) bin ich kein so großer Fan... das machen zwar tatsächlich mehrere Spiele, aber dann passierts schnell mal, dass manche Mods nur im Workshop und manche Mods nur auf mod.io verfügbar sein werden

Andererseits ist die weit erdrückende Anzahl an Spielern auf Steam... sodass das Thema "Workshop" nicht ganz abgeschrieben ist...

Bevor ich auf den eigentlichen Vorschlag eingehe, möchte ich einmal kurz darauf eingehen, Blaupausen "als 1 Objekt" zu handhaben bzw. stattdessen als Modell/.obj Datei zu laden, da dieser Wunsch häufiger geäußert Ich möchte dabei nicht auf den spielerischen Vorteil eingehen (zB dass Blaupausen einfacher wieder entfernt werden können, wenn sie aus 1 Objekt bestünden), sondern nur auf den technischen Aspekt (um den es hier ja scheinbar auch in erster Linie geht?)

Tatsächlich ist es bereits so, dass das Spiel alle Bauelemente innerhalb eines Chunks zu einem Mesh kombiniert, d.h. man hat ohnehin nicht tausende Objekte, sondern technisch nur 1 Objekt pro Chunk. Korrekter ausgedrückt werden eigentlich auch nicht die Elemente kombiniert, es wird von vornherein nur ein einziger Mesh generiert.

Das geschieht bereits auf die technisch effizienteste Weise und auch der generierte Mesh ist auf minimalsten Memoryverbrauch hin optimiert (d.h. alle Daten pro Vertex - bis auf die Position - werden bereits als 8-Bit Wert gespeichert).

Würden Blaupausen fortan nur noch ein Modell laden (zB die exportierte .obj Datei), würde sich an der allgemeinen Performance nichts ändern. Was hingegen schneller geschehen würde wäre das Generieren des Chunks (da nicht erst der Mesh generiert werden muss, sondern sofort ein fertiges Modell geladen würde). Gleichzeitig würden aber im Multiplayer enorme Probleme hinzukommen, da ein gespeicherter Mesh wesentlich mehr Daten enthält als eine Blaupause: Derzeit ist ein einzelnes Bauelement 110 Bytes groß. Würde dieses Bauteil durch ein klassisches Modell repräsentiert (zB durch eine .obj Datei), wäre es hingegen ca. 1500 Bytes groß, also mehr als 13x soviel. Im MP müssten also wesentlich mehr Daten synchronisiert werden...

Und wie gesagt, die Performance wäre am Ende exakt dieselbe, lediglich das Generieren des Chunks wäre schneller (zumindest im Singleplayer). Gleichzeitig wären nachträgliche Änderungen (Bauteil entfernen o.ä) aber auch nicht mehr so einfach möglich.

Wenn man mit vielen kleinen Bauteilen arbeitet und Performanceprobleme feststellt, dann liegt das in erster Linie an der Anzahl der Polygone bzw. genau genommen die Vertexdichte. Wenn die Framerate alleine durch das Betrachten des Bauteils zu niedrig ausfällt, dann ist die Grafikkarte am Limit. Hier muss man aber auch immer unterscheiden, ob das Bauwerk selbst wirklich für die Performanceprobleme zuständig ist, oder ggf. andere Dinge wie die Anzahl der Lampen/Lichtquellen, Npcs o.ä.

Wenn die Framerate hingegen erst beim Berühren des Bauteils nach unten geht, dann kommt das eher von der Physik-Engine, denn diese kommt mit so feingradiger Kollision nicht gut zurecht. Das Problem kennen viele vmtl. auch noch aus der Java-Version, vor allem aus den trickreicheren Zeiten, als zB gerne mal mehrere Planken gedreht platziert wurden, um einen Zylinder zu erhalten - beim Berühren dieser Elemente ging die Performance dann in den Keller.

Aber auch hier gilt, dass man leider nichts gewinnen würde, wenn das Spiel zB stattdessen eine .obj Datei laden würde... offenbar ist das eines der häufigeren Probleme.

Unity verwendet von Haus aus PhysX 4.x, welche nicht schlecht ist (deutlich performanter ist als die Physik-Engine damals in der Java Version), aber leider nicht mehr ganz der Höhe der Zeit entspricht... in Unitys ECS gibts zwar stattdessen eine Eigenentwicklung ("Unity Physics") sowie optional auch Havok (welches definitiv performanter ist), aber ECS steckt leider generell noch in den Kinderschuhen. Theoretisch ist aber in dem Bereich noch Luft nach oben.

___________

Was das Spiel nicht macht ist eine Polygonreduktion. Das wäre in den meisten Fällen (also bei komplexen Bauwerken) leider nicht performant umsetzbar... sowas wäre ohnehin nur i.V.m. "Blaupausen werden als .obj geladen" denkbar, aber auch ein polygonreduziertes Modell würde immernoch wesentlich mehr Speicher belegen als eine Blaupause (und die o.g. Multiplayer-Probleme mit sich bringen).

Trotzdem wäre die Ersparnis nicht in allen Fällen so groß, da nur gleichartige Bauteile kombiniert werden können, d.h. Bauteile die dieselbe Textur und Farbe haben. Außerdem müssen die Bauteile exakt aneinanderliegen und die gleiche Ausrichtung haben, also so platziert sein, dass sie problemlos mit einem einzigen Bauteil repräsentiert werden könnten.

Insgesamt sind eigentlich nur folgende Optimierungen möglich bzw. denkbar:

• Andere Physik-Engine. Das würde helfen bei Performanceproblemen beim Betreten/Berühren komplexer Bauwerke. Zum aktuellen Zeitpunkt in Unity aber leider keine Option. evtl. aber in Zukunft
• Man könnte Bauwerke, die in der Ferne sichtbar sind, als "3D Imposter" darstellen (d.h. das 3D Modell wird in der Ferne durch einen "Screenshot" ersetzt). Sowas ist aber relativ kompliziert umzusetzen und wäre nur bei dicht bebauten Welten vorteilhaft (zB bei einer großen Stadt). Optisch könnte der Schwindel u.U. auffliegen
• Um die Geschwindigkeit beim Laden der Chunks zu erhöhen, könnte das Spiel bzw. der Client den fertig generierten Mesh auf der Festplatte cachen. Solange es dann keine Änderung gab, müsste der Chunk beim nächsten Mal nicht neu generiert, sondern der fertige Mesh könnte von der Platte geladen werden. Nachteil ist, dass das idealerweise eine SSD erfordert (die man für RW am besten eh haben sollte), und dass aber auch relativ viel Speicher für sowas draufgehen kann (gerade bei vielen oder komplexen Welten)

___________

Um aber auf den ursprünglichen Vorschlag zurückzukommen, sowas wäre grundsätzlich denkbar. Das wäre dann tatsächlich darauf beschränkt, dass die zu kombinierenden Bauelemente so liegen müssen, dass sie problemlos durch ein einziges Bauteil ersetzt werden könnten. Wenn zB mehrere Zylinder genau übereinandergestapelt werden, könnten diese dann hinterher durch einen langgezogenen Zylinder ersetzt werden. Oder wenn ich mehrere 1x1x1 Blöcke als Fläche oder in Reihe platziere, dass diese durch einen einzigen, breiten Block ersetzt werden könnten.

So eine Mechanik ist aber auch nicht ganz trivial umzusetzen. Es ist in erster Linie ein mathematisches Problem, kein technisches Problem

Quote from Forscherdrang

Bei Glas wäre die Verbindung tatsächlich interessant für gebogene Fenster & dergleichen.

Da ist sonst immer die Naht so stark zu sehen, besonders bei Klarglas

Ich fürchte, dass das auf dem Screenshot oben nicht funktionieren würde, da es sich hier ja um versetzt platzierte Bauteile handelt... die könnten ja nicht durch einen einzigen Block repräsentiert werden.

Dass die Naht sichtbar ist wäre leider durch alle o.g. Maßnahmen nicht verhinderbar... dafür müssten ja die Flächen, die sich teilweise berühren, aufgebröselt und der sich überdeckende Teil entfernt werden - das ist leider aus Rechensicht noch viel komplexer, sodass man sowas leider nicht auf performancefreundliche Art umsetzen könnte

Sinnvoller wäre hier eher, dass das Spiel Glaselemente anders rendert, sodass immer nur die vorderste Glasfläche sichtbar ist. Das ist aber möglicherweise nicht immer gewollt

Quote from Kryssi_79

Unity bietet sowas schon an.

Z.B.

Mesh.CombineMeshes() aus Unitys Mesh-Klasse, um mehrere Blöcke zu einem Objekt zu verschmelzen.

Oder

aus der Unity asset store

[...]

Display More

Die Unity-API zum Verbinden von Meshes hat leider das Problem, dass hier Meshes quasi "wie vor 20 Jahren" verbunden werden Leider ist der Großteil der Unity-API (einschl. der CombineMeshes() Methode) nicht multithreading-kompatibel, was für RW ein KO-Kriterium ist... von Asset-Lösungen hingegen bin ich persönlich ohnehin kein Freund, da man hier essentielle Kontrolle abgibt...

Aber wie gesagt, es gibt ohnehin nur einen einzigen Mesh, der beim Laden des Chunks dynamisch zusammengebaut wird, d.h. gar nicht erst mehrere Meshes, die verbunden werden müssten

Quote from Forscherdrang

Super vielen Dank Dann muss ich mir die anderen 4 auch gleich mal angucken

Gibt insgesamt sogar 7 Varianten des Skeletts

Quote from Forscherdrang

Aber bevor ich jetzt anfange damit rum zu spielen eine kleine Frage noch.

Du meintest ja, dass noch einige Folterinstrumente dazu kommen.

Ist dort zufällig so ein Käfig dabei ? (oder so ähnlich)

Die Frage kann ich mit einem eindeutigen Ja beantworten

Quote from SonoBionda

Was Objekte angeht ja ... construction nicht unbedingt ... aber vegetation wäre für "Wildnisbauer" auch sinnvoll

Der Vollständigkeit halber müssten vmtl. dann auch constructions mit rein (wird momentan zwar noch nicht in POIs verwendet, ist aber vorgesehen) Ich packe das mal auf meine Liste, ich weiß aber nicht, ob noch ein Hotfix kommen wird... wahrscheinlich wird es dann wohl erst mit dem nächsten regulären Update was (welches aber noch dieses Jahr erscheint).

Quote from Forscherdrang

Können wir irgendwie auf dieses Skelett zugreifen ?

Ja, das ist eine Variante des skeletonstatic Objektes, genau genommen die Variante 5 bzw. "lying2". Du kannst ihn also spawnen mit dem Befehl item skeletonstatic 1 5 (oder item skeletonstatic 1 lying2)

Leider zeigt die Item-Spawnliste nur die Hauptvariante an... das wird mit dem nächsten Update aber geändert, sodass alle Item- und Objektvarianten über das Menü erhältlich sind

Just to avoid misunderstandings: the game does not spawn new threads or something like that. It just creates a new JNIenv pointer everytime you access an API method from a new thread (that was not created by the game). It's a waste of resources ofc and could also result in other issues, so it's definitely a more serious bug.

Unfortunately there are no more hotfixes planned, but I'll prepare at least a hotfix for the server which fixes this bug, would that work for you? The next regular update (which also contains the fix) should still be ready this year

Quote from xynix

Hey Red, it looks like placing a Cooking Grate on a 'pre-generated' (POI) campfire makes the Cooking Grate disappear into thin air.

Thanks for letting me know! It seems that the cooking grate takes the wrong position into account when being placed on a POI campfire So the cooking grill is there, but usually at a much lower position I will fix that with the next update (unfortunately it won't fix cooking grates that were already placed on these campfires)

Quote from WickedSchnitzel

I am assuming that the new POIs won't spawn in already generated worlds? On a multiplayer server. So we would need to wipe the world to see these?

Usually there is no need for a wipe As mentioned by Bamse and Avanar , POIs spawn in all unmodified chunks, i.e in all chunks which haven't been modified by a player (e.g. by digging a hole, placing a block, cutting down a tree etc)

Der Fehler gibt an, dass die Weltdateien beschädigt sind und nicht geladen werden können (der genaue SQL Fehler lautet database disk image is malformed). Konkret scheint die "Chunks.db" beschädigt zu sein...

Falls du die Welt schonmal von einem anderen Server kopiert hast, stelle sicher, dass sie nur kopiert wird, wenn der Server ausgeschaltet ist (da sonst die kopierten Dateien fehlerhaft sein können). Falls du die Welt aber damals neu auf diesem Server erstellt hast, dann ist leider nicht mehr nachvollziehbar, warum die Weltdatei beschädigt ist In dem Fall musst du entweder die Welt löschen (ggf. reicht es die Chunks.db Datei zu löschen (es könnten aber noch andere Dateien beschädigt sein), oder aus einem Backup (falls vorhanden) wiederherstellen)

Thanks for bringing this to my attention! I can confirm that this is a bug in the API: the native JNI interface is only valid in the current thread, or more precisely, each thread requires a separate JNI env pointer (this is a restriction from JNI). When accessing an API method which communicates with the native side (which is the case for most methods and objects) from another thread, the game creates a new JNIenv pointer for that thread. Unfortunately it does not cache this pointer, so a new pointer will be created for subsequent accesses. This is quite problematic and can result in a number of issues.

I will prepare a fix for that... do you only run your plugins on dedicated servers atm?

Hey, yeah, unfortunately we haven't updated the server.example.properties file in a long time Probably it makes sense to incorporate this in the build process, so a new example file is always generated

But a new config file can be generated by deleting the file, then starting a server.

However, what do you mean exactly with "weather effects don't seem to have any effect"? Does that mean the temperature has no impact on the player? Basically the temperature is controlled by the permissions (if notemperature under "general" is set to true, temperature won't have any impact on players).

There is also a hidden option for the server.properties to overwrite this permissions: this is only relevant if Permissions_OverrideNoTemperature was excplicitly added to the server.properties.

Thanks for your feedback!

Quote from AshWardle

Look into it. You have to keep a constant sleep schedule. Also, make a dream journal too and read past written dreams before you go to bed. After a while of these habits, try sleeping on your back and relax your whole body and clear your mind. Eventually your brain will slip into a awake-dream state and you will be able to work on new development ideas in your sleep!

It's a bit OT, but I was looking into this many years ago (before RW was a real thing) I'm afraid these days my sleep schedule is a little too chaotic to pull something like that off

Quote from Funmichi

Really cool would be HUGE deserts with small oasis with water or a well to get water in the desert.

Yes, that would be a nice addition. I will put this on my to-do list

Quote from Darwin_Blackwolf

I'm not sure if this is an old undiscovered bug, or if a change was recently made to the chicken laying eggs code, but I've had chickens laying eggs while the game has been on pause several times

Hmm... yeah, unfortunately this is a "limitation by design". The game determines a fixed time when a chicken lays eggs... but thanks for bringing this to my attention! I will try to change that for the next update

Quote from Darwin_Blackwolf

One more possible bug found, although it could be seen as a feature too: When I stand in the rain, my Thirst goes up by 5 every 40 seconds. I checked with F3 and after 40 seconds, my Thirst went up by 5. I waited another 40 seconds and it went up by another 5. I looked at the settings to see if there was something I could turn off, but I didn't find anything.

This is actually intended (unless I misunderstood your post) Rain slowly quenches the thirst of the player. Probably it would be a bit frustrating for a player if he dies of dehydration while standing in the rain.

Quote from appelcorn87

hat das gründe warum die gießkanne im baumenue nicht mehr vorhanden ist ?

Ja, leider ist sie bislang noch nicht funktional, daher habe ich sie aus dem Baumenü erstmal rausgenommen

Quote from appelcorn87

und frage gehen die flaschen 🙃im mit dem nächsten update dann auch aufzufüllen bzw zu platzieren das mit den botischen bzw trögen hat ich ja schon geschrieben echt genjal + jezt kähme das fass mit dazu 🫶👍🏆

Das kann ich leider noch nicht 100% sagen, aber wir werden das auf jeden Fall zeitnahe einbauen.

Sobald es aber möglich ist, Items in der Spielwelt zu platzieren, wird das für alle Items gelten

Quote from appelcorn87

bin am experementiernen das der regen durch n hohlen zylinder auch durch dach in diese n reinfällt ansatz ist vorhanden muss es nur noch je nach lang genug regnen 🙃👍🏆

Wichtig ist dafür im Grunde, dass der Mittelpunkt des Objektes freien Blickkontakt zum Himmel hat. Kommt also ein wenig auf die Position des hohlen Zylinders an, das muss mittig platziert sein (und es muss ein gerades Rohr sein).

Quote from SonoBionda

Wenn wir also zwischen "mein und dein" unterscheiden können, warum nicht auch zwischen "dein und gespawnt"? Das wäre für mich sinnvoll

Also d.h. du würdest dich dafür aussprechen, dass zB unter "world" neben destroyobjects und destroyownobjects potenziell noch ein destroynaturalobjects (o.ä) hinzukommt, mit welchem besitzerlose Objekte (wie aus POIs) gemeint sind (und analog dazu auch entsprechende construction/vegetation Permissions)?

Quote from Elfradhr

I can not upload images to the forum. Theoretically it's easy ! The above solutions don't work for me; i just get nothing.

What happens exactly when trying to upload an image to the forums? Do you get an error message?

I'm really sorry to hear that... if this ever happens again, please send a report, so I can take a closer look at why this happened. To send a report, open the console (key ~ or `) and type report. Maybe add some additional information then like "base is missing" and send the report.

However, maybe try to restart the game and see if the things are still missing. Some users ran into the issue that some parts of the world temporarily disappeared, but a game restart restored it.

However, if the game crashes, you can also send a report - just restart the game to the main menu and use the report command there. To find out why it crashed, you can still send the report now (the game will automatically attach the latest crash dump)

Plugin API 0.9 (2025-10-31):

• [New] Corpse object representing dead bodies
• [New] NpcDeathEvent.getCorpse()
• [New] NpcDeathEvent.getStorageID()
• [New] World.resetChunk() to delete/reset a chunk
• [New] Internals.overwriteUIText()
• [New] Internals.addUIStyleSheet() and removeUIStyleSheet() (see https://docs.unity3d.com/6000.…Manual/UIE-about-uss.html)
• [New] Internals.addToUIClassList() and removeFromUIClassList() (see https://docs.unity3d.com/6000.…ement.AddToClassList.html)
• [New] Player.showRadialMenu() now supports icon colors, selection colors and tooltips
• [New] Prefab.setVFXParameter() overload to change texture parameters
• [New] ObjectElement.setStatus() now accepts optional "instant" parameter (to set the new status instantly)
• [Change] Player.showRadialMenu() now correctly supports up to 15 entries
• [Change] ObjectElement.setStatus() now also works for chests/doors if they're locked
• [Bugfix] Fixed crash on server/game shutdown if an asset was disposed manually

This version uses Unity 6000.0.60f1. This is relevant if you want to build asset bundles containing custom shaders or VFX effects

Das Problem sollte nun mit dem neuesten Hotfix behoben sein Zarkofir Falls es aber weiterhin auftreten sollte, lass es mich bitte wissen!

Quote from toolman

I found a glitch with the skull gate, no matter what I try I cannot place blocks on the sides or around the top without having it not open. i just went into the game and tried again and it work just find , but some thing weird is going on now I could not find it under items or any where in the game

Unfortunately the skull gate was not supposed to be in this update, I just forgot to remove it It will be fully ready when we add real dungeons, however, maybe I can still fix the collision issue with the next update

We've released another minor hotfix now. It fixes an issue when trying to place blueprints (which did not contain any construction elements), but it also fixes some texturing issue.
If you still run into any issues, please let us know

This update is again optional for multiplayer servers, but still recommended to install.

Hotfix (2025-11-05):

• [Change] Reduced armor value of knights armor
• [Bugfix] Fixed error when trying to place a blueprint which does not contain any construction elements
• [Bugfix] Fixed disappearing turtle shell when cutting a turtle
• [Bugfix] Fixed texture scale 0 setting not being correct
• [Bugfix] Fixed stretched texture on slope blocks and window frames