Posts by red51

A small new update is available now!

    Grundsätzlich wird die neue Version deutlich umfangreichere Rechte und Einstellmöglichkeiten bzgl. Blaupausen bieten: Da das Spiel jetzt ja weiß, wer welches Bauteil platziert hat, kann auch sehr einfach eine Permission hinzugefügt werden, dass ein Spieler nur Blaupausen von selbstgebauten Elementen anfertigen darf - dadurch können fremde Bauwerke nicht einfach geklaut werden, aber Spieler können ihre eigenen Kreationen sichern. Das ist vermutlich bereits der wichtigste Punkt (bzw. das war die nervigste Einschränkung in der Java Version).


    Da pro Area separate Permissions gesetzt werden können (und auch abweichende Permissions pro Spieler), kann ein Admin auch relativ einfach festlegen, dass ein Spieler bspw. nur in der eigenen Area Blaupausen anfertigen (oder platzieren) darf. Durch die Areas ist es auch möglich, dass - wenn gewollt - Gruppenarbeiten gesichert werden können (sprich wenn mehrere Spieler an einem Bauwerk arbeiten).


    -Nur eigene Blaupause setzen: ja/nein

    Meinst du damit, dass ein Spieler nur seine eigenen Blaupausen (also die, die er selbst angelegt hat) platzieren darf? Das ist ein wenig heikel, denn dadurch könnten Blaupausen aus dem Forum (oder aus einem künftigen Ingame-Browser) nicht mehr platziert werden, was die Freiheit insgesamt deutlich einschränkt :thinking:


    Außerdem könnte dieses Limit einfach umgangen werden, indem der Spieler die fremde Blaupause erst in einer Singleplayer-Welt platziert, und anschließend erneut eine Blaupause davon anlegt.


    -Transparenz der Blaupause: zahl

    Das sollte vll lieber eine Einstellung in den Spieloptionen sein, damit jeder Spieler das individuell anpassen kann ^^


    -Blaupause beschränkt auf Gruppen: Admin;Member

    Da die Permissions pro Gruppe angelegt werden können, kann jede Gruppe tatsächlich individuelle Rechte haben. Ein Beispiel-Setup wäre: Gäste dürfen weder Blaupausen erstellen noch platzieren, Member dürfen Blaupausen platzieren und nur Blaupausen von selbstgebauten Sachen anlegen, und Admins dürfen sämtliche Blaupausen anlegen.


    -Blaupause craften Material: 5 Goldbarren; 1 Papier

    Schwierig, das pro Permission einzustellen :thinking: Hier wäre ein universellerer Weg, um Crafting-Rezepte anzupassen, generell wünschenswerter...


    -Blaupause Maße Länge/Breite anzeigen: ja/nein

    Auch das wäre vll lieber eine Einstellung in den Spieloptionen, damit auch das jeder Client für sich ein-/ausschalten kann :D


    Ist es im MS nicht möglich die Blaupausen nur auf das eigene Grundstück zu beschränken. So kann könnte niemand einfach bei anderen Spielern Blueprints machen?!

    Ja, auf jeden Fall. Jede Area bzw. jedes Grundstück kann individuelle Permissions haben, einmal eine Grundpermission, die für alle Spieler gilt, und dann noch separate Permissions pro Spieler (typischerweise die "Grundstücksinhaber"): In der Grundpermission könnte dann das Erstellen von Blaupausen verboten, in der individuellen "Eigentümer-Permission" hingegen erlaubt sein.


    Vielleicht wäre ein besonderes Gebiet in dem Blaupausen getestet und hingestellt werden können, praktisch. Mit automatischer Löschung nach xx-Stunden oder xxx-Tagen, so dasss kein Admin tätig werden müsste.

    Das könnte definitiv mit dem aktuellen Permission-System umgesetzt werden ;)


    Was Blaupausen betrifft, sollte auch für die Poster gelten.

    Welcher Aspekt genau? Poster werden vom Spiel weitestgehend wie normale Bauteile behandelt. Aber auch da bietet bereits das aktuelle Permission-System grundsätzlich alle relevanten Einstellmöglichkeiten.

    Separat hinzukommen wird lediglich eine Permission, ob Poster überhaupt platziert werden dürfen, und voraussichtlich auch eine Maximalauflösung (wie in der Java Version).


    ganz ander idee das die leut ihr eigens blaupausen machen könnten 2 bedingungen
    1 eigens grundstück

    2 vom admin einem permit ( zeitlich begrenzte erlaubnis X min blaupausen machen zu können )

    Punkt 1 ist auf jeden Fall möglich, zu Punkt 2 müssten wir uns mal Gedanken machen (da wäre evtl. eine Art Command oder so denkbar). Alternativ könnte ein Admin einen Spieler aber auch temporär einer entsprechenden Permission-Gruppe zuweisen (die die nötigen Blaupausen-Rechte hat), und dann nach ein paar Minuten wieder wegnehmen.


    Es werden fremde Blaupausen geringfügig verändert oder gefärbt und dann als eigene Kunst ausgegeben. Das war mein Grund keine Blaupausen mehr anzubieten. Ein sehr unschönes Verhalten, aber ein Copyright dafür gibt es ieider nicht. Das Umbeschriften durch das Kopieren der Blueprints sollte auch nicht möglich sein.

    Schwierig, sowas zu verhindern... spätestens wenn die Blaupause platziert wurde, geht das Spiel davon aus, dass das Bauwerk dem Spieler gehört. Das ist anders auch nicht zu lösen (sonst müsste das Spiel die UID des Spielers pro Block speichern, was den RAM-Verbrauch massiv nach oben treiben würde, da die UID als Text gespeichert werden muss [da auf manchen Plattformen die UserID auch Zeichen enthalten kann] - ohne einen wirklichen "Vorteil" im Spiel zu bieten).


    Auch unabhängig von der technischen Seite ist es immer etwas schwierig, festzustellen, ab wann eine geänderte Blaupause als eigenes Werk zu betrachten wäre. Wenn ich ein Gebäude herunterlade und nur einen Block umfärbe, dann ist das sicherlich nicht gegeben, wenn ich aber einen Stuhl herunterlade und in einer detailreichen Burg platziere, dann wäre eine Blaupause der Burg (inkl. Stuhl) durchaus als eigenes Werk anzusehen :nerd:


    In eindeutigen Fällen (zB Person A veröffentlicht einen Stuhl, und Person B kopiert den Stuhl, malt ihn lediglich etwas an, und gibt es dann als eigene Kreation aus) würden wir die Blaupause löschen (und Wiederholungstäter sonst auch sperren). Bei weniger eindeutigen Fällen sollte sich der betroffene User am besten an den Autor der vermeintlich geklauten Blaupause wenden (oder im Zweifelsfall uns kontaktieren).


    a simple not allowing a blueprint to be made in the base permissions of an area in the unity version should be protection enough from other people making blueprints of your builds. While when a player is added to the property, they can be allowed to make blueprints on that property when set to something like friend or owner. This is done in the permissions and set when setting a protected area and adding a player to the area. I believe you can restrict the placement of blueprints the same way.

    Yes, this is indeed possible and probably this will be the most common way to handle blueprints. But of course this also works for regular permissions (i.e. one could restrict players to only create blueprints containing blocks that were originally placed by that player), so even a server which does not use any areas gets enough control over blueprints ^^

    Wenn ich das richtig verstehe geht es dann quasi in erster Linie um die Crafting-Kosten, sprich zum Herstellen der Blaupause (also um sie erstmal nur ins Inventar zu kriegen) muss man die Rohstoffe aufbringen (und kann sie anschließend irgendwo platzieren)? Das wäre ein interessanter Ansatz. Hier wäre ggf. sogar eine eigene Werkbank denkbar (also eine "Blaupausen-Werkbank"), die so eine Kiste bereits integriert hat in welche die notwendigen Rohstoffe reingelegt werden können. "Problematisch" bei dem Ansatz wäre nur, wenn die Blaupause weggeworfen wird und ein anderer Spieler sie aufhebt - von der Logik her müsste er ja dann die Blaupause für mein spezifisches Projekt erhalten, momentan werden Blaupausen aber in der Form nicht mit Spielern synchronisiert. Das wäre aber sicherlich ein lösbares Problem...


    Damals war mal geplant, dass im Survival beim Platzieren einer Blaupause zunächst eine Art "Baustelle" erscheint, an welcher dann ebenfalls eine Art Kiste auffindbar wäre. Erst nachdem dann alle benötigen Rohstoffe in diese Kiste gelegt werden, könnte der Bau abgeschlossen werden.

    Wenn beim Platzieren der Blaupause hingegen bereits alle Rohstoffe im Inventar vorhanden wären (zB besonders bei kleineren Blaupausen wie Möbelstücke usw), würde die Blaupause direkt platziert (ohne diesen Kisten-Zwischenschritt). Ebenso würde sich das im Creative-Mode verhalten.


    Die Frage wäre, welcher Ansatz praktischer wäre :thinking: Beim ersten Ansatz (wenn ich ihn denn wirklich korrekt verstanden habe) würde man den "Preis" der Blaupause direkt beim Craften bezahlen, anschließend kann die Blaupause irgendwo sofort platziert werden (oder auch erstmal in eine Kiste für später eingelagert werden). Beim zweiten Ansatz hingegen hat die Blaupause selbst (also das Item) keinen Wert, sondern erst wenn man die Blaupause platzieren will, muss man die Rohstoffe aufbringen (wofür man allerdings beliebig viel Zeit hat und auch andere Spieler könnten dabei helfen).

    Bei den Fliesen könnte man beim Färben derselben die Fugen mit einer andere Farben einfärben. Das geht zwar wie in der Vergangenheit auch, bedeutet aber gleichzeitig mehr Bauteile.

    Evtl. ändern wir es langfristig, dass beim Färben von Fliesen bspw. nicht mehr die Fugen mitgefärbt werden, aber mehrere Farben pro Textur (sprich eine andere Farbe für die Fugen als für die Fliesen) wird es wohl in absehbarer Zeit leider erstmal nicht geben :( Bis dahin wäre die Variante, mehrere Bauteile zu verwenden wohl die einzige Option... hilfreich sein kann in dieser Hinsicht übrigens evtl. die "Scheiben" Form - nur entsprechend statt Glas mit einer anderen Textur: Anders als Blöcke ist die Scheibe komplett flach und bzgl. der Performance vorteilhafter (da weniger Polygone), und kann daher bspw. verwendet werden, um ein Muster an einer Wand oder dem Boden zu erzeugen (auch praktisch für Straßenmarkierungen usw).


    Um so eine Scheibe zu erhalten, muss man einfach item pane in die Konsole eingeben (anschließend eine gewünschte Textur auswählen).


    Beim Selbsterstellen von Fugen, muss meist auf die 0 Texturskalierung zurückgriffen werden. Diese Skalierung weist aber überhaupt keine Textur mehr auf, sondern ist glatt, so dass man eigentlich jede andere Textur verwenden kann. Es wäre praktisch die Skalierung glatt und zusätzlich einen Reiter mit einer 0 Skalierung mit Textur anzubieten

    Texturskalierung 0 kann man sich vorstellen, dass die Textur auf die Größe 0 skaliert wurde - entsprechend wird nur 1 Pixel der Textur verwendet. Viele Texturen ähneln sich bei dieser Skalierung logischerweise (je nach Farbton des 1. Pixels der Textur).

    Was meinst du mit "zusätzlichem Reiter mit einer 0 Skalierung"?


    Bei den Texturen fehlt noch mehr Auswahl. ^^

    In Zukunft werden noch mehr Texturen folgen, da haben wir definitiv noch einiges an Spielraum ^^ Wir müssen uns allerdings erstmal auf ein paar andere Dinge fokussieren, bevor wir uns mehr Texturen widmen können :silenced:

    Beim Anmalen oder Ausbessern von Areal mit dem Terraforming Werkzeug, fällt man trotz kleinstem Radius Bäume in der Umgebung, das heißt das Tool verändert die Pflanzen außerhalb des

    Sichtfeldes des Bearbeitungskreises hinaus

    *Eigentlich* sollte das nur Bäume betreffen, die keinen Bodenkontakt mehr haben :thinking: Momentan wird diese Prüfung bei Änderungen des Terrains für den gesamten Chunk durchgeführt, daher kann es passieren, dass beim Graben eines kleinen Loches ein nahegelegener Baum (sofern innerhalb des Chunks, welche 32x32 Blöcke groß sind) umfällt, sofern er schwebt.


    Wenn die Bäume aber Bodenkontakt haben und dennoch umkippen, sollte das hingegen nicht sein 8|


    Ein späteres Verschieben der Bäume ist zwar möglich, obwohl fixiert, eine Drehung in eine andere Richtung leider nicht mehr. Es wäre sehr praktisch wenn das noch implementiert werden könnte.

    Die Drehung sollte auch mit dem edit Befehl möglich sein, geht aber nur im Creative-Mode. Du kannst zB edit rotate (für eine relative Rotation) oder edit setrotation (für eine absolute Rotation) verwenden. Als weitere Parameter dann die Drehung um die X (links/rechts), Y (hoch/runter) und Z Achse (vorwärts/rückwärts). Um den Baum zB zur Seite zu legen, kannst du bspw. edit setrotation 90 0 0 eingeben etc.


    Die Möglichkeit Bäume zu minimieren ist toll :love: , allerdings wäre ein wenig kleiner noch besser, da diese Bäume vorerst reicht wuchtig und nicht gerade als Zimmertanne dienen können.

    Zumindest sind mit dem edit Befehl beliebig kleine Größen möglich (also edit setsize) ;)

    Beim normalen Platzier-Werkzeug (des Setzlings) müssen wir uns die Min- und Max-Größen nochmal genau anschauen. Das Platzieren von Bäumen in dieser Form ist momentan eh eher eine temporäre Lösung ^^


    (DIe Hickorybäume, die es bisher gibt, werden ja sofort groß).

    Das wird sich ändern sobald Landwirtschaft bzw. richtiges Pflanzenwachsum implementiert ist ;)


    Beim Wechseln der Blöcke in einer andere Textur ist mir jetzt mehrmals aufgefallen, dass in der Slotleiste zwar der Block in der gewünschten Textur angezeigt wird, allerdings das Spiel

    das noch nicht gemerkt hat und leider noch die vorherige Textur verwendet

    Ja, das ist leider noch ein Bug... möglicherweise wird das mit dem nächsten Update behoben.

    Genau weiß ich es nicht mehr, ich hatte verschiedene Farben ausprobiert, zu viele und der gewünschte Farbton war nie dabei. Auf jeden Fall war meine Tür irgendwie weiß, anstatt blau.

    Hmm... leider kann ich das so bisher nicht reproduzieren :wat:


    In der Java-Version hatten wir Planken oder Woodplanktriangles, die immer auf der gewünschten Ebene liegen blieben und sich beim Bauen nicht ungewollt hochkannt stellen ließen oder in eine sonstige Richtung drehen ließen. Dreiecke auf dem Boden blieb zur weiteren Benutzung brav ^^ auf dem Boden liegen.

    Wenn ich jetzt mit Dreiecken arbeite, ist leider die Wahl des Untergrundes nicht möglich, d. h. das Dreieck bewegt sich, ungewollt! natürlich, in verschiedene Richungen.

    Es sind Formen keine flachen Teile wie in der Java-Version, das ist schon klar.

    Es wäre sehr praktisch wenn man für gewisse Bastelarbeiten die Ebene, also waagrecht oder senkrecht, vielleicht auch diagonal, feststellen könnte, so dass ein ungewolltes Herumdrehen gar nicht möglich ist. Fixation auf den Boden, waagrecht, und das Mosaik lässt sich viel einfacher formen, als wenn sich das Bauteil durch eine ungewollte Bewegung in der Achse verschiebt.

    Die Wahl und Festlegung der gewünschten Achse würde sicherlich das Bauen erleichtern.

    Puhh... sei mir bitte nicht böse, aber ich fürchte, ich habs immernoch nicht verstanden :lol::saint: Ich habe mir das Verhalten des "Dreieck" Blocks mal angeschaut und auf Anhieb keinen großen Unterschied zur dreieckigen Holzplanke in der Java Version festgestellt :monocle: Sprich ich habe sie dünner gemacht (Shift + Pfeiltaste links), dann auf die Seite gelegt (Bild Auf/Ab), anschließend konnte ich sie mit Pfeiltasten Links/Rechts um die Y-Achse drehen...


    Ist vll das modulare Andocken aktiv? Oder das Raster? Beides kann nämlich einen Einfluss auf die Ausrichtung und Positionierung des Bauteils haben, was teilweise irritierend sein kann.


    Ich weiß allerdings auch nicht, wie man am besten ein Mosaik baut (weder in der neuen noch in der alten Version) :drunk: Ideal wäre evtl. ein Video aus der Java Version, die das gewünschte Verhalten zeigt?


    Allerdings bleibt die Fps trotz HUD bei einem Screenshot sichtbar. Wäre schön, wenn die Schrift dann verschwinden würde.

    Das sollte eigentlich nicht sein :wat: Wenn das HUD ausgeschaltet ist, dann sollte überhaupt keine UI auf dem Screenshot auftauchen (weder FPS noch irgendwelche Menüs)... verwendest du die Ingame-Screenshot Funktion?

    Spiegel wären ein nettes Feature, können aber aus Performancesicht etwas problematisch werden (wie yahwho schon erwähnt), da für das Spiegelbild die Umgebung ein zweites Mal gerendert werden muss (statt aus Sicht des Spielers, aus Sicht des Spiegels). Wenn jetzt viele Spiegel in näherer Umgebung vorhanden sind, kann das ein ziemlicher Performancekiller werden :dizzy: Hier gäbe es zwar durchaus Spielraum für Optimierungen, aber da es mit der Performance dennoch etwas heikel bleibt, würde ich so ein Feature lieber nach hinten schieben :saint:

    Was dazu aus meine Erfahrung noch fehlt ist die Möglichkeit eine Farbe zu picken (aufzunehmen)

    Achso, das wird im nächsten Update auch drin sein: Wenn die Taste für "An Weltelement anpassen" (standardmäßig EINFG) gedrückt wird während man den Pinsel oder die Farbrolle in der Hand hält, dann wird autom. die Farbe des betrachteten Bauteils übernommen :D

    WHEA_UNCORRECTABLE_ERROR deutet tatsächlich auf ein Hardwareproblem hin :/ Es kann aber auch durch Temperatur- oder Treiberprobleme verursacht werden.

    Ist Windows denn auf dem neuesten Stand? Ansonsten am besten auch nochmal den neuesten Grafiktreiber installieren (vll idealerweise eine Neuinstallation des Treibers vornehmen).


    Es kam zwischendurch übrigens eine Option zum Spiel hinzu, die Framerate zu begrenzen - das kann die Last auf die Komponenten reduzieren. Damit wird ein etwaiges Hardwareproblem zwar nicht gelöst, aber je geringer die Last auf den Komponenten, desto weniger wahrscheinlich ein Absturz (zumindest i.d.R). Der Punkt "Frame Limiter" findet sich in den Grafikeinstellungen. Du könntest die FPS dort evtl. mal auf 60 oder 50 begrenzen (bzw. auf einen geringen Wert als du typischerweise im Spiel erreichst).

    Okeeeey, jetzt habe ich doch mal eine Verständnisfrage. Woher weiß das Spiel, welcher User wohin gebaut hat und dort nicht beeinflussen darf? Der eine baut links vom Berg, der andere rechts davon, der nächste gräbt Tunnel oder baut zusätzliche Berge etc. Die Konvertierung muss dann je nach User woanders wirksam werden.

    Das kann ja immer woanders sein, daher ist der einzige Weg, das "einigermaßen" zu konvertieren, dass das Spiel alle bebauten Chunks durchgeht, drumherum jeweils einen ausreichend großen Bereich mit der alten Generierung erstellen, und diesen langsam mit der neuen Generierung verschmelzen. Es ist keine perfekte Lösung, würde aber einigermaßen passen. Ist aber leider ein gewisser Komplexitätsgrad hinter...


    Oder langfristig (am Ende der ToDo-Liste) vielleicht sogar zu einem Tutorial-Gebiet werden, um die Steuerung etc zu lernen????

    Das wäre eine gute Idee, für sowas wäre der Startbereich der Demo-Welt (mit etwas Anpassung) tatsächlich gut geeignet ;) Das behalten wir mal im Hinterkopf


    Ich habe mal einen Screen von einer alten Welt nach Konvertierung bzw. Biomupdate gefunden. Was bei einer Konvertierung passieren kann. Nicht, dass es passiert, aber was durchaus für eine komplett neue Welt / Karte sprechen würde und solche Vorkommen auch 100% ausgeschlossen werden können.

    Ja, alte Welten waren damals nach dem Biom-Update nicht mehr kompatibel. Also genau genommen konnte man sie noch laden (und Gebäude mit Blaupausen sichern), aber die alten Chunks passten nicht mehr ansatzweise mit neu generierten Chunks zusammen - und da das Spiel immer nur die Chunks speichert, die geändert wurden, kam da dieses Durcheinander bei raus. Das haben wir damals in Kauf genommen, weil eine richtige Konvertierung wäre enorm zeitaufwändig gewesen. Manche User haben uns das schon sehr übel genommen, weshalb wir die Welt-Generierung daraufhin in künftigen Updates eher nur noch mit Samthandschuhen angefasst haben (wodurch solche Situationen nicht mehr so in dieser Form auftraten, aber im Gegenzug leider auch diverse Terrain-Updates oder neue Biome auf der Strecke blieben) :|


    Bei der Demo Welt ist wohl davon auszugehen, dass in den meisten Fällen bisher noch nicht so viel gebaut wurde (das war damals beim Biom-Update ja noch anders) - und in den Fällen, in denen bereits viel gebaut wurde, ist es vermutlich "ausreichend", wenn man die Welt einfach wie bisher weiter laden kann und alle bisherigen Chunks noch intakt sind :thinking:


    Diese Riese hast du heute beim Terraforming schon.

    Das ist noch etwas anderes: Momentan können offenbar in LOD Bereichen solche Risse auftreten, das liegt aber an einem Bug in der LOD-Generierung. Sobald man sich dem Bereich nähert, sollten diese Risse verschwinden. Dieser Bug ist nervig, sollte aber hoffentlich bald behoben sein (vmtl. im Zuge des Welt-Updates).


    Beim Biom-Update damals hingegen haben die Chunks ja vorne und hinten nicht mehr gepasst, und teilweise waren Chunks übereinander usw :dizzy:

    Ich kann dagegen nicht sagen ,dass ich die Textur Änderung bei mir sofort bemerkbar gemacht hätte. ich habe keine Änderung gemerkt und daher das Spiel neu gestartet

    Das ist eigenartig :thinking: Wenn direkt oberhalb der roten "Unsupported Action" Meldung auch die grüne "Edit construction: texture" auftaucht, dann hat das Spiel diese Änderung eig. auch durchgeführt... Wurde der Befehl evtl. zwischendurch versehentlich falsch geschrieben? Dann kommt nur die rote Meldung (oder je nachdem eine andere rote Meldung), was aber in der Vielzahl der Nachrichten (vor allem der vielen roten Meldungen) vll schnell untergehen könnte?

    Leder oder Metall sieht nach dem Einfärben anders aus, das ist eigentlich klar. Warum allerdings eine Tür eine komplett andere Farbe bekommen kann, ist mir nicht schlüssig.

    Hmm... wie genau meinst du das, dass Türen eine komplett andere Farbe bekommen? Heißt das wenn du zB Tür 1 die Farbe #FF0000 (rot) gibst, und Tür 2 die gleiche Farbe verpasst, sie auf beiden Türen unterschiedlich aussieht? 8|


    Wäre es möglich die Arbeitsebene vorzugeben, z. B. horizontal oder vertikal? So können Formen auf dem Boden ebenso schnell gedreht werden wie an einer Wand.

    Wie meinst du das genau?

    Wäre es vielleicht programmiertechnisch möglich, dass ihr den Usern "einfach" :P ;) :P eine Selbstwahl-Option in den Settings dazu bastelt? Ich habe z.B. gerne deutliche Kontraste, z.B. weiße Schrift auf schwarzem Hintergrund oder umgekehrt, oder Cyan auf dunkelgrau etc.

    Am sinnvollsten wäre hier ja eine Option, die das global für alle Texte anpasst, aber das ist leider ein wenig schwierig umsetzbar, da sich die Texte ja an den verschiedenen Stellen im Spiel teilweise deutlich voneinander unterscheiden :thinking:


    Uhm, und wenn ich schon dabei bin ^^ vielleicht auch die Textgröße der Hilfstext-Schriften beeinflussbar machen? Bei einem anderen Spiel, bei dem die Schrift mir einfach zu klein war und meine Nase am Bildschirm geklebt hatte, habe ich den sauren Apfel gewählt. Anstatt in 1920 x 1080 zu spielen, spiele ich in 1366 x 768. Mein Nacken dankt es mir :D :D

    Hier wäre eine Universaloption vll auch ganz schön, aber bei den Hilfstexten macht es evtl. Sinn, darauf gesondert einzugehen ^^ Wir müssen uns das mal genau anschauen und gucken, welche Optionen wir inwieweit tatsächlich anbieten können. Und vor allem natürlich auch standardmäßig die Sichtbarkeit erhöhen (da der jetzige Zustand tatsächlich nicht so optimal ist) :saint:

    Handelt es sich um die Java Version, oder die Unity Version? In der Unity Version gibt es mit dem "size" Befehl momentan leider noch Probleme, vor allem wenn das Bauteil eine negative Größe hat (das ist zB dann der Fall, wenn das Bauteil gespiegelt wird) - vielleicht hängt es damit zusammen?


    Die Zahlen für den Size-Befehl einzugeben ist ein Krampf. Der Cursor springt an eine andere Position, als man eigentlich haben möchte, sehr nervig. :(

    Leider ist das ein Problem in Unitys neuem "UI Toolkit" i.V.m. mit deren neuen Input-System. Das "UI Toolkit" - welches wir für unsere UI verwenden - ist noch relativ neu und derzeit noch in einer "Preview" Fassung, daher gibts hier leider noch sehr viele Probleme (unter anderem auch die von dir angesprochenen Probleme mit Textfeldern). Da können wir momentan leider nicht viel machen (wir möchten eigentlich nur ungerne wieder ein eigenes UI Framework schreiben [wie wir es in der Java Version taten], da dies enorm zeitaufwändig ist). Einige UI-bezogene Bugs werden sich mit dem nächsten Update aber beheben (da es zwischenzeitlich ein Update für UI Toolkit gab).

    Was das Färben angeht: Mit dem nächsten Update kann zumindest beim item Befehl hinten ein Farbcode angegeben werden (nur bei Bauelementen), also zB item block #FF0000 oder item block 64 100 #FF0000 - damit erhält man dann den Stack direkt in der angegebenen Farbe.


    Bald kommt außerdem ein Farbpinsel (als Item) hinzu. Dieser wird sich so wie der jetzige Farbroller verhalten (d.h. ein Bauteil stufenweise einfärben), wohingegen der Farbroller dann Bauteile fortan sofort einfärben wird (und dadurch deutlich schneller arbeitet).

    Wir haben die Haltefunktion schon fürs Update fertig, standardmäßig kann man sie aktivieren (also den Zoom "einrasten"), wenn man 2x schnell hintereinander Z drückt. Die Taste kann aber auch in den Einstellungen unter "Steuerung" entfernt oder geändert werden ("Zoom" und "Zoom (Halten)" sind dort separat aufgeführt und können auf beliebige Tasten gelegt werden, genau wie das zB beim "Ducken" gelöst ist) :)


    Das Bild verstehe ich leider nicht ganz :saint:

    Das ist auf jeden Fall auf unserer Todo-Liste ;) Wir müssen noch schauen, wie wir die am besten sichtbarer bekommen, ohne, dass sie zu auffällig werden. Eine einfache Umrandung hat sich bisher nicht so gut angeboten, da die Schrift dafür zu klein und zu dünn ist... wir müssen mal schauen, ob wir evtl. einen ganz dezenten Hintergrund dazu packen, oder evtl. eine andere Lösung finden :thinking:

    Es wäre zwar absolut nachvollziehbar, eine Umfrage dafür zu starten, allerdings ist der ausschlaggebendste Faktor (für die Frage, wie genau die Demo-Welt konvertiert wird) eher technischer Natur: Das "Minimum", was wir auf jeden Fall umsetzen können, ist, dass die Demo Welt einfach weiterhin so aussehen wird wie jetzt auch. Wenn es technisch nicht zu viele Probleme aufwirft, dann können wir darüberhinaus evtl. die nicht-erkundeten Gebiete konvertieren, aber das können wir momentan leider noch nicht so richtig einschätzen. Wenn das nämlich zu aufwändig wird, würden wir das lieber sein lassen (bringt ja nichts, wenn wir wochenlang nur mit der Demo-Welt beschäftigt sind). Und diverse Einschränkungen bleiben so oder so bestehen (wenn zB jemand auf dem Kiesbett gebaut hat - was ja später der Meeresgrund wird - können wir das Gebiet ja nicht einfach fluten).


    Wenn wir jetzt aber eine Umfrage starten und die Mehrheit der User spräche sich dafür aus, dass unerkundete Gebiete konvertiert werden sollen, dann müssen wir das umsetzen, egal wie lange es dauert - das wäre suboptimal. Wir könnten zwar in der Umfrage auf die technischen Hintergründe hinweisen, aber das wird dann langsam etwas kompliziert :drunk: