Posts by red51

Quote from Forscherdrang

Bei mir sieht das Ganze so aus

Ich glaube SonoBionda hat sich eher auf die allgemeinen Spieleinstellungen in der server.properties bzw. beim Client die config.properties (oder alternativ die Einstellungen im Options-Menü) bezogen

Was die Permissions angeht, dafür haben wir hier übrigens auch eine Übersicht über alle Einstellungen

Quote from SonoBionda

Wir haben auf dem Server die Zeit angehalten.

Achso, was die Zeit angeht, so ist serverseitig die Einstellung Settings_TimeDuration vorhanden (ist aber keine versteckte Option). Die besagt, wie lange (Echtzeit-Minuten) ein Ingame-Tag dauern soll. Wenn der Wert zB auf 60 gestellt wird, so dauert 1 Tag im Spiel 60 Minuten (also 1 Stunde). Wenn der Wert auf 0 gestellt wird, so wird die Zeit angehalten.

Clientseitig gibt es dafür in den Optionen (im Spiel) auch direkt eine Einstellung dafür. Das betrifft allerdings natürlich nur den Singleplayer, im Multiplayer wird das ausschließlich vom Server gehandhabt

Quote from SonoBionda

Zu bestimmten Uhrzeiten (die ja nach wie vor noch gewechselt werden können) kam es bei einigen Spielern zu extremen Flacker-Erscheinungen (bei mir eingeschlossen) ... dieses Flackern war nur zu unterbrechen, wenn man in eine andere Richtung geschaut hat (meist weg von der Sonne)

Hmm... hast du ggf. ein Video oder Screenshots o.ä. von diesem Flackern? Das klingt für mich eher nach einen Bug oder dergleichen Trat das nur im Multiplayer auf, oder auch im Singleplayer?

Quote from SonoBionda

Vielleicht sind das Zeiten an denen so ein SkyUpdate statt findet (und durch das Anhalten der Zeit, dann ununterbrochen)!? Gibt es dafür bestimmte Uhrzeiten die man dann vermeiden könnte?

Aber gut zu wissen, dass dieses "Problem" dann clientseitig ist.

Ich denke nicht, dass das Flackern normal ist... das Problem ist also nicht unbedingt auf diese Einstellungen zurückzuführen (auch wenn die Einstellungen durchaus einen Einfluss darauf haben können).

Quote from ArcticuKitsu

I'm sure auto-walk would be needed if the sprint bar keeps dropping to zero. Do whatever you desire to do, though I feel it should stay as is while simply giving the ability to auto-walk while having a normal walk, and then auto-run for everything else (with a limit).

If the "auto-walk" becomes an "auto-run" feature, the player would sprint until the bar drops to zero, then keeps walking until stamina is fully restored and then starts to sprint again etc

Quote from ArcticuKitsu

I guess I'm just spoiled by what I've seen in VRChat with you able to pop in and out of vehicle's driver seat. When you pop out you can see the GPS Screen on the side, or on the dash. Basically what Euro Truck Sim 2 or American Truck Sim has on the side, or even newly added worlds in VRChat.

