Posts by red51

On Linux, we get the VRAM amount directly from Unity, so if the amount there is wrong, it indicates that Unity receives wrong data from the OS... tbh, that sounds a bit like a driver issue Does the laptop maybe have a second, integrated graphics adapter?

However, if the game crashes, a log file would be very helpful to find out why it crashed You could either send us a report (which attaches the log files automatically), or upload the latest log file here in this topic (or send it via PM to me). If you want to send a report, just restart the game right after a crash (just to the main menu), then open the console and type "report". Alternatively you could just upload the latest log file here (right after a crash) - it can be found in the "Logs" folder in the "_New Version" subfolder in the game directory (there should be a file called "Player.log")

The "DELETE GROWING PLANT" output is basically fine, it indicates that a growing plant was deleted from the database. The provided ID is the unique ID of the plant that was deleted. This happens if the plant either reaches its final growth stage (i.e. once it's fully grown), or if it gets destroyed by a player.

However, as soon as there is a broken plant (which is stuck in a particular growth stage), maybe try this: Get the ID of the plant by typing plantinfo into console while looking at the plant, then check if the log file contains any information about this plant (or maybe even the "DELETE GROWING PLANT" output with that ID). Alternatively you could check the growing plants table directly if it still contains this ID.

We'll improve the "plantinfo" command with the next update btw, so it will provide more information about the growth stage etc, so if plant growth still causes issues then, this will probably provide more information about what went wrong

Quote from reydelreyes

N Schreibschutz auf due confi würde mir dazu noch einfallen 🙈

Aber das wird bestimmt nicht funktionieren😅

Naja, das Problem ist leider, dass dann auch andere Einstellungen nicht mehr gespeichert werden könnten

Quote from Deirdre

Die Spitzen gab es schon in der Java-Version

Die Spitzen sind in der Tat ärgerlich... der Grund dafür ist folgender: Das Terrain kann man sich so vorstellen, als würde es aus Blöcken besteht, die allerdings alle weichgezeichnet wurden. Dadurch haben wir keine Blockwelt, sondern glattes bzw. weiches Terrain. Eine Konsequenz davon ist aber leider, dass einzelne "Terrain-Blöcke" nicht mehr angezeigt werden können - das Spiel benötigt mindestens einen 2x2 großen Bereich an "Terrain-Blöcken", damit das Terrain auch dargestellt werden kann.

Wenn beim Löschen irgendwo also ein bisschen Terrain zurückbleibt, was aber nur 1 Terrain-Block breit ist, wird das nicht dargestellt. In LOD-Chunks allerdings werden diese hingegen berücksichtigt, sodass es zu diesen Spitzen kommt, die verschwinden, sobald man sich ihnen nähert. Im Grunde heißt das also, dass dort in Wirklichkeit eine 1x1 Block breite Spitze vorhanden ist.

Das ist etwas, was wir auf jeden Fall noch ändern wollen - das würde aber leider die Welt-Generierung und auch die Terrain-Bearbeitung verlangsamen (und besonders letzteres ist ja eh schon etwas langsam), daher muss da etwas mehr Arbeit reinfließen, um das einigermaßen performant umzusetzen...

Man kann die Spitzen aber loswerden, indem man mit dem Lösch-Werkzeug den Bereich um die Spitzen herum markiert, die Auswahl aber mindestens 2x so hoch wie die Spitzen ist (vll sogar noch etwas höher). Das ist im Grunde auch genau das, was Desmagu vorschlägt

Hier zwei Bilder, die die notwendige Größe des Bereichs veranschaulichen:

Der Grund, warum der Bereich so viel höher sein muss, ist der, dass LOD-Chunks nochmal zusätzlich weichgezeichnet werden. Dadurch sind die Spitzen nicht so hoch, wie die eigentlichen Terrain-Daten bzw. Blöcke an der Stelle sind.

Quote from Deirdre

Pflanzen hängen nach Löschen des Terrains in der Luft, es macht für mich keinen Sinn diese vorher erst zu entfernen bevor das Terrain bearbeitet wird.

Ich kann bestätigen, dass manche Pflanzen leider nicht automatisch entfernt werden, wenn der darunterliegende Boden großflächig entfernt wird... das ist etwas, was wir auf jeden Fall noch beheben müssen

Quote from Deirdre

Felsen müssen manuell entfernt werden, da das Tool diese nicht als Terrain erkennt.

Felsen gelten (auch wenns merkwürdig klingt) als Pflanzen (genauso auch zB Baumstämme). Das hat technische Gründe, auch wenn man es von der Logik her anders erwarten würde

Als "Terrain" betrachtet das Spiel wirklich nur den Boden, also die reine Landmasse. Die Felsen können also mit dem Pflanzen-Lösch-Werkzeug entfernt werden, wie Avanar vorschlägt

Unfortunately the Standalone cannot authenticate Steam users atm (because the Standalone has no access to the Steam API)... this is something we want to change in the future though. The Java version was suffering from the same limitation unfortunately...

However, the Steam version is able to authenticate Standalone users. The LAN option is hidden in the Steam version (because some users were confused by this in the past). To host a LAN game, your friend has to right-click on the green "Play with Friends" button, this brings up a small menu where he could select "Play via LAN" - then you should be able to join his game

Alternatively I could send you a Steam key if you want, so you could use the "Play with Friends" option directly (which hosts a P2P session using Steams relay servers)

Quote from Deirdre

Der Anfangs- bzw. Endpunkt des Löschrahmens ist einfach zu setzen, allerdings heißt das nicht, dass damit schon ein Bearbeitungsrahmen gesetzt ist. Das Vergrößern des

Rechteckes oder Quadrates dauert wieder Minuten, Spaß an dieser Tätigkeit kommt nicht auf, sondern nur Frust. Rahmen mit Bild auf/-ab und den Pfeiltasten ziehen

funktioniert, allerdings es dauert das Erreichen des Zeils sehr lang

Ich weiß leider nicht, wie das Bereichswerkzeug weiter vereinfacht werden könnte?

Quote from Deirdre

Der Bearbeitungsrahmen für die Abflachung des Terrains ist zu klein bzw. generell zu klein und es dauert genauso lang, denn

flaches Gelände gibt es selbst am Meer nicht.

Das Terrainwerkzeug ist momentan genauso groß wie in der Java Version... das weiter zu vergrößern ist leider mit viel Aufwand verbunden, da die Terrainbearbeitung dafür überarbeitet werden muss. Die ist momentan so wie in der Java Version implementiert - da Chunks aber größer sind als in der Java Version und da C# in Unity langsamer als Java ist, ist die Terrainbearbeitung insgesamt bereits langsamer. Würde der Bereich noch größer, wird es unerträglich langsam.

Unsere Intention ist es, diesen Teil direkt nach C++ auszulagern (so wie auch die Chunkgenerierung selber). Das würde die Sache deutlich beschleunigen, sodass wir auch einen größeren Bearbeitungsradius bieten können. Leider ist das ein recht aufwändiges Unterfangen, da die Terrainbearbeitung insgesamt recht komplex aufgebaut ist und daher viele Abhängigkeiten zu anderen Spielmechaniken hat (es also nicht so einfach ausgelagert werden kann).

Das hat daher momentan eine niedrige Priorität... vmtl. werden wir das erst in Angriff nehmen, wenn die wichtigsten Kernfeatures in der neuen Version implementiert sind

Quote from Deirdre

Ich bemitleide jeden Survivalspieler, dem nicht einmal die Tools zur Verfügung stehen.

Leider weiß ich für den Survivalpart aber auch keine Lösung, wie solche Tools wie im Creative-Modus sinnvoll integriert werden können. Große Baumaschinen sind da denkbar (und auch langfristig geplant), aber selbst diese werden nicht so einen großen Bearbeitungsradius bieten wie die jetzigen Creative Tools...

Ansonsten müsste man irgendwelche Fantasy-Geräte ins Spiel bringen, aber hier bin ich mir nicht sicher, ob und inwieweit sowas zu RW passt

Quote from Deirdre

Was bedeutet das im Einzelnen? Was bedeutet unnused (Single- /Multiplayer) differenziert?

Ist dieser Befehl eher für Multiplayer gedacht, wenn der Spieler nicht mehr auf dem Server spielt, um das ewige Suchen und manuelle Löschen mit dem Rcon-Tool zu vermeiden?

Normalerweise werden beim Entfernen eines Bildes aus der Spielwelt (also beim Kaputthauen eines Posters) die Bilddateien im Welt-Ordner nicht entfernt. Dadurch wird unnötiger Speicher belegt... das ist natürlich in erster Linie im Multiplayer ein Problem, da hier schnell viele tausend Bilder im Laufe der Zeit zusammen kommen.

Mit dem Befehl cleanupimages werden in der Java Version dadurch alle Bilddateien von der Festplatte gelöscht, von denen es keine Instanz mehr in der Spielwelt gibt.

Der Befehl funktioniert im SP und MP, ist aber tatsächlich eher für den MP gedacht

Quote from Deirdre

Wie funktioniert das? Ich habe ja schon mehrmals angesprochen, dass ich einen 90° Winkel standardmäßig beim Neubeginn des Spiels eingestellt haben möchte.

Der Saver Befehl ?, wie funktioniert der überhaupt?, scheint ein unknown command zu sein.

Der setr Befehl sollte ja bekannt sein. Mit saver hingegen kann der aktuell eingestellte Rotationswert (der mit setr eingestellt wurde) dauerhaft gespeichert werden, sodass er beim nächsten Spielstart automatisch aktiv ist. Intern wird das dann lediglich in der config.properties Datei gespeichert (unter "game_construction_rotation_precision")

Hmm... die neue Version ist eigentlich darauf ausgelegt, dass der zuletzt verwendete Wert gespeichert bleiben soll (anders als die Java Version, bei welcher das immer auf einen Standardwert zurückgesetzt wurde)

Da die neue Version auch - anders als die Java Version - diese Werte getrennt für Dinge wie Blaupausen, Bauelemente, Pflanzen etc. speichert, wären das mindestens 9 zusätzliche Einstellungen, wenn man das von Hand ändern können sollte...

Ich weiß nicht, wie vorteilhaft es tatsächlich wäre, wenn das Spiel den Wert immer zurücksetzt... wenn es noch mehr Resonanz dazu gibt, dass sowas erwünscht ist, könnte man das ggf. implementieren (die aktuelle Implementation müsste dafür umgeschrieben werden).

Ansonsten wäre aber vll die Plugin API eine Lösung dafür. Man könnte recht einfach ein Plugin erstellen, welches die Werte bei jedem Laden einer Welt wieder auf einen beliebigen Standardwert setzt. Das Nachteil wäre allerdings, dass dies nicht im Multiplayer funktioniert (es sei denn das Plugin wird auf dem Server installiert)

Quote from Deirdre

Wäre es spieltechnisch machbar, die Oberfläche einer gesetzten Blaupause zu bearbeiten? Das Spiel müsste dann natürlich die Form erkennen, bei der das möglich ist.

Ich wüsste leider nicht, wie das aussehen soll... denn die Blaupause enthält ja i.d.R. viele Bauteile, die so an sich gesehen auch keine einzelne Oberfläche besitzen... aber auch sonst können Blaupausen bzw. die einzelnen Elemente darin nicht "verzerrt" werden (das ist leider auch der Grund, warum Blaupausen nicht in alle Richtungen individuell skaliert werden können)

Quote from SteffiOneiro

A) Wenn ich eine Fläche auswähle und diese plaziere, plaziert sie sich nur manchmal aber nicht immer. Das finde ich seltsam. Einmal passiert etwas, beim nächsten Versuch passiert wieder gar nichts. Da dachte ich, ob das Tool F 5 überhaupt schon voll funktionsfähig ist?

