Posts by red51

Quote from Bogus

Wann haste denn das Welt Update denn geplant ? ;D

Naja, verlässliche Zeitangaben sind leider immer schwierig zu geben... den 1. Teil des Welt-Updates wollten wir gerne schon letzten Monat fertig haben, aber das hat offensichtlich nicht ganz funktioniert... der 1. Teil wird aber jetzt sehr zeitnahe kommen, definitiv zu 100% diesen Monat (und nicht erst am 30.)

Dieses erste Update enthält aber sowieso nur Vorbereitungen für das eigentliche Welt-Update, d.h. mit diesem Update wird man leider weiterhin an die Demo-Insel gebunden sein Es wird aber eine exorbitant große Menge an neuen Pflanzen & Bäumen geben, neue Items und diverse andere Dinge.

Die eigentliche neue Welt-Generierung inkl. Wasser wird dann mit dem 2. Teil des Updates kommen. An den Features haben wir die letzten Monate schon teilweise gearbeitet (zB dem Wasser), das ist auch der Grund, warum der 1. Teil des Updates noch nicht draußen ist.

Beim 2. Teil fällt es mir besonders schwer, eine verlässliche Zeitangabe zu geben (weil auch das Update extrem umfangreich wird). Das sollte aber idealerweise auch nicht in unendlich weiter Ferne kommen.

Zweifelsohne ist das Welt-Update das mit Abstand umfangreichste Update. Auch künftige Updates wie NPCs, Fahrzeuge etc. sind nicht so arbeitsintensiv

Quote from Deirdre

Wann ist überhaupt das nächste Update geplant? Und wird es dann auch wieder Sandstein ohne Konsole geben?

Wie gesagt, das nächste Update wird jetzt sehr zeitnahe erscheinen. Das Problem mit dem Sandstein wird dann behoben sein

This sounds like a native issue Maybe have a look if there is a log file available called "Player.log" in ~/Library/Application Support/com.JIW-Games.RisingWorld/ or alternatively in ~/Library/Logs/JIW-Games/Rising World/. If there is such a file, please upload it here

Quote from MommaT

But for the life of me I cannot figure out how to make a beam. Every which way I try I can't seem to reliably get the thing to be long and skinny. I've rotated the object it several ways and then try to get the X side to change length but it only changes the Y and Z sides no matter which way it is rotated. I was able to do it once, but every time is an adventure.

