Posts by red51

Quote from ArcticuKitsu

Auto-Walking & Running:

We can include that with the next update Not sure though if "auto-walk" is still needed then, maybe it's sufficient if the player just always sprints?

Quote from ArcticuKitsu

Horse Auto-Run:

The "auto-run" feature will also work for horses

Quote from ArcticuKitsu

Wool & Yarn Automation:

Unfortunately we have no short-term solution for that, so I can't say much about that yet

Quote from ArcticuKitsu

Boats & Vehicles:

Hmm... I'm not sure I understood this correctly Basically the player just has to make sure he has a map in his inventory, then he will be able to access it from the boat?

It just so happens that the next update will provide a proper Item API in general This means it will distinguish between different item types (unlike the old API, which used different "Attribute" types for an item - that term was a bit confusing). So with the next update, it would look like this:

//Get equipped item
Item item = player.getEquippedItem();

//Check if item is a construction element
if (item instanceof Item.ConstructionItem construction) {
    System.out.println(construction.getConstructionName());  // <- prints "block", for example
}

//Else check if item is an object
else if (item instanceof Item.ObjectItem object){
    System.out.println(object.getObjectName());  // <- prints "workbench", for example
}

//Else check if item is a garment
else if (item instanceof Item.ClothingItem clothing){
    System.out.println(clothing.getClothingName());  // <- prints "mininghelmet", for example
}

//Else check if item is a blueprint
else if (item instanceof Item.BlueprintItem blueprint){
    System.out.println(blueprint.getBlueprintName());  // <- prints "My summer house", for example
}

These item subclasses will also provide specific access (e.g. to get the definition file etc). In case of blueprint items, you will be able to access various information about the blueprint (like number of construction elements it contains, creator name etc)

-----

However, if you're working with the PlayerPlaceBlueprintEvent, you can already check the amount of elements the blueprint contains: It provides the methods "getConstructionCount()" (to get the number of construction elements in the blueprint), "getObjectCount()" (to get the number of objects like furniture) and "getPlantCount()" (the number of vegetation). If these values exceed your threshold, you can cancel the event

Hehe, thanks for your feedback, I'm happy to hear you like it!

Quote from Ozorvals

Last small question: How many digits after the decimal point are taken into account in the parameters? 4? I do calculations to obtain the values of some parameters, this is to determine the correct rounding.

There is no hard-coded limit, but the game works with 32 bit floating point values, so it only has roughly 6-8 significant digits. If the precision value is too small (i.e using more than 4 digits after the decimal point), it may not work properly.

So in general, I would recommend to stick to precision values with up to 4 digits after the decimal point But if there are scenarios where a higher precision is required, you can still try it though (depending on the world position, element size etc, it may or may not work).

Quote from Deirdre

Please make the red font customizable, I can hardly read it myself. The yellow font is very nice.

Yes, probably it's better to use yellow text here In the meantime, you can change that manually in the language file btw: To do that, go to the /Data/StreamingAssets/Languages folder and open the en.json with a text editor (or the de.json if you want to update the German language file). Seach for the term <color=red>Surface scale (or in the German file <color=red>Oberflächengröße) and replace color=red with color=yellow, then save the file

The idea is to have a proper and worthy replacement for the Java version Some of the content in the Java version wasn't that important IMHO, so we try to focus on more important things atm... but even when the most important features are finally implemented, is it really better if we focus on some of the smaller stuff of the Java version (e.g. curtains, banisters, a rolling pin etc) instead of working on more useful features like the ability to place items like tools & weapons in the world, for example?

In fact we're running out of money (because all updates for the new version were mainly targeted at the existing community and this barely results in any new sales), so we finally have to bring the new version into a state where it could be considered "fully playable" (at least to the same degree as the Java version). The current situation is quite problematic, because we barely sell any copies of the game (considering the store page on Steam still advertises the old and dusty Java version). We all agree that having more plants, objects or new building materials would be really nice (and these things are indeed on our to-do list), but first we have to focus on the key features (biomes, caves, hostiles etc).

Once the Java version had been replaced with the new version, we can finally focus on adding smaller features and other things as well

Quote from Mattuk56

ability to put posters on walls [...] things like flowing water

Posters were added with the latest update In fact they're even more versatile compared to the Java version, since you can now paint posters, and there is also a powerful new "decal" poster type available (which adapts to uneven surfaces, like on this screenshot)^^

Flowing water is also in the game already (it was added with the world generation update back then)

Das ist an sich kein direkter Bug, das ist tatsächlich erstmal normal Radial-Menüs werden dynamisch erzeugt und dann zur Layer hinzugefügt (und nach dem Ausblenden wieder gelöscht), daher ist die Layer selber immer sichtbar. "screen" ist im Grunde die Layer selbst, während "apiElement" eine Art Duplikat davon ist, was automatisch jede Layer hat. Die meisten API Elemente, die auf regulärem (also nicht über Internals) Wege zur UI hinzugefügt werden, landen dort. Das ist dafür da, damit es keine Probleme zw. API Elementen und normalen UI Elementen gibt.

Es spricht aber nichts dagegen, dass die RadialMenuLayer selbst jeweils ein- und ausgeblendet wird, wenn ein Radial-Menü erscheint oder geschlossen wird. Dann werden die selbsterstellten Elemente immerhin auch mit ein- und ausgeblendet. Das können wir mit dem nächsten Update ändern

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)