Hmm... kann es sein, dass das bei sehr großen Bereichen passiert? Hier gibt es scheinbar tatsächlich einen Bug, dass der Bereich zwar auf 128 Blöcke begrenzt ist, mit dem Tool aber ein deutlich größerer Bereich markiert werden kann (dann aber trotzdem nur ein 128 Block großer Bereich gefüllt wird) Das müssen wir noch fixen.

Oder hast du das Problem auch bei kleineren Bereichen? Falls ja, könntest du sonst ggf. einen Report senden? Lasse dafür am besten die Bereichsauswahl aktiv und öffne dann die Konsole (Taste ^). Gibt dort "report" ein und füge ggf. noch weitere Infos hinzu (zB "Kann kein Terrain platzieren" o.ä)

Quote from SteffiOneiro

C) Was ich fälschlicherweise mit F5 Punkt 4 gebaut habe und nicht gut aussah, bekomme ich auch nicht wieder gelöscht. Wie lösche ich die selbe Fläche wieder? Der Befehl "Undo" in der Konsole hat in dem Fall auch immer nicht funktioniert. Irgendwie war ich gestern ziemlich ratlos.

Normalerweise kannst du den Bereich löschen (also das Terrain innerhalb des Bereichs), indem du die Taste ENTF drückst^^

