Posts by red51

Basically the blueprint files contain various meta data, followed by the preview image (thumbnail and screenshot, both in JPG format), followed by the actual building data (which is compressed) The first bytes of the blueprint (basically the header) contains information about where the data is located in the buffer.

Blueprint data endianness in the new version is always Little Endian.

The very first byte contains the blueprint version, currently (as of 0.4.5) it is version 6. We use the version for compatibility checks in future updates (possibly the format may slightly change in a future update, so that would be indicated by the version number).

Java blueprints use a different format btw. Since they use the same file ending (".blueprint"), you can check if it's a Java blueprint by having a look at the first three bytes: In the Java version, the whole blueprint data was GZIP compressed, so if the first byte is always "31", the second byte is "139", and the third byte is less or equal to "8", it's most likely a Java blueprint. Java blueprints use Big Endian btw, but that's a different story. Once a Java blueprint is loaded in the new version, it gets converted to the new version format automatically.

The whole data structure of a blueprint in the new version looks like this:

HEADER

META DATA

THUMBNAIL DATA

SCREENSHOT DATA

BLUEPRINT CONTENT

UNCOMPRESSED BLUEPRINT DATA (LZ4)

SERIALIZED CONSTRUCTION DATA (per element)

SERIALIZED OBJECT DATA (per element)

SERIALIZED PLANT DATA (per element)

SERIALIZED TERRAIN DATA

Terrain data is a flattened 3d array consisting of shorts, where the first 8 bits contain the optional terrain "strength" or density between 0 and 100 (used to apply additional smoothing to the terrain) and the last 8 bits contain the actual terrain ID (0 is air).

To get the index in the terrain array from an x, y and z value, you can use this code: x + y * sizeX + z * sizeX * sizeY

I hope I didn't miss anything

* when it comes to strings, the buffer first stores the number of characters as 16 bit int (short), then the individual characters (2 bytes per char). If the string is null, a "-1" is stored instead (again as 16 bit int)

Quote from thomasvitrano87

With the blueprints, will large/detailed ones cause lag on a unity version world as they have in java?

The new version basically handles lots of construction elements much more efficiently than the Java version, so there should be an improvement in terms of performance But of course that highly depends on the hardware, and rendering lots of construction elements always come at a cost...

Having that said, if you run into performance issues in the new version (especially when it comes to detailed buildings), please let us know, so we can take a closer look at the issue (there is always a chance that there are still bugs which only occur under certain circumstances)

Yes, definitely yes

Das Inventar wird momentan sicherheitshalber geleert, wenn ein fehlerhaftes Item darin enthalten ist oder wenn die Inventardaten generell fehlerhaft sind... schwer zu sagen, warum das in deinem konkreten Fall aufgetreten ist Der Fehler muss beim vorherigen Mal als du gespielt hast bereits aufgetreten sein. Gibt es da vll irgendwas spezielles, was du zuletzt gemacht hast?

Mit setspawninventory oder kurz spawninventory kannst du - wie lenko schon sagt - dein aktuelles Inventar als Spawninventar festlegen. Wenn du dann respawnst, also nach dem Ableben, erhälst du dieses Inventar automatisch wieder (aber nur, wenn die "Inventar behalten" Einstellung in den Spieleinstellungen deaktiviert ist).

Quote from Deirdre

red51 Danke. Ich verwende Bäume auch als Zimmertannen usw.

Das ist grundsätzlich kein Problem, schwierig wirds aus Performancesicht wirklich erst, wenn extrem viele Miniaturbäume auf kleinstem Raum platziert werden, zB wenn man eine vermooste Wand erzeugen wollte und dafür hunderte oder gar tausende winzige Bäume daran entlang platziert etc

Quote from lenko

Wie immer stellt sich aber auch hier die Frage, wenn die Eisenbahn ins Spiel kommt wie breit das Gleis ungefähr sein wird und wie hoch die Züge sein werden ?

Gute Frage, das ist noch nicht 100% festgelegt, aber ich denke mal es macht Sinn, wenn wir uns an den gängigen 1435mm orientieren, zumindest für reguläre Züge

Was die Höhe angeht, das kommt wohl ein wenig auf die jeweilige Lok bzw. die Waggons an... diese Dampflok (die wir ursprünglich eigentlich für die Java Version vorbereitet haben, aber auch gut in die neue Version passt) wäre zB mit Schornstein ca. 9 Blöcke hoch und ca. 6 Blöcke breit (und ohne Kohlewagen ca. 22 Blöcke lang), bzw. ein Tunnel müsste wohl eher mindestens 10 Blöcke hoch und 7 Blöcke breit sein, eher noch größer.

