Posts by red51

Quote from Yaromid

Ich habe gerade den Thread wiederentdeckt und mir sind einige Horror-Erinnerungen von der "alten" Weltgeneration hochgekommen. Was mich am meisten an der Biom-Generierung in der Java-Version gestört hat, war die stupide Kachel-Anordnung, d. h. die Welt bestand im Grund aus Quadraten von Biomen, was man sehr gut auf Karten erkannt hat

Ja, das war in der Tat nicht schön. Auf Karten wurden auch ein paar andere Probleme sichtbar (zB dass sich Teile der Welt manchmal wiederholt haben, was definitiv ein Bug ist). Die Welt wird allerdings in der neuen Version auch in Kacheln unterteilt sein (damit können wir sicherstellen, dass wir künftige Updates an der Welt vornehmen können [zB neue Dungeons oder Biome], ohne, dass alte Welten inkompatibel werden). Allerdings werden die Kacheln deutlich größer, und die Übergänge wesentlich natürlicher und unauffälliger

Quote from Yaromid

Kann man uns dazu schon etwas Greifbares zeigen, red51? Ich verweise auch nochmal auf den Beitrag hier drüber

Leider habe ich in der Hinsicht noch nichts parat Es fehlen noch ein paar Dinge bei der Weltgenerierung damit hier richtige Inseln ausgespuckt werden. Unser Plan ist es, uns nach dem Multiplayer-Update darum zu kümmern.

Quote from LuckyMarvini

Hello, he tried and it’s still not working. He was sad that he needed to refund the game, but when he has a better laptop/pc, he will definitely buy it again!

I'm sorry to hear that it still didn't work But yes, in this case it seems to be the best option then

Quote from yahwho

Without any ale in my system, thinking more clearly about it, yes that would mean writing code - for - every - single - getter - setter - constructor- and his aunt. And then every time one was added or changed. I do like creating work but this now sounds ridiculous!

Best stick to Plan A!

Yeah that's true, that would be way too much additional work and redundant code (which, in return, would be fairly error prone) Nevertheless, maybe we still find a way to offer a proper restart functionality. Maybe it's even sufficient to have something like that just for Windows: On Linux, it's fairly easy to set up a crontab via script, but on Windows, the TS seems to be a bit more problematic

Quote from yahwho

Have a Happy Easter red51

Thanks, Happy Easter to you too

Quote from LuckyMarvini

He downloaded the driver update, but sadly his game is still freezing. As well in multiplayer as in singleplayer. It isn't crashing anymore tho, just his screen is stuck. Is the best option for him, to refund the game?

I'm sorry to hear that Your friend could try to disable some graphics settings and see if this improves the situation. One last thing he could also try is to open the "config.properties" file in the game directory with a text editor and set graphic_instancing to false, then save the file and run the game again - this disables geometry instancing, which results in higher memory consumption, but some integrated graphics adapters struggle with this feature. But if the game still freezes, it's probably better to refund the game - unless your friend has any plans to get a new laptop in the near future. Unfortunately the upcoming new version won't run on an Intel HD graphics adapter anyway (due to insufficient performance)

Quote from yahwho

I've not looked too much into this yet (it is Saturday night after all ), but couldn't you just start a JVM with the JNI that then creates a new JVM as needed?

That wouldn't help if it's still the same process. And in this case we need to find a way to communicate with the other JVM (that was started by the JVM), since all our native references and pointers wouldn't be valid anymore.

Quote from yahwho

That would mitigate the segmentation fault?

It could be either a bug in the JDK, or this behaviour is simply not supported (which is more likely). In most cases there is almost never a situation you actually have to recreate a VM after destroying it

Quote from yahwho

Use the first JVM as a kind of bridge/ interface?

This would add a massive degree of complexity The API already got a lot complexer in the new version due to the communication between Java and the native side (via JNI). Right now the native part alone is more than 10k lines of code (without taking any Java code like the actual API into account), and some API stuff is still missing

