Posts by red51

Sorry ersmtal für meine späte Antwort!

Quote from noci

Zuerst war ich ein wenig Verwirrt da es kein Boolean Parameter gibt, aber als ich mich getraut habe den mit dem Integer (0/1) zu benutzen hat es ebenfalls geklappt.

Unity verwendet intern keine bools für Material-Parameter (das wird einfach über floats abgebildet), aber wir könnten das der Einfachheit halber trotzdem zur API hinzufügen

Quote from noci

red51 Jetzt habe ich nur das Problem das ich wenn der "Animator 2"[2.] Aktiv ist, kann ich nicht mehr "Shader"[2.] nutzen, warscheinlich überschreit die Animation die werte. Ich Habe versucht ihn mit der API zu Aktivieren oder Deaktivieren, leider ohne erfolg.

Das ist merkwürdig Kannst du mir das AssetBundle (und den Namen des Prefabs) ggf. einmal zusenden? Dann kann ich versuchen es bei mir zu reproduzieren

Quote from noci

Was ich auch noch gerne wüste, was mache ich mit invokeComponentMethod, klingt Spannend, aber konnte da, noch nix mit bewirken.

Damit kann eine beliebige Methode einer Component aufgerufen werden. Die meisten wichtigen Methoden der wichtigsten Komponenten sind bereits exposed (zB die Animator- oder Material-Methoden), aber diese Funktion ist hilfreich für Dinge, die noch nicht nach außen getragen wurden. Beispiel: Wenn dein Prefab eine Rigidbody-Komponente hat, und du zB die WakeUp() Methode aufrufen möchtest, könnte der Code dazu so aussehen:

prefab.invokeComponentMethod(null, "Rigidbody", "WakeUp");

Oder die Translate() Methode der Transform-Komponente, bei der ein Vector3 als Parameter übergeben wird:

prefab.invokeComponentMethod(null, "Transform", "Translate", new Vector3f(10f, 0f, 0f));

Analog dazu gibt es noch die setComponentProperty() Methode, womit "Properties" statt Methoden/Funktionen aufgerufen werden können. Beispiel: Wenn du die Masse eines Rigidbody auf 100 setzen möchtest (in Unity ist "mass" ein Property), könntest du das zB so machen:

prefab.setComponentProperty(null, "Rigidbody", "mass", 100f);

Quote from noci

Was ich mir noch Dringend wünsche ist das auslesen des Transform und eine Liste der enthaltenen Unterordner also jeden Tranform im Prefab mit Namen

Schwierig... das Problem ist leider, dass dafür das Modell zusätzlich serverseitig geladen werden muss. Bei Prefabs aus AssetBundles ist das zwar nicht so das große Problem, aber zB FBX Dateien brauchen relativ lange zum laden... das würde leider ein sehr teurer Funktionsaufruf...

Wir können mit dem nächsten Update aber eine neue "readLocalPosition()" bzw. "readWorldPosition()" einbauen, mit welcher von einem Prefab bzw. einem beliebigen Child die derzeitige lokale bzw. globale Position (und Rotation) ausgelesen werden kann. Der Aufruf ist dann an einen Spieler gebunden und arbeitet mit einem Callback (da die Position vom Client abgefragt wird - schließlich könnte sie theoretisch bei jedem Spieler anders sein, vor allem wenn eine Komponente zB animiert oder physikalisch ist). Ich weiß nicht, ob das in deinem Fall vll schon weiterhilft?

Quote from noci

Dabei ist mir aufgefallen das ein Timer nicht das Optimale ist

Warum? Für wiederholende Aufgaben ist ein Timer eigentlich die geeignete Lösung. Ansonsten kannst du sonst auch das UpdateEvent abgreifen, welches jeden Tick aufgerufen wird. Für komplexe Rechenaufgaben o.ä. wäre sonst auch ein klassischer Thread denkbar.

Quote from noci

