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).
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)
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
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
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).
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...
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
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.
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...
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)...
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?
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.
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.
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)
Thanks for the log and the report (we received it)
Actually this is unfortunately indeed a bug 
It only happens in multiplayer and is related to other players using vehicles We'll fix that with the next update, but if this keeps happening, we'll try to prepare a hotfix for that in the meantime!
They are a missing feature that I hope to see soon : the resource cost for blueprints in survival mode. Where it is on the list ? More on the top or on the bottom ?
It's still on our to-do list, but unfortunately I can't say for sure when this will be added
Since you will be working on npcs, if you think this could be done, it will be soo good to have some specific/eating/rest stences for animals, like cows laid down, seated pigs (as shown on the picture bellow), instead of being continuously wandering which is not very natural. It will be so immersive and cool
Actually animals do eat sometimes, but we definitely have more plans for improvements regarding animal behaviour However, probably this will only happen after replacing the Java version on the store page...
I think I'm doing something wrong here hehe. Everything is in single player. I seem to have set the resolution to 256x256 by typing 'setoption customimageresolution 256' but I don't know how it worked because it didn't seem to take effect until I loaded up the game 2 days later. The images were still 512 for that whole session after the commands
Oh, sorry for the confusion, it looks like you can't change that during runtime So right now the only way is to change that manually in the config.properties file (the Game_CustomImageResolution setting)... alternatively you can still use the "setoption" command, but then you also have to type "saveoptions" (to save it to the config file) and reload the world for the changes to take effect...
This only affects posters which are uploaded after changing the setting btw, it does not affect existing posters!
However, we'll change this with the next update, so you can also change this setting at runtime without having to restart the game 
Red, I've been trying since this new client came out to connect to my Server and it always says wrong version. I created the server using SteamCMD and the instructions on this forum a month or so ago. When I updated clients to the "posters" version they have never been able to connect.
I've run the SteamCMD update command for this (in the directory it is installed on my private server) like 10 times and it never works. Anyone have ideas on what to do?
When using SteamCMD, it sometimes doesn't detect or download new updates unfortunately... but usually you can fix that by appending a validate parameter to the update command (i.e. app_update 339010 -beta unity validate)
@red Könnte man die bist zu einem Update die glatte Oberfläche der Poster nicht dauerhaft in der Config speichern? Ich nutze Leinen oder Öltexturen auf Postern eher selten.
Leider ist das an sich keine Einstellung im Spiel, sondern ein Parameter, der pro Objekt eingestellt wird... daher können wir sowas nicht so einfach als Option anbieten Wir könnten zwar sowas wie "Standardattribute" einbauen, die immer gesetzt werden, doch der "DisableNormal" Flag ist bei anderen Objekten außer Postern meist eher unerwünscht...
red51 ist es möglich alle Konsolenbefehle in die Datenbank (StreamingAssets\definitions.db) aufzunehmen ?
Eine separate DB-Tabelle mit Befehl und Parametern (+ alles was noch Sinn macht). Die Beschreibung könnte in die Sprachdatei rein.
Das würde die Sache leider nur verkomplizieren, und das hätte keinen wirklichen Nutzen, da es quasi keine Daten gibt, die mit einem Konsolenbefehl assoziiert sind (und der Konsolenbefehl eh nur aus der Ausführung von Code besteht)
Welche Informationen benötigst du denn konkret zu den Befehlen? Hilft ggf. der commands Befehl weiter? Damit werden alle Konsolenbefehle ausgegeben - diese findest du anschließend (wie alle Konsolenausgaben) in der Log-Datei wieder. Ansonsten könnten wir auch einen anderen Befehl einbauen, um das zB direkt in die Zwischenablage zu kopieren o.ä.
Another minor hotfix is available now btw It's just a clientside update, so no need to update multiplayer servers for this
Hotfix 2023-07-07:
