Posts by red51

    Objekt-Texturen (also Texturen für Möbel, Türen usw) sind momentan leider fest auf max. 1024x1024 beschränkt... Bauelemente hingegen haben auf hohen Einstellungen eine Auflösung von 2048x2048, daher wird der Unterschied dann besonders sichtbar. Leider bot Unity bis vor kurzem keine Möglichkeit, sowas freier konfigurierbar zu gestalten (außer Texturen mehrfach in versch. Auflösungen auszuliefern - das machen wir zB bei Bauelementen oder Terrain, da diese Texturen an einer zentralen Stelle geladen werden).


    In dem konkreten Fall ist die Holztür aber tatsächlich etwas unscharf. Ich denke, dass wir diese spezielle Textur zumindest mit dem nächsten Update vergrößern können ;)

    Sowas ist auf jeden Fall über die Plugin API möglich :)


    Man müsste mal schauen, inwieweit man sowas sonst auch im Vanilla-Spiel umsetzen könnte :thinking:

    Langfristig waren mal sowas wie "Command Blöcke" oder "Befehlsblöcke" geplant, ähnlich wie in MC. Das könnte man natürlich auch mit Areas koppeln... aber das ist leider auch mit einigem Aufwand verbunden :(


    Eine simplifizierte Variante wäre sonst ggf. eine Option bei Areas, dass beim Betreten oder Verlassen bestimmte Konsolenbefehle durch den Client ausgelöst werden - das wäre flexibel genug, um das, was du dir vorstellst, umzusetzen (beim Betreten könnte dann zB gm 1 ausgeführt werden und beim Verlassen gm 0 sowie clearinventory) ^^

    Das Einbinden der Bilder ist tatsächlich etwas heikel... einerseits kann das Thema Copyright tatsächlich recht problematisch werden. Andererseits werden Blaupausen durch viele Bilder teilweise auch recht groß :thinking: Denn das Spiel speichert nicht die png/jpg Daten, sondern die Rohdaten, wie sie direkt zur GPU gesendet werden - und die sind meist deutlich größer als png/jpg Bilder (ca. 1 MB für ein 1024x1024 px Bild).


    Ich bin mir ehrlich gesagt noch nicht 100% sicher, wie wir damit am besten umgehen wollen. Vorteilhaft wäre sowas abgesehen von den oben genannten Problemen auf jeden Fall.

    Wann kann man damit in etwa rechnen? Weil ich bin gerade dabei eine Wendeltreppe zu bauen und das mit der Texturausrichtung an der Welt statt an der Rotation des Bauelementes sieht doof :( ebenfalls sieht es doof aus bei Fußböden wenn die Ausrichtung dann schräg anstatt parallel zu den Wänden verläuft

    Wir überarbeiten derzeit ein paar Spielmechaniken, auch ein paar Kleinigkeiten hinsichtlich des Bauens. Evtl. können wir fürs nächste eine Option anbieten, womit die Textur mit dem Bauteil ausgerichtet wird statt eine feste Ausrichtung zu haben :thinking: Wahrscheinlich wird das dann eine weitere Option im Baumenü sein (und ggf. eine globale Spieleinstellung, falls man das generell so haben möchte). Wir müssen aber erst noch ein paar andere Dinge dafür umsetzen (zB Radial-Menü überarbeiten, da es momentan noch nicht mehr Einträge darstellen kann usw), kann daher leider nicht versprechen, dass es mit dem nächsten Update kommt... wir versuchen es aber ^^

    Sorry, dass ich erst so spät antworte, das ist leider etwas untergegangen :/


    Es gibt leider keine Liste zu allen Einstellungen :| Die normale server.properties (oder beim Client die config.properties) Datei enthält standardmäßig alle Einstellungen, die es gibt. Es gibt aber noch ein paar versteckte Optionen, die nicht darin auftauchen. Normalerweise markieren wir eine Einstellung nur dann als "versteckt", wenn wir uns dabei entweder noch nicht sicher sind, ob wir das so beibehalten wollen, oder wenn es eine sehr spezifische technische Einstellung ist. Manchmal auch dann, wenn die Einstellung standardmäßig gar nicht benutzt werden soll (denn sobald sie einmal in der Config-Datei steht, kann das Spiel nicht mehr wissen, ob sie standardmäßig drin stand oder der Spieler sie bewusst eingetragen hat).


    Wir könnten ggf. mal eine Übersicht anfertigen über die Einstellungen, die es insgesamt gibt (inkl. der versteckten Einstellungen). Das ist allerdings mit Vorsicht zu genießen, da manche der Einstellungen technisch sehr spezifisch sind (und zB nur für Notfälle vorhanden sind, zB bei technischen Problemen o.ä).


    Gibt es denn eine bestimmte Einstellung, die du suchst oder dir wünschst? Eine Einstellung für "stillen Schatten" gibt es eigentlich nicht direkt (und wenn, dann schon gar nicht für den Server, da sowas nur clientseitig behandelt wird)... es gibt clientseitig (in der config.properties) lediglich die Einstellung "EnableLightEffects" (ist nicht versteckt), womit zB Lichter von Lagerfeuer & Co nicht mehr flackern. Zusätzlich gibt es fürs Sonnenlicht sonst noch die versteckte Option "SkyUpdateInterval", womit das Update-Interval für den Himmel (einschl. Sonne & Mond) definiert wird.

    Steht die Entwicklung, wie es in Trello steht, noch immer mit Fokus auf Mounts? Bin bisschen verwirrt, weil sich das schon seit Monaten nicht geändert hat :thinking:

    Die Trello Roadmap hinkt leider etwas hinterher :/ Wir wollen gerne ein paar Bilder posten, allerdings gibts momentan noch nicht so viel zu zeigen... ich werde die Roadmap aber so bald wie möglich aktualisieren ;)

    There is unfortunately no command to edit the surface, but with the next update, we can add a "surfaceoffset" and "surfacescale" command to set an arbitrary value for both the surface offset & scale ;)


    However, when changing the scale and offset without commands, the precision is determined by the "move precision" and "scale precision". More precisely, changing the surface offset (which is just done with the arrow keys [while surface edit mode is active ofc]) depends on the "move precision" (can be changed either in the radial menu [c], or by using the setp command). Changing the surface scale (which is done with the arrow keys + shift) depends on the "scale precision" (which is affected by the setl command).


    If the grid is active, it affects the surface offset automatically though (it then depends on the currently set grid size). It has no impact on the surface scale (this one solely depends on the setl setting), it it basically overrides the setp setting (move precision). So if the grid is active and you want to edit the surface offset, you either have to set a smaller grid size (with numpad +/-), or disable the grid (and set a lower value for the "move precision" (through the radial menu or with the "setp" command) :)


    But maybe we change that behaviour so the surface offset will ignore the grid anyway... IDK... it was originally added for moving the element manually (where it definitely makes sense to stick to the grid [as long as the grid is active]), but for the surface offset, it's probably debatable whether it's helpful :thinking:

    Grundsätzlich sind die Layer eine direkte Abbildung der Layer, die es im Spiel gibt. Mit ein paar Collidern kollidiert der Spieler generell nicht (zB TRIGGER, MISC, ITEM, DEBRIS, OBJECTINTERACTION usw).


    Bei einem Raycast kannst du grundsätzlich gegen jede Layer prüfen. Du kannst also durchaus zB die Layer TRIGGER benutzen und bei einem Raycast dann gegen diese Layer prüfen. Wichtig ist aber wie gesagt, dass du bei einem Raycast immer eine Bitmaske angibst (also in dem Fall Layer.getBitmask(Layer.TRIGGER);) ;)


    Kann der Trigger ohne Collider gemacht werden aber dennoch für den RayCast möglich sein?

    Leider unterstützt Unity selber erstmal nur einen Raycast innerhalb der Physik-Engine, welche wiederum zwingend Collider benötigt... die Java Version konnte zwar auch einen Mesh-genauen Raycast durchführen ohne dass es einen Collider gab, aber dabei würde eine Menge Garbage auf nativer Seite entstehen - und damit kann Unity aufgrund seines prähistorischen Garbage-Collectors leider nur sehr schlecht umgehen, anders als Java. Wir haben sowas aus dem Grund nie in der neuen Version umgesetzt und setzen daher selber auch nur auf Collider... :|


    Was aber mit dem nächsten Update hinzukommen wird: Support für "Ghost Collider" (in Unity über den "Trigger" Flag definiert - nicht zu verwechseln mit Layer.TRIGGER, die hat damit nix zutun). Damit kannst du einen Collider hinzufügen und mit diesem Flag sagen, dass der Spieler trotzdem immer durchlaufen können soll (egal welche Layer gesetzt ist). Der Collider hat dann nur noch bei Raycasts Relevanz (sowie Hit & Interaktion) ^^

    This happens if pivot snapping is active. The game resets the rotation after placing the element if pivot snapping is active, because otherwise it feels a bit awkward if the rotation is kept and you want to snap the element to the newly placed one, for example. It's a bit difficult to compare this with the Java version, because it had no pivot snapping (instead the modular snapping was more limited there and it wasn't even possible to rotate the element while it was snapped to another element).


    Having said that, there is indeed a bug: if manual placement mode is active, the game still resets the rotation (if pivot snapping is active). This is not supposed to happen, we will definitely fix that with the next update ;)


    A workaround for now (until this gets fixed with the next update) would be to set up the desired rotation first, then enable manual placement (right ctrl) and disable pivot snapping (enter). Now you can move the element manually and the game won't reset the rotation after placing the element.


    For the overall behaviour mentioned above (not about the manual placement), IDK if it's a good idea to disable it... it didn't really improve the situation IMHO. We could add an option for this, so we could wait for some feedback about it. If people prefer it, we could make that the new default behaviour.

    The biomes update will definitely introduce desert and snowy biomes ;) There had been some work on other biomes as well (volcanic biomes, jungles etc), but I can't say for sure if they will be part of the initial update... we really have to replace the Java version with the new version ASAP (and we're running out of time), so probably we'll focus on the most important biomes for now ^^

    Also die Dateipfade sind Koreckt, aber die Normal wird nicht benutz, jedenfalls ist keine wölbung drin zu erkennen :/
    Bei den Prefab's klappen die Normal einstellungen, Siehe eigenes Decal

    Das scheint ein Problem seitens des Spiels zu sein :wat: Genau genommen ist das Problem, dass das MaterialAsset unter der Haube den Standard HDRP Lit Shader verwendet. Die Normal-Map wird zwar zugewiesen, aber bei diesem Shader sind die Normal-Maps zusätzlich an zwei Keywords gekoppelt (also separate Shader-Varianten). Aus technischer Sicht ist sowas zwar einfach nur unnötig (nahezu 0 Performancegewinn und unnötig lange Build-Zeiten sowie höherer VRAM Verbrauch), wenn aber diese Keywords nicht explizit gesetzt werden, dann hat die Normal-Map in dem Fall keine Wirkung...


    Wenn im Editor mit dem HDRP Shader gearbeitet wird, dann werden diese Keywords automatisch gesetzt, sobald du eine Normal-Map zuweist. Das gilt aber leider nicht für programmatisch erstellte Materials, daher muss das dort manuell erfolgen.


    Auf jeden Fall danke für den Hinweis, das werden wir mit dem nächsten Update beheben :saint:


    Zum Platzieren der Objecte Setze ich sie auf GameObject.setLayer(Layer.getBitmask(Layer.IGNORE_RAYCAST));, das Klappt auch Super die Objecte Wandern nicht mehr in meine Richtung.

    Oh, die Art zum Zuweisen der Layer ist leider nicht ganz korrekt: Hier wird keine Bitmaske benötigt, stattdessen musst du die Layer direkt zuweisen, also gameObject.setLayer(Layer.IGNORE_RAYCAST);. Eine Bitmaske ist nur in bestimmten Fällen nötig, zB beim Raycast, denn da ist ja unter Umständen gewollt, dass ein Raycast mehrere Layer berücksichtigen soll (und diese mehreren Layer werden dann über die Bitmaske abgebildet)^^


    Die Layer.IGNORE_RAYCAST hat den Int-Wert 2, bei der Bitmaske wird im Grunde eine 1 in Binärdarstellung einfach nur um so viele Stellen nach links verschoben (also hier 1 << 2), was in dem Fall 4 ergibt (1 << 2 == 0b100 == 4). Und 4 ist der Int-Wert für Layer.WATER (d.h. in deinem Fall hast du effektiv Layer.WATER zugewiesen), daher denkt das Spiel, dass es sich dabei um Wasser handeln würde (und wenn das Spiel eine Wasseroberfläche oberhalb des Spieler entdeckt, denkt es, du wärest unter Wasser) :D

    You can either upload your own images (as mentioned by yahwho ), or alternatively just refer to external images (without having to re-upload them to the forums). In this case, just hit the image button above and enter the image url into the "Source" field. Leave the "Link" field blank (this is just relevant if you want to redirect to another address when clicking on the image), and the forum will show the image found at that address ;)


    Just make sure to use the url to the actual image file. To do that, rightclick on the image you want to share and choose the option that says "Copy image address" or "Copy link" or "Copy image location" (depending on the browser you're using).

    Mir ist aufgefallen, dass sich die Despawnzeit für Fußabdrücke & Einschusslöcher,

    welche man in den Grafikeinstellungen bestimmen kann, nicht Speichern lässt

    bzw. sie sich nach dem schließen des Einstellungsfensters,

    sofort wieder auf 5 Sekunden zurück setzt.

    Oh, danke für den Hinweis, das ist nicht gewollt 8| Das Problem tritt dann auf, wenn "Fußabdrücke" deaktiviert sind... das ist in den Optionen irreführend aufgelistet, denn die Einstellung bezieht sich nur auf die Fußabdrücke (wird aber auf 0 gesetzt, wenn Fußabdrücke deaktiviert sind)... das werden wir ändern :saint:


    Du kannst das Problem aber umgehen, indem du Fußabdrücke aktiviert lässt. Einschusslöcher werden aber leider noch nicht von dieser Einstellung beeinflusst, das muss leider noch manuell in der config.properties im Spielverzeichnis angepasst werden ("Game_DecalDespawnTime").


    Nun zu den Decal Postern.

    Allein schon die Idee dazu & auch die Umsetzung im Spiel ist absolut brillant.

    Ich liebe es <3

    Die Sache hat bloß einen Haken & zwar die Sichtweite.

    Selbst mit dem Befehl "distanceview" konnte ich nicht wirklich viel daran ändern.

    Danke für dein Feedback, das freut mich zu hören :) Was die Sichtweite angeht, leider haben Decals momentan noch eine feste maximale Sichtweite (ich glaube es sind 128 Blöcke). Das liegt daran, dass sie speziell gerendert werden und die Sichtweite daher einen größeren Einfluss auf die Performance hat als bei normalen Postern... wir müssen mal schauen, wie wir das am besten in eine separate Einstellung packen können. Mit dem nächsten Update können wir aber als temporäre Lösung zumindest die Sichtweite erstmal auf 512 oder 1024 hochschrauben (sodass es eig. in den meisten Situationen ausreichend sein sollte) ;)

    I want all of the stuff from java and plus new extra items

    Well, actually I'm not even sure if we're really going to port every single object from the Java version to the new version :thinking: We can't just use the old Java models anymore, so everything needs to be recreated from scratch (and the new version requires higher detailed models than the Java version)...


    However, basically the new version offers a lot of other new objects in return (while having a higher quality in general). Of course we still want to add more objects and items, but there were also a few objects in the Java version which weren't that important IMHO.


    Having said that, please let us know if you want to see specific objects from the Java version being ported to the new version. That would be helpful for us to set the right priorities ;)


    English

    I think what the survival fun of montan lacks most is the placement of different terrain such as sand, gravel or grass. It's the same with decorative plants and stones, this currently only works in creative mode.

    This is definitely still on our to-do list and will be ready this year :)


    Das alles und wie Mattuk56 sagte, noch vieles andere. Ich vermisse auch Pflanzen. Palmen gibt es nur eine einzige, das ist einfach viel zu wenig

    Die Java Version hatte ebenfalls nur 1 Palme...


    Diese Pflanzen haben wir schon und das gefällt mir ehrlich gesagt überhaupt nicht. Neue Biome sollten auch ein paat neue Pflanzen mit sich bringen, sonst sieht es genauso aus wie momentan, wenn man sein Terrain selbst gestaltet hat, sehr enttäuschend. ;(

    Wenn du die bisherige Pflanzenauswahl als so schrecklich empfindest, dann sehe ich leider für die nächste Zeit schwarz :(

    Mir ging es eigentlich um separate Skalierung von Höhe oder Breite, dass sich hier das komplette Schild propormrtional verändert, war mir klar.... Bei den Fensterrahmen kann das aber separat geändert werden

    Ich verstehe nicht, was du meinst. Du kannst Schilder beliebig skalieren und (anders als in der Java Version) auch große Schriftarten verwenden. Beim transparenten Schild ist eine Skalierung nicht notwendig, du kannst es auf 1x1 belassen und stattdessen einfach die Schriftart vergrößern. Um aber ein Verzerren der Schrift zu vermeiden, sorge einfach dafür, dass das Schild genauso breit wie hoch ist.


    Mir war wichtig, dass ich das Schriftbild beim durchsichtigen Schild auch in der Höhe strecken kann. aber dann nehme ich eben Poster. 😀

    Ich weiß leider nicht, was du meinst...


    Dass man den Farbcode nicht kopieren kann, ist anscheinend untergegangen. (Das Möglichkeit des Eintippens im Farbfeld funktioniert auch nicht wieder).

    Du kannst den Farbcode unten markieren und STRG + C drücken um ihn zu kopieren, anschließend bei einem anderen Schild wieder markieren und STRG + V drücken um ihn einzufügen.


    Wenn die transparenten Schilder verkleinert werden, kann man sie möglicherweise an einem Hochhaus nicht mehr sehen, das sollte aber meines Erachtens als Feature möglich sein.

    Du kannst die transparenten Schilder auch skalieren, stelle aber nur sicher (um zu vermeiden, dass die Schrift verzerrt wird), dass das Schild genauso breit wie hoch ist.


    Das man einzelne Bereiche mit solchen Codes bearbeiten kann, wusste ich auch noch nicht.

    Dachte das ist mehr was für Programmierer, aber gut zu wissen. Danke für die Übersicht :thumbup:

    Das ist tatsächlich nicht sehr intuitiv, vmtl. werden wir noch eine kleine "Formatierungshilfe" bieten (so wie das bspw. auch in den Steam-Foren der Fall ist) ^^


    Dennoch sollte für den Text standartmäßig eine Helle Farbe,

    am besten Weiß bei den Schildern eingestellt sein.

    Wir werden es mit dem nächsten Update so abändern, dass Schilder bei ihrer erstmaligen Bearbeitung einfach die zuletzt verwendeten Einstellungen benutzen ^^ D.h. wenn du 10 Schilder platzierst und dann bearbeitest, dann wird das 2. Schild die Einstellungen vom 1. Schild übernehmen, das 3. Schild die vom 2. Schild usw. Dann muss nur 1x die Schriftart, Größe und Farbe eingestellt werden ;)

    red51 Das gleiche Problem besteht bei den Formen, da werden auch nicht alle beim Suchen sofort angezeigt. erst wenn man noch einmal scrollt , dann ja.

    Das besteht bei allen Scrollelementen, die so aufgebaut sind.


    Könnte man den Apfelbaum nicht anders benennen. er wird ja bei den ausgewachsenen Bäumen schon aufgeführt. Das war bis vor kurzem nicht der Fall, da gab es den ausgewachsenen Baum nur einmal.

    Der Apfelbaum ohne Äpfel wird nur 1x aufgeführt (derzeit unter den jungen Bäumen). Wie gesagt, das werden wir beheben.

    Der 2. junge Apfelbaum ist der richtige Baum, sprich der korrekte "junge Baum". Der 1. junge Apfelbaum ist lediglich der Apfelbaum im "gepflückten" Zustand, sprich ohne Äpfel, nur die Bezeichnung ist falsch... das werden wir noch ändern ^^


    Was das Problem beim Scrollen angeht: Das ist leider ein nerviger Bug in Unitys UI Toolkit, der seit einigen Versionen nun anhält... im Scrollfeld wird zwar gescrollt (an der Position des Scrollbalken erkennbar), aber intern befindet sie sich immernoch am Anfang (daher sind die Felder schwarz und nicht mit Daten gefüllt, und beim anschließenden scrollen springt sie meist nach oben). Wir haben den Bug gemeldet, aber bis heute ist nichts passiert. Wir wollten erst abwarten, ob das evtl. in der neuen Unity-Version behoben wird, was aber leider nicht der Fall ist (wenn jemand meint, dass es bei RW langsam voran geht, dann hat diese Person noch nie Unity erlebt^^).


    Lange Rede, kurzer Sinn: Da das Problem in Unity nach nun mittlerweile ca. 6 Monaten immernoch nicht behoben ist, werden wir für das nächste Update einen Workaround einbauen, sprich das Problem sollte mit dem nächsten Update behoben sein ;) Workarounds sind zwar etwas doof, da sie den Code verkomplizieren und unnötig Arbeit kosten (und ggf. wieder für neue Probleme sorgen sobald Unity das Problem von sich aus behebt), aber in dem Fall ist offenbar kein Verlass auf Unity...

    Der Text auf den Schilder ist zu dunkel, ohne Hilflicht fast nicht lesbar

    Naja, die Java Version hatte als vorgegebene Farben quasi nur Neonfarben ^^ Das vordefinierte Rot in der Java Version hatte den Farbcode #FF0000, das vordefinierte Blau war #0000FF, das Grün war #00FF00, Gelb war #FFFF00, das Weiß war #FFFFFF usw. Wenn ich genau diese Farben in der neuen Version verwende, dann sind die Farben ebenfalls sehr hell:




    Selbst bei Dämmerung, also bei schlechteren Lichtverhältnissen, ist die Schrift dann gut zu lesen:



    Wie gesagt, das sind exakt die Farben, die die Java Version vorgegeben hat. Wenn zB eine dunklere Farbe gewählt wird, dann erscheint sie natürlich auch entsprechend dunkler.


    Den Sinn des Pfeils nach rechts -> konnte ich nicht ergründen. :thinking:

    Das ist, wie room6675 schon sagt, ein Art "Vorschau-Button": Die Texte der Schilder unterstützen sog. Rich Text, d.h. du kannst Teile der Schrift zB anders einfärben, durchstreichen, unterstreichen, hochstellen, die Größe anpassen usw. Wenn der Vorschau-Button dann gedrückt gehalten wird, kann man den fertigten Text betrachten (und ggf. mit den Schildrändern abstimmen).


    Beispiel: Wenn du zB Hallo <color=red>Welt</color> schreibst, dann wird "Welt" rot eingefärbt. Hier ein Beispiel verschiedener Formatierungen:


    Hier der Text dazu:

    Code
    Das ist ein <u>Beispiel</u>
    für <color=red>RichText</color>
    Gerne <color=yellow>gelb</color> oder <i>kursiv</i>
    oder <size=200%>Groß</size>...


    Langfristig können wir diese Sachen generell in den Texteditor integrieren, damit man quasi wie in einem klassischen Texteditor (wie Word) den Text formatieren kann, aber das war aus Zeitgründen leider bisher nicht möglich, daher geht das nur manuell.

    Wir werden dafür aber noch eine Hilfe bereitstellen sowie eine Übersicht über die unterstützten Rich Text Tags. Hier eine ganz grobe Übersicht (aber nicht alles davon ist unterstützt):



    Der Pfeil bzw. "Play" bzw. Vorschau-Button ist dann dazu da, die Formatierung anzuwenden, damit du eine Vorschau davon sehen kannst.


    Es wäre natürlich super, wenn man die kompletten Einstellungen kopieren & Einfügen könnte. ;)

    Ja, da stimme ich zu ^^ Entweder packen wir das direkt in den Texteditor rein, oder ggf. als Option im Radialmenü (wenn man das Schild anwählt) :thinking:


    Die transparenten Textposter werden leider Absurd gigantisch, wenn man bloß 1 kurze Zeile mit großer Schrift hat. :angry:

    Hmm... wenn du das transparente Schild auf normaler Größe belässt (also 1x1), dann sollte es anschließend (nach dem Setzen von Text) von der Größe her eigentlich nur so groß wie der Text selber sein :thinking: Wenn das Schild aber vorher skaliert wurde, dann wird es proportional mit dem Text vergrößert (was dazu führt, dass das eigentliche Schild u.U. viel größer als der Text ist)... das ist nicht optimal... das werden wir nochmal anpassen. Aber wie gesagt, bis dahin einfach die Größe des Schildes auf Standard belassen, dann sollte es eigentlich keine Probleme geben ;)


    Die Leuchtkraft der Schilder ist in der Unity nicht besonders ausgeprägt, schlecht zu sehen irgendwie.

    Wie oben gesagt, es kommt eigentlich nur auf die gewählte Farbe an... ggf. auch auf die Farbe des Schildes selbst, aber das kann ja - wie von Ludy erwähnt - auch geändert werden. Aber auf meinen geposteten Bildern oben kann ich eigentlich nicht unbedingt bestätigen, dass die Farben grundsätzlich zu dunkel wären :wat:


    Beim nächsten Beispiel kann man erkennen, dass das durchsichtige Schild zwar vergrößert werden kann, aber im Gegensatz zur selbst gestalteten Schrift nicht separat skaliert werden kann, sondern nur an an allen Enden gleichzeitig, sodass die Schrift dadurch etwas merkwürdig verzerrt aussieht.

    Generell ist es so: Beim durchsichtigen Schild orientiert sich die Textgröße an den Proportionen des Schildes. Wenn das Schild zB auf Standardgröße belassen wird (1x1), dann ist die Schrift frei von Verzerrung. Wenn das Schild proportional vergrößert/verkleinert wird (was nicht unbedingt nötig ist), also zB auf 2x2, 3x3 usw, dann sollte die Schrift ebenfalls nicht verzerrt werden. Wenn aber das Schild doppelt so breit wie hoch gemacht wird (zB 2x1), dann ist die resultierende Schrift in die Breite verzerrt. Wenn es höher als breit gemacht wird (zB 1x2), ist die Schrift in die Höhe skaliert.


    Das war so beabsichtigt, weil das der einzige Weg ist, verzerrten Text zu haben (was ja manchmal gewollt sein kann). Auf den anderen Schildern ist Text hingegen nie verzerrt. Wir könnten das ändern, aber dann sind verzerrte Texte nicht mehr möglich.


    Wie gesagt, verzerrte Schrift kannst du vermeiden, indem du Schilder immer gleich lang und breit belässt. Grundsätzlich kannst du Schilder auch auf der Größe 1x1 belassen.


    Vielleicht wäre es besser gewesen die JAVA-Version weiter zu entwickeln als auf eine komplett neue Engine umzusteigen. Was aus meiner persönlich besser geworden ist, ist das Bausystem mit den Neigungen und den Andockpunkten. Die Grafik hat sich zwar verbessert aber der Landschaftsgenerator war vorher auch besser, kaum halbwegs ebenes oder nur leicht welliges Gelände zum gescheiten Bauen.

    Es ist schade, dass du die neue Version unterm Strich schlechter findest als die Java Version... es kommt sporadisch tatsächlich immer wieder vereinzelt Kritik an nahezu sämtlichen Aspekten der neuen Version. Manche beschweren sich über das Bausystem, manche finden das Crafting schlechter, manche mögen die neuen Tiere nicht, manche empfinden Blaupausen als unbrauchbar, und vor einiger Zeit wurde sich sogar über die Grafik beschwert, dass diese in der Java Version deutlich besser gewesen sei...


    Ich versuche in solchen Fällen immer wieder die Kritikpunkte so gut es geht nachzuvollziehen, aber manchmal ist mir das leider einfach nicht möglich :wat: Es gibt zwar bei vielen Features der neuen Version noch Luft nach oben (so auch die Schilder oder Weltgenerierung), aber ich kann leider meistens nicht erkennen, dass die Features in der Java Version insgesamt besser gewesen seien... ich will nicht sagen, dass die Java Version ein schlechtes Spiel wäre, aber ich muss ganz ehrlich sagen, dass es mir persönlich etwas schwer fällt, sie heute noch zu spielen (angesichts der neuen Version)...


    Wenn es um die Schilder geht, so sind diese wie gesagt noch nicht perfekt und es gibt definitiv Luft nach oben, aber ich hätte gedacht, die Schilder der neuen Version bieten bereits wesentlich mehr Möglichkeiten als die Java Version, da der Text nun frei formatiert werden kann sowie Schriftart und -größe angepasst werden können. In der Java Version gab es 2-4 feste Zeilen, eine handvoll vordefinierter Farben, eine feste Textgröße und einen einheitlichen Font.


    Die Sache ist, wir stecken unheimlich viel Zeit in die Überarbeitung diverser Features des Spiels rein. Hätten wir alle Features 1:1 aus der Java Version portiert, dann hätte die ganze Umstellung wesentlich weniger lange gedauert, sprich die Portierung wäre deutlich schneller vonstatten gegangen. Denn der meiste Zeitaufwand fließt in die Überarbeitung bzw. Neuimplementation der Features.


    Bitte nicht falsch verstehen: Es gibt in diversen Punkten Probleme und auch Bugs, und die müssen auch so angesprochen werden. Es gibt natürlich manchmal auch die Fälle von Feedback, in denen ein gesamtes Feature quasi als "schlecht" abgestempelt wird, obwohl sich die Person evtl. in Wirklichkeit nur über besimmte Kleinigkeiten oder Bugs ärgert. Uns fehlt leider vielfach die Zeit, eigentlich stehen wir nur noch im Dauerstress, denn sämtliche Updates der jüngsten Vergangenheit richten sich "nur" an die Bestandscommunity (da auf der Steam-Page ja noch die Java-Version beworben wird), was zB keinerlei positiven Einfluss auf unsere Verkäufe hat. Entsprechend beeilen wir uns so gut es geht, wodurch bei manchen Features auch ein paar Funktionen auf der Strecke bleiben (oder sich ein paar Bugs mehr einschleichen).

    Wenn das Feedback nun aber besagt, dass die überarbeiteten Features insgesamt schlechter als in der Java Version sind, dann ist in unserem Plan offensichtlich was gewaltig schief gelaufen :silenced: Da stellt man sich schon die Frage, warum wir überhaupt daran weiterarbeiten :dizzy:

    Es flackern übereinandergelegte Poster, leider, da das bei Pflanzenbildern, wie früher beim Efeu, nicht zu vermeiden ist, aber wie in meinem Fall, andere Bilder auch. Bei der Badematte vermute ist, dass darin zu viel Weißanteil vorherrscht. Habe dir auch von einem Fußboden Material per Pn geschickt. (Habe im Moment kein anderes Poster im Kopf, aber das Flackern geschieht öfter mal, auch wenn nichts übereinander liegt).

    Das "weiße Flackern" liegt im Falle der Badematte daran, dass der durchsichtige Teil im Bild tatsächlich weiß ist (und nicht den Farbton der Matte hat). Ich habe dir mal das gleiche Bild gesendet, allerdings nicht mit weißem durchsichtigen Hintergrund, sondern mit farbigem Hintergrund. In der Bilderanzeige von Windows sieht man zwar keinen Unterscheid, aber im Spiel ist hier kein weißer Rand oder weißer Bereich mehr zu sehen.


    Wir schauen aber mal, dass wir das vll schon vom Spiel aus abfangen :thinking:


    Was das Flackern selber angeht: Es scheint ein bisschen auf die Position des Posters anzukommen... in manchen Situationen funktioniert es besser, in manchen schlechter. Das ist etwas, was wir auf jeden Fall noch verbessern können ^^ Ich packe es mal auf unsere Liste.


    ...Wäre es möglich, per Kurzbefehl alle Poster auf einmal zu glätten? Ich habe es nicht so mit Ölgemälden in modernen Wohnungen und das dauernde Tippen von flat...., dauert zu lang. :D

    Vll wäre ein allgemeiner "editall" Befehl praktisch, in welchem man zB alle Objekte eines bestimmten Typs auf einmal bearbeiten kann... ich packe das mal auf unsere Liste ;)


    Könnte mann das nicht, beim Platzieren für jedes Poster, mit einem Häckchen das Variabel halten, oder läuft das Global :saint:

    Grundsätzlich wäre das sinnvoll, allerdings wäre es vmtl. auch generell nicht verkehrt, wenn Bilder, die teilweise durchsichtig sind - wie zB das Bild von TheKing - generell auf der Rückseite gespiegelt sind ^^