Quote from SteffiOneiro

E) Wenn diese Karten ohnehin zufallsgeneriert erstellt werden, währe es toll wenn man zukünftig eine Prozentangabe bzgl. Berge und Wassermenge etc. auswählen könnte oder zumindest mehrere Karten zur Auswahl hätte. Vielleicht kommt das ja auch mit einem künftigen Update und ich greife hier mit meinem Unwissen über das geplante irgendwie vor? Meine Fragen und Probleme sind aus meinem Spiel entstanden, wo ich nicht richtig umsetzten konnte, was mir so vorschwebte. Ich hoffe, meine Fragen und meine Kritik wird hier konstruktiv verstanden.

Das ist zumindest geplant, also dass man Einfluss darauf nehmen kann, wieviele Berge vs. Flachland es gibt... leider kann ich bisher noch nicht sagen, wann das genau kommt. Vmtl. erst, nachdem alle wichtigen Kernfeatures in der neuen Version implementiert sind (sodass wir die Storepage updaten können)

Quote from Deirdre

Was mich stört, ist die fehlende Möglichkeit des Texturwechsels bei 4.

Das ist tatsächlich ungewollt, das wird sich mit dem nächsten Update ändern

Leider benötigt die Oberflächenbearbeitung relativ viele Zusatzdaten, deshalb kann nur dadurch nur eine Seite verändert werden (in dem Fall immer die Oberseite)...