Passing data from Java to C#/C++ is quite easy, but receiving this data on the native side or passing data from native to Java (or vice versa) involves a lot of boilerplate code (especially if we're not only dealing with primitive datatypes, which is often the case in our API). If there was another bridge now this would make the API extremely bloated.

====================

Nevertheless, the issue with the JVM is really just a minor issue compared to the other issues that evolve if an application restarts itself

No, installing the new driver is actually the only thing that could fix the issue But there is a chance the latest driver is also suffering from the same issues (unfortunately the Intel HD graphics adapters aren't meant for gaming, especially when it comes to OpenGL, which is not as widely used as DirectX)...

The limitations I've mentioned about the JVM don't apply if you launch a VM as a new process, but in case of the new version, we need to create a VM through JNI (we need the native interface for the communication between Java and C#/C++) - but creating a VM after destroying a previous one always results in a segmentation fault. It's not very clear whether this is intended behaviour (simply because recreation of a VM is unsupported) or a bug (there is a very old bug report [almost 20 years old] about this). Basically it's specific to JNI. There is a (rather small) discussion on stackoverflow about that: https://stackoverflow.com/ques…e-jvm-after-destroying-it

But this isn't necessarily a major issue. Basically the main game faces the same issue (when returning to the main menu, which unloads the plugin API), so we make sure to have proper cleanup routines and we just reuse the old VM when loading another world (or joining another server). We could implement the same for the server itself (basically everything that's necessary for this is already in place [i.e. clean up network connections and release resources]), but I'm not sure if this is sufficient - if something goes wrong, this wouldn't work. Especially if any issues are related to the process (locks or issues with any connections), this wouldn't help at all (because it's still the same process).

Starting a separate process from within the application doesn't work either - at least it's not reliable. Basically the process API always run new processes as child processes, and terminating the main process also terminates childs. It is possible to run a detached process (which is still alive after killing the original process), but this sometimes results in strange situations (like invisible processes, and sometimes they can't even be killed), especially after doing this multiple times. But as mentioned, we have to tinker with that a bit - it was quite problematic in Java, but it might work better in C++.

Having a separate "launcher" which runs the game/server as child process is basically the proper way to do something like that (this is what our standalone is doing, but your RCON tool seems to be doing that as well?). In this case the "launcher" can always stop and restart the actual program at any time. But for our dedicated server, we don't have plans to introduce a separate launcher (since a launcher also introduces a few other issues - and it would also bloat the server).

Thanks for the info! If it also crashes in singleplayer and even in the main menu, it's very likely caused by the graphics driver. The Intel HD graphics adapters are known to have issues with OpenGL

Freut mich, dass es jetzt funktioniert, es war aber tatsächlich noch etwas mehr im Argen Es lag in diesem Fall an uns: Unsere temporäre IP Adresse (die wir momentan als Übergangslösung verwenden, bis das Problem mit dem Rechenzentrum gelöst ist) war noch nicht bei Steam gewhitelisted (wir haben dort eine IP-Whitelist aus Sicherheitsgründen eingerichtet), wodurch unser Server keine neuen Daten mehr von Steam erhalten hat Dadurch sind Server, die in den letzten ca. 3 Wochen dazukamen, nicht in der Serverliste aufgetaucht

Das ist momentan kaum aufgefallen, da ja generell etwas wenig los ist, da viele auf das neue Update warten...

Ich möchte mich dafür entschuldigen, aber gleichzeitig auch für den Hinweis und die Mithilfe bedanken, denn sonst wäre uns das wohl erst viel später aufgefallen!

Danke für die Infos und auch für den Log!

Der Server ist durchaus über den Query-Port erreichbar Er wird auch vom Steam-Masterserver erkannt, aber unser Server bekommt diesen neuen Datensatz irgendwie nicht Ich würde behaupten, dass das diesmal an uns liegt, vielleicht hängt das mit diesem Vorfall zusammen (tatsächlich ist das Routing unserer Server momentan immernoch eine temporäre Lösung, daher kann es sein, dass irgendwas nicht 100%ig funktioniert)...

Ich prüfe das nach. Das dauert leider einen kleinen Augenblick, ich melde mich gleich auf jeden Fall nochmal deswegen!

Quote from MrIgsh

1. der Logeintrag: "STEAM BIND TO 89368686 (5.83.168.110), PORT 10400, 10404 MODE: Authentication"

müsste das nicht der Port 10399 sein?

Das hat schon seine Richtigkeit

Quote from MrIgsh

2. in den server.properties die Variable: server_steam_port=0

Auch das ist soweit richtig. Diese Einstellungen fliegen mit der neuen Version raus, da sie tendenziell nur Verwirrung stiften. Auch die server_query_ip sollte idealerweise leer bleiben (das war damals nur ein Workaround für einen Bug in Steam selbst, aber den hat Valve irgendwann gefixed), aber in deinem Fall scheint das nicht das Problem zu sein.

Thanks for the report file! This may be caused by the integrated graphics adapter - the Intel HD graphics adapter had severe issues with OpenGL in the past. You could try to install a newer driver (the installed driver is dated on September 2020), here you can download the latest Intel driver: https://downloadcenter.intel.com/en/download/30266

Does the crash only happen in multiplayer sessions, or also when playing singleplayer (or when playing on public multiplayer servers)?

Quote from yahwho

I run MR on a dedicated Windows server, I assume it will be possible to run both the unity server and the new version at the same time?

Yes, you can run both servers simultaneously, as long as they're installed in different folders and use different ports

Quote from yahwho

Also, will the new version have any automatic restart functionally

Having a proper restart functionality is a bit problematic: You can't properly restart an application from within the application. In case of Java (the new version still needs a JVM for the plugin API), this introduces a few additional issues, since the JVM is very restrictive in this regard (once a VM, which was originally started from a certain process, is terminated, it's impossible to create a new one in the same process).

