So eine Haltefunktion für den Zoom können wir beim nächsten Update dazupacken 
Posts by red51
-
-
So ein Eckstück wäre auf jeden Fall hilfreich, ich packe das mit auf die Liste der anderen Formen, die noch so fehlen. Ins nächste Update schafft die Form es aber wohl nicht mehr rein
-
Der Blaupausen Undo-Befehl sollte unbedingt im Mp möglich sein, der Admin freut sich
Das stimmt schon, für Blaupausen wäre Zugriff auf den Undo-Befehl im Survival auf jeden Fall hilfreich
-
Was genau bedeutet "zum 2. Monitor gewechselt"? Heißt das, du hast den 1. Monitor deaktiviert und das Bild nur noch auf dem 2. angezeigt? Oder bist du mit Alt+Tab auf den Desktop gegangen bist und dort etwas auf dem 2. Monitor gemacht hast (und beide Monitore waren aktiv)?
Schwer zu sagen, was genau da los ist... das Wechseln des aktiven Monitors während des Spielbetriebs kann durchaus zu Problemen führen (auch außerhalb des Spiels sind da Fehlerquellen manchmal nicht ausgeschlossen, zB Windows oder der Grafikkartentreiber). Aber besonders Unitys HDRP ist in der Hinsicht auch etwas anfällig - hier würde ich tatsächlich in erster Linie den Fehler vermuten. Die UI bleibt weiterhin sichtbar, da diese separat gerendert wird. Ich fürchte, dass wir hier nicht viel machen können (da das Handling dafür nicht vom Spiel, sondern von der Engine vorgenommen wird, und anders als bei der Java Version haben wir darüber keine Kontrolle)...
Evtl. könntest du einen Report senden, wenn das nochmal auftritt (Konsole öffnen -> "report" eingeben), vielleicht enthält der Log einen Hinweis.
Das nächste Update wird aber in den Einstellungen die Möglichkeit bieten, explizit einen anderen Bildschirm auszuwählen. In Fällen, in welchen der Bildschirm beim Spielen geändert werden soll, kann das vll helfen.
-
Das hängt leider nicht mit der Weltgenerierung zusammen (bzw. das Weltgenerierungs-Update wird dort leider keine Besserung bringen): Das Spiel verwendet quasi die gleiche Methode wie die Java Version, um die LOD Chunks bzw. weit entfernten Chunks zu generieren (mit diversen Anpassungen, aber im Kern ist es noch dasselbe). Das zu verbessern würde die Performance und vor allem die Geschwindigkeit, mit der sich die Welt generiert, erheblich einschränken... und es würde auch ein nicht zu unterschätzender Aufwand dahinter stecken, das zu implementieren. Das wird sich also leider vorerst nicht ändern
Was aber ungewollt ist, sind diese Löcher, die dort entstanden sind. Es gibt momentan ein paar kleinere Fehler bei der LOD-Generierung, wodurch solche Phänomene zustandekommen. Das wird auf jeden Fall noch behoben.
Ansonsten gibt es noch folgende Möglichkeiten, die Situation zu verbessern: In der "config.properties" Datei kann Graphic_LODTerrainMesh auf 1 gesetzt werden, damit erhält der LOD-Bereich mehr Details.
Wenn das nicht ausreicht, dann bleibt als einzige Option, die "Detail-Sichtweite" zu erhöhen. In den Einstellungen ist dies zwar auf 10 Limitiert (entspricht 40 in der Java Version, also ca. das Doppelte des alten Maximalwerts dort), aber in der config kann auch ein höherer Wert gesetzt werden. Das kostet allerdings Performance und auch die Weltgenerierung wird spürbar verlangsamt
-
Diese Entscheidung ist okay aber was mich natürlich interessiert, was ist mit dem Rest vom MP Update zb rcontool, was natürlich die wenigsten interessiert. Die Permissions funktionieren noch nicht richtig, so daß es eine Admintration der Server schlecht möglich ist.
Das Problem bezieht sich grundsätzlich auch auf das RCON Tool
Hier vielleicht noch etwas extremer, weil noch weniger Leute Interesse daran haben (selbst unter den Serveradmins wird das Interesse vmtl. momentan überschaubar sein, weil im MP noch nicht wirklich was los ist).Ursprünglich wollten wir das RCON Tool als eigenes Update nachreichen, aber das trauen wir uns nicht mehr
Mit dem reinen MP Update wurde die Geduld mancher Spieler schon auf die Probe gestellt, und ein rein technisches Update (was für 99% der Spieler keinen ersichtlichen Mehrwert bringt) wird wahrscheinlich noch schlechter ankommen 
Wir werden das RCON Tool also vmtl. entweder mit irgendeinem Update vermischen, oder etwas später rausbringen, wenn der Bedarf dafür größer wird.
2) Y-Achse sollte abschaltbar sein
Wie genau meinst du das?
3) zum craftig sollte auch eine Axt ins Spiel finden
Eine Axt ist fürs nächste Update geplant
5) die Flaschen im Spiel bitte plazierbar machen.
Das Platzieren von Items allgemein müssen wir unbedingt noch zum Abschluss bringen... kann aber leider nicht sagen, wann genau das kommt...
Wie soll das eigentlich mit dem Eisenerz sein ohne Weltgeneration ? Und eine Weltgeneration ohne Blaupausen geht ja nun gar nicht.
Mit dem kommenden Update werden an der Oberfläche einzelne Erzadern spawnen. Wir dachten uns, dass das vll generell auch für später nicht schlecht wäre, wenn man Eisen und zumindest Kohle zusätzlich an der Oberfläche finden kann, sodass man nicht unbedingt in Höhlen absteigen oder Löcher buddeln muss, um seine ersten Werkzeuge bauen zu können. Fortgeschrittenere Erze werden hingegen nur unterirdisch spawnen.
red51 Mir persönlich dauert es mit den Blaupausen zu lange. Ich möchte bauen und nicht testen. Wenn ich z. B. ein Esszimmer bauen möchte, muss ich jeden Stuhl einzeln bauen.
Das ist verständlich... nach dem Crafting Update werden wir auf jeden Fall den Blaupausen widmen.
Die Leute schreien immer nach Survival. Das wird sich nie ändern
Das stimmt vermutlich, und zugegebenermaßen wird das "Crafting-Update" da nur bedingt was bringen... aber irgendwo müssen wir ja anfangen
Die Bau-Fraktion kann zumindest schon was bauen (auch wenns noch Einschränkungen gibt), die Survival-Leute hingegen können momentan rein gar nix machen Was aber will man mit einem Bau-Update auf dieser einen langweiligen Map?
Ich denke wir sind uns alle einig, dass das Welt-Update dringend benötigt wird
Ein paar Tiere wären danach auch nicht schlecht
Tiere wollen wir nach dem Welt-Update unbedingt reinbringen, die spielen definitiv eine Schlüsselrolle und sind sowohl für Bau-Leute als auch für Survival-Spieler relevant
-
Wir könnten so ein Feature evtl. zu einem späteren Zeitpunkt einbauen. Über die Plugin API (sobald sie denn verfügbar ist) wäre sowas auf jeden Fall auch umsetzbar. Ich würde das Feature aber lieber etwas nach hinten schieben, da in der neuen Version die Gefahr einer "RW Sucht" momentan vmtl. nicht so groß ist
LOL ja, ich glaube ich kenne das Spiel ... Bausimulation, begann mit A und ich war schnell ein Annoholic
Jedesmal, wenn der Hinweis kam, habe ich ganz ganz schnell ... ähm ... denSpielstand gesichert und dann weitergespielt Hehe, ich kenne das Problem bei diesem Spiel
Nach der Meldung dachte man sich "oh, schon so spät, jetzt noch schnell die Felder fertigmachen und kurz noch ein paar Häuser bauen", und nach gefühlten 10 Minuten kam der nächste Hinweis, dass wieder 2 Stunden vergangen sind 
-
Grundsätzlich ist der Vorschlag durchaus sinnvoll, aber leider gibts da ein Problem: Nämlich die Demo-Welt kompatibel halten. Wir haben ja gesagt, dass die Demo-Welt mit dem späteren, richtigen Welt-Update kompatibel sein wird (damit man jetzt ruhig schon bauen kann). Da die Weltgenerierung aber damals bei Erscheinen der Demo noch nicht fertig war, muss diese Welt für das Welt-Update einmal konvertiert werden - da steckt immer etwas Aufwand hinter (und leider auch die Gefahr, dass da etwas schiefläuft). Wenn wir aber zwischendurch noch eine zweite Welt anbieten, verkompliziert das die Sache ein wenig
Allerdings ist auch die Frage, ob eine zweite Demo Welt wirklich viel bringt, denn Wälder usw. fehlen ja leider weiterhin... ich glaube, wir würden uns lieber darauf konzentrieren, das Welt-Update selbst so schnell wie möglich an den Start zu bringen. Nach dem kommenden Crafting-Update wird es voraussichtlich noch ein Zwischenupdate geben (Blaupausen), danach folgt das Welt-Update.
-
red51 do you plan to add a realistic smelting and smithing system In the future? Me and a friend were thinking about making a mod, but would be nice to have it in regular gameplay
Can you elaborate on that? When it comes to smelting, this will work very much like in the Java version (i.e. the smelter will be one of the "interactive crafting stations"). When it comes to smithing, we have no specific plans about that unfortunately, but we appreciate any suggestions in this area
-
Kurz zum Verständnis: Ist hier ein separates Update gemeint oder das Blaupausen-Update? Ich hatte das jetzt so in Erinnerung, dass als nächstes Blaupausen kommen. Oder war damit eher gemeint, dass das nächste "größere" Update Blaupausen haben wird?
Als nächstes wird das Crafting-Update kommen, danach möchten wir Blaupausen einbauen. Vor dem MP Update waren wir uns in der Reihenfolge nicht ganz sicher und hätten evtl. auch erst Blaupausen bevorzugt, aber der Drang vieler User nach Survival-Features ist momentan recht groß und der Druck auf uns steigt - daher möchten wir unbedingt schauen, dass wir in dem Bereich etwas voran kommen (nach dem Crafting-Update kann man zwar sicher noch nicht von einem Survival-Game reden, aber es ist trotzdem ein essentieller Baustein dafür). Zumal das MP Update deutlich mehr negative Stimmen hervorgebracht hat als andere Updates (womit wir gerechnet haben, aber es hatte ja andere Gründe, warum wir den MP vorgeschoben haben), daher fürchte ich, dass ein Update rein aufs Bauen bezogen von manchen Teilen der Community negativ aufgefasst werden könnte
Vmtl. werden danach aber Blaupausen erscheinen. -
I mean that this can be only some sort of adaptation for the current RW generator (a kind of optimisation - if current generator uses heightmaps it can generate LOD faster), the LOD itself and volumetric generators (and caves) will require some sort of density function to generate LOD.
That does not work without degrading performance: Having a heightmap representation of the terrain available is not only helpful for LOD chunks, the game uses this information for other things as well (e.g. to decide which parts of the terrain will be affected by snow, or to handle ambient sounds properly etc).
If we want to keep it, but also have to generate additional data with higher resolution at the same time, this definitely has performance implications.
This is one of things sparse voxel octrees are created for - different LOD for chunks on different distance (and faster LOD generation for distant chunks). Voxels are stored hierarchically inside a tree, with 8 leafs per node, so for chunk with 32 blocks there will be 6 hierarchical levels, but these levels don't need a full grid of voxels.
This does not cover the actual problem: Octrees still have overhead we don't have to deal with at the moment. Irrespective of how much optimization will be put into their implementation, they will be slower than the current LOD implementation (unless we want to fundamentally change the way how the world and terrain is generated).
And when talking about memory, the terrain data isn't necessarily the main issue (only when it comes to serialization/deserialization or network traffic, but that's a different story), the main issue are the different meshes that need to be generated for this - and there is no way to save much memory on them. Currently the game only generates LOD chunks (both the data and their meshes) once and then never touches them again (unless the world at that location was modified). The game only has to distinguish between LOD chunks and regular chunks (although regular chunks are based on LOD chunks), so this handling is rather cheap (in terms of performance). If we want to implement dynamic LOD handling (i.e. only generate the different LOD levels when they're needed), this will be more complex and will definitely degrade performance compared to our current approach.
Blockscape appeared in 2012, and this method worked fine these days, it will not cost too much performance, and probably will be even faster that the current one
IIRC the old Blockscape version back then had some issues regarding performance (and there was probably a good reason why the dev switched to a different style the last years), however, I'm not sure if you can really compare Blockscape with RW. The game has a different style, and while the mountain looks great in Blockscape, the same mountain wouldn't look that great in RW.
You also have to keep in mind that terrain generation is only a small fraction of the things the game has to generate - so we can't spend too much of our frame budget on it. In Blockscape, for example, or in block based games like Minecraft, terrain and blocks are typically the same mesh. This approach doesn't work for RW, so plants and constructions still need to be generated separately (especially generating the latter can be quite time consuming).
At the end of the day, implementing a better algorithm for LOD chunks would only slightly improve the final visual result in most cases (on natural terrain, our LOD chunks typically fit quite well to regular chunks), but at the same time, this would result in a slower world generation (and probably a higher memory overhead).
As mentioned before, while there is certainly room for improvements, we can't spend any time on reworking the LOD chunk handling at this stage.
-
Brrrremse das Nachdenken
Wenn das nur temporär ist und die Spieler sich daran gewöhnt haben, kommt ein Riesenaufschrei, wenn das dann plötzlich wieder reduziert wird. 
Das ist tatsächlich ein guter Punkt! Wenn die Slotleiste erstmal erweitert ist, könnte es hinterher tatsächlich irritierend sein, wenn sie plötzlich wieder verkleinert wird
Vielleicht ist es wirklich sinnvoller, hier noch zu warten, bis es ein entsprechendes Tool gibt.Oder alternativ den Werkzeuggürtel direkt ganz hoch auf die Liste setzen und ins nächste update mit reinnehmen.
Fürs nächste Update schaffen wir es leider nicht mehr, aber vmtl. macht es Sinn, dass wir nicht mehr unendlich lange warten, bis es ein entsprechendes Item dafür gibt
Kannst du uns schon etwas über das nächste Update sagen
Ich hoffe, das wir das Update noch im Oktober fertig bekommen. Mit dem Update wird vor allem Crafting ins Spiel kommen sowie eine ganze Reihe neuer Items, und natürlich auch ein paar Sachen, die sich indirekt aus "Crafting" ergeben (zB Erze - zumindest erstmal Eisenerz - und entsprechend auch ein Schmelzofen etc).
Ich hoffe ja, das wir so schnell wie möglich zum API-Update kommen, damit ich schon mal mit meinen Plugins anfangen kann.
Ich würde die Plugin API gerne schneller voran bringen (zumal große Teile davon schon fertig sind), aber dadurch, dass große Teile der Community an der API eher weniger Interesse hat, und generell mittlerweile in der Community die Wünsche nach Survival-Features immer drängender werden, können wir da momentan leider nicht viel Zeit reinstecken
Ich verstehe aber gleichzeitig auch, dass es wirklich suboptimal ist, wenn die API unendlich lange auf sich warten lässt... wir müssen unbedingt zusehen, dass es zumindest in absehbarer Zeit eine vorläufige Version der API gibt (die vll noch nicht alle Features hat).
-
Im nächsten Update wird ein erster "undo" Befehl ins Spiel kommen
Damit können die letzten Schritte rückgängig gemacht werden (die Anzahl an Schritten kann eingestellt werden - auch im MP). Derzeit deckt der "undo" Befehl aber nur destruktive Aktionen ab, d.h. nur das Zerstören/Entfernen von Elementen (Bauteile, Pflanzen, Möbel) oder Änderungen am Terrain können damit rückgängig gemacht werden. Das Platzieren von Bauteilen kann damit also noch nicht rückgängig gemacht werden (was aber vmtl. auch nicht ganz so wichtig ist).Momentan ist auch vorgesehen, dass der Befehl nur im Creative-Mode funktioniert. Im Survival ist das ein wenig heikler, da es hier viele Wege gäbe, das Feature missbräuchlich zu verwenden (gerade im MP), wie Yarofey schon korrekterweise vermutet. Auch könnten damit Items dupliziert werden. Die Änderungen werden aber auch im Survival trotzdem getracked, d.h. wenn man versehentlich im Survival ein Bauteil kaputt gehauen hat, könnte man in den Creative-Mode wechseln und dort den "undo" Befehl durchführen.
Wir müssen mal ein wenig beobachten, wie gut der "undo" Befehl in freier Wildbahn funktionieren wird, vor allem im MP. Wenn alles reibungslos läuft, könnte man ihn später evtl. auch (mit Einschränkungen) für den Survival zugänglich machen, und zusätzlich auch eine Art UI anbieten
PS: Wenn mit F7 ein großer Bereich Elemente gelöscht wird, dann zählt das trotzdem als 1 Aktion, d.h. beim Undo wird entsprechend auch der gesamte Bereich zurückgesetzt
Ähnlich wird das dann später bei Blaupausen laufen, die die selbe Mechanik verwenden werden.Ich wäre mittlerweile sogar dafür einen Rückgängig-Befehl oder einen Wiederherstellbefehl für die Arbeiten mit dem Terraintool zu integrieren.
Es wäre wirklich recht praktisch, eine Möglichkeit zu haben, Chunks in ihren Ursprungszustand zu versetzen. Das ist zwar momentan *theoretisch* möglich indem man die jeweiligen Chunks aus der Welt-Datenbank löscht, aber das ist mehr als umständlich (und kann auch nicht zur Laufzeit gemacht werden)... wir haben ein entsprechendes Tool dafür mal auf unsere Todo-Liste gepackt
Auch 10 Schritte zurück würden schon ausreichen. Als Shortcut gerne Strg + Z wie in den meisten Programmen
STRG + Z wäre tatsächlich eine naheliegende Tastenkombi für den Undo-Befehl, aber das Problem ist womöglich, dass man diese beiden Tasten evtl. versehentlich drückt (zB wenn man sich duckt und mit Z heranzoomen möchte)... dadurch könnte ungewollt der Undo-Befehl durchgeführt werden (und da es noch keinen "Redo" gibt, kann das recht ärgerlich werden)
-
Zum einen ist mir was beim Edit-Texture-Befehl aufgefallen (also wenn ich einem bereits gesetztem Bauteil eine andere ID geben will) - Das Spiel führt den Befehl aus, gibt aber zusätzlich eine Fehlermeldung (rot geschriebene Bestätigung), dass der Befehl angeblich nicht unterstützt wird!
Oh, danke für den Hinweis! Das wird mit dem nächsten Update gefixed
Das andere ist etwas komplizierter, wo andere vielleicht auch mal mithelfen können - Ich denke, ich habe zufällig den Fehler gefunden, leider aber im Stress nicht dokumentiert und das Ergebnis ist mittlerweile nicht mehr vorhanden und nachstellen habe ich bisher auch noch nicht geschafft!
[...]
Danke für die Erläuterungen! Der "size" Befehl hat tatsächlich Probleme mit invertierten Objekten (also wenn die Größe einen negativen Wert enthält)
Weiteres Feedback in dem Bereich ist aber auf jeden Fall sehr hilfreich 
-
It is our intention to add some sort of "technical object" which will look like water
It will be treated as a separate object, however. Placing thousands of them in the same chunk will certainly degrade performance, but if you just use it for smaller things (e.g. to fill a bathtub), you won't run into performance issues. -
Same method can be used to generate high level of LOD, but instead of heightmap it will generate voxels of high octree levels (with filling all voxels below heightmap value)
Not exactly, if you want to benefit from having a more detailed LOD representation with caves and overhangs, LOD chunks need to rely on the same generator which is responsible for generating the regular 3D terrain data (instead of relying on the 2D generator, which just outputs a heightmap)...
As there are not a lot of voxels (probably the lowest voxel level can be a single voxel for a full chunk) it will be fast
If the resolution for LOD chunks is too low, it looks bad unfortunately. Currently it uses half the resolution of regular chunks (16x16 voxels horizontally instead of 32x32), which looks quite good (in terms of details). However, using lower resolutions (especially very low resolutions like 4x4, 2x2 or just 1 voxel per chunk) works on flat terrain, but looks bad on mountains or cliffs. Here is a comparison of LOD chunks with a low resolution (2x2) and LOD chunks with the current default resolution (16x16). The chunks close to the camera are regular chunks btw.
It would work for distant LOD chunks, but currently there is no way to have different LOD levels per chunk (handling that for so many chunks would increase memory overhead and degrade performance even further).
While the current approach is indeed very limited, it provides the best balance between quality and performance in most scenarios (there are a few bugs though which cause some visual issues right now - they will be fixed in the near future). But as mentioned, it fails at overhangs and cliffs (and also fails if a user wants to create a floating island, for example), so there is definitely room for improvements - but first we have to focus on other features (which are more urgent) before we can rework the LOD handling
-
Actually Dimensions is probably not the correct name for them, as they are technically not dimensions of space, but another worlds with same euclidean metric
. This feature can be really powerful, I hope that one day we will have it.Thinking about "dimensions" as "parallel universe" (or perhaps the concept of "dimensions" in Minecraft), that term does not look too wrong to me
But we will definitely keep that feature in mind
I have a small suggestion - it is possible to use voxel octrees to build distant LOD, octree will not increase data too much, but marching cubes will run faster on less data resulting with fast and volumetric LOD
Unfortunately that wouldn't really help
This would mean the client still needs to generate the full terrain data for LOD chunks (right now this is only done for regular chunks, while there is only a fast rough 2d representation generated for LOD chunks). And on max view distance, the game has to process up to 50k LOD chunks (and chunks are 4 times bigger compared to the Java version) - marching cubes would be considerably slower than our current LOD generator, so world generation would become too slow in that case...There are ways to speed that up though. While our current marching cubes algorithm (and also our LOD generator) is implemented in C++ (which is already many times faster than Unitys IL2CPP), it would be even faster if we use compute shaders for that. We will certainly give that a try in the long run, but right now there are unfortunately so many other pressing features on our to-do list
-
Der Fehler deutet darauf hin, dass bestimmte Spieldateien beschädigt sind. Falls du ein Texturenpack verwendest, kann der Fehler auch durch inkompatible Texturen zustande kommen. Ansonsten kannst du die Spieldateien reparieren, indem du via Rechtsklick auf RW in deiner Steam Bibliothek gehtst -> Eigenschaften -> Lokale Dateien -> und dort "Dateien auf Fehler überprüfen" auswählst. Steam sollte anschließend alle beschädigten Dateien erneut herunterladen.
Falls das Problem danach immernoch bestehen sollte, sag bitte Bescheid
-
gibt es eigentlich einen bestimmten Grund, warum der 'Gürtel' (Schnellauswahlslots) auf 5 begrenzt ist? Es wäre superschön, wenn es 10 Slots (1, 2 .. 9, 0) wie in den meisten anderen Spielen geben würde. Man muss beim Bauen extrem oft Materialen im Inventar hin & her schieben.
Die Intention war ursprünglich gewesen, dass die Slotleiste dann durch zusätzliche Ausrüstung (zB ein Werkzeuggürtel) oder bestimmte Kleidungsstücke erweitert werden kann
Ich hoffe, dass wir in absehbarer Zeit entsprechende Gegenstände ins Spiel bringen können... ansonsten könnten wir evtl. darüber nachdenken, die Slotleiste bis dahin auf 10 zu erweitern -
The first one - is it technically possible for new Unity version to support more than one world at runtime with ability for players to travel between them? Like, for example, 2 worlds with different structure and some sort of ability for players to travel between them? This is not for the vanilla game, mostly for the API, so someone can make a plugin with some sort of additional world/worlds, this can be used for many different aspects (custom RPG, player-only base worlds and others)
You mean a concept like different "dimensions" (so an arbitrary number of independent worlds can be loaded simultaneously)? This would be a nice feature and we have been thinking about adding that to the Java version back then, but unfortunately there would be quite some work involved to implement it - and considering this would be a feature that's only useful for the Plugin API (which unfortunately wasn't used by many people in the past), we put that feature on the back burner...
However, once the new version is more fleshed out and if there is some demand for such a feature (or at least if the game gets more active users), we will take such a feature into consideration again
Second question (mostly related to my older questions) - how far it will be possible to control generation with API? Will it be possible to define custom voxel data or heightmaps for the terrain, scatter custom objects/plants/materials over the world with more advanced way then in Java version (with game handing their storage in database per chunks, saving/loading them and multiplayer object management)?
It is definitely our intention to give more freedom to the API when it comes to the world generation. We're still not 100% certain about how the API will look like exactly, but probably you will be able to create a custom world generator class. It may then contain methods which provide terrain data (as 3D array), plant information (i.e. a list of all plants inside a chunk), object information etc. These methods are then called per chunk. Alternatively we may offer a way to register custom "world parts" (which provide these information for a larger area of the world).
We still appreciate any feedback in this area, but irrespective of how the API will look like exactly, you will basically have full control over the world generation
When it comes to custom objects, I can't say much about them yet unfortunately... but custom plants (or custom npcs, for example) will be useable by a custom world generator. Unfortunately we have no ETA for custom objects, plants or npcs yet...
Third question is about terrain, will it be always bounded to heightmaps for the distant LOD or it will be possible, for example, to use low-res meshes for it? Heightmaps can improve performance a lot, but they have many restrictions, probably it can be possible to switch lod type somehow? Like different graphics/world settings
Currently we have no plans to change the LOD chunk handling unfortunately
The current approach (heigthmaps for LOD chunks) is indeed very limited, but the main benefit is that the game can generate these chunks blazingly fast at the moment (compared to regular chunks which rely on marching cubes). Considering the much higher view distances compared to the Java version, it would be quite slow if the game has to generate more complex chunks instead of the rather basic LOD chunks... in addition to that, the game would have to store a lot more data per chunk: Currently LOD chunks indeed just hold the heightmap information, while regular chunks (i.e. within the "detail view distance") hold the full 3D terrain data. This only applies to chunks which have any data other than "air" though, but since the new version is capable of having tall mountains, this could still result in a lot more data (and RAM consumption accordingly)...Having that said, we're actually not 100% happy with the current LOD chunk generation. Maybe we will look for ways to improve it in the future, but right now we first want to focus on other parts of the game (which are urgently needed, like proper survival and exploration features)