Bei der Oberflächenbearbeitung werden direkt die oberen Eckpunkte verschoben - daher funktioniert das leider nicht bei der Kugel oder diversen anderen Bauelementen...

Es ist aber die Überlegung im Raum, das insofern abzuändern, dass quasi immer ein Würfel als Referenz genommen wird, und stattdessen alle nahgelegenen Punkte bzw. "Vertices" entsprechend zu verschieben. Dadurch könnte man dann auch die Kugel bearbeiten (die würde dadurch verzerrt werden). Das würde aber auch mehr Daten verursachen als der jetzige Ansatz, und wir müssten uns überlegen, wie wir sicherstellen, dass bisherige Bauten dadurch nicht beschädigt werden

Leider kann ich momentan noch nicht sagen, ob das funktioniert oder wann das kommen würde Wir müssen damit ein wenig herumexperimentieren (wahrscheinlich aber erst, sobald die neue Version die Java Version auf der Storepage ersetzt hat)^^

Quote from SonoBionda

Oder/auch eine vertikale Spiegelung zu ermöglichen?

Das ist grundsätzlich möglich: Mit dem Konsolenbefehl flip y kannst du den aktuellen Block entlang der Y-Achse spiegeln. Die zu bearbeitende Oberfläche wird dann auch gespiegelt (ich stelle gerade fest, dass es da zu Anzeigefehlern kommt - wir fixen das mit dem nächsten Update, kann aber auch durch aus- und wiedereinschalten der Oberflächenbearbeitung behoben werden)

Wir überlegen noch, wie wir das Spiegeln evtl. ins Radial-Menü unterbringen... vll dass beim Spiegeln ein Untermenü geöffnet wird, in welchem man auswählen kann, entlang welcher Achse gespiegelt werden soll

