Posts by red51

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

Grundsätzlich werden einzelne Bauteile in Blaupausen, die insgesamt kleiner als 0.01 sind, nicht platziert (wie SonoBionda korrekt beobachtet hat) Also Bauteile, bei denen sowohl die Länge als auch Breite und Höhe < 0.01 sind (was wirklich schon winzig ist). Die Bauteile sind trotzdem in der Blaupause gespeichert, werden nur beim Platzieren übersprungen. Die Intention dahinter war, dass Mini-Details auf klein skalierten Blaupausen ausgespart werden, um die Performance etwas zu verbessern.

Man kann das Verhalten aber ausschalten, indem in der config.properties Datei im Spielverzeichnis der Wert Game_BlueprintsIgnoreSmallElements auf False geändert wird (Spielneustart erforderlich)

Ich stimme zu, dass ein Hinweis, dass kleine Bauteile übersprungen werden, sinnvoll wäre. Andererseits könnte das manche User aber auch irritieren, denn in vielen Fällen stellt das eigentlich kein Problem dar, wenn winzige Bauteile ausgeblendet werden - der Warnhinweis würde aber den Eindruck erwecken, dass es ein Problem gibt Dazu müssten wir uns vll einmal Gedanken machen...

Quote from Bamse

This will be wonderfully. Just append a line to file, not replace all file and all will be fine.

Yes, by default the game will just append a line Alternatively one could put a '+' in front of the path (e.g. coordinates +relativefolder/subfolder/testfile.txt) to tell the game to append the line, or a '-' so the game overwrites the file content^^

Hmm... hard to tell what's causing this, especially if this sometimes happen in sapling stage, sometimes in a random grow stage Just to make sure, the saplings weren't placed in creative mode with the F6 placement tool, right? These saplings will never grow (this is actually intentional)...

Does it also happen in multiplayer in your case Bamse ?

What happens when restarting the game (if this happens in singleplayer) or the server (if this happens in multiplayer)? Does this update the saplings?

Bei zunehmender Entfernung vom Nullpunkt nimmt die Genauigkeit leider tatsächlich spürbar ab Das liegt daran, dass Koordinaten im Spiel als 32 Bit Gleitkommazahl (sog. "floating point number" oder kurz "float") repräsentiert werden, welche ca. 6-7 signifikante Stellen haben (sozusagen Stellen, die eine hohe Genauigkeit haben). Ist man ganz nahe am Nullpunkt, stehen quasi alle diese Stellen als Nachkommastellen zur Verfügung - das Spiel kann also Positionen und Größen mit einer Genauigkeit von ca. 0,000001 relativ präzise darstellen. Befindet man sich hingegen bei 10.000, werden schon 5 Stellen vor dem Komma "verbraten" - es bleibt also nur noch eine Genauigkeit von ca. 0,01 übrig. Ab 100k sind es nur noch ca. 0,1 und ab 1 Mio ist ca. nur noch eine blockweise Genauigkeit gegeben.

Leider sieht Unity (anders als andere Engines) keine Notwendigkeit, Unterstützung für "doppelte Präzision" (also 64 Bit Zahlen bzw. sog. "doubles") einzubauen. Das würde das Problem auf einfachste Art vollumfänglich lösen ("doubles" haben ca. 15 signifikante Stellen), womit auch Abstände von mehreren Millionen Kilometern zum Nullpunkt präzise dargestellt werden könnten...

Die einzige "Lösung" wäre daher, den Nullpunkt immer zu verschieben, wenn der Spieler sich bewegt. Sowas umzusetzen ist bei einem Spiel wie Rising World leider recht komplex - alle Koordinaten müssen jedes Mal umgerechnet werden. Das Verkompliziert viele Dinge enorm, und aufgrund der Komplexität bringt das auch eine gewisse Fehleranfälligkeit mit sich. Damit hätten wir aber eine quasi "unendliche Welt", denn dann wären theoretisch Entfernungen von ca. 40 Trillionen Kilometern zum Nullpunkt mit hoher Genauigkeit möglich (zum Vergleich, unsere Sonne ist gerade mal lächerliche 150 Millionen Kilometer von uns entfernt)

Langfristig möchten wir das gerne einbauen, aber da das Feature so umfangreich ist, neigen wir dazu, es etwas nach hinten zu schieben...

---

Wie @Deirde schon sagt, diese Probleme gab es auch bereits in der Java Version (die ebenfalls 32 Bit Zahlen verwendete), allerdings war das Problem dort wesentlich schlimmer ausgeprägt: Hier haben schon wesentlich früher Elemente angefangen zu wabbeln oder zu flackern. Selbst einigermaßen nahe am Nullpunkt gab es bereits Flackern (zB wenn Poster vor Wänden platziert wurden).

Wenn man sich in der Java Version bei zB 29.000 befindet und was baut und in der neuen Version bei 29.000 was baut, wird man feststellen, dass das in der neuen Version deutlich besser läuft (aber trotzdem alles andere als perfekt).

