Posts by red51

A new update is now available, introducing "Points of interest" and many more changes!
Latest hotfix: 0.9 (2025-10-31)

    Ich habe den Beitrag mal in einen eigenen Thread verschoben, da das ja nicht direkt auf die UI bezogen war :D


    Was die Zwischenwelt angeht, es gab damals schonmal Überlegungen zu sowas wie verschiedenen "Dimensionen", sprich dass sich nur Spieler sehen, die sich in derselben Dimension befinden. Sowas ist allerdings etwas kompliziert umzusetzen, zumindest was die Welt selber angeht - denn grundsätzlich müsste für jede Dimension eine eigene Welt bereitgehalten werden, was auch insgesamt deutlich größere Anforderungen an den Server stellt (einerseits ein viel höherer RAM-Bedarf, andererseits aber auch mehr Last für den Server, wenn verschiedene Welten in verschiedenen Dimensionen synchronisiert werden müssen)...


    Denkbar wäre lediglich, dass jede andere Dimension keine Weltgenerierung hat, sondern immer komplett leer ist (und der Betreiber selbst dort Landschaften anlegen müsste). Dazu müsste man sich mal Gedanken machen :thinking:


    Ansonsten wird es aber zumindest eine Möglichkeit geben, einen Spieler auf einen anderen Server weiterzuleiten. Theoretisch könnte man so also die Sache mit den Zwischenwelten lösen. Leider wäre das aber nicht nahtlos, d.h. beim Transit zum anderen Server würde der Spieler einen Ladebildschirm haben usw...


    Erweiterte Frage:
    Eigene klein Welt generieren und Bearbeiten per API.
    Wehre soetwas überhaupt mit der geplanten API möglich oder ginge das nur/einfacher über eine Unity Schnitstelle

    Also die neue API wird auf jeden Fall die Möglichkeit bieten, die Weltgenerierung zu beeinflussen ^^ Man kann auf dem Wege also theoretisch ganz eigene Weltgeneratoren schreiben.


    Was genau meinst du mit "Unity Schnittstelle"?^^

    Do you have plans to turn more parts into C++ code or it will remain C#?

    This would be only beneficial for performance-critical things, and it only works for things which don't have much dependencies to other objects and classes ^^ Communication between C# and C++ is a bit tricky, because we can't access managed objects from C++ easily. And on the other hand, we can't turn everything into unmanaged pointers or structs on C#... in general, Unity isn't really made for C++ programming unfortunately, so you can't access the Unity API from C++ directly unless you write a wrapper for it - but this introduces other problems and limitations, and also adds another layer of complexity due to not being able to communicate with Unity directly :dizzy:


    It wouldn't really help if we move causal stuff (e.g. UI handling, inventory handling etc) to C++, for example (in fact that would do more harm than good)...


    But there are still a few performance-critical things which are still written in C# (e.g. chunk modifications). This is something we definitely want to port to C++, but this is a bit tricky (because it still requires access to managed data and also requires proper synchronization of managed [C#] threads), so unfortunately I have no ETA for that yet :/

    An early (incomplete) API release will be available with the next update :) The main focus of that release will be the UI, so some other things may not work fully yet^^


    Will it make possible to change, for example, inventory size of a player or his hotbar? Or this will only affect visuals and API for inventory interactions will be separated?

    Changing the style through the Internals class will only affect visuals ^^ The Style class is mostly based on Unitys IStyle interface, so you can change almost all properties which are listed in their docs.

    I've added a new example image above showing the inventory with a replaced background image (just used the wooden Java background image in this case) ;)


    However, you can't add new inventory slots that way. We may add a method to attach new UI elements to any existing game elements, so in theory, you could add new slots then, but they won't work at all (because the inventory code isn't aware of these additional slots)

    This sounds like DLSS will most likely improve the performance in your case :) About the weather issue, hard to tell if there is really an issue... if you run again into a situation where the weather seemingly has a considerable impact on performance, you could press F3 and check out the second to last line: If either the FMOD CPU has a value greater than ~ 30 or if the "Channels" (at the end of that line) are > 60 or the Virtual Channels are > 500, maybe send a report ^^

    The Java version will definitely remain playable ;) We may release a bugfix update in the future if there are still some people playing the Java version (although it's unclear whether or when this may happen), but there are no more content or feature updates planned unfortunately...


    About the language used by the new version (even though that's a bit OT :D ), large parts are indeed written in C#, but most performance-critical things (e.g. chunk generation) are implemented in plain C++. The game is also mostly working with native memory (i.e. raw pointers instead of arrays), which isn't managed by Unitys ancient garbage collector (therefore it causes less frame drops during garbage collection).

    When compiling the game, however, all C# code is turned into C++ via Unitys IL2CPP. It's by far not as efficient as plain C++, but still faster than C# - although that's not the fault of C# (I don't think that C# is considerably slower than Java), actually it's Unitys old Mono implementation that is so slow.

    Wie wird das Nahrungs-/Trinkbedürfnis genau aussehen? Können die Tiere verhungern wenn man vergisst sie regelmäßig zu füttern? Ich hoffe man wird trotzdem Reisen können ohne dass die Tiere wegsterben.

    Wenn das implementiert wird, dann wird das vmtl. recht großzügig ausfallen ^^ Sodass Tiere sehr lange ohne Nahrung auskommen, in dem Fall dann aber zB keine Eier, Milch etc. mehr geben und ggf. auch der Nachwuchs langsamer heranwächst.
    Es wird aber auch eine automatische Futtermöglichkeit geben (die man aber natürlich von Zeit zu Zeit neu befüllen muss) ;)

    Hi red51 , by this do you mean we could start testing out the UI on a test server even if the UI doesn't have any method calls to update? If so, I would certainly be interested in this.

    We could prepare a preview version of the API for the next update :) It wouldn't be a full API release, i.e. some things (like model loading, database handling etc) don't work, and some events are not wired yet - but the UI part is almost ready now (we still have to implement image loading, but that should be ready in time for the update). Basically you could even use it in production (although there is still a chance that the API may cause crashes, especially if you use non-UI related events and methods) ^^

    We've implemented the UI part of the new API, so we can finally share more information about it. Please let us know if you're interested in a preview version of the API (specifically for the UI).


    If you have any questions or feedback, don't hesitate to post here :)



    Workflow


    The new version internally uses Unitys new UI Toolkit (formerly known as "UI Elements"), which is inspired by CSS. This means the new API no longer maintains a UI based on absolute and relative coordinates, instead they will use a flex layout. You can update the Style of a UI element directly - it determines the visual appearance and position of the element and is mostly based on Unitys IStyle class. However, you can still work with absolute and relative coordinates if you like.


    The new API has two workflows, and both can be combined. The main workflow is the Style-based workflow, while all UIElements also offer some simplified helper methods (like setPosition(), setSize(), setPivot() etc). The latter resembles the old GUI workflow, but internally these methods just update the underlying style.


    When using absolute coordinates, the reference resolution is always FullHD (1920x1080). The positions will be identical on other 16:9 resolutions, so if you place an element at the center using absolute coordinates (X: 960 Y: 560), it will be also centered on 1280x720 or 3840x2160 (4K) (and other 16:9 resolutions). The size will also be identical on all screens, i.e. if the element has an absolute width and height of 128 pixels, the game will resize the element on other resolutions as well.


    The initial API release will provide at least a base UIElement class, a UILabel and a UITextField.


    UIElement is the base class for all UI elements (similar to the old GuiElement class). You can use it as a container or panel. You can also add a background image to them, so they automatically replace the old "GuiImage" class. In other words, the UIElement class is now a combination of the old GuiElement, GuiPanel and GuiImage classes. UILabel is very much like the old GuiLabel class, while UITextField is very much like the old GuiTextField class.


    Note: When using the simplified workflow methods, the origin of the screen (0, 0) will be in the top left corner (unlike the Java version, where the screen origin was in the lower left corner). When working with the style, however, that doesn't matter, because you set the top, left, right and bottom distance on the style directly.

    When using relative values (percent values), the game now uses values between 0-100 instead of 0-1. So if you were using 0.5 in the Java version, this now becomes 50.



    Style and HoverStyle


    In addition to the regular style, all UI elements also have an additional, optional hoverStyle field: It determines the style of the element when it gets hovered with the mouse cursor. This way you could change properties like the color, size etc (e.g. when hovering the element, the color may change to blue or the font size of of the label may become bigger to achieve a hover effect).

    The game handles this automatically under the hood, so when the mouse enters the element, it automatically sets the hoverStyle, and when the mouse leaves the element, it automatically sets the original style.


    The hoverStyle is only used if the element is marked as "clickable" (so the element reacts to the mouse and mouse input). This is done through the setClickable() method (similar to how it worked in the Java version). In addition to the "clickable" flag, there is also a "pickable" flag: It determines if an element should "block" mouse clicks (irrespective of the clickable flag). If "picakble" is set to false, the mouse cursor will ignore the element, so you could click on another element which is behind the panel. If set to true, the panel will block the mouse input, so you couldn't click on elements behind it.



    Childs and Parents


    The new UI also supports childs and parents, like the old GuiElements. You can attach a UIElement to any other UIElement (which then becomes the new parent). The style (position, size etc) of a child then depends on the parent style. Childs also inherit certain style properties (like the font size) - unless they explicitly set them on their style. Moving a parent moves all childs automatically.


    Unlike the Java version, you no longer have to call Player.addUIElement() for all childs - you only have to call it for the parent now, and the game handles all childs (and childs of childs) automatically.



    Modify Game UI


    The Internals class will provide a way to modify the Style of any game UI element. E.g. change the color of the health bar or the background color or image of any game menus. However, you have to use this with caution.



    Message boxes


    The new UI will also provide a simple way to show message boxes to the player. The Player class will provide various showMessageBox() methods for this, where you could provide a callback to get the user selection. There are also similar methods to bring up a color picker or an input dialog, for example.



    Examples


    This is a basic example which creates a black panel centered on the screen with a size of 500x300 pixels containing a centered label. It uses the simplified workflow, which resembles UI creation in the Java version:





    With the new UI, we have a lot more control over our UI elements. We could have round edges on our panels, for example, or rotate elements. The next example uses almost the same code as above, but modifies some style properties (to have rounded upper left corner on the panel and also to rotate the label by 90 degree):





    The next example uses the new flex layout: We want 10 panels to be evenly positioned around the center. We first create an invisible container (we call it "screen") which covers the whole screen. We set "pickable" to false, so it does not block our mouse clicks. We set absolute coordinates, and set top, left, right and bottom to 0 (in other words: the distance to the top, left, right and bottom will be 0 px, so the element covers the whole screen).


    We set the alignItems property to "Center" (because we want our child elements to be centered), justifyContent will be set to "SpaceAround" (so the elements will be evenly positioned in the panel) and flexDirection will be set to "Row" (so they're aligned vertically instead of horizontally).


    For the child elements, there is not much we have to change: We set the width and height to 128 pixels, set a random background color (using a util method) and add them as childs to the "screen" parent. That's it!





    Legacy GUI


    We're thinking about providing a plugin which brings back the old GuiElements from the Java version. They will be based on UIElements. This is mostly for reasons of compatibility (so if you have a big complex UI, you don't have to recreate it from scratch). Please let us know if this is important for you.

    Hey, DLSS (on NVIDIA cards) and FSR (mostly for AMD cards) will indeed improve the performance, but only if you're currently gpu-bound (which is likely on 4K). To get a rough idea of the performance improvement by these techniques, you could go to the graphics settings and change the "Resolution scale" slider to a lower value, e.g. 60% (the game will look ugly then, but this is probably roughly the fps gain you could expect from DLSS/FSR) ;)


    However, it's weird that the weather causes such an FPS drop in your case :wat: The weather effects (rain and snow) spawn quite a lot of particles, but the particles are calculated and handled on the GPU, which makes them very efficient. The wind, on the other hand, always has a fixed cost, i.e. it doesn't matter if it's good or bad weather, so I don't think that's causing this issue :thinking: Maybe it could be something else (maybe a sound issue, consuming too much CPU power etc)..

    Do you also experience the FPS drop if you create a new world, then change the weather by typing weather heavyrain 1 or weather heavysnow 1 or weather storm 1 into console?


    Maybe you could send us a report (so we can make sure there isn't something else causing this issue)? To do that, wait until you run into the frame rate issues, then open the console (key ~ or `) and type "report", maybe add some information like "bad weather = fps drop", then send the report :)

    I agree that minigames and interactive objects are always a great thing! It's definitely our intention to add the piano to the new version, actually we've already done some preparations for it, so it should be ready soon :)


    Back then for the Java version, it was also our intention to add some other games like chess, card games and smaller video games (similar to games like space invaders, pong etc). In multiplayer, you could even play these games with other people. We've done a few preparations for that, but unfortunately it never made it into the game... however, we still want to add that to the new version (but it has a lower priority at the moment) :D


    I very much like the metal detecting idea :thumbup: It's definitely on our to-do list. The whittling suggestion also sounds interesting, we just have to think about how this could be implemented. We also have to think about the whistle idea... it sounds interesting, but it could be a bit overwhelming for the player if he gets too many "whistle-options" :drunk:

    Die Beschreibungen greifen tatsächlich schon etwas vor und enthalten Sachen, die teilweise noch nicht möglich sind :saint: Die Tränke (oder auch andere Behälter wie das offene Fass) wird man dann mit Wasser füllen können, wenn Eimer ins Spiel kommen :)


    Das wird aber leider noch nicht mit dem NPC Update passieren... Tiere haben auch noch kein Nahrungs-/Trinkbedürfnis - sowas ist zwar in Zukunft geplant, aber momentan leider noch nicht in greifbarer Nähe^^

    Es ist auf jeden Fall noch auf unserer Todo-Liste, dass der Radius der Lichtquellen beim Skalieren des Lichtes angepasst wird :)


    red51 Bitte die Lichtintensität für Laternen, Straßenlampen, Wandlaternen etc. ebenfalls anpassbar machen

    Die einzige Lichtquelle in dieser Auflistung, in der die Lichtstärke nicht einstellbar ist, ist die Laterne... für die könnte man das theoretisch umsetzen, wäre ja nicht ganz unrealistisch :thinking: Bei anderen Lichtquellen wie Fackeln oder Kerzen würde ich das aber eigentlich nur ungerne einbauen :monocle:


    Desweiteren wird die dezimierte Helligkeit bei den Lichtblöcken, ID 800, beim Anmalen wieder auf 100% gesetzt. Die Steine sollen nur farblich geändert werden und keine Helligkeitsänderung vorgenommen werden.

    Das wird mit dem nächsten Update behoben ;)

    Das kommende NPC-Update wird sich natürlich in erster Linie auf NPCs bzw. Tiere konzentrieren, da das momentan noch eines der am dringendsten benötigten Features ist. Wie aber bei fast jedem Update wird es auch ein paar andere Neuerungen und neue Items oder Objekte geben, und natürlich auch Bugfixes und diverse andere Änderungen ;)


    Unsere Hauptpriorität ist insgesamt, den Zustand zu erreichen, dass das Spiel die Java Version auf der Storepage ersetzen kann. Tiere sind dafür zB unabdingbar, während aber neue Texturen dafür nicht zwingend erforderlich sind (daher rutscht sowas in der Priorität leider automatisch etwas nach hinten). Zwar kann man generell sagen, dass "mehr Content" immer gut ist, nur leider werden zB "mehr Texturen" von vielen Spielern nicht automatisch als "mehr Content" angesehen, Tiere aber hingegen durchaus häufiger als "Content" angesehen wird - wobei das sowieso immer im Auge des Betrachters liegt, denn es gibt auch einige Leute, die der Meinung sind, die Java Version hätte Null Content (obwohl es ganz objektiv betrachtet relativ viele Texturen, Objekte, Items, NPCs und auch Features gab)...


    Nach dem NPC Update werden wir uns aber höchstwahrscheinlich an Poster und Schilder setzen (was vor allem auch im Bau-Bereich Relevanz haben dürfte), und evtl. können wir in dem Zusammenhang auch die neuen Blockformen sowie Türen reinbringen, die wir zwischenzeitlich vorbereitet haben :)

    2. Auf image-2 möchte ich ein Kantholz auf zwei Rundhölzer legen. Diese haben eine unterschiedliche Höhe und stehen etwas versetzt zueinander. Hier fände ich es toll, wenn man zwei Andockpunkte an den bereits platzierten Objekten wählen könnte und das zu platzierende Objekt relativ dieser Punkte ausgerichtet wird. Momentan behelfe ich mir so, dass ich erst das Kantholz an der Decke platziere und anschließend die Rundhölzer daran andocke.

    Ich habe leider nicht ganz verstanden, wie du das genau meinst :saint: Ist das etwas, was sich denn grundsätzlich mit dem manuellen Pivot-Modus beheben lässt?


    3. Auf image-3 sieht man, dass die Rundhölzer in der Luft hängen. Bei dem linken Rundholz kann man sich bücken und noch ein weiteres Rundholz darunter platzieren. Bei dem anderen muss man das Rundholz um 180° drehen. Auch bei Arbeiten über Kopf an Höhlendecken oder in Gebäuden hat man immer wieder Punkte, die nicht erreichbar sind. Vielleicht könnte man auch die nicht sichtbaren Andockpunkt anzeigen? Also quasi durch das bereits platzierte Objekt hindurch greifen.

    Schwierig... das Problem ist leider, dass wenn Pivots auch "durch Wände hindurch" anwählbar sind, dass dies schnell irritierend wird bei komplexeren Bauwerken (also wenn viele Bauteile verbaut sind). Wir hatten das schonmal getestet, da stehen dann plötzlich so viele Pivots zur Verfügung, dass es mehr schadet als hilft ^^ Bei wenigen Bauteilen oder in konkreten Fällen mag das aber hilfreich sein... wir müssen mal überlegen, ob man das evtl. als ein-/ausschaltbare Option anbieten kann, oder ob Pivots durch Wände hindurch ggf. nur in definierten Fällen anwählbar sein sollen (zB dass nur Terrain ignoriert wird - das würde in deinem Fall ja zB helfen) ;)


    6. Das Schema hinter Rotieren und Bewegen habe ich auch noch nicht ganz verstanden. Es kommt vor (könnte mit der Blickrichtung zusammen hängen), dass sowohl die Cursor- als auch die Bild-Tasten um die X- oder Y-Achse rotieren und eine Rotation um die Z-Achse nicht möglich ist. Gleiches gilt für das Bewegen/Sakalieren eines zu platzierenden Objekts. Es kommt vor, dass man das Objekt nur in zwei Richtungen bewegen kann und die Bild-Tasten das Objekt horizontal verschieben/skalieren (anstatt wie erwartet vertikal).

    Ja, das Skalieren und auch das Verschieben hängt tatsächlich mit der Blickrichtung zusammen... ich weiß nicht, ob das sinnvoll ist oder nicht, da das manchmal tatsächlich irritierend sein kann. Vll ist das auch etwas, was wir wieder entfernen :saint:


    5. Wenn man "manuelles Platzieren" aktiviert, scheint es nicht möglich zu sein, ein Objekt zu rotieren.

    Das stört mich auch wirklich sehr; es ergibt überhaupt keinen Sinn warum das nicht möglich ist, zumal man zum Skalieren auch bei festgesetzten Objekten trotzdem noch die Shift Taste benutzen muss.

    Also, warum nicht ohne Shift festgesetzte Objekte routieren ? edit: hm, ja, wahrscheinlich weil es ums Platzieren und nicht ums Drehen geht ... aber selbst wenn ich eine Taste für "Drehen/halten" vergebe, funktioniert die Kombi auch nicht zum Drehen.

    Das funktioniert aber eigentlich, ging sogar auch in der Java Version :) Ist leider nicht sehr intuitiv: Wenn das manuelle Platzieren aktiv ist und man dann STRG gedrückt hält, kann man das Bauteil mit den Pfeiltasten drehen :D


    Die Tastenbelegung für "Drehen" in den Einstellungen ist leider momentan nicht verdrahtet... das war ursprünglich in erster Linie für Gamepads gedacht und hat dort in den Optionen eigentlich nichts zu suchen... vll macht es aber Sinn, die trotzdem dort zu lassen, sodass man eine zweite Taste fürs Drehen belegen kann :thinking:


    Aber ich habe auch so langsam den Verdacht, dass das Ändern einzelner Keys alles durcheinander bringt.

    Normalerweise sollte das eigentlich kein Problem darstellen. Heikel wird es nur, wenn mehrere Funktionen auf dieselbe Taste gelegt werden - das Spiel warnt in dem Fall leider (noch) nicht. Das wird sich aber noch ändern ^^


    Aber verstehen kann ich das dennoch nicht; wenn mir der automatisch ausgesuchte Pivot nicht gefällt, könnte er doch trotzdem mit Punkt/Komma weiter springen :?: :!:

    Das müssten wir mal ausprobieren, also wie gut sowas in der Praxis funktioniert. Es könnte manchmal irritierend sein, vor allem wenn man versehentlich vorher einen anderen Pivot gewählt hat. So wie auch das manuelle Platzieren irritierend sein kann... einige Spieler haben das Andocken bisher als komplett unbrauchbar empfunden, weil sie versehentlich den manuellen Andockmodus aktiviert haben und dann der Auffassung waren, dass das Bauteil immer nur mit einem festen Punkt irgendwo andockt (was - ohne den Pivot zu ändern - tatsächlich oft nutzlos ist) :silenced:

    Wäre es dann nicht sinnvoll, Baumstammstücke als "4xBaumstammstücke" im Inventar zu stapeln, anstatt "2xBaumstammstücke (Hickory)" und "2xBaumstammstücke (hastenichjesehen)"?

    Wir könnten grundsätzlich alle Baustammstücke zu einem einzelnen, generischen Baummstammtyp zusammenfügen ^^ Das Problem ist nur, dass die einzelnen Baumstammtypen optisch ja unterschiedlich aussehen (der Birkenstamm sieht ja zB ganz anders aus als der vom Hickory-Baum). Wenn Bäume also nun einen einzelnen, generischen Baumstammtyp droppen, sähe das beim Kleinhauen des Baumstammes etwas komisch aus (wenn zB aus dem Birkenstamm plötzlich normale Holzstücke mit anderer Rinde herauskommen). Es gibt zwar viele Spiele, die das so machen (wo die Holzstücke optisch nicht zum Baumstamm passen), aber ich weiß leider nicht, ob das wirklich so optimal ist :thinking:


    Es stand auch schonmal die Überlegung im Raum, die Baumstammstücke zu entfernen, sodass Bäume direkt "Holz" droppen (welches gar nicht erst weiterverarbeitet werden muss). Diese Art der Simplifizierung gibts ja auch in anderen Spielen. Wir hatten uns letztenendes aber dann dagegen entschieden, um das Spiel nicht zu sehr aufzuweichen ^^

    Sorry für meine späte Antwort! :hushed: Grundsätzlich können Blaupausen aber an Pivots andocken, nur ab einer bestimmten Größe verhindert das Spiel das (weil das meist nicht gut funktioniert). Man kann es aber für alle Blaupausen erzwingen, indem man in der config.properties Datei im Spielverzeichnis (im "_New Version" Unterordner) den Eintrag Game_BlueprintsAlwaysAllowPivots=True hinzufügt ;)


    Es scheint aber so, dass die Pivots für manche Blaupausen teilweise generell nicht gut funktionieren... das müssen wir uns nochmal genauer anschauen :monocle:

    The "ConnectToOtherServer()" method is on our to-do list, probably it will be available for the first API release :)


    About the db-locked errors, the Java version SQLite connector was unfortunately using single-threaded mode, so if more than one thread accessed the database concurrently, there was a chance that this could end up in a db-locked error. The new version, on the other hand, runs SQLite in serialized mode, so it's fully thread safe^^

    However, this error could also happen if a Statement / PreparedStatement or ResultSet was not closed after using it, for example (unless they were used in a try-with-resources-block, which closes them automatically). But this would also cause trouble in MySQL.


    If you run into any db-locked errors or any other db-related issues in general (in SQLite or MySQL) with the new version, please let me know ;)

    The API unfortunately has no built-in methods for that, but there are various ways to sync data between two servers. If both servers are running on the same machine, you could create an SQLite database to read and write the data from both servers (this could be done whenever the player connects and disconnects). In WAL-mode, it should be possible to have two connections which can read and write concurrently.

    Alternatively you could create a read-only connection to the world database (where the inventories are stored) and retrieve the inventory data from it (i.e. the quest server could read the inventory data from the main server when the player connects, and if you want to sync the inventory back, the main server could read the inventory from the quest server when the player connects there accordingly).


    If the servers are running on different machines, you could use a MySQL server instead. Alternatively you could set up a webserver through Java: Java has a built-in HttpServer, and the API has methods to send http requests.


    Sending a player to another server, however, isn't possible yet... But we could add a "ConnectToOtherServer()" method for the player ;) It would first show a message box to the player where he has to confirm the server change, then he'll be disconnected from the server and reconnected to the other server.

    Unter Wasser ist es schwierig das Terrain zu bearbeiten, da die Sicht immer schlechter wird, je tiefer getaucht wird. Desweiteren ist ein Vorwärtskommen fast unmöglich, da

    das Wasser das Bewegen sehr schwierig macht. Das mag im Survival und beim Tauchen absolut in Ordnung sein, aber spezifisch beim Creativmode bzw.

    für die Terrainbearbeitung bitte Alternative hinzufügen.

    Du kannst dich im Flugmodus mit normaler Geschwindigkeit unter Wasser fortbewegen ;) Was die Sicht angeht, wenn es zu dunkel wird, kannst du evtl. das Licht im Creative-Modus (L) aktivieren. Ansonsten fällt mir da leider momentan auch keine bessere Lösung für ein...


    Das Aufziehen von Markierungsrahmen für Terrainbearbeitung und zum Löschen von großen Baugebieten dauert sehr lange. Eine andere Geschwindigkeit einzustellen,

    bringt nichts, da das Werkzeug dafür nicht ausgelegt ist. Ein zusätzliches Feature wäre wünschenswert.

    Wie meinst du das genau?