Posts by red51

Hey, DLSS (on NVIDIA cards) and FSR (mostly for AMD cards) will indeed improve the performance, but only if you're currently gpu-bound (which is likely on 4K). To get a rough idea of the performance improvement by these techniques, you could go to the graphics settings and change the "Resolution scale" slider to a lower value, e.g. 60% (the game will look ugly then, but this is probably roughly the fps gain you could expect from DLSS/FSR)

However, it's weird that the weather causes such an FPS drop in your case The weather effects (rain and snow) spawn quite a lot of particles, but the particles are calculated and handled on the GPU, which makes them very efficient. The wind, on the other hand, always has a fixed cost, i.e. it doesn't matter if it's good or bad weather, so I don't think that's causing this issue Maybe it could be something else (maybe a sound issue, consuming too much CPU power etc)..

Do you also experience the FPS drop if you create a new world, then change the weather by typing weather heavyrain 1 or weather heavysnow 1 or weather storm 1 into console?

Maybe you could send us a report (so we can make sure there isn't something else causing this issue)? To do that, wait until you run into the frame rate issues, then open the console (key ~ or `) and type "report", maybe add some information like "bad weather = fps drop", then send the report

I agree that minigames and interactive objects are always a great thing! It's definitely our intention to add the piano to the new version, actually we've already done some preparations for it, so it should be ready soon

Back then for the Java version, it was also our intention to add some other games like chess, card games and smaller video games (similar to games like space invaders, pong etc). In multiplayer, you could even play these games with other people. We've done a few preparations for that, but unfortunately it never made it into the game... however, we still want to add that to the new version (but it has a lower priority at the moment)

I very much like the metal detecting idea It's definitely on our to-do list. The whittling suggestion also sounds interesting, we just have to think about how this could be implemented. We also have to think about the whistle idea... it sounds interesting, but it could be a bit overwhelming for the player if he gets too many "whistle-options"

Die Beschreibungen greifen tatsächlich schon etwas vor und enthalten Sachen, die teilweise noch nicht möglich sind Die Tränke (oder auch andere Behälter wie das offene Fass) wird man dann mit Wasser füllen können, wenn Eimer ins Spiel kommen

Das wird aber leider noch nicht mit dem NPC Update passieren... Tiere haben auch noch kein Nahrungs-/Trinkbedürfnis - sowas ist zwar in Zukunft geplant, aber momentan leider noch nicht in greifbarer Nähe^^

Es ist auf jeden Fall noch auf unserer Todo-Liste, dass der Radius der Lichtquellen beim Skalieren des Lichtes angepasst wird

Quote from Deirdre

red51 Bitte die Lichtintensität für Laternen, Straßenlampen, Wandlaternen etc. ebenfalls anpassbar machen

Die einzige Lichtquelle in dieser Auflistung, in der die Lichtstärke nicht einstellbar ist, ist die Laterne... für die könnte man das theoretisch umsetzen, wäre ja nicht ganz unrealistisch Bei anderen Lichtquellen wie Fackeln oder Kerzen würde ich das aber eigentlich nur ungerne einbauen

Quote from Deirdre

Desweiteren wird die dezimierte Helligkeit bei den Lichtblöcken, ID 800, beim Anmalen wieder auf 100% gesetzt. Die Steine sollen nur farblich geändert werden und keine Helligkeitsänderung vorgenommen werden.

Das wird mit dem nächsten Update behoben

Das kommende NPC-Update wird sich natürlich in erster Linie auf NPCs bzw. Tiere konzentrieren, da das momentan noch eines der am dringendsten benötigten Features ist. Wie aber bei fast jedem Update wird es auch ein paar andere Neuerungen und neue Items oder Objekte geben, und natürlich auch Bugfixes und diverse andere Änderungen

Unsere Hauptpriorität ist insgesamt, den Zustand zu erreichen, dass das Spiel die Java Version auf der Storepage ersetzen kann. Tiere sind dafür zB unabdingbar, während aber neue Texturen dafür nicht zwingend erforderlich sind (daher rutscht sowas in der Priorität leider automatisch etwas nach hinten). Zwar kann man generell sagen, dass "mehr Content" immer gut ist, nur leider werden zB "mehr Texturen" von vielen Spielern nicht automatisch als "mehr Content" angesehen, Tiere aber hingegen durchaus häufiger als "Content" angesehen wird - wobei das sowieso immer im Auge des Betrachters liegt, denn es gibt auch einige Leute, die der Meinung sind, die Java Version hätte Null Content (obwohl es ganz objektiv betrachtet relativ viele Texturen, Objekte, Items, NPCs und auch Features gab)...

Nach dem NPC Update werden wir uns aber höchstwahrscheinlich an Poster und Schilder setzen (was vor allem auch im Bau-Bereich Relevanz haben dürfte), und evtl. können wir in dem Zusammenhang auch die neuen Blockformen sowie Türen reinbringen, die wir zwischenzeitlich vorbereitet haben

Quote from Taiskorgon

2. Auf image-2 möchte ich ein Kantholz auf zwei Rundhölzer legen. Diese haben eine unterschiedliche Höhe und stehen etwas versetzt zueinander. Hier fände ich es toll, wenn man zwei Andockpunkte an den bereits platzierten Objekten wählen könnte und das zu platzierende Objekt relativ dieser Punkte ausgerichtet wird. Momentan behelfe ich mir so, dass ich erst das Kantholz an der Decke platziere und anschließend die Rundhölzer daran andocke.

Ich habe leider nicht ganz verstanden, wie du das genau meinst Ist das etwas, was sich denn grundsätzlich mit dem manuellen Pivot-Modus beheben lässt?

Quote from Taiskorgon

3. Auf image-3 sieht man, dass die Rundhölzer in der Luft hängen. Bei dem linken Rundholz kann man sich bücken und noch ein weiteres Rundholz darunter platzieren. Bei dem anderen muss man das Rundholz um 180° drehen. Auch bei Arbeiten über Kopf an Höhlendecken oder in Gebäuden hat man immer wieder Punkte, die nicht erreichbar sind. Vielleicht könnte man auch die nicht sichtbaren Andockpunkt anzeigen? Also quasi durch das bereits platzierte Objekt hindurch greifen.

Schwierig... das Problem ist leider, dass wenn Pivots auch "durch Wände hindurch" anwählbar sind, dass dies schnell irritierend wird bei komplexeren Bauwerken (also wenn viele Bauteile verbaut sind). Wir hatten das schonmal getestet, da stehen dann plötzlich so viele Pivots zur Verfügung, dass es mehr schadet als hilft Bei wenigen Bauteilen oder in konkreten Fällen mag das aber hilfreich sein... wir müssen mal überlegen, ob man das evtl. als ein-/ausschaltbare Option anbieten kann, oder ob Pivots durch Wände hindurch ggf. nur in definierten Fällen anwählbar sein sollen (zB dass nur Terrain ignoriert wird - das würde in deinem Fall ja zB helfen)

Quote from Taiskorgon

6. Das Schema hinter Rotieren und Bewegen habe ich auch noch nicht ganz verstanden. Es kommt vor (könnte mit der Blickrichtung zusammen hängen), dass sowohl die Cursor- als auch die Bild-Tasten um die X- oder Y-Achse rotieren und eine Rotation um die Z-Achse nicht möglich ist. Gleiches gilt für das Bewegen/Sakalieren eines zu platzierenden Objekts. Es kommt vor, dass man das Objekt nur in zwei Richtungen bewegen kann und die Bild-Tasten das Objekt horizontal verschieben/skalieren (anstatt wie erwartet vertikal).

Ja, das Skalieren und auch das Verschieben hängt tatsächlich mit der Blickrichtung zusammen... ich weiß nicht, ob das sinnvoll ist oder nicht, da das manchmal tatsächlich irritierend sein kann. Vll ist das auch etwas, was wir wieder entfernen

Quote from Taiskorgon

5. Wenn man "manuelles Platzieren" aktiviert, scheint es nicht möglich zu sein, ein Objekt zu rotieren.

Quote from SonoBionda

Das stört mich auch wirklich sehr; es ergibt überhaupt keinen Sinn warum das nicht möglich ist, zumal man zum Skalieren auch bei festgesetzten Objekten trotzdem noch die Shift Taste benutzen muss.

Also, warum nicht ohne Shift festgesetzte Objekte routieren ? edit: hm, ja, wahrscheinlich weil es ums Platzieren und nicht ums Drehen geht ... aber selbst wenn ich eine Taste für "Drehen/halten" vergebe, funktioniert die Kombi auch nicht zum Drehen.

Das funktioniert aber eigentlich, ging sogar auch in der Java Version Ist leider nicht sehr intuitiv: Wenn das manuelle Platzieren aktiv ist und man dann STRG gedrückt hält, kann man das Bauteil mit den Pfeiltasten drehen

Die Tastenbelegung für "Drehen" in den Einstellungen ist leider momentan nicht verdrahtet... das war ursprünglich in erster Linie für Gamepads gedacht und hat dort in den Optionen eigentlich nichts zu suchen... vll macht es aber Sinn, die trotzdem dort zu lassen, sodass man eine zweite Taste fürs Drehen belegen kann

Quote from SonoBionda

Aber ich habe auch so langsam den Verdacht, dass das Ändern einzelner Keys alles durcheinander bringt.

Normalerweise sollte das eigentlich kein Problem darstellen. Heikel wird es nur, wenn mehrere Funktionen auf dieselbe Taste gelegt werden - das Spiel warnt in dem Fall leider (noch) nicht. Das wird sich aber noch ändern

Quote from SonoBionda

Aber verstehen kann ich das dennoch nicht; wenn mir der automatisch ausgesuchte Pivot nicht gefällt, könnte er doch trotzdem mit Punkt/Komma weiter springen

Das müssten wir mal ausprobieren, also wie gut sowas in der Praxis funktioniert. Es könnte manchmal irritierend sein, vor allem wenn man versehentlich vorher einen anderen Pivot gewählt hat. So wie auch das manuelle Platzieren irritierend sein kann... einige Spieler haben das Andocken bisher als komplett unbrauchbar empfunden, weil sie versehentlich den manuellen Andockmodus aktiviert haben und dann der Auffassung waren, dass das Bauteil immer nur mit einem festen Punkt irgendwo andockt (was - ohne den Pivot zu ändern - tatsächlich oft nutzlos ist)

Quote from Taiskorgon

Wäre es dann nicht sinnvoll, Baumstammstücke als "4xBaumstammstücke" im Inventar zu stapeln, anstatt "2xBaumstammstücke (Hickory)" und "2xBaumstammstücke (hastenichjesehen)"?

Wir könnten grundsätzlich alle Baustammstücke zu einem einzelnen, generischen Baummstammtyp zusammenfügen Das Problem ist nur, dass die einzelnen Baumstammtypen optisch ja unterschiedlich aussehen (der Birkenstamm sieht ja zB ganz anders aus als der vom Hickory-Baum). Wenn Bäume also nun einen einzelnen, generischen Baumstammtyp droppen, sähe das beim Kleinhauen des Baumstammes etwas komisch aus (wenn zB aus dem Birkenstamm plötzlich normale Holzstücke mit anderer Rinde herauskommen). Es gibt zwar viele Spiele, die das so machen (wo die Holzstücke optisch nicht zum Baumstamm passen), aber ich weiß leider nicht, ob das wirklich so optimal ist

Es stand auch schonmal die Überlegung im Raum, die Baumstammstücke zu entfernen, sodass Bäume direkt "Holz" droppen (welches gar nicht erst weiterverarbeitet werden muss). Diese Art der Simplifizierung gibts ja auch in anderen Spielen. Wir hatten uns letztenendes aber dann dagegen entschieden, um das Spiel nicht zu sehr aufzuweichen

Sorry für meine späte Antwort! Grundsätzlich können Blaupausen aber an Pivots andocken, nur ab einer bestimmten Größe verhindert das Spiel das (weil das meist nicht gut funktioniert). Man kann es aber für alle Blaupausen erzwingen, indem man in der config.properties Datei im Spielverzeichnis (im "_New Version" Unterordner) den Eintrag Game_BlueprintsAlwaysAllowPivots=True hinzufügt

Es scheint aber so, dass die Pivots für manche Blaupausen teilweise generell nicht gut funktionieren... das müssen wir uns nochmal genauer anschauen

The "ConnectToOtherServer()" method is on our to-do list, probably it will be available for the first API release

About the db-locked errors, the Java version SQLite connector was unfortunately using single-threaded mode, so if more than one thread accessed the database concurrently, there was a chance that this could end up in a db-locked error. The new version, on the other hand, runs SQLite in serialized mode, so it's fully thread safe^^

However, this error could also happen if a Statement / PreparedStatement or ResultSet was not closed after using it, for example (unless they were used in a try-with-resources-block, which closes them automatically). But this would also cause trouble in MySQL.

If you run into any db-locked errors or any other db-related issues in general (in SQLite or MySQL) with the new version, please let me know

The API unfortunately has no built-in methods for that, but there are various ways to sync data between two servers. If both servers are running on the same machine, you could create an SQLite database to read and write the data from both servers (this could be done whenever the player connects and disconnects). In WAL-mode, it should be possible to have two connections which can read and write concurrently.

Alternatively you could create a read-only connection to the world database (where the inventories are stored) and retrieve the inventory data from it (i.e. the quest server could read the inventory data from the main server when the player connects, and if you want to sync the inventory back, the main server could read the inventory from the quest server when the player connects there accordingly).

If the servers are running on different machines, you could use a MySQL server instead. Alternatively you could set up a webserver through Java: Java has a built-in HttpServer, and the API has methods to send http requests.

Sending a player to another server, however, isn't possible yet... But we could add a "ConnectToOtherServer()" method for the player It would first show a message box to the player where he has to confirm the server change, then he'll be disconnected from the server and reconnected to the other server.

Quote from Deirdre

Unter Wasser ist es schwierig das Terrain zu bearbeiten, da die Sicht immer schlechter wird, je tiefer getaucht wird. Desweiteren ist ein Vorwärtskommen fast unmöglich, da

das Wasser das Bewegen sehr schwierig macht. Das mag im Survival und beim Tauchen absolut in Ordnung sein, aber spezifisch beim Creativmode bzw.

für die Terrainbearbeitung bitte Alternative hinzufügen.

Du kannst dich im Flugmodus mit normaler Geschwindigkeit unter Wasser fortbewegen Was die Sicht angeht, wenn es zu dunkel wird, kannst du evtl. das Licht im Creative-Modus (L) aktivieren. Ansonsten fällt mir da leider momentan auch keine bessere Lösung für ein...

Quote from Deirdre

Das Aufziehen von Markierungsrahmen für Terrainbearbeitung und zum Löschen von großen Baugebieten dauert sehr lange. Eine andere Geschwindigkeit einzustellen,

bringt nichts, da das Werkzeug dafür nicht ausgelegt ist. Ein zusätzliches Feature wäre wünschenswert.

Wie meinst du das genau?

Actually light is supposed to pass through glass, but unfortunately fire and flames are not visible if they're behind a glass pane... this is a bug which will be fixed with the next update

"Postponed" indeed just means we're currently not working on it and we have no ETA for it yet - but it's still planned (otherwise we would remove it from the roadmap)

For Moveable Structures, we'll probably start working on them once the most important features are implemented (and the new version has finally replaced the Java version)

Unfortunately you can't place terrain materials yet But that's on our to-do list

Currently the only way to place terrain in the new version is to use the creative mode terrain tools: To do that, open the console (key ~ or `) and type "gm 1", then hit F5 to enable the terrain tools

Sorry für die späte Antwort!

Quote from Deirdre

Das Anmalen bzw. Übermalen von gewissen Terrain-Strukturen funktioniert nicht richtig. Über Gras malen war schon immer sowieo sehr schwierig, war in der Java-Version auch schon so.

Das ist leider momentan noch technisch bedingt Das hängt mit der Reihenfolge zusammen, wie die verschiedenen Materialien vom Shader zusammengesetzt werden... bei manchen Texturen ist es daher notwendig, einen größeren Bereich zu bemalen damit man eine Wirkung sieht.

Wir möchten dafür mittelfristig auf jeden Fall noch eine Lösung finden...

Quote from Smoka

Mir ist da noch was aufgefallen mit dem Licht, von Lampen.

Das Licht scheint durch bauelemente,wenn man in einer Bestimmte entfernung ist.

Es gibt in den Grafikoptionen eine separate Einstellung für die "Schatten Sichtweite" - Schatten werden nur bis zu dieser Entfernung gerendert Leider kann diese Einstellung höchstens auf 300 gesetzt werden, aber vll reicht es in dem Fall? Ansonsten kann mit dem Konsolenbefehl "setoption ShadowDistance" auch ein höherer Wert gesetzt werden (mit "saveoptions" wird diese Änderung dauerhaft gespeichert).

Quote from Dark Megatron

Die Tiermodelle sehen echt gut aus.

Vielen Dank!

Quote from Deirdre

So weit ich das auf dem Handybildchen erkennen konnte, ja. Ich vermisse aber den Esel, Regenwürmer brauche ich nicht unbedingt.

Das erste NPC Update wird noch nicht alle Tiere ins Spiel bringen, die insgesamt geplant sind... die Regenwürmer hingegen sind fürs Angeln gedacht (wie in der Java Version)^^

Sorry for the confusion, it looks like the username is only used by the Steam version, not the standalone We will fix that with the next update! But I'm glad you were still able to fix the issue in the meantime

Merry Christmas to everyone and a happy new year!

Unfortunately the name setting isn't exposed yet (but it's still on our to-do list), however, you can change the name manually in the config.properties file To do that, go to the game directory (for the Steam version, go to the "_New Version" subfolder), then open the "config.properties" file with a text editor and change the Game_Username field (add your desired name there), then save the file and run the game again. Now the game should use this name instead

Quote from Lyandreth

And no idea why the standalone Unity version automatically gave me the same name as Steam version!! The UIDs are very different...

The standalone uses your forum name by default (while the Steam version uses your Steam name). Names are not unique (players are identified by their UID), so more than one user can have the same name basically

Quote from SonoBionda

Meine Frage wäre, könnte man dafür nicht einen Custom-Befehl eingeben/anlegen und das komplette Zurücksetzen (also Größe UND Oberflächenbearbeitung) auf eine Tastenkombi wie bspw. Shift+Entf

legen

Grundsätzlich würden wir dafür ja eine eigene Tastenbelegung einführen, allerdings sind solche Tastenkombis momentan vom Spiel nicht vorgesehen, also zumindest benutzerdefinierte Tastenkombis Bislang war sowas noch nicht erforderlich... in diesem konkreten Fall stellt sich ggf. die Frage, ob es dann nicht generell wünschenswert wäre, wenn mit Shift+Backspace nicht auch automatisch die Oberflächenbearbeitung zurückgesetzt werden sollte Ggf. könnten wir sonst auch eine Option dafür anbieten, vll wäre das erstmal der sinnvollere Ansatz^^

Quote from Avanar

So als Laie gefragt - kann man nicht einen zusätzlichen Faktor mit einbringen? Also das es mehr als einen 0-Punkt gibt? Gerade im MP wäre es ja schwierig den 0-Punkt mit dem Spieler zu verschieben, weil es mehrere Spieler gibt.
Könnte man diesen 0-Punkt daher nicht Spieler (oder Client)-bezogen verschieben? Sodass jeder Spieler für sich einen eigenen 0-PUnkt hat.

Naja, das entspricht vom Aufwand her eigentlich bereits dem "Verschieben des Nullpunkts", was ich in meinem vorherigen Beitrag erwähnte Ob der Nullpunkt dann nur einmalig oder immer wieder dynamisch verschoben wird, macht eigentlich keinen so großen Unterschied mehr hinsichtlich der Implementierung.

Das Problem ist, dass wenn der Nullpunkt nicht mehr bei 0 liegt, sondern irgendwo anders, dass das Spiel dann sämtliche Koordinaten umrechnen muss: Wenn ein Tier zB bei X 1000 und Z -500 spawnen soll, sind das bei verschobenem Nullpunkt ja plötzlich ganz andere Koordinaten (würde der Nullpunkt in 1000er Schritten verschoben, würde aus 1000 / -500 plötzlich 0 / 500 und ein Nullpunkt-Offset von 1 / -1). Hinzu kommt, dass Positionen nicht mehr als einfacher Vektor repräsentiert werden können (also jeweils ein X, Y und Z Wert), sondern man entweder doppelte Präzision verwenden muss, oder 3 Zusatzwerte für die Nullpunktposition.

Bei einem kleineren Projekt wäre sowas noch einigermaßen einfach umzusetzen, bei RW gibt es aber so viele Stellen, wo mit Koordinaten gearbeitet wird - die müssten alle umgeschrieben werden. Und leider ist hier aufgrund der Komplexität großes Fehlerpotential vorhanden (wenn wir zB eine Stelle vergessen, kann das mitunter zu schwer auffindbaren Bugs führen)...

Quote from reydelreyes

Weil wenn man die ganzen verschiedenen Biome garnicht geniesen kann weil praktisch ab der nächsten insel schon probleme auftreten fände ich das doch etwas unpraktisch 😅

Unsere Intention ist es eigentlich, auch ohne Verschiebung des Nullpunkts erstmal einen "gut" bespielbaren Bereich bis 30.000 bis 50.000 zu haben (also dass man in dieser Region keine Einschränkungen ggü. dem Nullpunkt haben muss). Grundsätzlich sollte das jetzt auch kein so großes Problem sein. Größtes Hindernis momentan sind eigentlich die zitternden Hände, was einfach unschön ist...

Das oben erwähnte Texturproblem wird mit dem nächsten Update bereits behoben. Und Lücken zwischen Bauelementen sollten eigentlich auch nicht unbedingt auftreten, das müsste man sich einmal genauer anschauen, unter welchen Umständen das genau auftritt Beides sollte behebbar sein.

Langfristig (wenn die neue Version ausgereifter ist) kann man dann evtl. einen verschiebbaren Nullpunkt in Angriff nehmen, damit man eine wahrhaft "unendlich große Welt" hat

Quote from reydelreyes

Er kann es natürlich auch so lösen das dass Spiel die nötigen berechnungen in einem Ladebildschirm durchführt wenn du denkst das da weniger fehler passieren können

Die Berechnungen hinter einem "verschiebbaren Nullpunkt" selbst sind nicht so das große Problem... die würden zwar generell etwas Performance kosten (immer), das sollte aber einigermaßen überschaubar bleiben. Das Problem sind eher die enorm vielen Stellen im Spiel, die mit Koordinaten oder Vektoren arbeiten und die fortan umgerechnet werden müssen

Quote from Deirdre

red51 Es gab, gibt für die Java-Version den Befehl graphic_logarithmic_depthbuffer, um das Flackern zu minimieren. Vielleicht könnte so etwas für die Unity auch verwendet werden.

Dafür sehe ich eigentlich keinen Bedarf In der neuen Version sollte es auch so wesentlich weniger Flackern als in der Java Version geben. Der logarithmische Tiefenbuffer behebt leider keine Probleme mit zitternden Händen oder wabbelnden Bauelementen, sondern reduziert lediglich das Flackern zwischen zwei eng übereinanderliegenden Bauteilen (zB das Flackern von Postern, die an Wänden hängen etc). Dafür kostet der logarithmische Tiefenbuffer aber auch Performance (weshalb er in der Java Version standardmäßig deaktiviert war).

In der Java Version ist (auch trotz aktiviertem logarithmischem Tiefenbuffer) bei zB 32.000 die ganze Umgebung stark am wabbeln (selbst wenn man still steht). Wenn man sich in der Java Version einmal nach X 32000 und Z 32000 teleportiert und sich die gleiche Stelle in der neuen Version anschaut wird man feststellen, dass es in der neuen Version schon deutlich geschmeidiger läuft. Anbei mal ein Video davon, wie stark das in der Java Version ausgeprägt war (mit aktiviertem log. Tiefenbuffer): java-x32000-z32000.avi

Quote from Yaromid

Nach schnellem Testen mit Bauen von normalen Blöcken neben der Blaupause, denke ich, dass das nur bei der Blaupause auftritt Hier nochmal ein anderes Bild von dem „Fugenproblem“

Das dürfte eigentlich ein lösbares Problem sein, denn eigentlich werden Bauteile bereits relativ zu ihrem Chunk gespeichert... ich denke, da summieren sich einfach beim Berechnen der Position (beim Platzieren der Blaupause) Rundungsfehler (aufgrund der eingeschränkten Genauigkeit von 32-Bit Zahlen). Ich schaue mir das einmal genauer an, vermutlich können wir das sogar schon mit dem nächsten Update beheben