Posts by red51

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

Actually we did already prepare some of these block shapes This is a rough overview of the upcoming block shapes:

• half sphere
• hollow half sphere
• quarter sphere
• hollow quarter sphere
• eighth sphere
• hollow eighth sphere
• alt. slope corner (slope corner type that was still missing)

Probably we'll add them shortly after the npc update. We'll also increase the quality of the cylinders, hollow cylinders and the sphere (so they appear more rounded).

We'll think about the inverted cylinder and the hollow cone / hollow half cone. What would be the use-case for these shapes?

Quote from SonoBionda

Was ist denn mit der Anregung hier im Forum, dass Blaupausen mit vielen Einzelstücken quasi in ein 3 D Modell umgewandelt wird ... da wäre allseitiges skalieren doch kein Problem ... ist das technisch machbar?

Ja, wenn Blaupausen als einzelnes Modell repräsentiert werden wäre es kein Problem, sie frei in alle Richtungen zu skalieren Das umzusetzen ist aber leider mit etwas Aufwand verbunden... das Spiel ist momentan darauf ausgelegt, dass Blaupausen im Grunde auch nur das bestehende Bausystem verwenden, also einzelne Blöcke platzieren. Das kann man natürlich ändern, aber das können wir leider erst machen, wenn wir insgesamt etwas mehr Luft haben

Leider würde das das Skalierungsproblem aber nur bedingt lösen, da so ein "Blaupause-als-1-Objekt"-Feature auch nur optional verwendet wird (man möchte ja größere Gebäude bspw. möglicherweise weiterhin in einzelnen Bauelementen haben). Und da wäre es irgendwie etwas schade, dass das freie Skalieren nur im "Blaupause-als-1-Objekt"-Modus verfügbar ist, nicht aber bei normalen Blaupausen

Could you elaborate on that? Do you mean a creative mode tool (similar to the current terrain tools [F5]) to raise/lower the terrain? Or do you mean a way to import custom heightmaps during world creation?

Quote from paulevs

A very small bug - sometimes normals on construction elements can be inverted (right part)

Sorry for my late response, I missed that post for some reason However, are these just blocks? Or is it a different element on the right side (e.g. the backface of a slope or something like that)? Was the element flipped/mirrored?

Quote from Galochka

Hello. And when is it planned to introduce seasons in the game?

Unfortunately we have no ETA for that yet... there is quite some work involved to add full-fledged seasons, but it's still on our to-do list

However, we'll add at least naturally occurring snowfall (similar to a short winter season) in the near future^^

Quote from Kyo

Can I ask for, maybe getting some kind of teasing (like few animal pics or a very short anim. footage?) ( even maybe some piece of claws crab ?! ).

We don't have any screenshots yet (because the animal models aren't fully ready yet), but once the first animals are in the game, we'll definitely share some screenshots

Erstmal Danke für den Log! Leider enthält er keine Infos zum Absturz... das kann zwar auch durch einen Bug o.ä. passieren (wenn das Spiel zB auf eine falsche Speicheradresse zugreift, ohne den Zugriff vorher zu prüfen), wenn aber der ganze Rechner hängt, klingt das meist nach einer externen Ursache (zB Treiberabsturz o.ä)

Was genau ist denn nach dem Absturz passiert? Warst du wieder auf dem Desktop, oder ist das Bild eingefroren, oder wurde der Bildschirm schwarz?

Mit dem nächsten Update werden ein paar zusätzliche Sicherheitsprüfungen eingebaut, womit zB ein falscher Speicherzugriff bereits vom Spiel abgefangen wird. Das kostet zwar minimal Performance, dafür sollte es aber keine kommentarlosen Crashes mehr geben (zumindest auf die Crashes bezogen, die vom Spiel selbst stammen). Wie gesagt, das könnte ggf. auch mit diesem Absturz zusammenhängen, aber möglicherweise hat das auch eine andere Ursache. Ich würde vll einmal versuchen, den neuesten Grafiktreiber zu installieren (auf der NVIDIA Seite ist eine neuere Version vorhanden). Falls du danach trotzdem erneut einen Absturz haben solltest, melde dich bitte nochmal

Wow, this is amazing and a very creative solution! Well done!

Leider können Blaupausen momentan tatsächlich nur proportional skaliert werden Das Problem ist folgendes: Jedes Bauelement speichert momentan eine Länge, Breite und Höhe. In einer Blaupause können Bauteile aber zB schräg verbaut werden (bzw. nicht jedes Bauteil in einer Blaupause hat automatisch die selbe Ausrichtung), und wenn man diese Blaupause nun zB breiter oder länger machen würde, würde das die schrägen Bauteile verzerren. Hier ein Bild, um das zu verdeutlichen:

Das Spiel kann Bauteile momentan aber leider (noch) nicht verzerren, weshalb Blaupausen nur proportional skaliert werden können... wenn wir das ändern wollen, würde das den Speicherbedarf pro Bauteil etwas erhöhen, weshalb wir uns da noch etwas zurückhalten wollen... vielleicht kommt das aber noch in einem künftigen Update