Quote from lenko

Dazu stellt sich mir die Frage ob es vielleicht möglich sein wird, fahrende Züge, zb durch ein Punktleitsystem auf gebauten Gleisen fahren zu lassen.

Können später dann Züge automatisiert werden oder brauchen sie zwingend einen Fahrer.

Am sinnvollsten wäre hier wohl eine Kopplung mit dem Stromsystem: So könnte es zB spezielle Schienenelemente geben, die bspw. ein Haltesignal oder Geschwindigkeitssignal beinhalten, wodurch ein automatisiert fahrender Zug entsprechend halten oder seine Geschwindigkeit anpassen könnte. Und natürlich auch ein Schienenelement, welches ein Signal ausgibt, wenn ein Zug darüberfährt.

Dadurch wären einerseits simple Szenarien umsetzbar (zB Zug fährt im Kreis und bleibt jeweils eine bestimmte Zeit pro Haltestelle stehen), als auch komplexere Steuerungen (andere Züge warten, wenn Bahnhof oder Schiene belegt sind, oder fahren in bestimmten Abschnitten langsamer usw).

Aber später kann ich dazu bestimmt mehr sagen

Quote from Deirdre

Könnte man die Skalierung der Bäume noch verringern? Diese sind selbst nach Verkleinerung noch zu groß und bis es etwas neues gibt, das einzige Grünzeug.

Naja, das jetzige Platzieren über die Setzlinge ist eh mehr so ein Platzhalter, später soll stattdessen ja wirklich auch nur ein Setzling statt des voll ausgewachsenen Baumes platziert werden (das Platzieren von fertigen Bäumen hingegen wandert dann in den Creative-Mode)

Wir müssen uns zu der Größe ein paar Gedanken machen. Das "Problem" bei sehr kleinen Bäumen ist, dass Bäume in der neuen Version generell relativ viele Polygone haben, und das Rendern einer Miniaturversion eines Baumes ist quasi genauso "teuer" wie das Rendern eines ausgewachsenen Baumes - allerdings ist man bei Miniaturversionen viel eher dazu geneigt, sehr viele davon auf kleinstem Raum zu platzieren, was dann schnell an der Performance nagen kann...

Nichtsdestotrotz kannst du nachträglich die Größe eines Baumes in der Welt uneingeschränkt mit dem edit size Befehl verändern (also zB edit size 0.1 0.01 0.1 für einen 0.1x so großen Baum etc).

Ich persönlich finde einen einzelnen Sammelthread, wo sich jeder mit Problemen melden kann, eher unübersichtlich. Spätestens wenn mehrere Leute hintereinander Fragen stellen, einzelne Posts davon aber ggf. in längere Diskussionen ausarten, zwischendrin dann wieder neue Fragen von anderen Usern auftauchen, entsteht das reinste Chaos

Ich glaube auch ehrlich gesagt nicht daran, dass sich dadurch wirklich die Anzahl an Fragen oder so reduzieren ließe Wenn die potenzielle Antwort in einem Sammelthread bereits 1 oder 2 Seiten zurückliegt, würden vmtl. die meisten User trotzdem die Frage erneut posten.

Und spätestens wenn ein Sammelthread sehr umfangreich wird (sagen wir hundert Seiten oder mehr), hätte ich auch keine Lust, sämtliche Seiten zu durchstöbern, ob meine Frage eventuell schon irgendwo gestellt wurde. Da kann man gleich die Suchfunktion nutzen (und die funktioniert bei eigenen Threads mindestens genauso gut)

Thanks for your suggestions! Unfortunately I can't say much about that yet We have plans for automation when electricity gets added, but I go into detail about that yet.

About the ores, that's definitely planned (but unfortuantely I can't say for sure which ores will be added exactly) We also want to add various alloys in the long run.

Quote from wara

Is this the right version?

You can find the server version at the very top of the console output / server log. The file version doesn't matter. The latest Java version is 0.9.6

Quote from wara

Is this the right SteamID?
This is not my Steam64 id.

This is the SteamID of the game server, it's not related to your personal SteamID.

If you want to host a private multiplayer session (so friends can connect to your actual SteamID), use the "Play with friends" option instead (the "Play with friends" option can be found in the singleplayer menu of the game)

Sorry for not being clear, you have to rightclick on Rising World in your Steam library, i.e. in the Steam client to get to the Steam-specific settings for the RW server, there you can select the beta you want