Allerdings bräuchte man schon eien "kontinuirlichen Event" um z.B. die entfernung zum Spieler zu ermitteln, der müsste aber nicht auf jedem Tick hängen, vieleicht nur bei Spieler Bewegung, Change World, Load/Spawn, MoveToFinish

Das Problem ist leider die Entkoppelung von Client und Server... da die API niemals clientseitig ausgeführt wird, sind Millisekunden-genaue Aufrufe leider nicht möglich (allein der Ping zw. Client und Server ist der begrenzende Faktor). In vielen Fällen aber ist ein Timer (mit einem Interval von 0) oder das o.g. UpdateEvent aber normalerweise ausreichend.

Quote from noci

Wenn du schon ein wenig zu NPC's und API sagen könntest wehre das Super.

Leider noch nicht Bisher ist da noch nicht viel in dem Bereich passiert, da wir momentan noch zu sehr mit anderen Features beschäftigt sind... sobald die Java Version endlich durch die neue Version ersetzt wurde haben wir hoffentlich mehr Luft dafür

Quote from noci

Hier habe ich einfach mal ein Shader gebaut der die Basistexture Abdunkelt und als Emissiv raus gibt das macht es erstmal
Ist das der Weg den du auch genommen hast?

Öhm... ist die Frage an mich gerichtet gewesen?

Quote from noci

Wenn du für die UI noch die Liste und Dropdown freigeben könntest wehre das Wunderbar

Hehe, "freigeben" klingt ein wenig so, als müssten wir nur einen Haken setzen, damit die Dinge verfügbar werden Ein Dropdown Element ist in unserer UI leider generell nicht vorhanden bisher, stattdessen verwenden wir was anderes (siehe zB die Auswahlelemente für Dinge wie Auflösung etc. im Settings-Menü). Das wollen wir aber auch noch in der API abbilden

Es gibt zwar von UI Toolkit derartige Elemente, die haben wir aber nie verwendet (und auch deren Style nie angepasst), da diese vor nicht all zu langer Zeit leider nur im Editor verfügbar waren und nicht zur Runtime Wir könnten das aber trotzdem in Zukunft integrieren und in der API exposen bei Bedarf.

Eine List-View können wir allerdings leider nicht anbieten (da diese virtualisiert ist und das nicht über die API abgebildet werden kann), aber eine Scroll-View ist geplant (damit kann dasselbe erzielt werden)

Quote from noci

Oder für die Nutzung von USS & UXML, noch einen kleinen Tip gibst, wie mann das geladen bekommt wenn beide StyleSheetAsset vorhanden sind

UXMLs kannst du leider noch nicht laden, sondern nur USS Dateien (als StyleSheetAsset) Die können einem UI Element dann via addStyleSheet() zugewiesen werden. Es können darin ja Klassen definiert werden, diese können dann via addToClassList() zugewiesen werden.

Quote from noci

red51, noch ein kleiner Fehlerbericht:

Oh, danke für den Hinweis, das wird mit dem nächsten Update behoben

Quote from noci

Könnte eventuell bei dem ColorPicker noch die Intesity hinzugefügt werden, vieleicht mit einem weiteren Schalter HDR

Wie meinst du das mit der Intensity genau?

Mit HDR meinst du vmtl. eine Möglichkeit, RGB oder HSV Farbraum vorzugeben, oder?

Sorry für die späte Antwort, aber wir können mit dem nächsten Update zumindest Attribute für die Klassen "ObjectElement", "ConstructionElement" und "Plant" hinzufügen Da ein Sign i.d.R. auch ein ObjectElement ist bzw. dem zugehört (siehe Sign.getRelatedObject()), könntest du darüber Attribute speichern & auslesen

