Wenn ein Baum neben einem festen Gebäude wächst oder auf ein Gebäude fällt, dann wachsen die Äste durch die Mauern durch.
Leider ist nicht zu verhindern, dass Bäume, die direkt neben einem Gebäude stehen, ins Gebäude "hineinwachsen"
Das wäre nur zu verhindern, wenn die Bäume keine Modelle wären, sondern vom Spiel generiert werden - dann würden sie aber leider noch schlechter als in der Java Version aussehen (typischerweise passt der Ansatz eher bei Blockspielen)...
Oder anders ausgedrückt: Bäume in dem Detailgrad dynamisch generieren zu lassen wäre ein absoluter Performancekiller ![]()
Bei gefällten Bäumen hingegen liegt es tatsächlich an der Kollision. Das können wir definitiv ändern, müssen aber erst ein wenig damit herumexperimentieren, denn komplexere Kollisionshüllen erhöhen grundsätzlich auch die Chance, dass die Physikobjekte "rumbuggen" ![]()
War für mich in Java schon schwer, aber jetzt krieg ich es irgendwie überhaupt nicht hin, weil die Stufen so blöd andocken
Hast du in der Java-Version dafür die Andocken-Funktion verwendet? Hast du sonst evtl. einmal den manuellen Pivot-Modus ausprobiert (über das Radial-Menü einstellbar)? Da sollten die Andockpunkte eigentlich genau das machen, was man von ihnen erwartet (auch wenn dieser Modus manchmal ein wenig "umständlich" ist)^^
Wenn man was mit PnB und Blöcken gebaut und geprintet hat und es eins von beiden nicht mehr gibt (glaube den Block ansich, weil ja jetzt alles PnB ist), erkennt die neue Version das dann überhaupt richtig? Vorher stand da doch XY Blöcke und XY Bauelemente, oder nicht?!
Keine Sorge, sowohl die damaligen Planken+Balken sowie auch die Blöcke werden einfach durch die neuen Blöcke repräsentiert
Die alten Blueprints enthalten genug Informationen, um das passend zu rekonstruieren.
Wie soll denn das craften später umgesetzt werden. Also zb wie komm ich vom Baum zum Block
Grundsätzlich wird das so ähnlich wie in der Java Version: An der Werkbank wählt man die gewünschte Textur + Form und crafted dann das Bauteil - die "Kosten" orientieren sich dann immer am Material (Holzblöcke werden aus Holz hergestellt, Metallblöcke aus Metall usw) ![]()
Allerdings: Vorschläge und Wünsche sind da immer willkommen ![]()
Drehen ging heute auch erst wieder nachdem ich die Kollision entfernt habe.
Die Kollision sollte mit dem Drehen eigentlich nichts zutun haben ![]()
Die Helligkeit ist extrem. Ich sehe nichts. Mache ich Nacht ist es zu dunkel, bei Tag zu hell, sehr anstrengend.
Du könntest ggf. versuchen die Helligkeit in den Grafikeinstellungen herunterzustellen. Der nächste Hotfix (gerade am kompilieren) wird die Situation evtl. auch etwas verbessern.
Das Raster an den Bauteilen fehlt extrem. Ein genaues Bauen ist nicht mehr möglich und ob das neue dunkle Raster besser is, da bin ich im Moment noch am Zweifeln.
Wir müssen uns da noch Gedanken machen... der alte Ansatz der Java Version war nicht ganz so schön, vor allem bei diagonalen Bauteilen, das hat mich ein wenig gestört (und sieht einfach "verbuggt" aus):
Wir müssen uns da unbedingt eine andere Lösung überlegen ![]()
Unter F3 habe ich die ID gefunden, aber die Texturgröße leider immer noch nicht, trotz Block in der Hand.
Die Texturskalierung eines verbauten Blockes findet sich unten links auf dem Bildschirm in der Ecke, unter der Healthbar (auf Deutsch ist es als "Texturgröße" tituliert). Du musst dafür einen Block ausgerüstet haben und ein Bauteil in der Welt anschauen:
Wenn du sie aber nicht umgestellt hast ist sie immer auf 1 gestellt ![]()
Bunten Putz soll es ja irgendwie nicht geben, aber in irgendeiner Texturen zu bauen um dann rote, blaue oder schwarze Bauteile erst Färben zu müssen, macht für mich irgendwie keinen Sinn
Naja, das hat ja so keiner gesagt, hier brauchen wir einfach Feedback. Aber bunter Putz wäre angesichts der Einfärbemöglichkeit irgendwie doppelt gemoppelt
Hier wäre die Frage, ob es da nicht einen etwas stringenteren Weg gibt? ZB eine Färbemöglichkeit direkt beim Platzieren der Blöcke oder so ![]()