Also unmittelbar nach der Ausgabe "STEAM BIND TO 0 (), Port: 30980, 30984 MODE: Authentication" wird die Steam API initialisiert. Sobald das erfolgreich war, wird die Verbindung zu Steam aufgebaut (asynchron) und danach die SteamID ausgegeben. Sobald dann von Steam die Rückmeldung kommt, dass die Verbindung aufgebaut wurde, kommt die "Steam Servers Connected..." Ausgabe.

Nach Ausgabe der SteamID hat der RW Server keinen Einfluss mehr darauf, wie lange der Verbindungsaufbau zu Steam dauert. Wenn also die SteamID noch zeitnahe ausgegeben wurde, es aber lange dauert, bis "Steam Servers Connected" erscheint, dann muss es an Steam liegen bzw. aus irgendeinem Grund scheint die Verbindung zwischen dem Server und den Steam Servern langsam zu sein.

Achso, d.h. jetzt läuft es und du kannst zum Server verbinden?

Was meinst du mit "es dauert lange bis er sich mit Steam verbindet"? Beziehst du dich damit auf die letzte Ausgabe im Log à la "Steam Servers connected"? Oder meinst du es dauert lange, bis du selber connecten kannst?

If you want to get the Java server, you have to opt-out of the [unity] beta branch. To do that, rightclick on the RW dedicated server in Steam -> select properties -> betas -> select "None" and close the window. But before doing that, it's highly recommended to uninstall the server first and remove all remaining files from the folder manually, otherwise any remaining files of the new version server may interfere with the Java server.

If you want to keep both servers, I'd recommend to move the content of the "RisingWorldDedicatedServer" directory (in Steam/steamapps/common/) to a separate folder or subfolder (for example you could call it "_New Version"), then install the Java server (or vice versa). Instead of starting the server through Steam then, you could just run the particular server exe directly (or create a shortcut to it)

Schwer zu sagen, was da los ist, ohne die genaue Konfiguration des Servers zu kennen Bei einem Root Server (also ein richtiger dedicated Server, der zumindest nicht in deinem lokalen Netzwerk bzw. hinter einem Router sitzt) könntest du evtl. probieren die öffentliche ServerIP in die "server.properties" eintragen (unter "server_ip") - das Feld kann zwar normalerweise auch leer gelassen werden, aber wenn zB irgendeine Form von NAT dazwischen stattfindet, dann kann es sinnvoll sein, die genaue IP anzugeben.

Du sagst ohne Firewall geht es auch nicht: Welche Firewall hast du denn deaktiviert? Nur die Windows-Firewall oder ggf. auch die eigentliche Server-Firewall (vom Provider), falls vorhanden?

Wenn der Server in der Liste auftaucht heißt das zumindest schonmal, dass der Server über den Query-Port (Serverport-1, also in dem Fall 30979) erreichbar ist. Sind auch die weiteren Ports (Serverport bis einschl. Serverport+4, also 30980-30984) TCP und UDP frei?

Denkbar wäre ggf. auch ein clientseitiges Problem. Hast du evtl. deine lokale Firewall (also auf deinem Rechner) und ggf. auch Antiviren-Programm einmal deaktiviert bzw. RW auf die Ausnahmeliste gesetzt? Der Server scheint momentan nicht online zu sein, sonst hätte ich selber einfach mal probiert, darauf zu connecten

Hmm... did you maybe try another port, e.g. the default port (4255, so the game uses ports 4254-4259)?

Are the ports still shown as closed (while the server is running) on this page, for example: https://www.yougetsignal.com/tools/open-ports/

In this case there must be something wrong, independent of the RW server

Der sporadisch auftretene Absturz dürfte mit dem nächsten Update *eigentlich* behoben sein Was die vielen Vorschau-Bauteile angeht, die werden momentan leider noch relativ ineffizient dargestellt (anders als zB Blaupausen oder in der Welt platzierte Bauteile), daher kann das bei großen Bereichen spürbar auf die Framerate gehen. Das müssen wir unbedingt noch überarbeiten, ich weiß aber leider noch nicht, ob wir das noch rechtzeitig zum nächsten Update schaffen

Eine Einstellung gibt es leider nicht direkt dazu, du könntest lediglich die Anzahl an maximalen Richtungen beim Platzieren auf 1 reduzieren (das ist dann wie in der Java Version), dann sollte das nicht mehr auftreten... schränkt allerdings auch etwas beim Bauen ein

Quote from lenko

Wäre es evtl nicht möglich der Wasser Intelligenz, sagen wir Mal eine Performance Genauigkeit nur dann zu geben, wenn es merkt das in einem Junk oder bestimmten Radius gebaut wird irgendwo mitten im Meer schippert man ja im Normalfall dann nur drüber und die Genauigkeit ist weit nicht so gefragt wie im Umkreis von Baugebieten.

