Posts by red51

The next update will be available on Friday, October 31, towards the evening (GMT+1)

    Ich hoffe das es ein guter Texturenmix wird, da ich nach dem Bauupdate sofort beginnen möchte eine kleine moderne Stadt zu bauen

    Es wird auf jeden Fall einige sehr interessante Texturen geben (und diese werden im Vergleich zur Java Version deutlich hochauflösender [bis zu 2K] und dank Dingen wie Schatten, Glanz usw. spürbar authentischer) :D Sicherlich werden manche Sachen wohl noch fehlen, aber das wird sich dann nach dem Update ergeben (und wie gesagt, wir können auf jeden Fall noch weitere Texturen hinzufügen).


    Frage: Wird es dann auch möglich sein Bautexturen auszutauschen? Hab noch nen Ordner mit vielen eigenen Steintexturen die ich dann vielleicht gerne nutzen würde, wenn mir eure Texturen nicht so gefallen sollten ;)

    Texture-Packs sind geplant, aber leider noch nicht mit dem nächsten Update verfügbar :| Hier müssen wir bei der neuen Version ein wenig weiter ausholen, denn hier ist ein Material nicht mehr mit einer einzelnen Textur verknüpft (wie in der Java Version), sondern mit mehreren verschiedenen Texturen (Albedo, Normal Map, Height Map etc) sowie ein paar Metainformationen. Gleichzeitig liegen die Texturen nicht mehr als einzelne Bilder in den Spieldateien vor, sondern sind zu fertigen TextureArrays zusammengepackt.


    Wir brauchen also unbedingt einen eleganten Weg, dass der User eigene Texturen laden kann. Wir haben da einige Pläne zu, einschließlich serverseitiger Texture-Packs sowie die Möglichkeit, neue Texturen hinzuzufügen, aber dazu kann ich leider noch nicht viel sagen :silenced:


    Ich muss aber auch den Hinweis geben, dass die neue Version - anders als die Java Version - idealerweise PBR Texturen erwartet. Man kann zwar auch weiterhin klassische Texturen wie in der Java Version verwenden (zB ein Foto von einer Ziegelwand), aber diese werden dann ohne Zusatzmaps (zumindest Normal Maps) etwas "platt" aussehen. Sobald wir uns aber dem Feature "Texture Packs" nähern, werde ich dazu ein paar konkretere Infos geben können ;)


    wird die neue version schon für server geeignet sein ?

    Wie Yarofey schon sagt, leider wird es das Multiplayer-Update noch nicht geben. Das ist zwar in großen Teilen schon fertig, aber sowohl das Bau- als auch das Multiplayer-Update sind sehr umfangreich, sodass der Release von beidem gleichzeitig die Suche nach etwaigen Fehlern massiv erschweren würde :/ Das MP-Update wird nach dem Release des Bau-Updates aber definitiv nicht lange auf sich warten lassen

    Jap, das Update kommt definitiv im April, sonst hätte ich das nicht so geschrieben :)


    Tut mir allerdings Leid bzgl. der Urlaubsplanung lenko und reydelreyes:/


    Weiß man, ob für das Bau-Update eigentlich der komplette "Construction Elements"-Abschnitt auf Trello abgeschlossen wird, oder werden einige Punkte noch verschoben?

    Vermutlich wird der "Debris" Punkt (also passende Trümmer) etwas nach hinten geschoben, und auch einige Texturen werden noch fehlen. Da sämtliche Texturen von Grund auf neu sind, sind wir sehr auf Feedback gespannt und möchten lieber noch nachträglich sinnvolle Texturen hinzufügen, statt jetzt alle vorhandenen Plätze mit sinnlosen Texturen zuzuballern :D


    Also aktuell sind 50 Holztexturen schon ziemlich respektabel, würde mich also nicht wundern, wenn man erst später den Rest bekommt.

    Genau, derzeit sind 50 Holztexturen drin. Den Teil sehen wir soweit sogar als "abgeschlossen" an, aber wenn die Community zu dem Entschluss kommt, dass bestimmte Holzarten noch fehlen, können wir die noch nachträglich hinzufügen (technisch ist das auf jeden Fall noch möglich).

    Momentan arbeiten wir an Stein- und Ziegeltexturen. Mehr Texturen (Metall, Stoff, Glas, leuchtende Texturen, natürliche Materialien etc) sind vorbereitet, aber hier kann ich noch nicht genau sagen, was alles genau im Update sein wird.

    Und was die Welt Generierung an geht, da gibt es so ein mod für minecraft. Das heißt TerraForged, es generiert wirklich gutaussehende Landschaften. Und da frage ich mich ob es genau so sein wird mit rising world? ( Besonders schnee aufem berg darf nicht fehlen ;) )

    Hehe, naja, das Problem ist, dass genau solche Landschaften zwar in Minecraft gut aussehen, aber bei einem "smooth" Terrain überraschenderweise recht langweilig erscheinen :wat: Gerade so Stellen wie bei 0:20 oder 0:40 sehen bei MC zwar durch die Blöcke interessant aus, aber bei einem smoothen Terrain (in dem Fall also eine glatte Fläche) etwas merkwürdig...

    Aber Dinge wie Schnee auf hohen Bergen sind auf jeden Fall geplant :) Generell wird die Weltgenerierung deutlich interessanter als in der Java Version ausfallen.

    Die Sache mit den Blueprints ist so auf jeden Fall sinnvoll Arakara und lenko ^^:thumbup: Tatsächlich war damals der ursprüngliche Plan, dass beim Platzieren eines Blueprints im Survival zunächst eine Baustelle erscheint, zu welcher die nötigen Materialien nach und nach dazugeschafft werden müssen (mit Ausnahme von kleinen Bauplänen, für die man die nötigen Materialien ggf. direkt im Inventar hat). Fürs Erste werden wir das mit den Blueprints aber vmtl. noch so wie in der Java Version handhaben (damit das Feature so schnell wie möglich erscheinen kann) und es dann nachträglich Survival-tauglich machen :D


    und ansonsten wenn ich den sessel haben will muß halt dafür ein ganzen wald abholzen und da rein stopfen :D

    Dieser Sessel hat dann aber auf jeden Fall eine sehr negative Klimabilanz :crazy:

    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.