Ich hab auch zwei Monitore, habe dieses Problem noch nicht gehabt. Vielleicht liegt es ja auch an Windows, die machen ja auch immer so tolle Updates 
Hmm... also mit dem letzten Update hat sich in dieser Hinsicht tatsächlich was geändert, nämlich es ist nun möglich, das Spiel einem anderen Monitor zuzuweisen 
Es ist aber trotzdem eigenartig, warum zuerst der 2. Monitor bei dir angewählt wird... das bedeutet, dass Unity bei dir offenbar standardmäßig den 2. Monitor ansteuert (unser Code wird erst ausgeführt, nachdem das Fenster einen kurzen Augenblick sichtbar war - d.h. erst dann wird der aktive Monitor vom Spiel gesetzt).
Ist in den Einstellungen denn der korrekte Monitor ausgewählt? Was passiert, wenn du dort den Monitor einmal änderst, speicherst (funktioniert das?), und anschließend wieder auf den richtigen Monitor zurück änderst? Besteht das Problem nach einem Neustart dann immernoch?
Das Abbauen von Bäumen im Kreativmodus und die Reste der Bäumen sehen seltsam aus. 
Die Teile verschwinden anscheinend erst wenn das Spiel verlassen wird.
Es könnte sein, dass die "Despawnzeit für Items" in den Einstellungen da eine Rolle spielt
Es könnte sein, dass die "Despawnzeit für Items" in den Einstellungen da eine Rolle spielt
Das dachte ich mir auch schon, aber das seltsame Stapeln nach oben müsste nicht sein. 
Was mir beim Anmalen von Blöcken auffällt, ist, dass sich manche Blöcke sehr gut farblich verändern lassen, andere dagegen sehen aus, wie lackiert.
Diese nehmen die Farbe zwar an, aber wirklich schön ist das nicht, da der Farbauftrag zu krass ausfällt. (Was heißt schön, kommt natürlich auf den
Verwendungszweck an). Eine Möglichkeit zur Einstellung der Farbintensität, halte ich da für sehr praktisch.
Links im Bild ist die ID 260, rechts die ID 266. Unten sind die Originale, oben die eingefärbten Blöcke.
Das Abbauen von Bäumen im Kreativmodus und die Reste der Bäumen sehen seltsam aus.
Wenn der umfallende Baumstamm sofort zerschlagen wird, bevor er wirklich umgefallen ist, dann spawnen die einzelnen Baumstammstücke (also die Items). Dasselbe ist auch in der Java Version so. Die despawnen erst abhängig von der Despawnzeit für Items.
Diese nehmen die Farbe zwar an, aber wirklich schön ist das nicht, da der Farbauftrag zu krass ausfällt. (Was heißt schön, kommt natürlich auf den
Verwendungszweck an). Eine Möglichkeit zur Einstellung der Farbintensität, halte ich da für sehr praktisch.
Links im Bild ist die ID 260, rechts die ID 266. Unten sind die Originale, oben die eingefärbten Blöcke.
Das Problem ist, dass je monotoner die Grundtextur ist, desto mehr tritt das Phänomen auf, welches du beschreibst... leider ist es schwierig, da eine allgemeingültige Lösung zu finden, die für alle Blocktexturen gleichermaßen funktioniert...
Du hast aber beim Malen mit dem Pinsel (statt dem Farbroller) etwas mehr Kontrolle über die Farbintensität. Falls du mit dem "edit color" Befehl arbeitest, dann kannst du den "Alpha" Wert mitangeben: Standardmäßig gibt man dort ja eine Farbe als Hexadezimalzahl an (nach dem Muster #RRGGBB, zB #FF0000 für knalliges rot). Hinten dran kannst du noch zwei Ziffern (auch hexadezimal) für den Alpha-Wert angeben (also zB #FF000080 für einen halb eingefärbten knallroten Block [80 hex ist 128 dezimal, was genau 50% entspricht], oder "#FF0000C8" für einen überwiegend eingefärbten Block etc). Wenn der Alpha-Wert nämlich nicht angegeben wird, dann setzt das Spiel automatisch ein "FF" hinten dran (also maximale Einfärbung).
Das Problem ist, dass je monotoner die Grundtextur ist, desto mehr tritt das Phänomen auf, welches du beschreibst... leider ist es schwierig, da eine allgemeingültige Lösung zu finden, die für alle Blocktexturen gleichermaßen funktioniert...
Du hast aber beim Malen mit dem Pinsel (statt dem Farbroller) etwas mehr Kontrolle über die Farbintensität. Falls du mit dem "edit color" Befehl arbeitest, dann kannst du den "Alpha" Wert mitangeben: Standardmäßig gibt man dort ja eine Farbe als Hexadezimalzahl an (nach dem Muster #RRGGBB, zB #FF0000 für knalliges rot). Hinten dran kannst du noch zwei Ziffern (auch hexadezimal) für den Alpha-Wert angeben (also zB #FF000080 für einen halb eingefärbten knallroten Block [80 hex ist 128 dezimal, was genau 50% entspricht], oder "#FF0000C8" für einen überwiegend eingefärbten Block etc). Wenn der Alpha-Wert nämlich nicht angegeben wird, dann setzt das Spiel automatisch ein "FF" hinten dran (also maximale Einfärbung).
Danke für die genaue Erklärung, das hilft ungemein. 
Ich verwende RGB-Farbcodes, mit Pinsel oder Farbrolle färbe ich nicht.
Es gibt einige Texturen die doppelt sind: ID 215, 216, bzw. diese haben nur eine andere Farbgebung, (bei 225 kann ich auch keinen Texturenunterschied festellen), dann ID 227, 228, nur andere Farbe.
Wird es die alten Texturen aus der Java noch geben, bzw. einige davon waren extrem schön.
Es gibt einige Texturen die doppelt sind: ID 215, 216, bzw. diese haben nur eine andere Farbgebung, (bei 225 kann ich auch keinen Texturenunterschied festellen), dann ID 227, 228, nur andere Farbe.
Ein paar Texturen sind tatsächlich nochmal als dunkle Variante vorhanden. Meistens kann man diesen resultierenden Farbton nicht ganz mit dem Einfärben erzielen. Die Sache ist aber, dass diese Varianten (anders als neue Texturen) keine Performance oder Resourcen kosten Auch freie IDs haben wir ja noch genügend (wir verwenden ja den ID Bereich von 0-1000, und dazwischen haben wir bewusst sehr viele Lücken für neue Texturen gelassen).
Wird es die alten Texturen aus der Java noch geben, bzw. einige davon waren extrem schön.
Mehr Texturen sind definitiv geplant, auch das Blaupausen-Update wird ein paar neue Texturen reinbringen Alle Texturen aus der Java Version können wir nicht übernehmen, bzw. es ist generell leider viel Arbeit, den (geringauflösenden) Java Texturen eine höhere Auflösung zu verpassen und PBR-tauglich zu gestalten. Du kannst mir deine Favoriten der Java Version aber gerne mitteilen, dann kann ich da auf jeden Fall mehr zu sagen.
Beim Öffnen des Baumenus bewegt sich die Spitzhacke immer ruckartig nach vorne.
Das müsste nicht unbedingt sein. Das passiert nur, wenn die Picke in der Hand gehalten wird.
Welches Baumenü meinst du genau? Auf welche Taste ist es bei dir gelegt?
Leider wird meine vorab eingestellte Rotation in der Config beim Neustart des Spieles nicht übernommen.
Das war doch bisher noch nie, oder irre ich mich da jetzt
Das war doch bisher noch nie, oder irre ich mich da jetzt
Doch in der Java-Version schon. Ich habe 90° eingestellt, und das blieb dann auch nach Neustart erhalten. Ich habe jahrelang damit gebaut, gerade wegen Balken und Brettern die beste Einstellung. Mit 15° konnte ich nie was anfangen.
Doch in der Java-Version schon. Ich habe 90° eingestellt, und das blieb dann auch nach Neustart erhalten. Ich habe jahrelang damit gebaut, gerade wegen Balken und Brettern die beste Einstellung. M
Ist mir wohl dann entgangen, da ich die Gradzahl ja auch ständig ändere und anpasse.
Leider wird meine vorab eingestellte Rotation in der Config beim Neustart des Spieles nicht übernommen.
Das ist bei mir aber schon so. Wenn ich aus dem Spiel gehe und wieder rein, ist die Rotation immer noch die selbe. Nur die Größe wird auf Blockgröße zurück gesetzt.
Auf V.
Welches Baumenü meinst du denn genau? Das normale Baumenü kann es ja eigentlich nicht sein, da dies nur aktiv ist, wenn ein Bauelement in der Hand ist (hier kann ja also keine Spitzhacke ausgerüstet sein)?
Leider wird meine vorab eingestellte Rotation in der Config beim Neustart des Spieles nicht übernommen.
Hmm... eigentlich sollte das aber übernommen werden Welchen Wert hast du in der config denn eingetragen? Evtl. kannst du einmal diese Zeile hier posten (oder die config Datei hochladen)?
Wenn ich mir das Licht der verschiedenen Tageszeiten zwischen Java-Version und Unity-Version vergleiche, gefällt mit das Licht, Sonne und der blaue Himmel in der Java-Version viel besser. Wir haben jetzt zwar Schatten, aber die Morgensonne un 8 Uhr ist nicht mehr da, der Sonnenuntergang ist rot, sehr rot, gut für manche Bilder, erinnert aber eher an den Mars als an die Erde. So sieht die untergehende Sonne in manchen Gebieten aus, aber nicht überall auf der Welt. Irgendwie fehlt der abgeschwächte Teil, der eher an einen Regenbogen, mit Verlaufsoptik erinnert, als an eine Marssonne.
Das ist tatsächlich noch nicht final. Dass der Himmel mit dem letzten Update so rot geworden ist hängt ein wenig mit den kommenden volumetrischen Wolken zusammen - die Art und Weise, wie diese gerendert werden, hat nämlich einen Einfluss auf die finale Farbe des Himmels bzw. des Nebels. Volumetrische Wolken sind momentan leider erstmal deaktiviert (da fehlt zwar nur noch etwas Feinschliff, das wollten wir aber nicht beim Crafting- oder Blaupausen-Update dazwischenschieben), sobald sie aber drin sind, wird sich ein realistischeres Gesamtbild ergeben.
Wir können das Rot auch im nächsten Update schon etwas abschwächen, aber wie gesagt, das Endergebnis wird es wohl erst zusammen mit den volumetrischen Wolken geben
Don’t have an account yet? Create a new account now and be part of our community!