Das größte Problem sind in meinen Augen aber die zitternden Hände: Auch das ist zwar weniger geworden als in der Java Version, ist aber nach wie vor zu stark ausgeprägt. Wir suchen da noch eine vernünftige Lösung... leider ist auch hier Unitys HDRP recht einschränkend, sodass das schwierig auf performante Weise umsetzbar ist... ich bin mir aber sicher, dass wir da noch eine Lösung finden werden

Das Texturproblem auf Bauelementen hingegen ist nicht gewollt Das haben wir leider etwas vor uns hergeschoben (vor dem Welt-Update hat man sich ja kaum in diesen Regionen aufgehalten). Das werden wir mit dem nächsten Update beheben, sodass Texturen auch bei weiter Entfernung zum Nullpunkt normal dargestellt werden

Die Lücken in den Bauwerken bei weiteren Abständen zum Nullpunkt hingegen sind merkwürdig... tritt das nur bei Blaupausen auf?

Quote from Forscherdrang

Sind diese Blaupausen für andere Spieler zugänglich?

Oder werden diese weiß mit der Info "Ungültige Blaupause"?

Die Blaupausen (also als Item) sind grundsätzlich nur dann für den Spieler verfügbar, wenn er die Blaupausen auch bei sich in den "Blueprints" Ordner abgelegt hat. Das Spiel speichert die Blaupausen bisher nicht noch zusätzlich in der Welt, sondern lediglich ein paar Metadaten darüber. Wenn du also eine Welt teilst, in der Blaupausen (als Items) in Truhen liegen, wird ein anderer Spieler die nicht ohne Weiteres verwenden können...

Platzierte Blaupausen sind aber selbstverständlich vorhanden (sind ja danach ganz normale Bauelemente)

Quote from Forscherdrang

Allerdings ist mir aufgefallen, dass fast die gesamte Größe, jeweils auf eine Datei Fokussiert ist.

Der "Chunks.db" Datei.

In der Chunks.db sind quasi alle Chunks gespeichert, also Terrain, alle platzierten Bauelemente usw., daher ist diese Datei mit Abstand am größten

Quote from Forscherdrang

Würde es in Bezug auf diese Grenzen etwas bringen, den Backup Ordner z.B mit WinRar oder WinZip zu verpacken?

Ist es möglich diese Grenzen anzuheben? z.B. Max 15 Anhänge & 20 MB

Packen kann die Größe meist um 30-50% reduzieren, das kommt ein wenig auf die Welt drauf an Grundsätzlich werden die einzelnen Chunks bereits komprimiert gespeichert, allerdings gibt es oft viele Chunks, die Ähnlichkeit zueinander haben (zB flaches Terrain, oder Chunks die komplett mit Stein oder Luft gefüllt sind etc), sodass ein Zip-Tool hier noch was rausholen kann.

Das Limit für Dateianhänge möchten wir erstmal nur ungerne weiter anheben (es müsste ja vor allem deutlich angehoben werden, damit man hier auch größere Welten teilen kann)... in besonderen Fällen können wir das Limit aber grundsätzlich einmal kurzzeitig anheben, damit auch ein größerer Upload möglich ist

Quote from Arakara

Vermute ich richtig, dass dabei dann Türen etc nicht mehr zu öffnen/benutzen wären?

Guter Punkt, darauf müsste das Spiel gesondert eingehen, denn Objekte wie Türen etc. können nicht zu einem einzelnen Mesh zusammengepackt werden (da jedes Objekt andere Materialien und Texturen verwendet) - das ist lediglich bei Bauelementen möglich... Objekte würden also weiterhin eigenständig bleiben und wären damit auch weiterhin benutzbar

Wir würden aber vmtl. das "Blaupause-als-1-Objekt" Feature anders umsetzen, nämlich so, dass das Spiel zwar weiterhin die einzelnen Bauelemente & Objekte speichert, diese aber so miteinander verbindet, dass das Spiel weiß, dass beim Zerstören eines Elementes alle Elemente zerstört werden sollen etc.

Intern werden alle Bauteile eines Chunks beim Rendern eh schon zu einem einzelnen Mesh zusammengepackt, von daher hätte das hinsichtlich der Performance ohnehin keinen Unterschied - es geht also wirklich nur um den Spielaspekt, dass man nicht alle Bauelemente einzeln wegkloppen muss

Please bear with me, but I still have no idea what that tool would look like

It sounds a bit like you want to provide custom heightmaps to the world generator, so the world generates an island based on that heightmap?

Quote from Bamse

I just dreams , as red51, put a configurabile key bind who just throw a line with x,y,z into a file when player press it!

We could introduce a "coordinates" console command with the next update which prints the current coordinates and optionally saves them in a target file (e.g. something like "coordinates testfile.txt" to print the coordinates to a file called "testfile.txt" in the game directory)

You can then set it as custom command in the config.properties file (e.g. set "Game_CustomCommand1=coordinates testfile.txt") and assign a key for "Custom Command 1" in the controls setting (at the very bottom) - then your coordinates will be written to the file every time you press that key