Oh, I see, so you're more referring to modern ships? That would be a nice detail of course. Unfortunately we haven't started working on modern ships yet (and we don't have the funds to hire a 3d artist for that atm), but it's definitely something we will keep when implementing modern vessels

Quote from Deirdre

Ich fände das etwas heikel. Verwendet man als Spieler eine Blaupause ist davon auszugehen, dass diese selbst gebaut ist, und es gibt (noch) kein Copyright für solche Dinge

Es ist natürlich schon ein Argument, dass man bei so einer Funktion hinsichtlich des Copyrights nun nicht mehr sicher sein kann, dass der Ersteller der Blaupause auch tatsächlich der Rechteinhaber ist (wenn fremde Bilder verwendet werden) Derzeit kann man zwar auch nicht 100% davon ausgehen (könnte ja auch ein fremdes Bauwerk sein), aber die Lage würde sich bei eingebundenen Bildern sicherlich verschärfen...

Ich weiß allerdings nicht, ob sich für Serverbetreiber viel ändert, denn Bilder können die User ja so oder so bereits hochladen. Aber es bleibt auf jeden Fall ein heikles Thema... wir müssen uns dazu nochmal Gedanken machen

Quote from noci

Mir ist aufgefallen das ich eh, das zusätzliche Element Ein/Aus-Blenden Sollte, wenn ich das nur für ein Bestimmtes Menü brauche

Was bringt mein Menü im Kreismenü vom Bauen oder einem Anderen Plugin

Achso, naja, wir werden das trotzdem ändern (bzw. es ist schon geändert)

Quote from noci

Ich habe die Möglichkeit Entdeckt, den Lade Bildschirm zu über Springen.
Eigendlich eine schöne Idee, nur könnte da der Server das Letzte Wort haben?
Wenn ich Labyrinte oder Versteckte Hölen habe, könnte in der Zeit wo sich die Wellt aufbaut, das schon gesehen werden in welcher Richtung zu Suchen ist

Es gibt an sich nicht nur die Option, bewusst den Ladebildschirm zu überspringen, sondern das Spiel macht das auch dann automatisch, wenn das Laden aus irgendeinem Grund nicht weitergeht (aber die Grunddaten vom Server bereits erhalten wurden). Das Problem ist nämlich, dass wenn zB einzelne Chunks nicht geladen werden können, der Spieler sonst im Ladebildschirm hängen bleiben würde... was Ersteres angeht (also die Option zum Überspringen), so können wir dafür gerne auch eine serverseitige Einstellung einbauen, um das zu verhindern (würde dann mit dem nächsten Update "Settings_SkipLoadingAllowed" in der server.properties heißen) Letzteres (also das Überspringen des Ladens weil es nicht mehr vorwärts geht) würde aber dann vmtl. nicht davon betroffen sein (zumindest würde ich mich dabei etwas unwohl fühlen)

Quote from Deirdre

Eigentlich nicht. Ich habe einen Fensterrahmen kopiert, und wollte die Farbe ändern.

Ich habe einen Fensterrahmen im Inventar mit der ID 119 liegen, auch eingefärbt. Ich vermute mal, es handelt sich dabei um die ID 100 oder 101, aber wie ist das möglich?

Wenn beim Kopieren mit der mittleren Maustaste ein Block im Inventar liegt, geht man eigentlich davon aus, dass die ID darauf korrekt angezeigt wird.

Ich finde das jetzt etwas verwirrend.

Es muss aber eigentlich so sein Auch der von dir erwähnte Fensterrahmen kann auf regulärem Wege eigentlich nicht mit dieser ID hergestellt werden, d.h. er muss per Command gespawnt worden sein o.ä. Wenn zB eine Textur über den "edit" Befehl zugewiesen wird (oder ein Block per Command gespawnt wird), übernimmt das Spiel einfach die angegebene Textur-ID. Nicht-existente Texturen werden dann in der Spielwelt mit einer Standard-Holztextur dargestellt. Blöcke und Fensterrahmen können im Inventar ebenfalls korrekt mit nicht-existierenden Texturen dargestellt werden, da das Spiel die Icons dafür zur Laufzeit rendert (und dort dann ebenfalls die Standard-Holztextur zum Einsatz kommt). Lediglich bei der Texturauswahl (wie auf deinem Bild) fällt dann auf, dass es eine ungültige Textur-ID ist, da das Spiel dann kein fertiges Thumbnail für diese Textur findet.

Das kann auch schon vor längerer Zeit passiert sein. Es fällt meist nicht sofort auf, da das Spiel ja wie gesagt den Block mit einer Standard-Holztextur darstellt. Wenn du den Block dann zB mit der mittleren Maustaste kopierst, übernimmt er 1:1 die Textur (auch wenn sie ungültig ist). Wir könnten das aber zumindest insofern abändern, dass bei einer ungültigen ID entweder ein Hinweis angezeigt wird, oder in der Texturauswahl auch die Standard-Holztextur verwendet wird

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