Quote from noci

Und dachte auch schon daran dort mich mal zu Probieren, und da karm die Frage auf ob sowas wie "eine Passende DLL" die dann auch Unity interners nutzen kann (Dabei dachte ich mehr an neue Figuren, Animationen und was mann da noch alles anstellen kann) besser/einfacher wehre

Achso, naja, leider wird das nicht so einfach funktionieren Rising World verwendet (anders als die meisten Unity-Spiele) kein "Mono" (bei welchem man die Assemblies bzw. DLLs des Spiels einfach verändern oder austauschen kann), sondern IL2CPP - damit wird der Spielcode beim Kompilieren in C++ umgewandelt. Das ist zwar bei weitem nicht so schnell wie der Teil des Spiels, der direkt in C++ implementiert ist, aber immernoch wesentlich schneller als Unitys veraltetes Mono (hier habe ich mal einen Vergleich gepostet)

Das bedeutet aber auch, dass der Spielcode nicht so einfach modifiziert werden kann... Das ist einerseits vorteilhaft, da Hacker & Co es schwerer haben, das Spiel zu ihren Gunsten zu ändern (richtige Hacker wird das natürlich nicht abhalten, aber zumindest die ganzen Script-Kiddies^^), andererseits kann das Spiel aber auch nicht mehr so einfach modifiziert werden.

Bei letzterem Punkt muss man aber dazu sagen, dass sich das natürlich nur auf codeseitige Änderungen bezieht. Assets und diverse Spieleigenschaften können trotzdem verändert werden, denn einerseits speichert das Spiel vieles in der "definitions.db" im Spielverzeichnis (zB alle Eigenschaften von Items, Npcs, Wetter, Rezepte usw), andererseits liegen alle Modelle und Texturen in "Asset Bundles" vor (die grundsätzlich modifiziert werden können). Wenn jemand also zB ein anderes Modell für eine Spitzhacke einbauen möchte, dann liegen diesem "klassischen" Modding-Ansatz keine Steine im Weg

Der goldene Weg ist aber natürlich die Plugin-API, da hierüber sichergestellt wird, dass zB im Multiplayer auch alles richtig synchronisiert wird

Quote from noci

das ist eine Gute Frage, Spontan würde ich sagen mit "Sprung Markern"
-wenn zu der Zwischenwellt geweckselt wird, muss der Ziel Punkt mit angegeben werden und Wo der Spieler war wirde hinterlegt (bei den neuen Dynamischen sachen, muss dan ebend das Plug in sich das merken)

Bei einer API-basierten Lösung wäre das auf jeden Fall sinnvoll, dass die Position in der Zwischenwelt natürlich entsprechend gesetzt und geändert werden kann.

Quote from noci

Das scheint mir schon die sinvollste Lösung zu sein, dann sind Server betreiber und Plugin Ersteller zusammen verantworlich für die Performance

Ich denke auch, dass diese Lösung wohl am wenigsten Probleme bereitet

Quote from noci

Da wehre vieleicht ein ServerVorgaben, für die Plugins gut, quasie das mann im Plugin schon Größenvorgaben berücksichtiegen kann
Und eine gesicherte Mindest Größe z.b. 512x512x512 (sollte doch jeder server schaffen)
Dann kann das Plugin auf ein Minimum abgestimmt werden und sich ggf. ausbreiten

Das kommt darauf an... wenn es wirklich nur eine leere Zwischenwelt gibt (also ohne Landschaft), in welcher der Betreiber oder Admin also alles selber erschaffen müsste, bräuchten wir vmtl. nicht unbedingt eine Größenbeschränkung... denn einerseits hat der Betreiber es dann ja selber in der Hand, wieviel er dort baut (oder es zulässt, was da gebaut wird), andererseits ist das auch von der Datenmenge meist eh nicht so viel. Oder anders gesagt: Bei Gebäuden ist es quasi eh egal, ob sie nun in der Hauptwelt oder Zwischenwelt liegen. Ungünstig ist nur das Terrain bzw. die Landschaft, da dies ja in dem Fall doppelt vorhanden wäre (was aber wegfällt, wenn die Zwischenwelt kein Terrain generiert).