It's always safer to have an external program or script which performs the restart. However, there are a few dirty and unsupported workarounds though to still restart an application. We did some experiments with that in the past (with the Java version), but it wasn't possible to reliably restart an application (resulting in undefined behaviour - sometimes it worked, sometimes it resulted in messed up "invisible" processes, depending on the OS). This may be different in the new version, we have to run a few tests before I can give any information about that.

Windows offers a specific API to handle restarts, but that seems to be mainly intended to perform restarts after driver updates (or at least to release shared resources). I haven't looked into this API yet, but this would be obviously a very platform-specific solution (and even on Windows, this wouldn't be available on all versions).

Maybe we could alternatively implement a "soft restart", without actually performing a fresh restart of the application (not an actual restart, instead this would be more like a "reset"). I'm not sure if this is sufficient - especially if something goes wrong, there may still be unreleased resources

In short, we will try to find a proper way to restart the server reliably, but unfortunately I can't give any guarantees

Hast du den Namen des Servers angepasst? Standardmäßig heißen neue Server "Default Rising World Server", und dieser Name wird in der Serverliste ausgeblendet. Ansonsten ist in der server.properties Datei der Wert server_list_visible ausschlaggebend dafür, dass der Server in der Liste auftaucht (dieser muss auf "true" gesetzt sein).

Wichtig ist außerdem (aber darauf hat nur der Hoster Einfluss), dass der Query-Port (Serverport-1) freigegeben ist. In deinem Fall wäre das Port 10399.

Evtl. könntest du einmal die IP des Servers hier posten, dann könnte man feststellen, ob der Query-Port erreichbar ist. Ansonsten wäre vll auch ein Serverlog hilfreich, dieser findet sich im Serververzeichnis im "Logs" Ordner (du könntest den Log entweder hier direkt hochladen, oder mir gerne auch via PN senden)

Quote from Deirdre

I wish there would be an option, dirt, no grass.

It's on our to-do-list for the new version

