Posts by red51

Das Problem ist, dass die Vorschau sehr großer Bauteile marginal größer angezeigt wird, als sie wirklich sind. Auf deinem Bild ist das Bauteil 14 Blöcke lang, dadurch kommt leider diese sichtbare Abweichung zwischen Vorschau und finalem Bauteil zustande

Der Grund, warum die Vorschau marginal größer ist, liegt darin, um Flackern zwischen Vorschau und Block zu vermeiden. Beim normalen Bauen ist das meist auch kein Problem, nur bei recht großen Elementen (wenn trotzdem präzise damit gebaut wird) wird das dann sichtbar.

Wir wollten das generell mal ändern, aber aus Zeitgründen haben wir das leider bisher nach hinten geschoben (und zugegebenermaßen ist das in der letzten Zeit auch eher in den Hintergrund gerückt)... mit dem nächsten Update sollte das Problem aber behoben sein

Was minimalen Versatz zwischen bereits platzierten Bauteilen angeht: In ungünstigen Fällen kann das tatsächlich auftreten. Das liegt daran, dass die Größe jedes Bauteils minimal verändert wird, damit kein (oder kaum) Flackern bei überlappenden Teilen auftritt. In den meisten Fällen sollten diese Unterschiede nicht sichtbar sein, kann aber manchmal passieren. Mit dem nächsten Update wird das etwas verbessert, sodass diese Unterschiede noch seltener auffallen sollten. Für Extremfälle werden wir ein weiteres Attribut DisableOffset für Bauteile einbauen (kann dann mit dem Befehl edit attribute DisableOffset gesetzt werden), womit dieses Verhalten für das Bauteil ausgeschaltet werden kann.

Eine Textur mit der ID 119 existiert nicht, daher kann das Spiel sie nicht anzeigen. Wahrscheinlich wurde die ID per Konsolenbefehl (zB dem "edit texture" Befehl) einem Block zugewiesen?

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

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ß 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.

Quote from room6675

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 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.

Quote from Yaromid

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

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

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);)

Quote from noci

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)

Quote from Forscherdrang

Ändert sich dabei auch die Kompassnadel & die Ausrichtung der Bauelemente bzw. das Raster

Nein, das betrifft nur die Position der Sonne und des Mondes

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

Quote from noci

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 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

Quote from noci

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)

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).

Quote from Forscherdrang

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 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

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").

Quote from Forscherdrang

Nun zu den Decal Postern.

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

Ich liebe es

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)

Quote from Mattuk56

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 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

Quote from Forscherdrang

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

Quote from Deirdre

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...

Quote from Deirdre

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

Quote from Deirdre

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.

Quote from Deirdre

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...

Quote from Deirdre

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.

Quote from Deirdre

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.

Quote from Forscherdrang

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

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)

Quote from Forscherdrang

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

Quote from Deirdre

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.

Quote from Deirdre

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...