Quote from noci

Wie kompliziert wehre es LOD (Umgebungshintergrund) umgebung mit in die Zwischenwelt zu nehmen, die wehre ja schon aus der Normalen Map da?

Naja, das Problem ist, dass das LOD ja die Hauptwelt repräsentiert, d.h. alle Änderungen in der Hauptwelt werden darin also sichtbar sein... andererseits aber eignen sich die LOD-Chunks aber auch nicht für den Nahbereich, d.h. hier bräuchten wir in jedem Fall also weiterhin normale Chunks

Alles klar, mit dem nächsten Update wird es dann den Befehl toggleterrain geben, mit welchem sich das Terrain inkl. Vegetation ein- und ausschalten kann (im MP gibts dafür dann eine gleichnamige Permission, die standardmäßig deaktiviert ist)

Quote from Avanar

Wie wäre es denn diese "Zwischenwelt" größenmäßig zu begrenzen und, wie die Testwelt, nur eben und ohne Vegetation, NPC, etc. zu erstellen? Zudem nicht für jeden Spieler eine einzelne, sondern der Admin müsste entscheiden ob es nur 1 je Server gibt (z.B. für Admins/Mods) oder ob bestimmte Spielergruppen ihre eigenen bekommen. Das dürfte doch die Performanceprobleme minimieren?

Grundsätzlich ist das möglich, und je weiter diese Welt begrenzt wird, desto kleiner auch der Einfluss auf die Performance. Die Frage ist nur, wo zieht man die Grenze bzgl. Welt-Größe? Und wie sieht sie aus, also was für ein Terrain wird dort generiert (ggf. Flachland)? Das wird vmtl. etwas sein, wo man es nicht jedem recht machen können wird... Person A braucht vll nur einen 100x100 Blöcke großen flachen Bereich, Person B benötigt zwingend eine ganze Insel, Person C hätte an der Stelle gerne einen riesigen Ozean während Person D gar keine Landschaft braucht, sondern eh nur Inneräume dorthin verlagern will...

Wenn die Zwischenwelt in ihrer Größe begrenzt ist, wirft das auch andere Fragen auf... denn gerade beim Wechsel zwischen normaler (in ihrere Größe nicht begrenzte) Welt und (größentechnisch begrenzte) Zwischenwelt stellt sich die Frage, wie die Koordinaten dann umgerechnet werden. Angenommen ein Spieler befindet sich irgendwo fernab vom Nullpunkt (zB bei 30k) und soll nun in die deutlich kleinere Zwischenwelt gebracht werden, um an dieser Stelle einen "geheimen Lagerraum" zu bauen - das würde bei einer begrenzten Zwischenwelt dann Schwierigkeiten mit sich bringen...

Vll wäre es da universeller, wenn die Zwischenwelt zwar nicht begrenzt, aber dafür standardmäßig "leer" ist, also kein Terrain vom Spiel aus beinhaltet, man dort also nur bauen kann Schwieriges Thema

Aber unabhängig von dieser "Designfrage" ist die Implementierung so eines Systems leider dennoch mit einigem Aufwand verbunden, da das Spiel das Konzept verschiedener Dimensionen bisher nicht kennt... es müssten dafür einige Teile umgeschrieben werden. Für Spielersyncro etc. ist das kein Problem, aber das Welt- bzw. Chunk-Management wird dadurch komplexer

Also eigentlich wird die Rotationsgenauigkeit dauerhaft gespeichert, sowohl beim Ändern über das Radial-Menü als auch beim Ändern über die Konsole (via setr) Auch nach einem Neustart des Spiels sollte der zuletzt eingestellte Wert aktiv bleiben (auch wenn er über setr geändert wird)

Wenn ihr sagt, dass das nach dem Beenden des Spiels nicht aktiv bleibt, bin ich etwas irritiert... ich konnte das Problem bei mir nämlich leider nicht reproduzieren (und es wäre wie gesagt auch ungewollt, wenn dem so ist)...