Animated GIFs are still planned, but we decided to not add them with the recent update because they consume a lot of memory... each frame of a gif is basically a separate image (in VRAM it's a lot larger than the original file size btw). In singleplayer, this usually isn't a huge issue at all, but in multiplayer, this could result in a lot of trouble... it's probably better if we release animated GIFs as a separate update

Sorry for my late response! In the new version, the setting is called Disable Hunger / Thirst (Survival only) in the Miscellaneous settings. If you turn that On, hunger and thirst will be disabled.

So if you want hunger and thirst to be active, turn it to Off It's not affected by peaceful mode, but these settings only work in survival mode (in creative mode, you never have hunger or thirst). Also please keep in mind that this only works in singleplayer - in multiplayer, this setting is determined by the server admin.

Installation indeed works like in the Java version Which plugins did you try to install? Is it in multiplayer or singleplayer?

If a plugin cannot be loaded, the log file typically contains more information about what went wrong. You can find the "Player.log" file in the "Logs" folder in the "_New Version" subfolder (in the game directory), maybe upload it here

Quote from Deirdre

In the Java-version I've always use this feature with pleasure, now in the unity-version only very, very rarely, which is a pity, but the system has become user unfriendly

Could you elaborate on that? The Java version used a fixed gap size, there was no way to change the precision for that. We could set a hard coded value for the gap size precision in the new version as well, but I'm not sure if this really improves the situation

Also wir werden zumindest im nächsten Update einen Wert loadorder einbauen, was optional in die plugin.yml eingetragen werden kann. Wenn nicht angegeben, ist der Wert automatisch auf 0 gesetzt (und Plugins mit identischer loadorder wenn wie gewohnt alphabetisch geladen). Beim Spiel- bzw. Serverstart werden die Plugins sonst abhängig von ihrer loadorder geladen, d.h. eine niedrige loadorder führt dazu, dass das Plugin früher geladen wird. Wenn ein Plugin also hauptsächlich eher als Library fungiert, kann diesem Plugin direkt ein sehr kleiner Wert verpasst werden (zB -1000000). Einem Plugin, welches viele Abhängigkeiten zu anderen Plugins hat, könnte man vorsorglich einen hohen Wert geben.

In den meisten Fällen sollte das eigentlich schon helfen Die loadorder wird zwar vom Pluginersteller gesetzt (da ja in der plugin.yml festgelegt), aber wenn dort im Vorfeld sinnvolle Werte gewählt werden (wie zB oben erwähnt), sollte das i.d.R. passen. Nur, wenn ein Plugin wirklich extrem viele Abhängigkeiten zu anderen Plugins hat, und alle Plugins von unterschiedlichen Entwicklern stammen, könnte das vmtl. an die Grenzen stoßen.

Unfortunately the logs indeed contain no information about the crash, as mentioned by Juggernaut This indicates that some native crash occurs apparently, unfortunately this makes it difficult to find out what's really causing it...

It's possible that this is caused by a plugin... unfortunately JNI (Javas interface for communication between Java and native side) just crashes if an error occurs inside a JNI call, which makes it crash-prone if a plugin does something unexpected. This can still be considered a bug in the game, because ideally the game would catch all exceptions and have enough sanity checks to make sure a proper exception is raised instead of a hard crash, but it's difficult to track these errors...

To find out what's going on, you could try to launch the server from command line and redirect the output to a separate log file. It will contain more information than the regular log. To do that, you could just use this command to start the server: RisingWorldServer.exe 1> serverlog.log 2>&1

Unfortunately you no longer see any output in the command prompt and you can no longer enter input commands directly, but all log output will be written to a file called "serverlog.log" in the server directory (please bear in mind that this log file is overwritten everytime you start the server). If the server crashes again then, please upload the serverlog.log file here (or alternatively send it via PM to me)

Wenn das Forum meint, das eingegebene Kennwort sei falsch, dann ist da scheinbar irgendeine Abweichung zwischen dem eingegebenen Kennwort und dem ursprünglich gespeicherten Kennwort für den Account... ich kann Passwörter leider nicht einsehen, das wird komplett von der Forensoftware (WBB) gehandhabt, daher kann ich nichts dazu sagen... habe bisher aber noch nicht beobachten können, dass Passwörter plötzlich ungültig werden o.ä.

Du kannst aber im Anmeldebildschirm sonst einfach "Kennwort vergessen" auswählen, um ein neues Kennwort zu generieren (da kannst du dann eigentlich dasselbe Kennwort erneut angeben).

Quote from Sandboxgamer

Ich stelle mir eine onLoad()-Event, da wo man das Plugin bereit für andere vorbereiten kann oder in der plugin.yml ein Bereich, die sagt, welches Plugin muss als erstes geladen werden.

Es gibt tatsächlich bereits eine onLoad() Methode: Diese wird exakt dann aufgerufen, wenn das Plugin geladen wird (zu dem Zeitpunkt sind andere Plugins noch nicht unbedingt geladen). Die onEnable() Methode hingegen wird erst aufgerufen, wenn alle Plugins geladen sind

Das Problem bei den Abhängigkeiten ist aber, dass sobald eine Klassenvariable oder eine statische Variable direkt ein Objekt erzeugt (diese also nicht erst in onEnable() erzeugt werden), ein Fehler geworfen wird wenn das entsprechende Plugin noch nicht geladen ist. Das lässt sich leider nicht verhindern (schließlich weiß Java an der Stelle ja noch nichts von diesem Objekt, kann also seinen Konstruktor oder eine seiner Methoden nicht aufrufen). Man kann das Problem aber umgehen, indem keine fremden Objekte erstellt oder Methoden aufgerufen werden, bevor onEnable() aufgerufen wurde.

Wir könnten ggf. eine Option hinzufügen, mit welcher man die Reihenfolge festlegen kann, in der ein Plugin geladen wird. Dem Plugin also einen Wert geben (und alle Plugins werden anhand dieses Wertes sortiert, d.h. ein kleiner bzw. negativer Wert führt dazu, dass ein Plugin früher geladen wird, ein höherer Wert dazu, dass es später geladen wird). So könnte man den Plugins, die von anderen Plugins benutzt werden, einen möglichst kleinen Wert geben (zB -1000), und dem Hauptplugin einen höheren Wert (Standard 0 oder eine höhere Zahl)

Quote from noci

Bei moveToLocalPosition würde ich gerne noch die Höhe wehren dessen überarbeiten
Wenn ich mir etwas hinterher "laufen" lasse und es durch entfernung getriggerte neue Positionen gibt (der zurüch kelegte weg ist mal Kürzer oder Länger und kann auch mal mehr Steigung haben), fürt der Weg manschmal durch ein hügel oder über ein Tal, und in diesen Momenten würde ich gerne ein getTerrainsHeight einbauen
Entwerder da eine kleine Calback/Run oder mit der möglichkeit moveToLocalPosition(Vector3f position, float speed, boolean includeWater) wo der Scann schon mit drinn ist
Mir wehre ein calback lieber, feinere Kontrolle.

Das ist leider etwas schwierig... momentan wird die Bewegung bei moveTo vom Client und Server separat berechnet (d.h. der Client bekommt die Anweisung, das Objekt "smooth" an die Zielposition zu bewegen, und der Server berechnet die derzeitige Position eigenständig). Das ist deshalb so gemacht, damit der Traffic zwischen Client und Server so gering bleibt wie möglich (so wird nur 1 Paket zum Client gesendet, statt jeden Tick die Position zw. Client und Server zu synchronisieren, was selbst bei kurzen Strecken zu hunderten oder gar tausenden Paketen führen würde)...

Denkbar wäre ggf. aber ein optionales Callback, in welchem die aktuelle Position übergeben wird, die man dann entsprechend ändern könnte... das würde aber natürlich auch zu viel Traffic führen... dazu müssten wir uns mal Gedanken machen

Quote from noci

Ich weiß nicht wie weit der Status genau ist, aber zur Info UILabel.setFont will auch noch nicht wirklich

Ja, das ist leider noch nicht ganz umgesetzt... das wird sich hoffentlich bis zum nächsten Update ändern

Quote from noci

Könnte der ClassLoader vom Spiel, die nicht vorhabdene Klassen überspringen?

Ich würde das später im Enabel Abschnit selber Prüfen ob das Plugin mit den Klassen Vorhanden ist oder nicht

Das klappt leider nicht Grundsätzlich ist es erstmal noch kein Problem, wenn eine Klasse nicht gefunden wird (weil zB noch nicht geladen). Wenn diese Klasse aber dann bereits verwendet werden soll (obwohl noch nicht geladen), gibt es entsprechend einen Fehler (was ja auch logisch ist, schließlich kennt Java weder den Konstruktor noch eine der Methoden dieser Klassen).

Dieses Problem tritt i.d.R. dann auf, wenn Klassenvariablen (oder statische Variablen) direkt ein fremdes Objekt initialisieren. ZB wenn ein fremdes Plugin eine Klasse namens "UnknownObject" hätte, und in deinem Hauptplugin diese Variable vorhanden wäre (public UnknownObject o = new UnknownObject();), dann wird dieses Objekt direkt initialisiert, sobald das Plugin geladen wird (und wirft entsprechend einen Fehler, da er "UnknownObject" ja noch nicht kennt und er nicht weiß, was im Konstruktor von UnknownObject überhaupt passieren soll).

Was hingegen funktioniert: Die Variable erst in "onEnable()" initialisieren (also die Variable ist nur als public UnknownObject o; deklariert und in onEnable() wird o = new UnknownObject(); ausgeführt).

Quote from noci

ich wünsche mir einPrefab.setAnimatorResetTrigger(String path, String trigger), wie bei Animator.ResetTrigger

Das können wir mit dem nächsten Update einbauen Auch wenn du zwischenzeitlich eine andere Lösung gefunden hast, ist es trotzdem sinnvoll, möglichst viel von der Unity-API auch in der Plugin-API abzubilden

Oh, I'm glad to hear it works now!

Das Problem kann ich bestätigen Danke für den Hinweis, das werden wir mit dem nächsten Update beheben!

Es wäre tatsächlich sinnvoller, wenn die Sense mehrere Pflanzen erfassen würde Derzeit ist es so, dass wirklich nur die Pflanze weggehauen wird, die auch direkt betrachtet wird. Ich packe das auf jeden Fall mal auf unsere Liste

Allerdings erfüllt die Sense momentan leider nicht dieselbe Funktion wie die Sichel: Denn nur mit der Sichel kann man momentan Setzlinge erhalten, während die Sense die Pflanze einfach nur zerstört (im Falle von Weizen bekommt man dann zwar trotzdem Getreide, aber keine Setzlinge).

Hier stellt sich die Frage, ob man das generell ändern sollte (also dass die Sense auch Setzlinge hervorbringt). Beim Schneiden von zB Rasen war es in der Java Version ja so, dass man nur mit der Sichel Grashalme als Item erhielt (während die Sense lediglich großflächig den Rasen entfernte, aber keine Grashalme ins Inventar gab). Wir hätten das in der neuen Version vmtl. auch so umgesetzt, aber es wäre evtl. überlegenswert, ob man das ändern sollte? Andererseits könnte das die Sichel dann aber auch überflüssig machen, oder?

Ich bereue es ehrlich gesagt ein wenig, dass wir die Welten größer (also höher) gestaltet haben Es wäre vmtl. einfacher, wenn wir 1:1 die Welt-Generierung der Java-Version umgesetzt hätten. In der Java Version hatten Welten einen wesentlich kleineren Maßstab (der höchste Berg war ca. 200-250 hoch, während es in der neuen Version mehr als 800 ist).

Dadurch erscheint auch der Radius der Terrainbearbeitung deutlich kleiner, als noch in der Java Version, obwohl die neue Version genau denselben Bearbeitungsradius hat wie die Java Version.

Ein größerer Radius der Terrainbearbeitung wäre zwar sehr vorteilhaft, da stimme ich voll und ganz zu, aber leider können wir ihn nicht einfach so vergrößern, da wir sonst auf zu große Performanceprobleme stoßen... die Terrainbearbeitung ist zwar deutlich effizienter als in der Java Version umgesetzt, doch leider ist Unity bzw. IL2CPP selbst deutlich langsamer als Java (ca. 4-5x langsamer), was diese Bemühungen wieder weitgehend zunichte macht. Eine wirkliche Beschleunigung können wir nur noch erreichen, indem die Terrainbearbeitung direkt in C++ implementiert wird (so wie die Weltgenerierung), aber das bringt einige Probleme mit sich, da die Terrainbearbeitung auf viele Daten zugreifen muss, die nicht direkt über C++ zugänglich sind.

Es ist auf unserer Todo-Liste, aber leider ein umfangreiches Unterfangen, weshalb es derzeit eher eine geringe Priorität hat...

Quote from Deirdre

F5 4 erlaubt zwar einen größeren Radius, allerdings hängt das Tool meistens, Dauerdrücken der ENTF-Taste bringt auch nichts. Daher nimmt man am besten F5 1, aber damit eine Fläche zu begradigen, dauert Jahre.

Das Problem kann ich leider bei mir nicht reproduzieren Ein einzelner Druck auf die ENTF-Taste genügt eigentlich, um den Bereich zu entfernen (kann aber - wenn ein großer Bereich markiert ist - durchaus ein paar Sekunden dauern).

Du hattest aber ja generell das Problem auf deiner Welt, dass auch normale Terrain-Bearbeitungen teilweise nicht durchgeführt werden konnten. Ich konnte das bei mir leider bisher nicht reproduzieren und kann daher nicht sagen, woran das genau liegt... leider kann ich das Problem vmtl. nur beheben, wenn du mir deine Welt zusenden kannst

Quote from Deirdre

Und wer braucht dieses hügelige, unwegsame Gelände?

Man kann auch eine komplett flache Welt erzeugen. Mehr Optionen sind da auch geplant (zB "Flache Inseln", also eine Superflache Welt, die aber trotzdem in Inseln unterteilt ist), aber aus Zeitgründen kamen wir noch nicht dazu, das umzusetzen.

Quote from Deirdre

Möglicherweise gibt es diese großen Flächen irgendwo auf der Map versteckt, aber mit der Fluggeschwindigkeit 400 ist man dann tagelang unterwegs. 800 oder 1000 wären besser. Mir macht das absolut keinen Spaß

Es ist geplant, noch mehr Optionen zu bieten und auch generell dafür zu sorgen, dass tendenziell weniger Berge generiert werden, nur wie gesagt, bisher kommen wir leider nicht dazu, das zu implementieren Es gibt andere fehlende Features, die dringend umgesetzt werden müssen, damit die Java Version endlich durch die neue Version ersetzt werden kann...

Quote from Deirdre

Die Landschaft bewunderte ich nur am Anfang nach dem Upate, jetzt kenne ich alles und letztendlich sieht alles ähnlich aus, bis auf die nicht vorhandenen geraden Flächen.

Es ist klar, dass man irgendwann alles gesehen hat. Das ist bei prozedural generierten Landschaften immer so. Wenn man wirklich absolute Abwechslung mit einmaligen Landschaftsformationen möchte, dann muss eine Landschaft von Hand erstellt werden. Das ist grundsätzlich in jedem Spiel so.

In Zukunft werden zwar Höhlen und versch. Biome mehr Abwechslung bringen, aber ich garantiere jetzt schon, dass auch das leider irgendwann langweilig wird. Das ist unvermeidlich.

Die Landschaft in der neuen Version ist IMHO dennoch abwechslungsreicher als in der Java Version (und darum ging es uns in erster Linie). Eine Weltgenerierung, die "nie langweilig" wird, kann mit herkömmlichen Mitteln nicht implementiert werden (vll sieht es in Zukunft unter Mitwirkung von KI anders aus, aber momentan ist das quasi noch der Stand der Technik)...

Quote from Deirdre

Pflanzen bleiben beim Terraformen in der Luft hängen und bei einem großen Gebiet ist F7 so langsam, dass die Pflanzen am besten manuell entfernt werden. Die Felsen bleiben ebenfalls übrig und da nützt F7 überhaupt nichts, da diese Felsbrocken verteilt über große Flächen übrig bleiben.

Grundsätzlich werden Pflanzen dabei automatisch entfernen, sofern Pflanzen von Schwerkraft beeinflussen in den Einstellungen aktiv ist. Es kann zwar vorkommen, dass einzelne Pflanzen & Felsen zurückbleiben, aber der Großteil davon sollte dann i.d.R. verschwinden.

Die Pflanzen und Felsen, die doch zurückbleiben, können mit F7 aber sonst entfernt werden, wie Avanar schon sagt (Felsbrocken gelten als "Vegetation").

Hmm... do you play on a TV (instead of a regular monitor) maybe? Or do you have a setup consisting of more than 1 monitor? Maybe you could send us a report, then we can take a closer look at why this happened To do that, please open the console (key ~ or `) and type "report" (maybe add some additional information like "mouse offset" or something like that)^^

After sending the report, you could try to change the Display mode in the graphics settings. If it's set to "Fullscreen", try to change it to "Fullscreen Windowed" (or vice-versa). You could also try to change the resolution to your desktop resolution. Does that help?

Quote from VinnieDaArm

OK. I figured it out. My brain was the issue. I figured SteamCMD would update the directory I was in, seeing Rising World Unity Server already there. No. It was updating to the default location in ~/.local/shared. Ugh. I did the force_install_dir in SteamCMD and that worked. Thanks for your help, Red.

Oh, I'm glad to hear it works now

Thanks for the log The server is indeed running on the old version 0.6.5.1 (you can find that information at the very top of the log)... not sure why SteamCMD doesn't update it properly (even after adding the validate parameter) I would recommend to try to delete the server files then, as described above (just keep the Worlds folder and maybe the "Permission" folder and the server.properties file), then run SteamCMD again.

Quote from VinnieDaArm

It updated for the June 30th update. The Unity version exe has a date of 7-July-2023, but the version info shows older. I'll include a screenshot of both the Java version and the Unity version after the latest client update. I am not sure how to check the version on the server running on Ubuntu. Thanks for the help. I'd love to get this running again for my family. Such a great game.

The first image is from the Java version (and can be ignored^^), but the 2nd image indicates that you already got the latest game version (0.6.7.2), which was indeed released on July 7 So it's definitely the server which is causing the issue... you can also find the server version in the latest server log (there should be a "Logs" folder in the server directory). Maybe upload that log file here

In case of doubt, you may also try to delete all server files (except the "Worlds" and "Permission" folder and the "server.properties" file) and update the server again.

Quote from VinnieDaArm

I tried that. I appreciate the feedback, but it doesn't seem to change anything. I ensure the server isn't running, I execute SteamCMD inside the Rising World Unity server folder, and it says it updates (see screenshots below), yet when I launch the game (which is up to date) I get this error every time.

Hmm... is maybe your game outdated then for some reason? I have seen cases in the past where even the Steam client doesn't recognize new updates...

The game version game be found in the lower left corner of the main menu (the latest version is 0.6.7.2). For the server, the version can be seen in the server console at the top in the server console (when starting the server)