how about the Alt key?
We could use it, but it would collide with "Walk" (which uses the Alt key by default) 
There is actually another feature that's waiting for a dedicated key: something to change the grid rotation. Right now it can only be changed via command... not sure if it's better to move that to the building menu instead (which can be opened by holding C)? Or would it be better to move the texture offset option there? 
With the upcoming update, open containers (the open barrel or the trough) will automatically fill with water when placed outdoors during rain 
Sorry für die späte Antwort, aber danke für den Hinweis! Das wird mit dem kommenden Update behoben
Später wird es allerdings so sein, dass Salzwasser durchaus eingefüllt werden kann - dann allerdings nicht trinkbar sein wird. Gefäße werden dann nämlich auch die Information mitspeichern, welche Flüssigkeit eingefüllt ist.
Did a spiral stairs using rotated treads, but world textures looks horrible so I switched to local textures to align with each tread. But this resets the texture origin the same for every block causing every tread to have the same identical pattern.
I would like to use the arrow/pg keys just like resizing/rotating a block - but instead shift where the texture origin is on the block. Do not see how to do this but it was suggested on discord that it can be done.
Being able to shift the texture is unfortunately not possible yet... but it sounds like an interesting feature (in combination with local texture alignment). I will put that on our to-do list Although for this feature it's necessary that the block preview shows the texture... this wasn't implemented yet because it's a bit tricky to show the correct alignment on the block preview...
We'll also have to think about a proper way to control that... maybe adding another key for it? E.g. hold the key, then use the arrow keys to move the texture?
Sorry for responding so late, but the next update will indeed change the grid behaviour
I want to give a bit of background information about why the grid behaviour was changed: The problem with the old grid behaviour was that the position was always based on a 1x1 block. For example, if you had a 0.5x0.5 block and a 0.5 grid size, it aligned like this:
If you had a 0.25x0.25 block and a 0.25 grid size, it looked like this:
The same applied to a 2x2 block, which didn't align well to the grid:
The previous update tried to fix these situations. Unfortunately it had the side effect that if you wanted to place a 0.5x0.5 block in a grid with a size of 1, it was no longer centered. Of course this is also problematic...
With the upcoming update, we want to try to fix both situations: If the block size is less or equal the size of the grid (e.g. if you want to place a 0.5x0.5 block in a grid with a size of 1), it will be centered. Otherwise it will try to align to the grid. IMHO that should be the best compromise.
However, we'll also add an option to switch back to the old grid behaviour (in case the new grid behaviour is still causing trouble) 
ja red51 der August hat nur noch 4 Tage
Sorry für die späte Antwort! Leider kamen letzte Woche familiäre Probleme dazwischen, wodurch ich nochmal 1-2 Wochen draufpacken muss, wodurch das Update leider erst im September kommen kann 
Ich habe den Hinweis zunächst nur im Steam-Forum geschrieben, sorry, das hätte ich auch hier machen sollen 
Erstmal vielen Dank für dein Feedback! 
1. Idee: Möbel komplett selbst bauen & benutzbar machen
Da wir ja schon jetzt mit normalen Blöcken fast alles bauen können (Tische, Küchen, Bänke, Theken etc.), wäre es eine coole Weiterentwicklung, wenn man diese selbstgebauten Möbel auch funktional machen könnte.
Das ist absolut sinnvoll und das möchten wir gerne auch so gut es geht ermöglichen Wie Deirdre schon erwähnt sind Scharniere geplant bzw. die Möglichkeit, Bauteile beweglich zu machen. Damit wären dann auf jeden Fall einige Möglichkeiten gegeben.
Ansonsten gibt es für Stühle zB bereits die Sitzfläche als separates Objekt - diese hat einen etwas größeren Interaktionsradius, sodass sie problemlos in Möbeln "versteckt" werden kann. Dadurch kann man zB einen eigenen Stuhl bauen, auf welchen man sich auch tatsächlich setzen kann.
Bei Kisten ist das teilweise auch möglich.
2. Idee: Items frei in der Welt platzieren
Viele Items im Spiel (Werkzeuge, Lebensmittel etc.) könnten direkt frei platzierbar werden, statt sie nur in Behältern zu lagern.
Das ist auf jeden Fall noch geplant und wird in absehbarer Zeit ins Spiel kommen
3. Idee: Kühlräume / Temperaturzonen
Es wäre geil wenn es Objekte wie Kühlschränke usw. gibt. Mann könnte ganze Räume mit Kühltechnik ausstatten:
Mit einem Gerät (Kühlaggregat, Klimaanlage etc.), das einen bestimmten Raum „herunterkühlt“.
Kühlschränke werden auf jeden Fall kommen sobald Lebensmittel verderben können (was auf jeden Fall geplant ist). Ganze Räume hingegen runterkühlen klingt definitiv interessant, ist aber leider auch schwierig umzusetzen, da das Raumvolumen oft nicht auf performante Art berechnet werden kann (da Bauteile ja grundsätzlich beliebig klein und beliebig angeordnet sein können)...
4. Verbesserung: Licht / Schattenberechnung
Aktuell ist mir aufgefallen, dass Lampen keine korrekten Schatten werfen.
Kannst du ggf. einen Screenshot von der Problematik posten? Generell versuchen wir, die Auflösung der Schatten so gering wie möglich zu halten, um den VRAM-Verbrauch nicht in die Höhe zu treiben... für eine Punktlichtquelle müssen bspw. bereits 6 Schattentexturen gespeichert werden (für jede Richtung). Möglicherwise hängt das Problem, welches du hast, damit zusammen.
Für Feuer (zB dem Lagerfeuer) berechnen wir die Schatten grundsätzlich in etwas höherer Qualität, da hiervon meist nicht unendlich viele Elemente auf engem Raum platziert werden... bei Lampen allerdings ist es ja manchmal so, dass Spieler davon hunderte auf kleinem Raum verbauen (daher ist es hier umso wichtiger, die Performance im Auge zu behalten).
ich hoffe ja sehr, dass man dann auch die Leitungen wirklich verlegen kann
Oh, ja, wenn es Elektrizität gibt, wird man die Leitungen entsprechend verlegen können 
Ein Mammut wurde tatsächlich öfter schon vorgeschlagen, es würde also wohl eine Nachfrage dazu bestehen. Da RW ja ohnehin vage ist mit einer Einordnung in ein Zeitalter, finde ich das nicht ganz so problematisch. Ehrlich gesagt könnte ich mir sogar Dinos vorstellen (zB in einem speziellen Biom, ggf. ein seltenes unterirdisches Biom oder eine separate Insel), aber hier ist es tatsächlich eher unwahrscheinlich, dass sie ins Spiel kommen
Bin mal gespannt, wenn die Fackelhalter aus der Java Version rein kommen.
Das kann ich leider noch nicht genau sagen... wir wollen die nämlich eigentlich etwas anders umsetzen als in der Java Version, nämlich dass gleichzeitig auch eine Fackel ausgerüstet werden kann... allerdings ist das gleichzeitige Ausrüsten zweier Items noch nicht implementiert, daher ist leider auch die Fackelhalterung nach hinten gerutscht 
Weiß jemand was genau das Rot umkreiste bedeutet?
Ich habe die "Creative-Mode" Karte etwas umsortiert und dadurch sind diese Einträge zustandegekommen 
Es wird aber mit dem nächsten Update ein neues Platzierwerkzeug für den Creative-Modus kommen, mit welchem mehrere Pflanzen auf einmal auf Terrain "gemalt" werden können. Das ist vor allem hilfreich wenn man zB einen Wald erstellen will, oder eine Blumenwiese o.ä., also grundsätzlich immer dann, wenn mehrere Pflanzen in einen größeren Bereich platziert werden sollen.
Heisst das jetzt Werkzeug Platzieren im Sinne von ner Axt irgendwie, irgendwo hinlegen können oder bezieht sich das auf was völlig anderes und ich sehe vor lauter Wunsch nach der Möglichkeit ne Axt platzieren zu können schon Gespenster
Das Platzieren von Items (also Werkzeugen, Waffen, Lebensmitteln usw) in der Spielwelt ist auf jeden Fall geplant Ich wollte ursprünglich für dieses Update bereits damit anfangen, aber leider haben wir für das Update schon zu viele Baustellen aufgemacht... ich denke aber, dass es ggf. mit dem übernächsten Update oder so kommen könnte 
Und für die, die auf Konsolen Support warten, sie arbeiten gerade daran.
Tatsächlich arbeiten wir "nur" an Gamepad-Support, wie Desmagu schon sagt Genau genommen verbessern wir den Gamepad-Support. Das machen wir aber auch eher nebenbei, also nicht als Hauptfokus, d.h. beim nächsten Update gibt es leider noch keinen vollständigen Gamepad-Support, aber viele Probleme damit werden behoben und eigentlich alle grundlegenden Spielmechaniken sollten mit Gamepad funktionieren. Was weiterhin fehlen wird ist die Steuerung der UI via Gamepad, leider benötigt das weiterhin Maus/Tastatur...
Um Missverständnisse zu vermeiden wird es mit dem nächsten Update mindestens 2, ggf. 3 Modi bzw. Einstellungen geben: Einerseits "Standard", welcher das hier beschriebene Verhalten zeigen wird. Dann darüberhinaus ein "Immer mittig" Modus, der das alte Verhalten wiederherstellt (Blöcke also immer mittig platziert, basierend auf einem Raster mit Größe 1 - auch wenn das vll verwirrend klingt, aber so war das Rasterverhalten in der Vergangenheit).
Optional evtl. noch ein "Immer am Rand" Modus (o.ä), mit welchem sich die Blöcke immer an den Rand bewegen, so wie es jetzt der Fall ist. Aber ich bin mir nicht sicher, ob die Anwendungsfälle dafür nicht bereits mit dem neuen "Standard"-Modus abgedeckt werden.
Um aber nochmal zu verdeutlichen, was mich am alten Raster störte bzw. was ich gerne vermeiden möchte (und weshalb es überhaupt eine Änderung gab): Wenn ich bspw. mit einem 0.5x0.5 großen Block baue, möchte ich bei einem 0.5er Raster gerne, dass der Block innerhalb des Rasters liegt. Mit dem alten Verhalten kommt aber leider sowas bei raus:
Intuitiv ist das mMn nicht gerade. Bei einem 0.25x025 großen Block und 0.25er Raster sieht es entsprechend so aus:
Bei einem 2x2 großen Block und einem 1er Raster sieht es so aus (obwohl 2x2 als Vielfaches von 1 ja nahtlos in ein 1er Raster passen müsste):
--------------
Ein typischer Anwendungsfall für einen 0.5er Block wäre zB wenn ein Spieler eine Wand bauen möchte, diese aber dünner als 1 Block haben will (zB 0.5 groß). Mit dem alten Verhalten steht man dann aber plötzlich vor dieser Situation:
Man kann die Wand also nicht bündig zur Bodenplatte setzen. Klar, jetzt kann man selbstverständlich mit dem manuellen Modus oder dem Andocken arbeiten, aber ideal wäre es ja, wenn man das bereits ausschließlich über das Raster lösen kann. Die obigen Bilder zeigen doch, dass das Raster hier offensichtlich ein Manko hat.
Schöner wäre es IMO, wenn ein 0.5er Block sich auch in einem 0.5er Raster nahtlos einfügt, wie hier:
Wenn der Spieler dafür erst den manuellen Modus oder Andocken nutzen muss, ist das bei einem so simplen Anwendungsfall meiner Meinung nach bereits zu viel verlangt, und trägt auch dazu bei, dass neue Spieler schnell das Handtuch werfen. Wenn ich mir die negativen Reviews der letzten Monate anschaue, ist ein auffallender Hauptkritikpunkt der, dass das Bausystem zu kompliziert ist.
Natürlich möchte ich ja auch niemanden was wegnehmen oder Dinge unnötig verkomplizieren. Dass die Änderung mit dem letzten Update in anderen Bausituationen für Ärger sorgt, ist nicht gewollt gewesen. Ich denke, dass der kommende Standard-Modus den besten Kompromiss darstellt, aber darum bitte ich ja auch um Feedback, damit möglichst alle Anwendungsfälle berücksichtigt werden können.
Wenn es trotzdem Sonderfälle gibt, in denen der Standardmodus Probleme macht, man aber damals mit dem alten Verhalten immer gut zurechtkam, kann man selbstverständlich den Rastermodus dann dauerhaft ändern und muss sich damit nicht herumschlagen.
Das Problem hier betrifft ja nicht ausschließlich den ersten Block; sondern eher wie sich das fortsetzt. Das wechselt doch andauernd von <1 / 1 / >1
Meinst du auf das aktuelle Verhalten bezogen, oder auf das geplante, hier beschriebene Verhalten (was der Standardmodus werden soll)?
Denn was man horizontal mittig anlegen möchte, muss ja nicht auch zwangsläufig vertikal mittig sein
Das Spiel berücksichtigt beim Platzieren grundsätzlich auch die Kollision, d.h. es weicht durchaus vom Raster ab, wenn ein anderes Element den Platz versperrt. Vor allem vertikal ist das häufig der Fall. Das war aber auch mit dem alten Verhalten bereits so (und kann im Zweifelsfall über die Kollision deaktiviert werden).
Wir müssen mal abwarten, wie das Verhalten nach dem Update tatsächlich ausfällt (und dann abwägen, ob man ggf. tatsächlich für vertikales und horizontales Platzieren verschiedene Modi anbietet). Die Modi werden aber voerst nur in den Einstellungen auftauchen, also noch nicht über das Baumenü - denn ich denke, dass viele wahrscheinlich den Modus nur einmal umstellen und dann nie wieder. Wenn aber der Bedarf da sein sollte, den Modus öfter mal zu ändern, dann würden wir den natürlich auch ins Bau-Menü packen
Sorry for my late response! But unfortunately I couldn't reproduce this issue on my end 
What itemID do you use when looking for a clothing, construction or object item? Working with these types of items is a bit tricky actually, since they're typically represented by a generic item. For instance, most objects (with few exceptions) are represented by the objectkit item (ID 790), while clothes are typically represented by the clothingitem (ID 785) and construction are represented by the constructionitem (ID 780).
In order to find a particular object item, for example, you can use the relateditem field from an ObjectDefinition. Example:
Thanks, I'm happy to hear it works!
Ich hatte mich mit einem Gebäude das im 45° Winkel gebaut war, herumprobiert und der Rest der Rasterumstellung ist mir nicht aufgefallen, da ich privat einiges zu tun habe.
So wie es jetzt ist, kann ich, im Gegensatz zu früher, nicht mehr bauen. Das Bauteil dockt nicht mehr an einer Linie an, sondern daneben und um mein Baustück festzusetzen, müsste ich das Teil manuell verschieben, wozu ich absolut keine Lust habe.
Bisher konnte ich das Kleinste, das Zweitkleinste und das Drittkleinste Raster für meine Arbeiten problemlos benutzen. Das ist jetzt so momentan nicht tmehr möglich, da der Block überall, aber nicht auf einer Linie automatisch stoppt.
Ich baue seit über 10 Jahren mit dem Raster, auch wegen der Berechnung von Längen und Größen sehr praktisch und finde es schade, dass das für mich nicht mehr funktioniert.
Es tut mir Leid, dass du Probleme mit dem geänderten Verhalten des Rasters hast. Ich kann leider nicht immer alle Situationen vorhersehen. Aber du kannst das Problem doch auch einfach ansprechen oder - wenn du es nicht im Forum posten willst - einen Report dazu senden, damit ich das anpassen kann (und wenn das zB in den ersten Wochen nach dem Update ist, kann der Fix dafür meist auch innerhalb weniger Tage kommen).
Ich habe ja bereits gesagt, dass wir das Verhalten ändern werden. Wenn das aber nicht ausreicht und sowas nur in Negativität endet, dürften wir das Spiel gar nicht mehr anpassen, da jede Änderung jemanden potenziell missfallen könnte oder auch ein unerwartetes Problem mit sich bringen kann.
Ich Baue viel mit Fachwerk und habe das Bauen seit dem update eingestellt. Es ist jetzt fast unmöglich (nur mit sehr sehr viel Aufwand) die Balken an ihren Bestimmungsort zu setzen und die Fachwerkfelder zu füllen. Ich würde mich sehr über das alte Raster freuen so macht mir das Bauen jedenfalls kein Spaß mehr
Tut mir Leid zu hören. Hätte ich das vorher gewusst, hätte ich das bereits in einem Hotfix angepasst. Aber würde das Verhalten wie hier beschrieben denn in deinem Fall ausreichen?
Aber wie gesagt, ich werde das ja wieder ändern. Es geht mir nur darum, dass das Standardverhalten möglichst optimal ist.
Ich habe noch Gebäude aus der Java Version, die im Raster gebaut wurden. So wie ich das jetzt verstehe, wird das verwenden solche blaupausen dann nicht mehr möglich sein.
Und auch die jetzigen gebauten Gebäude würden nicht mehr passen.
Blaupausen haben damit nichts zutun, da sie nicht in dem Sinne wie Blöcke skaliert werden können. Ich weiß auch nicht, wo du das meiner Beschreibung entnommen hast.
Die Änderung ist übrigens bereits seit dem letzten Update aktiv. Empfandest du es seitdem als dermaßen problematisch?
Warum wurde das Raster überhaupt verändert, nur weil manche Leute damit nicht klarkommen?
Ja, weil manche Spieler damit nicht klarkamen bzw. das Raster als nutzlos erachteten (was Schade ist und mir trotzdem das Bedürfnis gibt, das zu ändern). Gerade neue Spieler sind schnell damit überfordert.
Wenn eine Spielmechanik nicht gut oder nicht optimal ist, dann ändern wir sie logischerweise. Und wenn die Änderung nicht gut ist, dann passen wir sie gerne weiter an. Und das Bausystem im Ganzen hat das Manko, dass viele neue Spieler damit nicht zurechtkommen, deswegen sehe ich da generell noch Handlungsbedarf.
Aber auch objektiv betrachtet sind die Fälle, die ich doch auf meinen vorherigen Screenshots gezeigt habe, einfach nicht optimal. Intuitiv würde ich erwarten, dass ich einen auf 0.5 skalierten Block auch in einem 0.5er Raster platzieren kann. Oder dass ein 2x2 großer Block problemlos in das Standard-Raster passt. Beides war vorher eben nicht der Fall, und das machte vor allem auch neuen Spielern zu schaffen.
Ich bin überhaupt nicht für eine Änderung des Rasters! Zur Not zum Ein- oder Ausstellen, aber einen Sinn sehe ich darin nicht.
Vor der letzten Änderung hatte doch keiner Einwände gegen das Raster und daher verstehe ich die ganze Aufregung jetzt nicht.
Änderung zurücknehmen und alle freuen sich wieder.
Ich verstehe nicht, warum du plötzlich so negativ reagierst Ich versuche nur, die optimale Lösung für eine bisher noch nicht ganz so optimale Spielmechanik zu finden. Dem Feedback im Thread ist auch zu entnehmen, dass die Änderung ja nicht auf kategorische Ablehnung stößt, sondern offenbar durchaus ihre Daseinsberechtigung hat, es eben nur andere Fälle bzw. berechtigte Einwände gibt, die eine weitere Anpassung nötig machen bzw. in denen das vorherige Verhalten vorteilhafter war (und das sehe ich auch absolut ein).
Und wie gesagt, die Änderung ist seit dem letzten Update aktiv, aber erst jetzt kommt das Thema zur Sprache (woraus ich schlussfolgere, dass das Spiel zumindest nicht unspielbar geworden ist).
Danke für das bisherige Feedback! Nach ein bisschen herumprobieren könnte ich mir folgende Lösung gut vorstellen: Solange der Block höchstens groß wie das Raster ist (also bei einer Rastergröße von 1 dürfte der Block auch nur max. 1 breit sein, oder auch kleiner), würde er sich mittig in der Rasterzelle platzieren (also so wie das alte Verhalten war). Wenn der Block größer als das Raster ist (zB 2x2 bei Rastergröße 1), verhält er sich hingegen wie unter dem neuen System.
Das klingt zwar erstmal etwas verwirrend, scheint aber die meisten Anwedungsfälle gut abzudecken. Der Block auf dem Bild im Eingangspost von Desmagu würde sich dann wie gewünscht verhalten, aber auch ein 2x2 Block (wie auf meinem obigen Bild) würde sich optimal ins Raster einfügen.
Und wenn jemand mit 0.5 breiten Blöcken bauen will, kann er das bei einer Rastergröße von 0.5 auch machen, da der Block dann auch optimal im Raster liegt.
Oder gibt es evtl. Bedenken zu diesem Ansatz? Bzw. wird auch eine mittige Platzierung benötigt bei Blöcken, die größer als das Raster sind?
Vielleicht wäre es eine gute Idee, wenn man das Maßband am Anfang und Ende fixieren könnte, um eine Strecke abzumessen.
Diese Änderung ist bereits auf unserer Todo-Liste
Vielleicht würde es schon ausreichen, wenn man mit Block in der Hand im Radialmenü auswählen könnte, ob man den Block seitlich oder mittig zum Raster platzieren möchte.
Tatsächlich war mit dem nächsten Update eigentlich eine Änderung vorgesehen, womit die Drehung des Blocks einen Einfluss darauf hat, an welchen Rand des Rasters er sich bewegt. Mit o.g. Änderung wäre es dafür dann aber auch nötig, das Raster zu verkleinern Wahrscheinlich führt kein Weg an einer Einstellung für das Raster/Block-Verhalten vorbei, aber wichtig ist mir natürlich auch, dass das Standardverhalten möglichst vielen Spielern zuspricht
Hey, sorry for my late response! Originally there were indeed plans to add a shovel, and actually we even had a shovel in very early versions of the game (before it was released, so the shovel was never publicly available). It's actually a low-poly version of the one from the loading screen
It was intended to be used to dig up soil (while the pickaxe would be used for stone). But it was quite clunky to work with it due to the way how the terrain is smoothed... there are smooth transitions between stone and soil, which made it difficult to have separate items for the terrain materials. At the end of the day, we decided to just have a single tool for digging (the pickaxe)
There had been considerations over time to use the shovel for different things though, e.g. as a special smoothing tool etc. But I'm a bit afraid that this could be confusing (at first glance, people would think that the shovel would be used for digging soil while the pickaxe would be used for digging stone), so the shovel never made it into the game unfortunately...
On an M1 Max, it runs fairly well, but I unfortunately I can't say much about the regular M1 or Pro... I guess the game will still work fine there though. It also depends a bit on how much RAM your Mac has (if it just has 8 GB of RAM, it might be sufficient, but it would be better if it has a bit more RAM).
However, if you decide to give the game a try and you run into performance issues, please let me know - we will certainly find a solution then
It's definitely not a bad idea to expose the camera to the Plugin API, but if you want to implement something like head bobbing, you will probably have to modify the camera every frame... unfortunately this wouldn't work well with the Plugin API, since it's designed to only run serverside (when thinking of it as a multiplayer game). So any changes done through the API will be applied to the client with a certain delay (typically the ping between client and server). Ofc there is no server when playing in singleplayer, but you still have a minor delay (typically a few frames), which makes any frame-critical operation impossible.
The API can only circumvent that by providing certain helper methods, e.g. something like a method to set a camera position/offset smoothly (so the game performs the smooth movement under the hood). This way you're still more limited compared to having direct access to the camera, but it should work in most cases. Not sure if that would help in this case?
Drawing outlines around elements is more difficult though, especially since the game is using Unitys HDRP. Passing custom shaders to the client is actually possible through the API, but the HDRP also requires you to write a custom pass to achieve such an effect. Unfortunately this isn't something that could be exposed to the API, even if the API would run clientside...
So that definitely requires classic modding. Currently we have no plans to switch to Mono unfortunately... we might reconsider this in the future, but we ran some tests back then and things like chunk generation were up to 6 times slower in Mono compared to IL2CPP...
However, there is an ongoing effort @Unity to switch to .NET CoreCLR (which would even provide better performance than IL2CPP), but unfortunately there is no ETA (and many people who were originally involved in this process no longer work at Unity, so I'm afraid this switch won't happen anytime soon)... 
However, BepInEx also supports IL2CPP games. Ofc it's more difficult to write mods (due to the lack of easily accessible source code), but it should be possible to create a mod for the game this way
The surface scale/offset is indeed a bit confusing. For each vertex of a construction element, the game first multiplies the (local) vertex position (represented as a vector) with the element size, then adds the surface offset to it and multiplies the resulting position with the surface scale. To get the final position, the game then also applies the element rotation to the vertex position. The bold part is only applied to the upper block surface (the one that can be moved), while the rest is always applied to all vertices.
So the pseudo-code would look like this:
For a regular, 1x1x1 sized block, all vertices have a local position of 0.5. For example, the upper right front vertex has the coordinates (0.5|0.5|0.5), the upper left front vertex has the coordinates (-0.5|0.5|0.5) etc). Now the size is applied (1x1x1), which doesn't change the position in this case (obviously). Now if there is a surface offset of 1 along the x axis, for example, that value is simply added to the vertex position, i.e. the upper right front vertex moves to (1.5|0.5|0.5). Now the surface scale is applied, if it's 0.5, for example, the resulting position would be (0.75|0.5|0.5).
Sorry für die späte Rückmeldung, aber ich kann das Problem bestätigen. Danke für den Hinweis! Das betrifft tatsächlich sämtliche Terraintexturen
Es gibt in der config.properties zwar die Einstellung "Game_BuildingSelectorAlpha", aber leider hat die keinen Einfluss auf Terraintexturen... ich werde das mit dem nächsten Update beheben (also beides, sowohl die Grundtransparenz als auch die Einstellung)