Dementsprechend wäre es ja auch doppelt gemoppelt, wenn man irgendwo einen Standardwert hinterlegen kann (weil das lediglich für neue Spieler relevant wäre, die das Spiel zum ersten Mal starten - hier ist aber eh unwahrscheinlich, dass diese die config anpassen, bevor sie RW das erste Mal gespielt haben).

Das Spiel speichert die Einstellung übrigens in der config.properties unter "Game_BuildingRotatePrecision", "Game_BuildingMovePrecision" und "Game_BuildingScalePrecision". Das sind die Werte, die über setr/setp/setl bzw. über das Radial-Menü auch geändert werden.

Wichtig ist aber noch der Hinweis, dass Bauelemente, Pflanzen und Blaupausen eigenständige Einstellungen haben. Wenn man also für Blöcke die Rotationsgenauigkeit ändert, dann gilt das nicht für Blaupausen und umgekehrt. Die Idee dahinter war, dass man bei Blöcken ja ggf. mit anderen Präzisionen arbeitet als bei Blaupausen... wir könnten das aber sonst auch ändern.

Ist das vielleicht der Grund für die Verwirrung? Ansonsten klingt das für mich nach einem Bug

Quote from SteffiOneiro

ist es möglich den Umfang des Geländewerkzeugs zu vergößern, um zb eine sehr große Fläche platt zu machen oder zu erheben?

Wie Avanar und Deirdre schon sagen, mit Numpad + und - kannst du das Raster verkleinern/vergrößern (leider momentan aber noch auf eine maximale Größe beschränkt). Um eine Fläche zu plätten bzw. zu ebnen, könntest du Enter drücken - damit wird quasi eine Art "Obergrenze" gebildet, bis zu welcher Höhe Terrain aufgeschüttet werden soll. Mit Bild-Auf und Bild-Ab kann diese Obergrenze nach oben oder unten verschoben werden. Am besten funktioniert das dann i.V.m. dem Werkzeug 1 (unter F5)

Die Oberflächenbearbeitung ist in der Tat etwas schwierig zu bedienen, daher würde ich das nur empfehlen, wenn man das unbedingt benötigt Ansonsten kannst du (wenn die Oberflächenbearbeitung nicht aktiv ist) den Block ganz normal mit Shift und den Pfeiltasten bzw. Bild-Auf und Bild-Ab skalieren, wie Avanar und SonoBionda auch erwähnen. Wenn du den Block proportional skalieren willst, kannst du auch Shift und +/- drücken

Zu B: Wenn du den Block mit der Oberflächenbearbeitung verändert hast, dann muss beim Zurücksetzen (Backspace sowie Shift+Backspace) ebenfalls die Oberflächenbearbeitung aktiv sein - sonst wird nur die normale Skalierung bzw. Drehung zurückgesetzt^^

Sorry für die späte Antwort! So einen Befehl können wir aber grundsätzlich einbauen

Soll das Terrain dabei komplett ausgeschaltet werden (also auch keine Kollision mehr etc)? Soll es nur das Terrain betreffen, oder auch Vegetation, Gras etc?

Quote from Kyo

red51 do you think it's faisible to have Crabs with this initial NPC update? Sorry for asking, but I really love the idea of sandy beaches with this little guys running all over to catch them

Crabs are actually on our to-do list Unfortuantely we still don't have a proper model ready for that, so I'm afraid they won't make it into the initial NPC update... but they're definitely planned

Quote from ArcticuKitsu

2) I wish we can have scaffolding. I severely need it while building and for my clearing projects. If possible, would it be too much to ask to have scaffolding in the upcoming update? I'm struggling to complete projects.

Maybe we can get the scaffoldings ready for the next update I can't guarantee that though, so if they don't make it into the npc update, they will be ready shortly after it^^

The ping is indeed to be expected, but the game shouldn't crash Do you still run into this issue? Maybe you could send us a report? If the game crashes again, please restart the game (to the main menu), then open the console (key ~ or `) and type "report" (maybe add some additional information like "game crashes when joining a server") and send the report The report automatically attaches the current and the previous log, so if you do that right after a crash, it may contain a few more information about it