Posts by red51

    red51 bekommen wir das multiplayer update bevor die Welt Generierung. Wenn ja, ist das bisschen komisch weil wo sollen wir bauen im multiplayer?

    Ja, MP kommt vor der Welt Generierung. Je früher der draußen ist, desto schneller können dort etwaige Probleme gefunden werden (der Netzwerkteil ist ein komplexer Bereich, den wir selber nur sehr eingeschränkt testen können, da hier eine Vielzahl von Faktoren eine Rolle spielt [Bandbreite, Verbindungsqualität, Spielerzahl usw]).


    Ein Baubereich ist ja grundsätzlich vorhanden. Momentan ist die neue Version ja so oder so noch in der "Testphase". Mit dem Bau- sowie MP-Update wird die neue Version zwar deutlich interessanter als noch die Demo, aber dennoch fehlen noch viele wichtige Dinge. Wenn ein Serverbetreiber alle relevanten Features mitnehmen möchte (Wasser, Biome, Dungeons etc), muss er leider ja eh noch ein wenig warten. Es macht zwar Sinn, mit dem MP Update ruhig einen Server aufzumachen (das wünschen wir uns auch, da sonst etwaige Probleme mit dem MP unentdeckt bleiben), aber man sollte evtl. nochmal mit einer neuen Welt einsteigen, sobald die Version umfangreicher geworden ist.


    Allerdings werden auch Baupläne relativ bald kommen, sodass auch Bauwerke, die mit dem kommenden Update erschaffen werden, in neuere Welten übertragen werden können.

    Ich hätte mal eine Frage zu den Blaupausen. Wenn ich ein Gebäude in einem Spielstand (Welt) in einen Anderen kopieren will, was wird die maximale Größe sein, die ich in eine Blaupause speichern kann?

    Ich kann leider noch keine genaue Aussage darüber treffen, wie das in der neuen Version genau aussehen wird, aber bis dato haben wir zumindest noch keine künstliche Größenbegrenzung eingeplant. Für eine Größenbegrenzung gibt es gute Pro- & Contra-Argumente: Einerseits ist es vorteilhaft, wenn man riesige Gebäude bequem in einen einzelnen Bauplan packen kann. Andererseits kann es im MP komisch sein, wenn ich plötzlich einen kilometerbreiten Blueprint platziere. Hier müssten wir uns mal Gedanken zu machen... Feedback wäre dazu auch recht hilfreich :)

    Grundsätzlich gilt jedoch - als technische Limitierung - dass ein Blueprint maximal immer nur den Teil der Welt umfassen kann, der auch wirklich generiert und geladen ist.

    Allerdings sollte man alle für die Blaupause benötigten Einzelteile liefern müssen um sie anwenden zu können. Das Farmen von Rohstoffen und Craften von Objekten sollte essentieller Bestandteil bleiben.

    Das ist grundsätzlich geplant. Das war auch schonmal für die Java-Version geplant, ist aber leider nicht mehr dazu gekommen :saint: Der Ursprungsgedanke ist, dass man alle Grund-Rohstoffe der Bauteile, die im Blueprint enthalten sind, aufbringen muss, um den Blueprint zu platzieren (zumindest im Survival-Modus). Allerdings gibts mit dem Ansatz auch Probleme, bspw. wenn ein selbstgebauter Sessel aus 10000 Bauteilen besteht, und entsprechend exorbitant hohe Holzkosten mit sich bringt :dizzy:

    Hier müssten wir uns mal überlegen, was die optimale Lösung dafür wäre...


    Auf jeden Fall sollte man auch daran denken das nur eine Blaupause von seinen eigenen Sachen gemacht werden darf nicht so wie jetzt das jeder der Blaupausen Erstellen darf auch alle Bauten von anderen Spielern Blaupausen kann.

    Ja, das wird in der neuen Version auf jeden Fall so umgesetzt :) Für jedes Bauteil wird gespeichert, wer es platziert hat. Die Einschränkung, nur eigene Bauteile speichern zu dürfen, wird man als Serverbetreiber direkt über die Permissions einstellen können (das existiert also unabhängig von etwaigen Protection-Plugins).

    I love the large Island/continent kind of idea for worlds, it sounds like it will give much more realistic and unique terrain, and also remove those ugly instantaneous biome transitions. Will all islands be a similar size? Or will we get a more realistic world with some variation, some large continent like islands, with some smaller islands just off the coast?

    Our world generator (which isn't fully ready yet though) is basically capable of generating islands with various sizes - from quite small islands (around 128x128 blocks in size), to big islands (up to 8000x8000 blocks). Our default world generator will mostly generate big islands, and sometimes groups of smaller islands. We're also thinking about having an option for players to determine the types of islands they want (rather big or rather small islands) when creating a new world, but unfortunately I can't give any guarantees about that yet. As said, the world generator isn't fully ready yet, but I can probably share more information about that in the next few months :)


    Also have you ever thought about adding rivers to world generation? I feel rivers are a big missing component of our worlds, we have oceans, lakes, mountains, plains, forests etc, I think adding rivers would make a finishing touch to world generation. Rivers are one of the important terrain features for building, as evidenced by the fact pretty much every major city on earth was built on one.

    Rivers would be a nice feature, and we have some plans for them, however, generating rivers in a procedurally generated voxel world is always a bit tricky. We want to focus on a few other things first before adding rivers to the game.


    And i hope the ai in the new version will be good like in red dead redemption 2 here for a exemple

    Well, unfortunately you won't get the same level of detail in RW as in RDR2 :| Implementing such an AI is a matter of time (and manpower) - the more time (and/or manpower) you have, the more you can spend working on details like that. So in this regard, I'm afraid we can't compete with a AAA studio... I'd love to get this level of detail, but then we would spend years solely working on NPCs :dizzy:

    When it comes to NPCs, our main priority is to get them working first (more or less like in the Java version, although the new version will definitely introduce some improvements in this regard). So we first have to focus on features which actually affect gameplay. Once everything is working, we could further improve it in the long run ^^


    Are you planning a lot of furniture, clothes, animals like cats, dogs, birds in the game? Cooking ..?

    Yes, these things are planned ;)


    Red, Will it be possible to craft windmills and water mills for generating electricity and processing grain into flour, for example?

    I can't get too much into detail about these things yet, but once electricity is implemented, there will be various power sources.


    It has me curious what sort of 'modern' vessels we shall gain. If we get something along the lines of an S.S Nomadic type boat I'd be happy. Its the right size to go through big rivers, a place to live, and a place to store your goods. Even hold crafting stations. If it has any built in then that be even better. If its modern fishing boats, tug boats or whatever then that would be fine. I hope Red51 gets access to a good source of boats.

    Unfortunately we don't have any modern vessels yet (except the RIB which was also available in the Java version), but more vessels are definitely planned :)

    Hast du evtl. einen konkreten Vorschlag für so ein Item? Wenn es irgendwas ist, was einigermaßen realistisch ist bzw. zumindest in irgendeiner Form plausibel ist, dann können wir das durchaus einbauen :) Was man generell könnte wäre, dass das Schlafen in Betten generell langsam den Spieler heilt. Was evtl. auch denkbar wäre ist ein bestimmter Buff, den der Spieler erhalten kann, wenn es ihm besonders gut geht oder die Umgebung besonders vorteilhaft ist (quasi ein "Zufriedenheits-Buff", welcher dann einen leicht heilenden Effekt hat). Diesen Buff könnte der Spieler auch vorübergehend erhalten, wenn er besonders zubereitete Gerichte verspeist (das wäre dann in puncto Kochen zumindest auch ein guter Grund, aufwendige Gerichte zuzubereiten, statts einfach die Rohzutaten zu verspeisen).


    Zwei Dinge gibt's aber doch. Zum einen gibt es nichts gegen Vergiftung (mich hat mal eine Spinne vergiftet und ich habenichtherausgefunden wie man das heilenkann).

    Vergiftungen gibt es in der Java Version leider noch nicht, aber vermutlich hast du geblutet. Das wird unten rechts durch die Bluttropfen (bei den Status-Icons) angezeigt. Das bekommst du mit einer Bandage wieder in den Griff :)

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


    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.

    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! :D

    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) :drunk: 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 :thinking:


    Have a Happy Easter red51 :thumbup:

    Thanks, Happy Easter to you too :D

    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) :/

    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.


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


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

    This would add a massive degree of complexity :wat: 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 :dizzy:

    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 :nerd:

    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 :saint: 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 :wat: Dadurch sind Server, die in den letzten ca. 3 Wochen dazukamen, nicht in der Serverliste aufgetaucht :silenced:


    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 :thinking: Er wird auch vom Steam-Masterserver erkannt, aber unser Server bekommt diesen neuen Datensatz irgendwie nicht :wat: 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!


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


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

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


    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 :thinking:


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

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