Thanks for the error log! I'm sorry to hear about the crash... but the log file indicates a native crash occurred - in most cases this is caused by the graphics driver, but of course there is also a chance something else is going on. To find out what's really going on, a report file would be very helpful. To create one, run the game (it's sufficient to just load the main menu), open the console (by pressing ` or ~) and type report, then a report file will show up in the game directory. Please upload this file here (or just post the file content in this thread, or alternatively send me a PM)

Quote from Avanar

Hey red, wie wäre es wenn du dafür die community mit einbeziehen würdest und so eine kreative Story zustande käme?

Naja, grundsätzlich kann ja jeder Vorschläge posten Eine "richtige Story" stelle ich mir aber bei RW ein wenig schwierig vor (also eine Story, die erklärt, wer der Spieler ist, wo er herkommt, und warum er da ist). Einigermaßen denkbar wäre meiner Meinung nach nur sowas in Richtung "Schiffsbruch" bzw. gestrandet sein, aber selbst das ist nicht ganz passend, denn für sowas würde ich das Gameplay dann eher in eine etwas andere Richtung lenken (zumindest wirkt es komisch, wenn der Schiffsbrüchige iwann nicht mehr ums Überleben kämpft, sondern sich Autos und hochmoderne Maschinen baut). Generell müsste man RW wohl anders auslegen, wenn eine richtige Handlung oder Storyline reinkommen sollte (also bspw. eine Story im Sinne von Skyrim, The Forest etc)

Sinnvoller bei so einem Spiel wie RW finde ich hingegen eine unabhängige, lose Geschichte, die unabhängig vom Spieler erzählt werden kann. Etwas, was der Spieler nicht unbedingt machen muss. Etwas, wozu der Spieler auch nicht gedrängt wird, sondern er evtl. selber entdecken muss. Grundsätzlich eine Art Story, die dem Sandbox-Charakter des Spiels nicht zuwiderläuft.

This sounds very interesting SighBorg The terrain changes (i.e. terrain sculpting) shouldn't have a big impact on performance though, but other stuff like denser vegetation (compared to the original state), more npcs and more constructions definitely play a role. At the end of the day, rendering performance in the Java version only depends on the number of draw calls and total amount of visible polygons: When it comes to draw calls, this is mostly affected by npcs and vegetation (especially if there are many different plants). Polygon count, on the other hand, is basically affected by everything (every single plant, block or plank you place). Npcs play a special role, since animations add additional GPU load, and AI handling and collision detection for them add CPU load (due to limitations of the physics engine in the Java version npcs have quite a noticable impact on the CPU).

In the new version, npcs will have less impact on the CPU (mainly due to the much better physics engine and cheaper collision detections), but the rendering overhead is much bigger (due to the higher visual quality). Although it's a bit difficult to compare with the Java version: In the Java version, you'll get great performance, especially on low view distances, but performance becomes worse the higher the view distance. In fact it becomes extremely worse when setting higher values than the max values in the settings (21 detail distance, 50 total view distance), even on high end machines. In the new version, on the other hand, performance in empty worlds is worse compared to the Java version (especially on low view distances), but much better in complex scenes when having great view distances (in general, the new version is capable of rendering much bigger view distances). It's still important to have a powerful machine which can handle the base overhead of the new version

Freut mich, dass es jetzt funktioniert

Achso Ja also man wird tatsächlich ohne Werkzeug spawnen und sich zunächst Stöcke und Steine sammeln, aus welchen man seine ersten Werkzeuge herstellen kann. Ein direktes "Ende" in dem Sinne wird es nicht geben, allerdings ist der langfristige Plan (wenn alle Spielmechaniken stehen), eine Art optionale lose Story einzubinden, wobei das keine "Geschichte" im klassischen Sinne wird, sondern tendenziell eher so wie bei MC ausfällt (wo man ja quasi auch eine Art lose Story erleben kann, mit Endgegner usw, aber diese Story eig. nix mit dem Spieler direkt oder seiner Herkunft zutun hat).

Wie PresenceRusher schon sagt, das ist momentan nur die Demo der neuen Version, die noch sehr unvollständig ist. In der Downloadliste findest du auch die normale Java-Version (einfach "Standalone" genannt), bzw. der Link von Taiskorgon bringt dich direkt zum Download der Java-Version

Wichtig ist aber, die Standalone in ein anderes Spielverzeichnis zu packen als die Demo der neuen Version (oder alternativ die neue Version löschen), da sonst die Spieldateien miteinander kollidieren.