Posts by red51

The game indeed assigns a specific "activity" to npcs for this. In case of bandits, they have a "waiting" activity which means they're waiting until they see you. Unfortunately this is not exposed to the npc edit dialog yet... but thanks for bringing this to my attention! I will try to add this with the next update

Thanks for the reports! It seems that Unity does not detect the 3840x1080 resolution... during launch, the game lists all resolutions that are reported by Unity, and for some reason Unity thinks that 2560x1080 is the highest supported resolution I'm afraid this is a Unity issue (maybe affecting Unity 6 specifically). Unfortunately Linux does not get much love from Unity in general

You could maybe try to open the console and enter resolution 3840 1080 and see if that works. This forcefully changes the resolution with no extra checks, but there is a chance that Unity won't allow to set a resolution it considers unsupported...

About the crashes: unfortunately this is currently an issue affecting several Linux users. It's an internal Unity issue (most likely HDRP-related), so this is also out of our control unfortunately... it first appeared when we updated to this Unity version (before the update, the very same issue was mainly affecting Windows users). However, we will update to the latest Unity version with one of the next updates, so this might fix the issue (or make it worse, who knows)...

The JVM crash you see is probably just caused by the game crash. It always crashes when the game crashes. Unless you're using any plugins, it's unlikely that this causes the crashes...

About the memory leak (the warning in the log): this is unfortuantely also caused by Unity, or more specifically, by Unitys HDRP. But it doesn't seem to be a major issue because it's apparently just a few KB or MB, so nothing that would cause trouble. There is a chance that this might also be fixed in a newer Unity version

But I'd recommend to give Proton a try. It will most likely fix the crashes and also the resolution issue. Make sure to enable Proton for RW specifically (it's not sufficient to just enable it globally in Steam, instead it's necessary to select Proton right in the RW properties in your Steam lib). If it still doesn't work properly (or if you run into any other issues), please let me know

Am naheliegendsten ist hier eigentlich entweder ein Crash durch ein Plugin bzw. die Plugin API, oder aber dem Server geht zB der RAM aus... du verwendest weiterhin noch Plugins, oder hast du den Server schonmal testweise ohne Plugins betrieben? Im Serververzeichnis ist keine hs_err_pid Datei vorhanden, obwohl du "Plugins_SuppressFatalErrorLogs" auf False gestellt hast? Ist diese Einstellung weiterhin auf False gesetzt (manche Hoster überschreiben die Datei zB)?

Gibt es vom Hoster evtl. irgendwo eine Konsole oder ein Interface, in welchem du Serverausgaben sehen kannst? Denn die Serverlogs, die im "Logs" Ordner sind, können leider keine kritischen Ausgaben von Unity selbst erfassen (zB wenn dem Server der RAM ausgeht).

Ansonsten kannst du aber auch den Scheduler verwenden, um regelmäßig den Speicherverbrauch auszugeben. Lege dazu im Serververzeichnis eine Datei "scheduler.txt" an (falls noch nicht vorhanden) und füge dort diese Zeile ein:

@5m /memory

Damit wird alle 5 Minuten der Speicherverbrauch des Servers ausgegeben (im Log). Ggf. könnte man das sogar sonst jede Minute ausgeben (wäre dann "@1m"). Wenn der Server dann crasht, könnte der letzte Log am Ende Aufschluss darüber geben, ob evtl. zuviel RAM verbraucht wird. Relevant ist hier der Wert hinter "Managed" + der erste Wert von "Java VM" + der erste Wert von "Native".

Leider wurden offenbar keine Anhänge mithochgeladen, wodurch die Bilder (?) fehlen

Was den Launcher angeht, grundsätzlich ist es so, dass dieser schaut, ob in der config.properties ein Eintrag bei Game_Language vorhanden ist (und verwendet dann diese Spracheinstellung). Falls nicht, sollte eigentlich die Systemsprache verwendet werden. Aber das hat keinen Einfluss auf das Spiel selbst. Es ist auch egal, ob du über den Launcher startest oder direkt die .exe (allerdings werden neue Updates - wenn verfügbar - nur heruntergeladen, wenn du über den Launcher startest)

Was die alten Welten angeht, hier kommt es ein wenig darauf an, wie alt die wirklich sind. Wenn sie zu alt sind (zuletzt vor mehr als 1-2 Jahren gespielt), dann sind sie meist leider nicht länger kompatibel. Das Spiel kann alte Welten i.d.R. nur über wenige Updates hinweg konvertieren (je nachdem, was sich ändert), d.h. eine Welt müsste am besten mind. 1x pro Jahr oder 1x alle 2 Jahre geladen werden (je nachdem, was für Updates in der Zwischenzeit erschienen). Mit Fortschreiten der Spielversion wird das aber immer weniger kritisch (da es nicht mehr so viele grundlegende Änderungen gibt).

