Sorry for my late response, but there is actually a setting for this 
Unfortunately it's not exposed to the settings menu... you can set it by opening the "config.properties" file in the game directory with a text editor and setting Game_RunInBackground to True, then save the file and launch the game again - now the game should no longer pause when losing focus.
Having said that, if it's just about plants, they will still continue to grow if the game lost focus 
Es wäre schön, wenn ich nen Webrahmen im Obergeschoß und eine Werkbank mit Amboss im Erdgeschoß aufstellen könnte und die von der Existenz der jeweils anderen Kenntnis hätten.
Oder wenn man schon alles auf einen Haufen platzieren muss, dann wenigstens alles etwas kleiner skalieren könnte (wegen Platzmangel)
Schwieriges Thema 
Grundsätzlich war es gewollt, dass Werkbänke nicht durch Wände hindurch verwendet werden können... könnte man eventuell nochmal überdenken, ob man diese Limitierung aufheben sollte 
Könnte andererseits aber auch im MP bspw. zu Situationen führen, dass Spieler die Werkbänke anderer Spieler verwenden können, die in verschlossenen Gebäuden stehen (indem sie einfach nur nahe genug an der Hauswand stehen). Inwieweit das in der Praxis wirklich ein Problem ist, steht natürlich auf einem anderen Blatt...
Ich kann die Schriftfarbe nicht mehr ändern. Wenn ich auf übernehmen drücke bleibt es immer schwarz.
(creativ)
Oh, das ist aber merkwürdig 
Auf Anhieb konnte ich das leider nicht reproduzieren, daher frage ich mich, ob es vll an einer bestimmten Ausrichtung des Textelements liegt Tritt das bei anderen Textobjekten auch auf?
Wenn du das Textobjekt erneut bearbeitest, behält der Texteditor denn die korrekte Farbe bei (oder meint der danach auch, dass der Text schwarz sei)?
mir ist aufgefallen, dass meine eingesperrten Hühner stiften gehen, obwohl alles zu ist. Habe es beobachtet, ungefähr in der Mitte des umzäunten Bereichs, verschwindet das Huhn einfach so.
Da das Haus etwas erhöht von Boden ist, taucht es dann darunter auf und marschiert gemütlich davon.
Die Bodenplatten sind 0,5 Einheiten dick.
Wahrscheinlich arbeitet die collision detection nicht immer korrekt.
Die Collision Detection ist bei NPCs definitiv nicht optimal... aber normalerweise sollten sie nicht so leicht in der Lage sein, abzuhauen. Meist tritt das dann auf, wenn die sich irgendwie in den Zaun reinbuggen können (meist wenn etwas anderes davor steht, was sie dann reindrückt). Kannst du ggf. einen Screenshot von der Stelle posten, wo sie abhauen?
Im Grunde ist das Symbol nur für Leute, die mit Controller spielen. Die Taste B erfüllt seit geraumer Zeit den selben Zweck
Hehe, jein, tatsächlich ist B nicht standardmäßig belegt Es gibt aber seit geraumer Zeit den Eintrag "Blaupausen" in den Steuerungs-Einstellungen, was natürlich problemlos auf B gelegt werden konnte/kann. Unter der Haube führt das nur den blueprints Befehl aus.
Wo wir gerade bei Controller sind, weis jemand wie man Bauteile damit dreht?
Habe es mit einem PS4 Controller probiert & bin kläglich gescheitert
Ist leider nicht sehr intuitiv, aber standardmäßig geschieht das, indem du das D-Pad rechts gedrückt hälst und dann den rechten Stick verwendest 
Und bei Opa Zeron hab ich jetzt gelernt, dass es gar nicht Taucherbrille heißt, sondern Tauchermaske.
Ja, das ist korrekt Umgangssprachlich ist Taucherbrille zwar nicht ungewöhnlich, aber irreführend... ich werde das mit dem nächsten Update anpassen!
Und die Halskette kann man ja nur mit BH anziehen. Why?
Leider ist das momentan eine Beschränkung des Spiels bzw. der Art, wie Kleidungsstücke gehandhabt werden. Es ist so, dass das Spiel nur max. 5 Kleidungsstücke pro Person vorsieht bzw. max. 1 pro Körperabschnitt (Kopf, Gesicht, Oberkörper, Beine, Füße). Da die Halskette vom Spiel nur von Banditen verwendet wird (und man sie nicht craften kann) reichte es beim Einfügen der Banditen erstmal, das einfach als Oberteil zu behandeln. Deshalb ersetzt es leider auch andere Oberteile.
Das ist aber etwas, was ich mittelfristig auf jeden Fall noch anpassen möchte, damit es mehr Kombinationsmöglichkeiten gibt (Schmuck allgemein, Handschuhe usw)
Seit wann ist im Survival eigentlich die Grasfläche so groß beim auftragen
Gute Frage, ich weiß nicht, ob es dafür einen Grund gab oder wie lange das schon so ist 
Ich schaue mir das mal an und ändere das entsprechend... ist nämlich tatsächlich nicht schön 
Ja, generell ist in der Wüste sowie in der Arktis die Spawnrate von Gold/Aluminium tatsächlich sehr hoch... damals als die Regionen ins Spiel kamen hatten viele Spieler Probleme, diese Erze zu finden, sodass wir die Spawnrate solange erhöht haben, bis sich zumindest niemand mehr beschwert hat
Leider ist es aber auch so, wie Forscherdrang schon sagt, nämlich dass die Erzeinstellung bisher keinen Einfluss auf die oberirdischen Erzbrocken hat... das wollen wir aber auf jeden Fall noch ändern! Und generell müssen wir da nochmal ansetzen und das Balancing anpassen... vll macht es Sinn, die Erze an der Oberfläche zu reduzieren und dafür im Untergrund zu erhöhen (damit man, wenn man wirklich viel Gold/Aluminium braucht, zumindest mit etwas Zusatzarbeit auch weiterhin an große Mengen gelangt).
Sorry for not responding earlier! 
In fact this is a tricky issue: it's caused by the GPU Resident Drawer that was added some time ago. It seems that the shader that's shipped with the asset bundle is not compatible with it, or more precisely, it's not compatible with DOTS Instancing. That's a bit weird because the HDRP/Lit shader (or any shader created with shader graph) should support it should... maybe adding GPU Resident Drawer support in the HDRP asset might already fix this, I will look into this!
However, you can also fix this by adding a so called DisallowGPUDrivenRendering component to the prefab. It might work by doing that in the editor (before building the bundle), but alternatively this can also be done retroactively through the Plugin API by calling prefab.addComponent("DisallowGPUDrivenRendering");
I tried it with both asset bundles and it worked after adding this component through the API. But please let me know if it still does not work!
Du könntest ggf. mal in der server.properties die Einstellung Plugins_SuppressFatalErrorLogs auf False setzen - dann sollte eine hs_err_pid angelegt werden Wenn es beim nächsten Mal nochmal crashen sollte, dann könntest du schauen, ob du diese Datei findest (und evtl. hier hochladen)
Ich habe tatsächlich auch bereits Reports dazu bekommen, allerdings stammen alle Spieler vom selben Server Das erhärtet den Verdacht, dass es ein serverseitiges Problem ist...
Der Ausschnitt den du gepostet hast bedeutet, dass der Server abstürzt bzw. ein nativer Crash auftritt. Möglicherweise ist irgendwo ein Restart-Handling drin, sodass du nicht direkt merkst, dass der Server abgestürzt ist (da er dann direkt wieder läuft).
Wenn alle Clients zum selben Zeitpunkt rausfliegen und in dem Moment im Log auch der SIGSEGV auftritt, dann ist das eindeutig die Ursache dafür. Wenn das hingegen unabhängig geschieht, d.h. jeder Client fliegt zu einem unterschiedlichen Zeitpunkt raus und im Server findet sich in dem Moment auch kein SIGSEGV, dann muss es eine andere Ursache geben. Auch hier ist von einem serverseitigen Problem auszugehen. In dem Fall könnte der Serverlog weiterhelfen.
Theoretisch sind bei sowas auch deutlich komplexere Ursachen absolut denkbar (zB Peering-Problem) - das ist vor allem dann naheliegend, wenn alle betroffenen Clients beim selben Internetanbieter sind (bspw. ist ein gewisser magentafarbener deutscher Anbieter ein Negativbeispiel in dieser Hinsicht).
Wenn aber doch alle zur selben Zeit rausfliegen und in dem Moment der SIGSEGV im Log auftaucht, dann ist der Crash Schuld. In den meisten Fällen wird ein nativer Crash durch ein Plugin oder einem Bug in der Plugin API verursacht. Hier könnte ggf. im Serververzeichnis eine hs_err_pid Datei liegen, die vll mehr Infos enthält.
Sobald du einen Timeout bekommst kannst du relativ einfach herausfinden, ob der Server abgestürzt ist: Öffne diesen Link im Browser http://89.163.193.44:4254/ und prüfe dort die "uptime" - das gibt an, wieviele Sekunden der Server schon läuft. Wenn hier ein kleiner Wert steht (zB < 100 o.ä), ist der Server gerade neugestartet.
Vielen Dank, die Notizen sind alle wieder da
Das freut mich zu hören Rein interessehalber, sind die Notizen von alleine wieder aufgetaucht, oder hast du das Backup davon wiederherstellen können?
Bin jetzt bei Proton Experimental geblieben und da ist jetzt nur noch der "Extraklick" beim Starten geblieben ... und Beenden über den Spielmenü Button geht jetzt gar nicht mehr (muss immer manuell in die Steam Bibliothek wechseln und auf Anhalten klicken.
Was das Beenden angeht, hast du ggf. einmal die Game_NoAbort=True Option ausprobiert (also den Eintrag zur config hinzufügen, falls noch nicht vorhanden)? Damit sollte sich das Spiel unter Proton eigentlich korrekt beenden
Wo landen die Dateien? Mir fällt grad auf, dass ich im Hauptverzeichnis vom Spiel nur eine Logs-Verknüpfung habe, die als fehlerhaft angezeigt wird und ansonsten kann ich nichts mit log finden!?
Das ist etwas speziell: Leider können wir Unitys Log-Verzeichnis nicht ändern, daher erstellt das Spiel einen Symlink zum Log-Ordner im Spielverzeichnis. Nun ist es so, dass das Verzeichnis unter Linux und Windows jeweils unterschiedlich ist, und wenn bereits ein Symlink unter Linux erzeugt wurde, wird er unter Windows (beim Wechsel zu Proton) beibehalten, auch wenn er nicht mehr funktioniert.
Aber die Lösung hast du ja bereits gefunden: Wenn du die Logs-Verknüpfung löschst, wird sie beim nächsten Spielstart erneut angelegt
Alternativ kannst du auch logs (oder auch gamedir logs) in die Spielkonsole eingeben, dann öffnet das Spiel direkt den tatsächlichen Logs-Ordner. Standardmäßig ist das unter Windows /Users/<username>/AppData/LocalLow/JIW-Games/Rising World und unter Linux /home/<username>/.config/unity3d/JIW-Games/Rising World
Mal eine andere Frage: kann ich den Cache Ordner einfach mal löschen? Hab da seit 2021 über 12.000 Objekte drin
Ja, der kann einfach gelöscht werden
Habe es "überflogen" und glaub da steht auch was drin, warum das Spiel nicht beendet?!
Danke für den Log! Ich kann leider keinen Hinweis finden, aber ich vermute, dass es mit der o.g NoAbort Option zusammenhängen könnte
Vielen Dank für die Rückmeldung, freut mich, dass es jetzt wieder funktioniert! 
Ich habe die Posts mal in ein eigenes Thema verschoben, da es sich beim Audio ja nochmal um eine ganz spezifische Problematik handelt
Das hatte ich schon probiert und eben noch mal. Selbst wenn ich alles auf 0 einstelle kommt das Rauschen weiterhin. Daran liegt es nicht. Es klingt wie das Rauschen aus einem aufgedrehtem Verstärker ohne Eingangssignal. Die Mikrophone-Empfindlichkeit habe ich im Systemlautstärkeregler auch auf 0 eingestellt, auch wenn kein Mikro angeschlossen ist. Das Rauschen bleibt. Ich vermute hier wird die Soundkarte falsch angesteuert/eingerichtet. Ob das an Unity, Steam oder dem Spiel liegt kann ich nicht sagen. Das Problem tritt halt nur mit der internen Soundkarte bei Rising World auf. Aber nicht bei anderen Spielen oder mit dem USB-Headset. Wobei das Problem mit dem Rauschen auf den Lautsprechern auch bleibt bzw. erscheint, wenn ich auf das USB-Headset umgestellt habe und ich den Verstärker anlasse. Das Rauschen endet erst mit dem Beenden des Spiels.
Hmm... wenn dann wird das entweder an FMOD liegen (der Audio-Engine, die wir verwenden), bzw. eine Audioeinstellung darin, oder an den Audiobänken (was ich aber nicht glaube)
Tritt das Rauschen sofort von Spielbeginn auf an (also sobald sich das Spielfenster öffnet), oder erst nach wenigen Sekunden (bzw. sobald das JIW Logo erscheint und die Musik beginnt)? Ist in den Audio-Einstellungen (von RW) das korrekte Ausgabegerät ausgewählt?
Könntest du sonst ggf. nach dem Spielstart (mit dem USB-Headset, bei welchem das Rauschen auftritt) einmal kurz einen Report senden?
Tut mir leid; wann genau die Dateien verschwunden sind kann ich nicht mit Sicherheit sagen. Aber wahrscheinlich war es nach Proton, denn da fiel mir auf, dass ich die Konsole nicht öffnen kann und da hab ich auch zufällig in das leere Journal geschaut.
Also ich habe unter Linux Mint auch einmal probiert, ob ich das Abhandenkommen der journal.json reproduzieren konnte... leider war das nicht der Fall Ich muss allerdings dazusagen, dass auf der Maschine auch in der Vergangenheit RW bereits unter Proton lief. Aber ein wildes Hin- und Herwechseln zwischen Proton und der nativen Linux Version konnte das Problem nicht reproduzieren.
Das Spiel hat keine Handling dafür drin, diese Datei zu löschen, d.h. auch hier kann nur ein externer Faktor infrage kommen (vmtl. Steam)
Werden die auch in der Steam-Cloud gespeichert? Denn bei mir sind auch alle Einträge weg
Ja, die wird auch in der Steam-Cloud gespeichert 
Du könntest aber ggf. noch eine Vorgängerversion der journal.json im "Cache" Ordner finden (beginnend mit "journal", gefolgt von einem Timestamp). Das ist nicht der letzte Stand, sondern die Version vor der letzten Änderung am Journal...
(seit dem letzten Update wird das Journal-Backup im "Backups" Ordner gespeichert)
[...]
Ich habe die Posts mal in ein eigenes Thema verschoben, da ja keine Abstürze auftreten und die Audio-Problematik ja doch etwas spezifischer ist
After taking a closer look at this I'd probably recommend to handle this in the plugin instead - actually that would be more reliable and more performant If the game has an event (or a bool), we have to calculate that every frame the player position changes (to keep the behaviour consistent and predictable). It would always be necessary to calculate it, even if no plugin uses it.
But if a plugin implements it instead, it could actually just calculate it every block (or every chunk, for example), which would be better in terms of performance.
Im your case, I'd recommend to use the PlayerChangeBlockPositionEvent. If it doesn't have to be exactly the edge of the world (right now it's ~16 blocks from the world edge), you could use the PlayerEnterChunkEvent instead for even better performance (that would trigger at ~32 blocks from the world edge). I will add a new Server.getDistanceToWorldEdge() function with the upcoming hotfix which calculates the distance of a position to the world edge (to make this handling a bit easier and more consistent), so the code could look like this:
Das ist leider eine ärgerliche Einschränkung durch Unitys "GPU Resident Drawer". Wenn der aktiv ist, kann kein weiches Überblenden mehr stattfinden. Das ist aber vor kurzem von Unity in neueren Engine-Versionen behoben werden, darauf werden wir vmtl. im Zuge des nächsten regulären Updates auch updaten
Zwischenzeitlich kannst du es bei dir auch beheben, indem du den "GPU Resident Drawer" in den Grafikeinstellungen deaktivierst - allerdings kann das (je nach Hardware) spürbar die Performance verschlechtern, weshalb ich eher davon abraten würde.
Das hat mit der Spielwelt nichts zutun, d.h. die muss nicht erneuert werden Das Problem deutet tatsächlich eher darauf hin, dass die definitions.db Datei verändert (oder nicht aktualisiert) wurde und die Rezepte darin serverseitig nicht mit den clientseitigen Rezepten übereinstimmt, wie SonoBionda schon erwähnt Mit dem nächsten Update wird es eine zusätzliche Prüfung dazu geben, sodass man eine Benachrichtung erhält, wenn die serverseitigen Rezepte nicht mit den clientseitigen Rezepten übereinstimmen.
Die entsprechende Datei heißt definitions.db und findet sich im "Data" Ordner unter "StreamingAssets". Am besten einmal löschen und den Server aktualisieren. Falls es danach immernoch nicht funktioniert, sag bitte Bescheid
Yeah, it seems that for some reason the map showed a completely different island... honestly I have no idea how that happened, but I'm happy that deleting the map folder did the trick!
Thanks a lot for the report! According to the report, however, it seemed that Proton was not active, instead the native Linux version (and Vulkan) was running Did you enable Proton for Rising World specifically (when right-clicking on RW in the Steam lib -> Properties)? Steam is a bit confusing in this regard (if it's only set globally in Steam, it will still launch the native Linux version of RW).
You can check if Proton is used if you enter graphics into console - if the line contains "Direct3D 11.0", Proton is active. If it contains "Vulkan" instead, the native Linux version is running.
But I'm glad to hear that it seems to be working now!
I'm also going to report this silly little thing where the map is misaligned. I probably should open a new thread for it, but don't want to clutter
Don't worry about creating new threads, personally I prefer separate threads actually (at least if the issues are unrelated) 
But about the map issue, that's really weird 
Not sure what could be causing this... is it an older world? Does the map always show the wrong location?
You could try to go to the world folder (the folder with the name of your world in the "Worlds" dir) and delete the "Map" folder there, then restart the game. Is the map still incorrect then?
Bei mir sind die Einträge auch verschwunden - genauso wie die Colors.json und Server.json .... letztere haben sich inzwischen neu angelegt, da ich wieder meine Favoriten eintragen und schon mal den Farbroller benutzt habe ..... journal.json gibt es noch nicht, da ich keine Einträge vorgenommen habe.
Hast du zufällig gesehen ob die Dateien bereits beim Aktivieren von Proton verschwunden sind (also als Steam die Windows-Version heruntergeladen hat), oder erst nach dem Spielstart? Ich werde es ansonsten morgen einmal unter Linux testen können
Aber wenn ich dann mit der maus auf das Startlogo klicke, kommt der Startbildschirm. Hab ich auch erst seit kurzem.
Um dieses "Auf das Startlogo klicken"-Phänomen genauer zu erklären: Bei dem Spiel ist es standardmäßig so, dass das Rendern pausiert wird, wenn kein Fokus gesetzt ist. Zwar werden die Spieldaten usw. geladen, aber das Hauptmenü wird nicht sichtbar (bis das Spiel wieder den Fokus bekommt). Wenn das also vorkommt, scheint das Spiel aus irgendeinem Grund keinen Fokus zu haben... trotzdem wäre es vmtl. sinnvoll, das dahingehend zu ändern, dass das Spiel dann erst nach dem Laden des Hauptmenüs pausiert wird (sofern kein Fokus vorhanden)
Hier wird der Start von RW erwähnt, das dauert bei mir auch ungewöhnlich lange.
Die Log-Datei enthält eine Übersicht darüber, welcher Teil beim Spielstart jeweils wie lange dauert. Du kannst gerne einen Report senden (mit dem Hinweis auf "lange Startdauer" o.ä), dann kann ich mir das mal genauer anschauen
That's a bit tricky unfortunately The max sector is basically handled client- and serverside: on clientside, the game smoothly prevents the player from leaving the world bounds. This feels a bit like an "invisible wall", i.e it smoothly stops the player. It's not an actual wall, instead the player movement is slowed down the closer to player gets to edge of the world. Unfortunately the server isn't even aware at this stage that the player is leaving the sector, so unfortunately it couldn't trigger an event.
The server, however, also has a handling for the max sector: if the player still manages to escape the world bounds (e.g. by teleporting, or when moving with a very high speed etc), the server teleports the player back into the world bounds. This is a situation where we could trigger an event, but usually this shouldn't happen very often (considering the clientside handling should already prevent the player from reaching that point in most cases).
However, we could add a serverside check if the player is very close to the world bounds (i.e the point at which the client starts slowing down the player - which is ~ 16 blocks from the world edge), then trigger an event and/or set a bool. It wouldn't be 100% perfect because the player could still move a bit closer to the edge at that stage. Would that still work for you?
Sorry for my late response, but thanks for letting me know! I will fix this with the next hotfix (which should be available very soon)
Sorry for my late response, and sorry for all the trouble and confusion about areas! I was able to reproduce these issues and they should be fixed with the upcoming hotfix (which should be available very soon)
I'm sorry to hear that! Honestly this sounds a bit like Steam Cloud messing up the data? Another user ran into a similar issue... Steam Cloud is known to mess up things sporadically, but usually this happens when the game crashes, or when multiple instances of the game are running etc. 
But just to avoid misunderstandings, does that mean that multiple Steam accounts are used, i.e when other people use your computer, do they log into their own Steam account (or do you share a single Steam account)? When multiple Steam accounts are used, maybe Steam has stored the blueprints and worlds for another user? You can open this link in your Steam client to check the files that are stored in the Steam cloud for your account btw: https://store.steampowered.com/account/remotestorage
If Steam did not store this data for any of the other users, I'd probably recommend to disable Steam Cloud for Rising World