Basically shift + arrow keys change the width and depth of the element (horizontally), while shift + page up/down changes the height (or more precisely, the alternative keys you're using instead of page up/down). So to get a long beam, you could basically use shift + arrow down and shift + arrow left to make the element thinner (width and depth), and shift + page up to make it higher.

Having said that, alternatively the game also offers a "legacy" mode to get the same resize behaviour like in the Java version (i.e. arrow left or right to change the width and depth simultaneously, and arrow key up/down to change the height)

To enable it, go to the game settings -> Misc -> Building -> change "Resize Mode" to "Legacy". This makes it a lot easier if you want a replacement for the Java beams (although it's taking away some freedom, since you can't resize all 3 axes individually anymore).

Quote from MommaT

What else would be helpful is: when you are holding the shift key and using the arrows to change size, if the sides of the object were labeled on screen so you could see which side is which letter.

This is a great idea, I will put that on our to-do list

Zahlen und Buchstaben sind auf jeden Fall geplant Aus Performance-Sicht wären die natürlich deutlich vorteilhafter als selbstgebaute Buchstaben Die werden vmtl. nach dem Welt-Update kommen.

Momentan gibt es tatsächlich einen Bug, dass Blaupausen, die einen relativ langen Datei-Pfad haben, dafür sorgen, dass das Inventar nicht richtig deserialisiert werden kann - und wenn das Spiel da einen Fehler entdeckt, wird das Inventar sicherheitshalber gelöscht.

Zumindest dieses Problem wird mit dem nächsten Update behoben

Ansonsten wird das Spiel mit dem nächsten Update aber auch mehr Infos ausgeben (im Log), wenn das Inventar fehlerhaft sein sollte. Wenn das Problem also nach dem Update weiterhin auftritt, bitte nochmal einen Log hochladen (oder einen Report senden), dann sollten wir das eigentlich zeitnahe beheben können

Es kommt ein wenig darauf an, wie du den Server genau installieren möchtest Grundsätzlich enthält dieser Thread alle nötigen Informationen dazu (allerdings leider nur auf Englisch): Dedicated Server Setup [New Version]

Wenn du es über den normalen Steam Client machen möchtest, findest du den Dedicated Server unter Tools bzw. Werkzeuge. Dort kannst du via Rechtsklick in die Eigenschaften gehen und unter "Betas" entsprechend "unity - New Version Preview" auswählen (ähnlich wie beim Spiel). Wichtig ist aber, dass der Java Server - falls er vorher installiert war - erst deinstalliert werden bzw. in ein anderes Verzeichnis verschoben werden muss, da die Dateien der neuen Version sonst mit den alten Dateien kollidieren.

Falls du den Server stattdessen über SteamCMD installieren möchtest, ist es wichtig, den "unity" Branch herunterzuladen. Das geht mit dem Command app_update 339010 -beta unity.

Falls du allerdings deinen Server bei einem Gamehoster hast, dann kommt es darauf an, bei welchem. Manche Hoster bieten die neue Version auf jeden Fall an (zB GTXGaming), andere leider nicht.

We can add a "printkeybindings" command with the next update, which will create a text file containing all current key bindings

About the Mac keyboard, well, probably the page up / down keys are the only missing keys which are really important (if the keyboard has at least arrow keys). So it should be sufficient to just remap these two keys (e.g. bind them to * and #, for example)

Or is there another important key that's missing?

Hmm... what sort of red screen do you get exactly? Do you get an error message? Does it work if you try to run the game from the folder (i.e. not from Steam)?

We've tested the new version on our Mac (mini) and it worked, but of course there is a chance that it doesn't work on other OS versions or hardware configurations... if the game doesn't even start (i.e. no game window, error message etc), it's likely an engine bug - unfortunately this type of error is out of our control in most cases... Unitys support for Mac and Linux is horrible (although it's even worse for Linux), which is a pity

Quote from Deirdre

Ich bin zwar nicht Yaromid, aber eine Palme würde im Update eigentlich schon reichen. Damit könnte man schon viel anfangen.

Eine Palme wird tatsächlich im nächsten Update drin sein

Quote from Yaromid

Ich dachte als Erstes so an Birkenwälder, aber die sind bestimmt schon geplant

Ehrlich gesagt haben wir an Birkenwälder gar nicht gedacht, aber das ist eine gute Idee, ich packe das mal auf die Liste

Quote from Yaromid

Was ich mir tatsächlich sehr wünsche, wären Bambuswälder, die wären perfekt für ostasiatische Umgebungen und in Zukunft vielleicht ein sinnvoller Anhaltspunkt, um auch so was wie Pandabären zu spawnen? Jedenfalls wären Bambuswälder Performance-technisch vermutlich auch in "dichter Form" gut dran, da Bambus im Grunde nur wie ein langes Rohr ist (mit ein paar kleinen Ästen hier und da), also hat viel weniger Polygone als ein Baum

Bambus haben wir sogar auch vorbereitet, weiß aber nicht, ob der noch rechtzeitig fürs Update fertig wird... Bambuswälder wird es mit dem Welt-Update aber leider noch nicht geben...
Ein Pandabär wäre zwar auch ziemlich passend, aber leider fehlt uns zu sowas ein passendes Modell bzw. Animationen... aber vll kann das ja später reinkommen.

Was die Performance angeht, ein "Bambus-Baum" hat in der Tat deutlich weniger Polygone als ein normaler Baum. Unterm Strich wird die Performance in Bambus-Wäldern aber vmtl. nicht besser sein als in normalen Wäldern, da der Bambus eben recht dicht aneinander spawnen muss, damit es einigermaßen aussieht^^

Aber deine Vermutung stimmt demnach schon, nämlich dass man aufgrund der geringeren Polygonzahl mehr Bambus spawnen kann

Quote from Yaromid

Ansonsten würde ich mir auch gerne ein paar "tote" Bäume wünschen, halt Friedhofs-Ästhetik usw. die müssen aber nicht unbedingt in Wäldern auftauchen

Da ist das nächste Update genau richtig, denn da werden allerlei tote Bäume drin sein

Quote from Deirdre

Beim Aufstellen eines Bettes steht standardmäßig Größe 1 x 1 x 1. (Bett ca. 2.5 lg und 1.25 br.).

Beim Skalieren des Bettes stimmt die Größenangabe aber noch weniger.

Naja, bei Objekten (also Möbelstücken wie das Bett) ist es so, dass die Größenangabe relativ ist, also relativ zur Originalgröße. In dem Fall heißt 1 x 1 x 1, dass das Bett seine Standardgröße hat, bei 2 x 0.5 x 2 ist es zB doppelt so lang / breit und nur halb so hoch usw.

Wir müssen mal gucken, ob wir evtl. auch eine optionale absolute Anzeige anbieten können

Quote from Deirdre

Ich habe Probleme mit Java-Blaupausen in denen die ID 15 (36 im Spiel direkt) durch meine Textur ersetzt wurde. Diese Textur wurde überhaupt nicht übernommen.

Naja, die ID 15 war ja eine der nicht verwendeten schwarzen "N/A" Texturen in der Java Version, d.h. in der Blaupause ist auch lediglich die Information "15" vorhanden, nicht mehr, und nicht weniger Wie gesagt, die Texturen selbst (also die Bilddaten) werden nicht in Blaupausen gespeichert, da dies die Blaupausen massiv aufblähen würde (und darüberhinaus auch einige Copyright-Fragen in den Raum stellen würde, wenn Blaupausen im Forum geteilt werden)^^

Quote from Deirdre

Ich hatte die Java-Blaupausen erwähnt, auf denen die Farbblöcke in der Unity-Version viel dunkler rüberkommen.

Beim Vergleich der Farbblöcke fällt das nicht auf, allerdings ist der Unterschied bei einem gebauten Teil gravierend. Siehe Screen. (das helle Fenster stammt aus der Java-Version).

Auf dem Bild fällt der Unterschied natürlich sehr extrem aus, da der Rahmen auf dem rechten Bild im Schatten liegt, während er auf dem linken Bild direkt von der Sonne angestrahlt wird (da es in der Java Version ja keine Schatten gab).

Es kann aber durchaus sein, dass einige Farbtöne, die wir als Ersatz definiert haben, noch nicht optimal sind. Ich gucke mir das nochmal genauer an

Quote from Deirdre

Es wurde bestimmt schon einmal irgendwo erwähnt, xD, aber wäre es irgendwann möglich die Texturen von Möbeln zu verändern, um eine gleichmäßigen

Farbverlauf der Umgebung zu gewährleisten?

Das ist generell ein heikles Thema, da Objekte nun - anders als in der Java Version - ihre eigenen Texturen bzw. ein ganz konkretes "UV Mapping" haben. Das muss man sich so vorstellen, dass Objekte in abgewickelter Form vorliegen und darauf dann eine Textur angepasst wird. Hier ist ein Bild (von der CryEngine, aber das Prinzip ist überall dasselbe), was das recht gut verdeutlicht (links ist die Textur zu sehen, rechts das zugehörige Objekt): https://docs.cryengine.com/dow…Date=1439377292000&api=v2

Würde man nun einfach eine der Bautexturen darauf legen, würde das leider in vielen Situationen nicht gut aussehen und teilweise verzerrt erscheinen.

Mal sehen, ob wir dafür eine andere Lösung finden, aber momentan kann ich dazu leider noch nicht viel sagen.

Quote from Yaromid

Wie sieht das dann eigentlich mit Wäldern in der neuen Weltgeneration aus, wird es da nochmal unterschiedliche Varianten geben?

Also auf unserer Agenda stehen momentan nur Laub- und Nadelbäume Die werden natürlich anders aussehen als in der Java Version.

Wir haben aber prinzipiell so viele Bäume vorbereitet, dass wir später auch mehr Abwechslung pro Biom haben können (also zB auch eigene Wälder fürs mediterrane Biom - während das in der Java Version ja recht überschaubar war [das war die Gegend mit den Pappeln, zwischen Graslandschaft und Savanne]).

Gibt es ansonsten noch eine bestimmte Waldsorte, an die du gedacht hast?

Quote from Deirdre

Ist es dann bereits möglich die Bäume oder Pflanzen so weit zu verkleinern, dass sie bequem in Blumentöpfe passen, ohne dass auf Konsolenbefehle

zurückgegriffen werden muss?

Daran wollen wir eigentlich nichts ändern. Denn die Bäume sind sehr detailreich (sprich haben viele Polygone), beim Kleinerskalieren jedoch ändert sich daran nichts (die sind also aus Performancesicht genauso "teuer") - der Unterschied ist allerdings, dass man bei Miniaturversionen viel eher dazu neigt, viele davon auf kleinem Raum zu platzieren. Wenn jetzt ein Spieler bspw. ein großes Beet dicht mit Miniaturbäumen bepflanzt, würde das einen verhältnismäßig großen Einfluss auf die Performance haben - und besonders im Multiplayer kann das kritisch werden.

Das freie Skalieren via Konsolenbefehl werden wir definitiv nicht einschränken, aber wenn es auch regulär möglich wäre, Bäume so klein zu machen, ist das quasi wie eine Art "Unbedenklichkeitsbescheinigung"

Mit dem Update werden aber auch allerlei kleinere Pflanzen reinkommen, die man entsprechend problemlos (also auch ohne Befehl) auf Blumentopf-Größe bekommen kann. Die sind in jedem Fall deutlich performanter.

Quote from Deirdre

Mir macht auch etwas Gedanken, dass ich zu viele Pflanzen zu Dekozwecken verwende und dann viele Bauteile und später noch NPCs hinzukommen und

es dann zu Performanceproblemen kommen kann

Pflanzen werden nicht mit NPCs interferieren, d.h. auch sehr viele Pflanzen werden sich hinsichtlich vieler NPCs nicht negativ auswirken. Da sind wiederum viele Bauteile (Blöcke) eher ausschlaggebend.

Hier muss aber betont werden, dass das in der neuen Version bei Weitem nicht so extrem ausfallen wird wie in der Java Version. Die Physikengine der Java Version ist mittlerweile ca. 13 Jahre alt, das hinterlässt irgendwo seine Spuren...

Quote from Deirdre

Oder sieht es mit der Performance bei bereits ins Spiel integrierten Blumentöpfen besser aus?

Kommt drauf an... wenn wir Blumentöpfe mitsamt Blumen anbieten, dann werden die sicherlich besser optimiert sein. Leere Blumentöpfe hingegen machen keinen Unterschied.

Aber wie gesagt, wenn du mit kleineren Pflanzen (die mit dem nächsten Update reinkommen werden) arbeitest, musst du dir da keine Gedanken bzgl. Performance machen. Nur wenn du viel mit Bäumen bzw. Miniaturbäumen arbeitest (also per Befehl klein skalierte Bäume), dann wird das die Performance natürlich beeinflussen (aber trotzdem nicht hinsichtlich NPCs).

Quote from Arakara

Würde es bei dieser Dauer eine Reduktion geben können, wenn die Blaupausen auf verschiedene Unterverzeichnisse verteilt sind? Könnte (rein theoretisch) nur dann geladen werden, was in dem gerade angewählten Subverzeichnis steht? Und wenn dann ein anderes Subverzeichnis gewählt wird, wird kurz jener Inhalt geladen?

Ich kann mir nicht vorstellen, dass alle 1000 BPs auf einmal benötigt werden, sondern z.B. nur die Zaun-BPs, später nur die Dach-BPs, etc.

Leider würde das nicht helfen Die neue Version zeigt ja sämtliche Blaupausen mitsamt Vorschaubild in der scrollbaren Liste an (nur durch einen jeweiligen ein-/ausklappbaren Header getrennt). In der Java Version hingegen musste man im Journal stattdessen explizit die Gruppe wählen, und dann wurden auch nur diese Blaupausen angezeigt. Die Java Version hatte auch den Vorteil, dass von Blaupausen nur der Name angezeigt wurde, und erst beim Draufklicken wurden mehr Infos sowie das Bild sichtbar. Jetzt hingegen müssen von jeder Blaupause zumindest das Vorschaubild und ein paar Metadaten geladen werden.

Das ist in der neuen Version aber trotzdem schon weitreichend optimiert, bspw. werden die Vorschaubilder erst beim Scrollen dynamisch geladen (sprich das Spiel lädt die Bilder nur für die Blaupausen, die in der Liste aktuell auch sichtbar sind, und sobald beim Scrollen mehr Blaupausen sichtbar werden, werden ihre Bilder entsprechend nachgeladen usw). Dennoch dauert alleine das Zusammenbauen der Liste ein wenig, wenn mehrere 1000 BPs vorhanden sind...

Aber wie gesagt, mit dem nächsten Update wird das zumindest insofern etwas entschärft, dass nur noch bei Änderungen des Ordners neu geladen werden muss

Quote from Deirdre

red51 du sprachst von einer gewollten Verzögerung beim Setzen von Blaupausen, warum ist sas gewollt? Wer aus Versehen eine Blaupause zu früh setzt, der kann ja den Unsobefehl benutzen

Ich denke für den Durchschnittsspieler ist die kleine Verzögerung durchaus sinnvoll um ein versehentliches Platzieren zu verhindern. Gerade bei größeren Blaupausen dauert das Platzieren an sich (und der Undobefehl entsprechend auch) ja ein wenig - also nicht die künstliche Verzögerung, sondern allein die Dauer, bis alle Bauteile auftauchen usw. Und im MP bedeutet sowas auch recht viel Last für den Server, da ist es besser, so ein Versehen von vornherein auszuschließen. Man kann sich währenddessen ja auch bewegen und umschauen, um sich selbst ggf. nochmal zu vergewissern, dass alles passt.

Man könnte natürlich darüber nachdenken, für kleine Blaupausen die Zeit evtl. herunterzusetzen (also wenn bspw. nur wenige Teile oder nur eine Lampe o.ä. darin vorhanden sind).... das müsste man sich mal überlegen

Ich schätze es ist aber einfacher, wenn wir eine Option dafür einbauen (vorläufig aber erstmal nur über die config einstellbar). Ab dem nächsten Update kannst du folgendes zur config.properties Datei hinzufügen: Game_BlueprintsPlaceDelay=0.5 (um die Verzögerung auf 0.5 herunterzusetzen) oder Game_BlueprintsPlaceDelay=0 (um die Verzögerung ganz auszuschalten).

Quote from Deirdre

Beim Setzen von Lampen, gefärbt und gedimmt, als Blaupausen in einem Riesenpool angebracht und richtig positioniert, vergeht im Schnitt eine halbe Stunde, mindestens

Aber die halbe Stunde kommt doch nicht wegen der kurzen Verzögerung zusammen?

Quote from Deirdre

Ich habe mittlerweile auch Blaupausen die nicht zu nutzen sind, da die eigene Textur aus der Java Version in der Unity Version nicht erkannt wird. WIrd das mit dem nächsten Update geändert?

Du meinst Texturen aus Texturepacks? Oder was meinst du genau? Blaupausen speichern keine Texturen selbst (sonst könnte eine BP schnell sehr groß werden), sondern nur die Textur-IDs. Wenn also das Bauwerk in der Blaupause bspw. Marmor mit der ID 58 enthält, dann speichert die Blaupause auch nur die "58" (ohne zu wissen, wie die Textur aussieht oder ob sie evtl. ersetzt wurde). Beim Laden in der neuen Version sieht das Spiel dann nur "58" ohne zusätzliche Infos.

Quote from Yaromid

Gibt es Neuigkeiten zum Update ?

Also momentan sind wir noch damit zugange, jede Menge Pflanzen und Bäume in die neue Version zu packen Und entsprechend auch einige zugehörige Items (zB Obst & Gemüse).

Was ein bisschen schade ist, dass der Unity-Bug, wodurch Windows 7 User das Spiel derzeit nicht spielen können, bisher immernoch nicht behoben wurde. Unity weiß seit Oktober darüber Bescheid und der Bug wurde auch mittlerweile in ihrer alten Version (2021.2) und ihrer aktuellen Alpha (2022.2) behoben, in der aktuellen Version (2022.1) - welche wir momentan verwenden - aber ist der Fix dafür seit 2 Monaten "In Review" Ich hatte eigentlich gehofft, dass das zeitig zu unserem Update fertig wird...

Angepeilt haben wir eigentlich, dass wir das Update diesen Monat rausbringen können (also noch nicht die volle Weltgenerierung & Wasser & Co, sondern nur der 1. Teil davon, nämlich Pflanzen und diverse Vorkehrungen). Wir haben aber in den letzten Wochen noch recht viel Zeit in die eigentliche Weltgenerierung gesteckt (damit der 2. Teil des Updates, welcher ohnehin viel wichtiger ist, nicht unendlich lange auf sich warten lassen muss), wodurch aber natürlich der 1. Teil etwas weiter nach hinten gerät... wir werden jetzt aber zusehen, dass das einigermaßen zeitnahe kommen kann

Quote from Avanar

red51 ich dachte bisher, dass die Verzögerung beim Setzen der bp eine Art Sicherheit darstellt, gegen versehentliches setzen und spammen.

Ja genau, allerdings bezog ich mich oben nicht auf diese Verzögerung beim Platzieren (die ja durchaus gewollt ist), sondern lediglich auf die "Ladezeit" beim Öffnen des Blaupausen-Menüs (also wenn man an den Blaupausentisch geht) Sorry, falls ich mich da irgendwie missverständlich ausgedrückt habe^^

Normalerweise ist beim Öffnen des Blaupausen-Menüs keine nennenswerte Ladezeit vorhanden, sprich das Menü erscheint eigentlich mehr oder weniger sofort. Je mehr Blaupausen man aber hat, desto länger dauert es. Wenn man extrem viele Blaupausen hat (zB über 1000), dann kann es durchaus einige Sekunden dauern, bis das Blaupausenmenü erscheint (weil das Spiel erst alle Blaupausendateien durchgeht und das Menü dazu generiert).

Quote from Avanar

Aber bei xxxx bp wird es echt schwierig mit der Zeit. Gibt es nicht einen Mittelweg? Also nur 1x am Anfang laden und dann einen manuellen refresh?

Wie ja im vorherigen Post beschrieben, wird das Spiel ab dem nächsten Update die Blaupausen standardmäßig nur noch dann neuladen, wenn eine Änderung im Ordner erkannt wurde (also irgendeine Datei im "Blueprints" Ordner dazukam, geändert oder gelöscht wurde)

Ich denke, dass das die optimale Lösung sein wird (und es dann eig auch keinen Bedarf mehr nach einem manuellen Refresh geben dürfte).

Du könntest die Auflösung sonst auch über die "config.properties" Datei im Spielverzeichnis (also im "_New Version" Ordner) entweder löschen (dann werden alle Einstellungen auf Standard zurückgesetzt) oder ansonsten mit einem Texteditor öffnen und die Werte Graphic_ResolutionX auf 1280 ändern und Graphic_ResolutionY auf 720 ändern, die Datei speichern, und das Spiel erneut starten. Besteht das Problem mit den Buttons danach weiterhin?

Basically this information is still accurate - once the new version becomes the "main game", the Java version will move to a separate beta branch on Steam (for the standalone, on the other hand, the Java version and new version use separate launchers anyway).

The only information that's slightly outdated is the part about blueprints: In fact blueprint support is already there and Java blueprints are compatible with the new version (at least when it comes to blocks and construction elements)

Quote from Deirdre

red51 Ich habe extrem viele Blaupausen, 1000 dürfte noch zu wenig sein. da dauert das Laden mittlerweile schon sehr lange. Das sofortige Einfügen von neuen Blaupausen ist zwar ein Pluspunkt, aber ich gehe davon aus, dass das nur das Einfügen von Java-Blaupausen oder Blueprints aus dem Forum betrifft oder? Die Option zum einmaligen Laden wäre schon mega.

Ja, das betrifft in erster Linie das Einfügen von heruntergeladenen Blaupausen aus dem Forum (oder auch Java-Blaupausen). Später allerdings auch über die Mod-Schnittstelle (Workshop bzw. mod.io) heruntergeladene Blaupausen.

Mit dem nächsten Update werden wir das auf jeden Fall etwas abändern und die Blaupausen standardmäßig nur dann neuladen, wenn sich der Ordnerinhalt geändert hat. Das sollte das Problem eigentlich schon entschärfen Ansonsten wird man aber per Option auch generell bestimmen können, dass Blaupausen nur einmalig geladen werden sollen.

Quote from Deirdre

Das Einfärben mit der Farbrolle wäre eine gute Option, leider lassen sich die Ersatz- Putzfarben, durch Übermalen nicht aufhellen und eine Texturänderung mit der Rolle funktioniert ja leider nicht.

Kommt darauf an, welche Textur verwendet wird. Wenn es eine dunkle Textur ist, wird man die natürlich nur eingeschränkt aufhellen können, wenn es aber durch eine Farbe zustande kommt, kannst du das natürlich komplett anpassen.

Wenn du dir nicht sicher bist, ob der Farbton von der Textur selber oder einer darüberliegenden Farbe stammt, kannst du die Farbe zB mit edit color 0 zurücksetzen - wenn es immernoch zu dunkel ist, dann ist es die Textur selber. Mit edit texture könntest du dann höchstens die Textur ändern.

Quote from Deirdre

Beim Ziehen von Blöcken ist mitunter die Anzahl der Blöcke nicht zu lesen, egal aus welchem Winkel man es betrachtet

Momentan wird der Text leider von soliden Objekten (zB anderen Blöcken) verdeckt, wodurch er - je nach Position - manchmal nicht sichtbar ist. Mit dem nächsten Update aber wird die Schrift immer sichtbar sein, also auch durch Wände bzw. Blöcke hindurch (wie in der Java Version)

Implementing physics or gravity for construction elements is a bit tricky unfortunately: The user can freely place them (so they're not bound to a grid, for example, which makes it computationally intensive to find connected elements) and there is also no limit about how many elements could be placed. Some buildings consists of tens of thousands or even hundreds of thousands of construction elements - calculating structural integrity for them would have a big impact on performance unfortunately

However, it's still something we may add in the long run

Quote from VIXLENCE

Fire system, wooden materials burn over time changing their texture on a burnt tree, also falling to the surface so that a mountain of static burned garbage remains from the house.

Fire is also planned, actually we did some experiments with that some time ago, but it's also a bit tricky to implement good looking fire (due to the number of construction elements a building could consist of, but also due to their size - if a user creates a big construction element [e.g. a block with a size of 5x5x5], it's getting tricky to render fire appropriately on that). But as mentioned, it's still planned

Could you elaborate on that?