Du könntest sonst aber auch nach dem vergeblichen Laden einer solchen Welt mal einen Report senden, der würde Aufschluss geben, warum die Welten nicht mehr geladen werden können. Versuche dazu zunächst eine der Welten zu laden, und sobald du wieder im Hauptmenü bist, öffne die Konsole (^) und gib report ein (füge dann vll noch den Hinweis hinzu, dass du eine alte Welt nicht laden kannst)

Quote from Hintzi

Wann nächstes Update red51 ?

Wahrscheinlich diesen oder spätestens nächsten Monat

Quote from Hintzi

Nebenbei, ich komme mit der "Roadmap" nur bedingt klar muss ich sagen und es wirkt für mich sehr willkürlich wann was kommt, an was weiter gearbeitet wird und was bearbeitet wurde und nach hinten geschoben wurde^^

[...]
Aber mir wäre längerfristig eine Verbindlichere Roadmap doch lieber, wie das hier als Beispiel.

Das ist mehr als nachvollziehbar Leider aber auch schwierig umsetzbar... es ist so, dass ich nur selten konkret an einem einzelnen Feature arbeite. Meistens sind mehrere Dinge in Arbeit, oftmals kommen aber auch unvorhergesehene Dinge dazu. Sei es durch Vorschläge aus der Community, oder auch Bugs etc, die ans Tageslicht kommen. Um eine verbindliche Roadmap wie auf dem Screenshot zu bieten bräuchten wir bei einem so umfangreichen Projekt wie RW unbedingt mehr Manpower...

Eine verbindliche Roadmap wie auf dem Screenshot wäre aber auch sogar noch verbindlicher als eine grobe Einschätzung von mir im Forum. Zwar ist es auch da immer uncool, wenn die Einschätzung danebenliegt und ein Update länger braucht, aber bei einer konkreten Roadmap mit Terminangabe wäre das mE weit problematischer, denn viele Leute würden sich darauf berufen und fest mit den Angaben darauf rechnen. Ggf. kaufen sich Spieler das Spiel nur, weil die Roadmap ein bestimmtes Feature in zB 2 Monaten verspricht, und würden sich dann evtl. sogar betrogen fühlen, wenn das Update dann länger braucht.

Ich kann leider auch nur schwerlich eine verbindliche Roadmap für einen größeren Zeitraum (zB 1 Jahr) festlegen. Es gibt viele Features, auf die die Spieler warten und ich versuche möglichst viel irgendwie irgendwo dazwischenzupacken. Wenn ich jetzt sagen würde, dass wir in den nächsten 9 Monaten nur an Zügen, Autos und Schiffen arbeiten, würde das vmtl. jeden ärgern, der keinen großen Wert auf diese Features legt. Und neben reinem Content gibts dann noch diverse andere Features, die zwar keine besonders große Nachfrage haben, aber dennoch umgesetzt werden müssen (Gamepad-Support, 3rd Person Ansicht usw).

Manchmal kommt es auch vor, dass ein bestimmtes Feature einfach nicht so gut funktioniert wie erwartet oder nicht so richtig passt, sodass es dann wieder rausfliegt, bevor es überhaupt mit einem Update verfügbar wird. Das kommt aber eher selten vor. Eher passiert es schonmal, dass ein Feature dadurch wieder auf Eis gelegt wird bis wieder etwas Zeit für weitere Anpassung o.ä ist.

Leider ist auch die insgesamt benötigte Zeit für ein Feature schwierig einzuschätzen (dadurch kommen Updates auch oft erst am 33. des Monats ). Ich muss auch zugeben, dass es mir schwerfällt, ein bestimmtes Feature in einem nicht zufriedenstellenden Zustand zu veröffentlichen. Manchmal ist es der Feinschliff, der den Großteil der Zeit frisst.

Aber ich werde die Roadmap zeitnahe nochmal etwas aufräumen. Habe auch schon öfter darüber nachgedacht, die Roadmap umzuziehen (gibt mittlerweile bessere Alternativen), wollte die Arbeit aber bislang noch nicht machen (bzw. habe die Zeit dann lieber ins Spiel gesteckt)

There was actually a discussion about persistent attributes before: Persistent Attributes

Basically it's possible to implement this, but with some limitations unfortunately. The main limitation is that you wouldn't be able to store any type of object, instead it would be limited to serializable data (e.g. primitive data types, strings etc)... I will take a closer look at this

Hmm... that's weird Basically the game should support ultrawide resolutions, we've tested it at least with 3440x1440 (that's the resolution I'm using), 5120x1440 and 4K UHD (3840x2160)... maybe it's an issue specifically with the Linux version. I've only tested the game on Ubuntu and Mint recently...