Naja, das stößt leider auf mehrere Probleme: Einerseits wird das Wasser ja in den Terrain-Daten gespeichert, und diese haben lediglich ihre jetzige Auflösung (also 1 Block große Datenpunkte). Das kann leider nicht so einfach "bei Bedarf" geändert werden. Man müsste dann also wenn schon immer die Daten (also auch Terrain-Daten) mit einer hohen Auflösung speichern. Das wiederum aber erhöht den Speicherbedarf spürbar und zB im MP entsprechend auch den Traffic (doppelte Genauigkeit resultiert bspw. in 8x mehr Daten).

Andererseits werden die Berechnungen entsprechend auch massiv verlangsamt, wenn die Kollisionsprüfungen noch genauer ausfallen. Eine Verdoppelung der Präzision würde wohl auch nicht unbedingt reichen, um wirklich ein akzeptables Maß zu erreichen, sondern evtl. eher eine Vervierfachung (d.h. 64x so viele Daten) - und selbst da müsste man Einschränkungen hinnehmen, nämlich dass es bei detailreichen Bauten immernoch nicht so richtig passt

100% korrekt würde man sowas eigentlich nur mit wirklich dynamischem Wasser lösen können, also wo quasi jeder Wassertropfen simuliert wird. Wir sind technisch (also ganz allgemein, nicht auf RW bezogen) aber leider noch sehr weit von sowas entfernt. Im kleinen Stil funktioniert sowas mit diversen Einschränkungen zwar auch heute schon mehr oder weniger (also zB Wasser in einem kleinen Pool), aber bis sowas auch im großen Stil möglich ist, vergehen bestimmt noch 10-20 Jahre (vll sogar noch mehr)...

Wenn man sich sowas zB anschaut, sieht das zwar traumhaft aus, aber lt. Ersteller dauern die Berechnungen und das Rendern dahinter 8 Stunden (und das nur für diesen relativ kleinen Bereich). Da man aber um 60 FPS in einem Spiel zu erreichen nur 0.016 Sekunden Zeit für sämtliche Berechnungen u. Rendern hat (also nicht nur Wasser, sondern auch der ganze Rest des Spiels), sieht man, dass sich da noch eine Menge tun muss

Did you enter a Server_IP in the server.properties file? Since the server is behind a router, this may not work - in this case it could be necessary to keep the IP field blank.

Do you get this message [WARNING] UNABLE TO QUERY SERVER VERSION (0) at the very beginning of the log every time you start the server? This means that the server could not establish a connection to our server. This isn't necessarily a problem though, but could indicate that there is an issue with the connection

Quote from Yaromid

Also eigentlich ging es mir nur darum, wie Wasser mit Bauelementen interagiert. Wenn ich es jetzt richtig verstanden habe, muss sich das Wasser an das Blockraster halten – halt wie das Terrain – weswegen man in solchen Fällen wie einem "Unterwasserhaus" darauf achten sollte, dass (zumindest) die Außenseite genau am Raster ausgerichtet ist, damit der Bauteil-Wasser-Kontakt "nahtlos" ist?

Im Grunde ja Also Wasser ist in der Tat ans Blockraster gebunden, wie auch das Terrain. Ich kann leider noch nicht genau sagen, unter welchen Bedingungen Bauteile vom Wasser berücksichtigt werden können - momentan ist das noch nicht implementiert und ich weiß nicht, ob das beim ersten Release schon drin sein wird (weil Wasser ja dort wie gesagt eher Nebensache ist). Das Problem ist, dass in einem Chunk ja theoretisch enorm viele Bauteile platziert sein können, und da diese eine freie Position, Größe und Rotation haben können, sind auch entsprechende Kollisionsprüfungen relativ rechenintensiv (zumindest deutlich teurer als zB in einer reinen Blockwelt)...

Tendenziell wird es aber langfristig zumindest Blöcke, die im Blockraster platziert sind, berücksichtigen. Solche Blöcke (also mit Größe 1x1x1 und im Blockraster platziert) kann das Spiel ab dem nächsten Update auch generell effizienter darstellen und einfacher berechnen, unabhängig vom Wasser

Blöcke, die nicht im Raster platziert sind, erschweren die Berechnungen ein wenig... hier kommt es ein bisschen auf den Schwellenwert an, ab wann ein Block Wasser blockieren würde oder nicht. 100% akkurat wird das aber dann vmtl. nicht, da das Wasser ja wie gesagt so oder so ans Blockraster gebunden ist (wenn der Block also nicht im Raster ist kann es sein, dass zwischen Wasser und Block also entweder eine Lücke ist, oder dass das Wasser ein wenig heraussteht).