Posts by red51
-
-
I fully agree that intuitive controls and a structured, self-explaining UI is extremely important. Having a tutorial is certainly not a full solution for this, because most players would probably indeed just skip it
Although there are certain controls and features (like the "surface edit mode" or the pivot snapping) which would be a bit difficult to explain via tooltips and minors hints 
I also think that the building part is still too complicated for new players, although I'm not sure how to simplify it (while keeping its flexibility)... we definitely appreciate any suggestions in this area
However, regarding planks, I'm not sure if there is really a need for them... basically planks are nothing but thin blocks, so isn't the regular block shape already sufficient? If we add a plank shape (i.e. basically a flat block), there would be enough reason to add a half block or half cylinder as well, but having too many shapes which are basically just a resized version of one of the default shapes could make the menu a bit unstructured...
There was also a similar discussion in the German section some time ago, as mentioned by Avanar , but are there really so many use-cases for planks, i.e. enough use-cases to justify adding a thin block?
I still however, feel that a plank should be a basic object. Particularly for casual gamers and the proverbial noob.
Is there a reason why this would be helpful for causal gamers specifically? I'm not sure if planks were really widely used by causal gamers in the Java version... apparently most causal gamers mostly just used blocks back then (which were quite limited in the Java version)... if someone isn't used to the Java version, I'm not sure if he would really miss planks
-
Da es ja sowieso irgendwann auch eine Spielereinstellung geben wird, würde ich die Höhe der Figur momentan so lassen. Aber ( mit Hinweis ) später in den Einstellungen für die Figur uns die Möglichkeit zu geben, die Figur auch größer, kleiner, dicker und dünner zu geben. Wer dann nicht mehr durch eine Standarttür passt, hat pech gehabt. Aber auch hier kann dieser Spieler ja mit den Größen auch bei den Objekten dann spielen. Denke das dies so das einfachste wäre red51
Grundsätzlich stimmt das ja schon, aber wenn es da zu große Abweichungen gibt bzw. jeder Spieler selbst entscheiden kann, wie groß er ist (also zumindest auch wie groß seine "Kollisionshülle" ist), könnte es im Multiplayer und beim Teilen von Blaupausen evtl. Probleme geben
Wenn sich zB ein Spieler sehr klein macht (vll auch versehentlich oder einfach ohne darüber nachzudenken), und seine Bauwerke zu klein baut, könnte das für viel Irritiation oder sogar Frustration sorgen... spätestens wenn er zB seine Blaupausen teilen möchte, und niemand durch die Türen gehen kann, weil alles zu klein ist... red51 da es im letzten halben Jahr allgemein zu Verwirrung wegen der aktuellen Demo-Welt geführt hat, würde ich vorschlagen, dass ihr einfach irgendwo eine Notiz einblendet, damit Spieler in der neuen Version informiert werden, dass es noch keine Weltgeneration gibt und diese später kommt (z. B. beim Erstellen einer neuen Welt). Solche Fragen landen ja oft in den Foren und werden dort beantwortet, aber es wäre gut, wenn man das auch nochmal im Spiel klargestellt wird, da manche Leute das auch schnell missverstehen können und die neue Version als unbrauchbar abschreiben
So oft fragt ja eigentlich niemand nach, ob die Weltgenerierung final ist bzw. "was damit nicht stimmt"
Es gibt aber durchaus immer wieder Situationen, in denen bemängelt wird, dass diverse Features in der neuen Version noch nicht funktionieren oder noch fehlen. Es gab auch schon den einen oder anderen negativen Review, weil zB Feature X oder Y der neuen Version fehlt oder unausgereift ist... ich bin mir allerdings auch nicht sicher, ob ein Hinweistext das wirklich verhindert hätte... Eigentlich ist die neue Version ja extra in einem separaten Beta-Branch versteckt, d.h. man muss sie ja aktiv anwählen (das kann ja zumindest nicht versehentlich passieren)...Ich denke aber, dass ein generischer Hinweistext im Hauptmenü zumindest nicht schaden kann
Wäre es möglich eine kurze Übersicht der kommenden Features mit einem disclaimer bzgl alter/neuer Version im Hauptmenü einzublenden?
Wie meinst du das, bzw. wie soll das genau aufgebaut sein? Eine Feature-Übersicht wäre ja u.U. relativ umfangreich, vor allem wenn auch kleinere Features aufgelistet sein sollen (zB Wettereffekte, Kisten etc)
Oder meinst du was anderes? -
schau dir dieses Bild an irgendwie ist das Haus zu klein. w2ie kommt das?
Jemand hat offensichtlich ein kleines Haus in der Java Version gebaut bzw. als Blaupause gespeichert. Manche Leute haben in der Vergangenheit ja manchmal schon bewusst Miniaturstädte gebaut (und die Baupläne auch teilweise im Forum veröffentlicht)
Mit der neuen Version hat das nichts zutun, wie gesagt, Blaupausen sind in der neuen Version noch gar nicht verfügbar (die kommen erst mit dem nächsten Update)
-
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. -
red51 Was mir bei dem Thema Größe einfällt, dass es bei irgendeinem Update die Größe des Spielers? angepasst wurde und sich dieser ab dato bücken musste, um Treppen herunter zu laufen, die vorher ohne Probleme begehbar waren. Ich habe leider auch ein paar mittelalterliche Häuser, wo mich so etwas sehr stört, da ich die Höhe verändern müsste. Wenn das nicht die Spielergröße war, könnte man diese Veränderung zurücknehmen, dann wären solche Gebäude in der Unitiy-Version, wo der Spieler größer sein soll, besser und ohne Umbau nutzbar?
In der Java Version wurde damals die Größe tatsächlich schonmal geändert. Zuvor war der Spieler so klein, dass er gerade eben so durch 3 Block hohe Türen durchlaufen konnte - allerdings blieb er in solchen Durchgängen ständig stecken bzw. das resultierte in viel rumgezittere, weil der Durchgang einfach zu klein war. Wir haben das damals leider erst spät geändert, weil das ein wirklich suboptimaler Zustand war...
Die Änderung wurde teilweise negativ aufgefasst, wodurch wir den Spieler damals wieder geringfügig kleiner gemacht haben - damit passte er durch 3 Block hohe Türen gerade eben so nicht mehr durch, aber dafür mussten manche alten Gebäude nicht mehr angepasst werden. Das Problem war, dass 3 Block große Türen trotzdem so aussahen, als könnte man dort durchlaufen.
Und sobald der Durchgang geringfügig größer war (zB der Durchgang direkt auf Terrain gebaut war, wo der unterste Block ja nur zu 1/4 rausguckt), gab es wieder das alte Problem (rumgezittere etc).
In der neuen Version haben wir die Spielerfigur so groß gemacht, wie es damals in der Java Version bei der ersten Änderung vorgesehen war (also bevor wir das wieder etwas abgeschwächt haben).
Ich weiß dafür aber leider auch keine bessere Lösung... den Spieler wieder so klein wie damals zu machen wäre wirklich nicht gut, da man dann bei 3 Block hohen Durchgängen ständig am "rumbuggen" wäre. Es ist irgendwie doof, wenn man einen "schlechten Zustand" nur aufgrund einer damaligen Fehlentscheidung beibehalten muss
Besser wäre es, die betreffenden Gebäude anzupassen und besonders kleine Durchgänge etwas zu vergrößern. -
I agree that we definitely need more help texts and hints for the new building features
A tutorial would be also helpful, considering some of the new building features are quite complex at first. That's on our to-do-list, and some of these things certainly should be implemented before the new version goes live on the store page -
Danke für die Erläuterungen!
Dieser "graue Bereich" ist momentan quasi nur ein Platzhalter, wie lenko schon sagt, dieses Gebiet wird später überwiegend vom Meer bedeckt sein. Gleichzeitig werden die Inseln aber auch wesentlich größer, denn der jetzige Berg, der sich in der Demo befindet, stellt nur einen recht kleinen Bereich einer Insel dar. Die Weltgenerierung ist leider insgesamt noch nicht fertig, daher ist die Landschaft etwas trist (wenig Vegetation, keine Wälder, kein Wasser etc). Viele warten auf die Weltgenerierung und das ist auch wahrscheinlich eines der wichtigsten Features, die noch fehlen. Das Update für die Weltgenerierung soll aber in der ersten Jahreshälfte 22 kommen.Bei der Java Version habe ich auf Hessenstrolsche gespielt und war nicht als einziger Spieler auf der Mapp und somit humpelt man jetzt als einziger Spieler durch die Welt
Wie meinst du das genau? Der Mehrspieler ist ja bereits implementiert, d.h. man kann bereits mit anderen Leuten zusammen spielen. Die neue Version bietet alle Multiplayer-Optionen wie schon die Java Version (P2P, also "mit Freunden spielen", dedizierte Server usw).
Wenn man jetzt ein Gebäude baut und diesen Blueprint in die alte Version setzt stimmt das Größenverhälltnis nicht.
Hmm... das müsstest du evtl. auch etwas näher erläutern... wie kommst du darauf, dass das Größenverhältnis nicht stimmt?
Eigentlich sollten die Maßstäbe weitestgehend mit der Java Version übereinstimmen. Die Spielerfigur ist lediglich marginal größer geworden (vll 5-10 cm), d.h. Durchgänge, durch die man sich in der Java Version gerade eben so durchquetschen konnte (was meist unschön war) könnten jetzt zu klein sein. Das sollte aber eigentlich in den meisten Fällen überhaupt kein Problem darstellen.Allerdings wird es nicht möglich sein, Blueprints aus der neuen Version in die alte Version zu übertragen. Das wäre mit viel Aufwand verbunden, gleichzeitig würde uns das jetzt unnötig einschränken...
Man wird allerdings alte Blueprints aus der Java Version durchaus in die neue Version übertragen können (zumindest Bauelemente)
Wir arbeiten derzeit daran. Wir haben zwischenzeitlich schon einige Blaupausen aus dem Forum testweise importiert und bisher passten die Größenverhältnisse ziemlich gut. Das Blaupausen-Update wird spätestens im Januar erscheinen. -
Ich hatte mich jetzt mehr auf die Vorschläge beschränkt. Und dachte das man ja zb eine Balkontür nicht nur öffnen und schließen kann, sondern auch kippen. Das gleiche gilt ja auch für Fenster. Jetzt kämen noch Klappen hinzu die nach oben oder unten aufgehen. Zum Schluss noch der Traum von Schiebetüren die ja seitlich nach außen aufgehen.
Achso, verstehe
Also die Möglichkeit, eine Tür zu kippen "universell" umzusetzen ist ein wenig schwierig, aber wir könnten das später durchaus für spezielle Türen anbieten (zB Balkontüren, die man auch in echt nicht nur öffnen, sondern auch kippen könnte) Eine universelle Funktion um eine Tür zur Schiebetür zu machen wäre schon eher denkbar
Aber ich würde vmtl. auch da spezielle Türen (also richtige Schiebetüren) bevorzugen, auch aus optischen Gründen (bei den regulären Türen wäre sonst wohl oft die Klinke im Weg, zumindest optisch). -
8. Hide grass if it is under construction element
Hehe, well, unfortunately there is currently a bug which prevents the "grass occlusion" to work properly
Usually it only works if you actually stand on the ground, but if you're at a slightly higher elevation, it no longer works (resulting in grass being visible through construction elements again). But we will fix that ASAP 9. Move items up if they are below terrain
Sometimes when you break element its center will be below terrain, and as a result - summoned item will be dropped below terrain into the void. Suggestion is to moved it to the nearest point of terrain above it, and the player will not lose any resources anymore.
Oh, that's not supposed to happen
If blocks are slightly below ground (i.e. if their upper surface is still almost barely visible), they're supposed to spawn above the ground if removed via sledgehammer... this may not work properly on slopes though (if most part of the upper surface is covered by terrain, and if the distance between the center of the surface to the ground is too great)... this definitely needs some improvements. Or did you also experience that on flat ground?10. Change size of construction elements on icons
Construction elements can have different sizes, but this is not shown on their icon which sometimes makes their identification difficult. If the icon will have same outlook as an element in the world it will be much easier to define what elements you have in inventory
Well, the problem is that the size is not stored persistently for construction elements in your inventory...
11. Make some construction elements possible to attach with snapping tool
Good point, we will add a pivot for the wall torch with the next update
And if you will enable grid snapping instead Wall torch will be inside the wall until you make the grid really small
Yeah, the grid definitely needs a bit more love, especially when it comes to object placement. It's on our to-do-list
-
Tatsächlich hat ein Block ca. eine Größe von 0,5 x 0,5 x 0,5 Metern
Dieser Maßstab hat diverse Gründe, einer der Hauptgründe ist aber, dass wir den Maßstab der Java Version gerne beibehalten wollten. Damals bot sich diese Blockgröße an, da dadurch Hauswände eine passende Dicke bekamen.Aber auch die "Auflösung" des Terrains spielt eine Rolle, denn auch dort hat das zugrundeliegende Raster, in welchem die Terrain-Daten liegen, diesen Maßstab. Wäre ein Block (bzw. eher gesagt "1 Einheit") 1 Meter groß, würde das Terrain deutlich ungenauer sein. Natürlich hätte man die Werte fürs Terrain auch jeweils umrechnen können, aber so ist es etwas einfacher.
Es bietet sich auch ein wenig an, dass ein Block standardmäßig eine Größe von "1 Einheit" hat. Wäre "1 Einheit" entsprechend 1 Meter groß, würde das zu ziemlich großen Blöcken führen (wären ja nach aktuellem Maßstab 2 x 2 x 2 große Blöcke).
Wir könnten aber evtl. eine Einstellung einbauen, wodurch das Spiel die Größen automatisch ins metrische (oder imperiale) System umrechnet. Dann würde ein Standardblock statt "1 x 1 x 1" eine Größe von "0,5 x 0,5 x 0,5" Metern haben. Beim imperialen System wirds schwieriger, hier müsste man evtl. einfach auf "20 x 20 x 20" Zoll aufrunden (schließlich sehen "19,685 x 19,685 x 19,685" Zoll blöd aus und sind keine wirklich tolle Standardgröße)... andererseits aber auch wieder heikel, wenn die Umrechnung zwischen Meter und Zoll so ungenau erfolgt
Kann man schon ungefähr abschätzen wann die Blueprints kommen?
Definitiv nicht später als Januar
Aktuell kennt man die genaue bezugsgrosse nicht. Daher gehen viele davon aus das 1 block 1 Meter entspricht und wundern sich dann warum der char nicht durch die Tür kommt
Bei MC (oder anderen Spielen mit gleichgroßen Blöcken) war es mit den 1 Meter großen Blöcken tatsächlich einfacher, wobei ich hier sagen muss, dass die Größenverhältnisse bzgl. Türen auch nicht so 100% passten, bzw. die Türen verhältnismäßig klein wirkten... bei RW merkt man aber zumindest bei einer 1x2 Block großen Tür sofort, dass das nicht stimmen kann bzw. deutlich zu klein ist
In der Vergangenheit haben manche Leute intuitiv die Türen 1x3 oder 2x3 Blöcke groß gebaut, was in der Java Version grenzwertig klein war (eigentlich zu klein). In der neuen Version ist der Spieler ein bisschen größer, sodass er keinesfalls mehr durch eine 3 Block hohe Tür gehen kann.Ich weiß aber auch leider nicht, wie man das intuitiver gestalten könnte
Wären die Blöcke in RW standardmäßig 1 Meter groß (also nach jetzigem Maßstab 2x2x2 Blöcke), dann wären die echt riesig -
Danke für die bisherigen Türvorschläge
Einige dieser Varianten haben wir auf jeden Fall schon in der Vorbereitung, ich kann aber leider noch nicht sagen, wann das "Türen-Update" genau kommen wird. Es wird aber deutlich mehr Abwechslung als die verschiedenen Türen der Java Version bieten Ich denke Mal das Deirdre eher das schon öfter angesprochedes Schanier für den Bau von Türen mein.
Sowas wäre natürlich auch mein Favorit, was Türen und damit auch leicht zu gestalten Fenster angeht.
Das ist tatsächlich ein heikles Thema... wir werden uns aber damit auf jeden Fall nochmal auseinandersetzen
Es wäre aber wahrscheinlich kein Ersatz für eine Grundauswahl an Türen, denn während Spieler mit großem Baufokus vmtl. viel Gebrauch davon machen würden, möchten Gelegenheitsspieler möglicherweise nicht alles selber bauen müssen und würden ggf. vorgefertigte Türen bevorzugen. D.h. wenn dann müssten Scharniere wohl zusätzlich zu einer Grundauswahl an Türen ins Spiel kommen 
red51 vielleicht etwas unpassend aber wäre es in Zukunft hier nicht möglich der Tür durch das Menü zu sagen in welche Richtung sie sich öffnen lässt.
Wie meinst du das genau? Grundsätzlich kannst du ja bereits bestimmen, in welche Richtung die Tür sich öffnet: Wenn du sie um 180° drehst, öffnet sie sich in die andere Richtung, und wenn du sie dann spiegelst (über das Kontextmenü oder die ENDE Taste), kannst du quasi festlegen, auf welcher Seite der Türknauf sein soll (ohne die Öffnungsrichtung zu ändern). Damit können zB auch richtige Doppeltüren gebaut werden (anders als in der Java Version, wo dafür immer eine Tür offen stehen musste).
-
Seile werden vmtl. spätestens ungefähr dann kommen, wenn auch Elektrizität ins Spiel kommt (da das Platzieren von Kabeln dann wohl ähnlich vonstatten gehen wird)
Vorher wird es aber auf jeden Fall wohl eine Seil-Textur geben, wodurch man Seile dann zumindest mit Blöcken nachbauen kann. Keine perfekte Lösung, aber vorläufig vll für viele Situationen ausreichend Auch wenn es schwierig ist es umzusetzen, ich finde dass das Spiel mehr Physik haben sollte. Dadurch wirkt es "beweglicher" und nicht so steif und ist durch die Physik moderner und auch noch interessanter.
Da stimme ich zu, aber das Problem wäre dabei die Performance
Bzw. die "Skalierbarkeit": Während ein paar Seile kein Problem wären, würden hunderte oder tausende physikalische Seile schon recht viel Rechenleistung erfordern. Selbst wenn "nur" die Takelage eines großen Segelschiffes aus physikalischen Seilen bestehen würde, könnte das schon Performanceprobleme bereiten...Wenn Spiele heutzutage physikalische Seile bieten (also Seile, die wirklich physikalisch sind, sprich mit ihrer Umgebung interagieren), dann sind es meist nur sehr wenige Seile, die gleichzeitig sichtbar bzw. "aktiv" sind...
Vor ca. 6 Jahren habe ich schon red51 gebeten Seile ins Spiel zu bringen aber NICHTS und so wird es auch bleiben, genau so das fließende Wasser. Aber was kam eine neue Version von Rising World und die gefällt mir GARNICHT, so das mußte mal raus.
Tut mir Leid zu hören, dass dir die neue Version nicht gefällt
Gibt es denn etwas konkretes, was dir nicht zusagt? Evtl. ist es ja etwas, was man ändern könnte. Erstelle aber vll einen eigenständigen Thread dafür, da es ja vmtl. nicht direkt mit Seilen zusammenhängt Ich möchte aber auch sagen, dass wir im Laufe der Zeit viele Vorschläge der Community umgesetzt haben. Leider hat es bislang nicht alles ins Spiel geschafft (darunter auch Seile), oft gibt es dafür aber auch organisatorische Gründe (zB wenn für Feature B erst Feature A umgesetzt werden muss, was natürlich die Umsetzung von Feature B insgesamt verzögert).
-
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).
-
Alle diese Dinge wären prädestiniert für das künftige Stromsystem
Oder anders gesagt: Alle momentanigen Einstellungen (an/aus, Helligkeit, Farbe) wird man auf jeden Fall über das Stromsystem steuern können (das beinhaltet auch automatisierte Schaltungen und Timer).Das einzige Problem ist nur, dass es wohl noch ein wenig dauert, bis Elektrizität reinkommt... wenn wir aber vorher eine andere spezifische Lösung einbauen (zB eine Schaltuhr explizit für Lampen), wäre das hinterher wohl doppelt gemoppelt sobald das Stromsystem da ist...
Vll wäre das aber zumindest für die Straßenlaterne ein denkbares Feature (wo so eine Zeitschaltung ja auch in Zukunft geeignet wäre), ähnlich wie die Einstellmöglichkeiten bei den Lichtern der Absperrung
-
Hehe, das wären auf jeden Fall nette Features
Also der Schneemann aus der Java-Version wird auf jeden Fall noch seinen Weg in die neue Version finden Schneebälle wären ebenfalls nicht verkehrt, schade, dass diese Dinge nicht passend zu Weihnachten reinkamen, aber ich packe es auf jeden Fall mal auf unsere Todo-Liste.
-
We also wish everyone a Merry Christmas and a Happy New Year!
-
Hehe, vielen Dank, vor allem auch vielen Dank für die netten Worte
Wir wünschen natürlich auch allen frohe Weihnachten und einen guten Rutsch ins neue Jahr!
-
Ist es möglich die Tür wie ein Bauteil zu behandeln und dann auch AltGr zuzulassen? Nicht das ich eine Trapezförmige Tür möchte aber wenn diese Änderung dann abgerundet wäre, nicht eckig, dann könnte das sogar ganz gut aussehen.
Das wäre wirklich praktisch, aber leider auch etwas schwierig umzusetzen
Während die Bauelemente ja eher relativ simple Formen haben, sind die Objekte meist deutlich komplexer aufgebaut... und auch die Textur wird bei Objekten anders projiziert als bei Bauelementen und würde bei so einer Aktion wohl unweigerlich verzerrt werden... selbst ein professionelles 3D Programm hätte Schwierigkeiten damit, so eine Funktion automatisiert bereitzustellen...Alternativ musst du uns für jede Tür eine oben abgerundete Variante bieten
Ich schätze das wäre wirklich die einzige Lösung
Allerdings reicht es wahrscheinlich auch, wenn in erster Linie die mittelalterlichen Türen eine abgerundete Variante hätten, oder?Für meine Bauweise im Kreativmodus wäre mir eine Funktionalität wichtiger, egal ob eingebaut, oder ob blockiert
Meinst du damit eine Funktion im Spiel, wodurch die Prüfung, ob eine Tür blockiert ist, ignoriert wird? Oder meinst du damit was anderes?
-
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?