Do you run the native Linux version, or do you play via Proton? Maybe send a report, hopefully it contains more information about why the resolution is not properly detected To do that, open the console (key ~) and type "report". Alternatively you could also load a world, then press ESC and hit the red report button in the lower right corner of the screen.

Thanks for the reports! Just to avoid misunderstandings, when talking about "lags", you mean actual lags, i.e the game still runs smoothly but there is a huge delay in various actions (sending chat messages, world takes ages to load etc)?

What's suspicious in the logs is that there is apparently a very high ping (often between 200-1000ms)... is it only that high while experiencing these lags? Or is it always that high?

The problem with a high ping is that it drastically reduces the overall throughput. For instance, a ping of 800 ms and 1% packet loss results in a max theoretical bandwith of only ~18 KB/sec.

If the bandwith if fully used up for sending larger data, for example, you won't even receive smaller packets in the meantime (like chat messages). In other words, if the game is busy downloading images, plugin data or world data, you will experience the lags you've described above. According to the logs, there is a lot of data sent from server to client (up to several hundreds of MB).

Unfortunately there might be other reasons why the ping is that high, e.g. a high general server load. If I understood it correctly, all players suffer from the lags, is that correct? Or does it only affect certain players?

The server log might contain more information if something is wrong there... do you mind sending me a server log from a session where these lags occurred? Feel free to send it via PM to me

Das ist merkwürdig Wenn das Spiel hängt, wurde zu dem Zeitpunkt denn dann bereits "[END]" im Log ausgegeben (am oder nahe am Ende der Log-Datei)? Wenn nicht, dann scheint irgendwas vom Spiel zu hängen... was ist denn dann in dem Fall die letzte Ausgabe?

Wenn "[END]" aber bereits ausgegeben wird, dann könnte ich mit dem nächsten Update ggf. eine Option einbauen, womit das Spiel gekillt wird, vll könnte das helfen

Ja, True wäre dort der richtige Wert, dann kümmert sich Unity selbst um das Beenden. Wenn es aber mit True nicht klappt, probiere einmal, es explizit auf False zu stellen

Die Ausgabe "[END]" im Log ist die letzte Ausgabe vom Spiel. Ab dem Zeitpunkt hat das Spiel leider keine direkte Kontrolle mehr darüber... wenn also beim Hängen bereits "[END]" drin steht, muss entweder Unity oder Steam verantwortlich sein (höchstwahrscheinlich eher Unity). Da das ganze aber in deinem Fall über Proton läuft ist das auch ein weiterer Faktor, der eine Rolle spielen kann...

Die Cloud sollte es eigentlich nicht sein, da die erst nach dem Beenden des Spiels aktiv wird (also erst, sobald auch Steam sagt, dass das Spiel nicht mehr läuft). Normalerweise zeigt Steam dann aber für RW auch an, dass die Cloud synchronisiert wird.

Quote from yahwho

Is it just the screen rendering that is paused then red51 I assumed the main game thread was paused.

It does indeed pause the main thread The game also pauses a few other things (e.g. clientside npc handling etc), but some stuff like cooking food, plant growth etc will still continue to work

Thanks a lot for your feedback, I'm glad to hear it worked!

Das Forum sollte wieder funktionieren, leider war der Speicherplatz aufgebraucht Das Forum (bzw. sämtliche Dateianhänge) werden langsam auch echt groß

Was das Beenden des Spiels angeht: Hast du mal die Game_NoAbort Option für die config.properties ausprobiert? Vielleicht ist das das auch etwas untergegangen. Aber das wäre in meinen Augen der naheliegendste Grund für das langsame Beenden.

Die letzten Ausgaben im Log kannst du eigentlich ignorieren. Es ist Unity selbst, welches seine Allocations nicht aufräumt bzw. einen Memoryleak erzeugt. Wenn ich mich recht entsinne trat das mit irgendeiner Unity Version auf. Das habe ich mir in der Vergangenheit schonmal genauer angeschaut und kann sagen, dass wir hier aber von einem absolut vernachlässigbaren Problem reden. Das ist wahrscheinlich auch nicht für die lange Dauer beim Beenden verantwortlich

Quote from hedgehogform

But doesn't that disable gpu rendering and put it on the cpu??? That's not really good.

I will try playing around with both methods you said though.

No, it's still rendered by the GPU It's just excluded from the "GPU Resident Drawer". This is a new feature that was added a few months ago, making rendering lots of objects a bit more efficient. Unless you're spawning hundreds or thousands of instances of the prefab, you probably won't notice a difference.

But about my previous suggestion: probably you can't add the component in the editor (before building the bundle), so it might be necessary to add it through the Plugin API. But that should definitely work

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

Quote from SonoBionda

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

Quote from FioO

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

Quote from 1987_ew

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?

Quote from Forscherdrang

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.

Quote from Forscherdrang

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

Quote from FioO

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!

Quote from FioO

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)

Quote from Forscherdrang

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.