Sorry für die späte Rückmeldung! Ränge in der Form gibt es leider bisher nicht... seitens des Spiels werden die Gruppenzuweisungen nicht automatisch verändert, daher gibt es so ein Konzept noch nicht.
Was genau benötigst du für so ein Plugin denn? Einfach eine weitere Permission wie "rank", die der User in der Permission-Datei eintragen kann?
Looks like the println (https://javadoc.rising-world.n…ntln(java.lang.String,int) statements do not get added to the log file.
Thanks for letting me know! This should be fixed with the upcoming update 
And also the normal "System.out.print ()" is not on the log file and not in the Console.
Hmm... unfortunately I could not reproduce that 
Unless you change the output stream, it should automatically go to the log (and to the console) 
Leider gibt es das bisher tatsächlich noch nicht für die API 
Die letzten Wochen ist nicht viel an der API passiert, aber ich denke, dass wir das bald einbauen können.
Thank you so much for your feedback and your kind words Actually we're currently preparing the soundtrack and we hope to get it ready with the upcoming store page update (or shortly after that) 
Only the original icons of hunger and thirst will not be removed.
Hmm... this seems to be an issue in the game itself According to the plugin code (thanks for posting it on github paulevs), it just overrides the style of the hunger/thirst icons (using the Internals API) - that code looks correct. However, apparently the way how searches/queries work have changed in Unitys UI Toolkit in newer Unity versions, which breaks our current code (used by the API to find a UI element) 
We will try to fix that with the next update. Unfortunately there is no workaround for plugin creators But there is also no need for plugin creators to change anything (so this plugin should work properly again after the next update)^^
Red51, you startled me with this Halloween claw hands in the radial menu. I went 'WTF?!'......
Hehe 
Will it be added to the game?
Yes, that's still on our to-do list, but I can't say for sure when it will be ready... we'll have more room for this after the upcoming store page update
Oh, I dont have that setting, is it possible for me to added that setting myself?
Sorry, my bad, it's a hidden option atm (but we've already changed that for the next update) But yes, you can just add that line to the server.properties file then
Although, when I went into the game and opened the console with the Tilde (~) key, the logs were empty
Sorry for the confusion As mentioned by james1bow , I was referring to the debug console (showing all outputs of the game which would end up in the log file, too), not the ingame console that can be opened by pressing tilde
Unfortunately the debug console isn't enabled by default, but you can enable it by opening the config.properties file (in the "_New Version" folder in the game directory) with a text editor and setting Game_DebugConsole to True. The debug console is a separate window, so it's also useful to run the game in windowed mode then (so the debug console remains visible)
Are there really lots of people looking for such a feature? A demand for npcs/bandits attacking or raiding player bases (breaking down walls etc) indeed comes up from time to time (and some people are definitely looking for such a feature), but it's hard to tell how many people in the community really want this feature
Honestly I'm not sure if such a feature would work well in RW... unlike in other games, the building system isn't made for this... ideally the game needs a simplified building mechanic for that (where you just use modular walls, foundations, roofs etc, i.e build a base quickly with very few elements, like in most other games). With the current building system, there is a chance that such a feature would mostly result in a lot of frustration for a new player who isn't expecting this (who spend a lot of time creating a detailed building and who may not be aware of blueprints yet)
The building system also makes it quite easy (too easy?) for players to avoid bandit attacks. A player could create obstacles bandits couldn't pass anyway (e.g. create walls consisting of countless layers of thin blocks etc), so I'm not sure if such a feature really adds much of a "challenge" to the game.
IMHO it would be more reasonable if bandits can only break through objects like doors, for example. However, the game definitely needs better pathfinding for npcs before we can implement something like that (or tinker with base raids etc in general). It's quite difficult to implement proper pathfinding in RW, mostly due to the building system (buildings could consist of so many building elements which would quickly kill performance if we take a traditional approach on pathfinding), so unfortunately it will require quite some work (definitely something for the post-storepage-update era)
About your suggestion regarding blueprint tags specifically, basically it's not a bad idea to have tags for building elements in general, but what would prevent a player from just assigning the "interieur" tag to his entire building (and therefore preventing bandits from breaking in)? If a player can easily circumvent base raids, I'm not sure if it that feature would be really useful?
Thanks for the log file! Unfortunately it doesn't contain any information about a crash, so this seems to be a native crash... unfortunately this makes it a bit difficult to find out what's really going on there
Currently the main reasons for a crash are either out-of-memory errors (according to the log, the server has 196 GB of RAM, but since it's a game hoster, there is most certainly a lot less available for the server), or - more likely - issues with a plugin. The problem with JNI (that's the way how plugins interact with the game) is that every exception always causes a fatal error (i.e. a hard crash). The server tries to prevent that, but apparently there are still situations where this happens.
If you don't want to remove plugins temporarily (to see if you still run into crashes), maybe try this: open the server.properties file in the server directory with a text editor and set Plugins_SuppressFatalErrorLogs to False, then save the file and restart the server. Now when the server crashes, it should create a hs_err_pid file in the server directory. Maybe upload this file here
These are the npcs that can be considered very rare (as of version 0.7.5.2) 
You can spawn them with the spawnnpc console command (spawnnpc <name> <variant>, e.g. "spawnnpc pig carrot" etc):
Freut mich, dass es jetzt funktioniert! 
Danke für den Hinweis! Das Problem scheint damit zusammenzuhängen, dass das Spiel die Bilder im Cache speichert (und das mit abweichenden Auflösungen dann nicht zusammenspielt)... um das zu umgehen, kannst du in der config.properties Datei Game_CacheIcons auf False ändern (das hat eig kaum Auswirkungen, öffnen des Inventars könnte lediglich etwas langsamer sein), dann sollte es eigentlich funktionieren (alternativ kannst du auch den Befehl setoption cacheicons false verwenden)
Wir werden das mit dem nächsten Update aber korrigieren. Auch werden wir den Befehl dahingehend ändern, dass man eine Textur-ID angeben muss (bzw. -1 für alle Texturen verwenden kann)
Das ist wohl tatsächlich ein Bug Wenn sich das Boot in Innenräumen oder unter der Erde befindet (vmtl. gilt einer der beiden Zustände unter den Brücken), wird die Windstärke reduziert (was erstmal gewollt ist). Nur leider wird zusätzlich die Beschleunigung des Bootes nochmal abgesenkt, wodurch das Boot ca. 10x langsamer ist, als es eigentlich sein sollte... wir werden das mit dem nächsten Update korrigieren
Grundsätzlich haben die Permissions (also die, die bspw. mitgeliefert werden) nichts direkt mit der Admin-Berechtigung zutun - die "admin.json" ist zB einfach nur eine Beispielgruppe, die "admin" heißt, die ist unabhängig von Admins (deren UID in der server.properties eingetragen ist). Die hätte auch "owner" oder "full" o.ä. heißen können. Auch ein Admin ist also automatisch erstmal in der "default" Gruppe.
Das klingt zwar tatsächlich erstmal irritierend, aber das Permission-System ist prinzipiell optional.
Standardmäßig ist Permissions_AdminsFullPermissions auf True gestellt - dadurch werden die Permissions bzw. die Permission-Gruppe für Admins ignoriert und feste Berechtigungen dem Admin zugewiesen (zB darf er alle Commands ausführen usw).
Wenn du als Admin eine andere Permissiongruppe haben möchtest (dich zB der "admin" Gruppe zuweisen willst), musst du das über den setplayergroup oder kurz spg Befehl machen, wie james1bow schon sagt. Wenn du in der "admin" Gruppe bist bzw. wenn die zugewiesene Gruppe die nötigen Berechtigungen enthält, kannst du danach entweder Permissions_AdminsFullPermissions auf False ändern, oder alternativ dich auch als Admin entfernen, entweder manuell oder über den revokeadmin Befehl (denn wenn du mit dem Permission-System arbeitest, dann ist es nicht unbedingt nötig, als Admin in der server.properties eingetragen zu sein).
The code above looks fine (except the "1 usage" and "no usage" in lines 7 and 17, but that doesn't seem to be part of the code?).
According to the folder structure, you will find the built plugin in the "artifacts" folder. Basically you just need the "TestPlugin.jar" file (unless you're using external assets like images or models, but that's a different story). Just move the "TestPlugin.jar" file into a separate folder in the "Plugins" dir, so it could look like this:
When launching the game and loading a world, you should see the "Server name:" and "World Name:" output in the console/log. If that doesn't work, do you mind uploading the TestPlugin.jar here, so I can take a closer look at it?
I've read both Getting Started and the Create a Plugin threads, and while they may make sense to someone experienced with Java tools, it seems as though I'm doing something wrong. It would help to see somebody set up a project from scratch, so a novice can see how to properly package a plugin
Unfortunately the "Getting Started" and the "Create a Plugin" threads are a bit outdated... the content is still mostly valid for the new version, but we definitely want to rework them soon. We'll do that after the store page update
Oh, thanks for letting me know! It seems that the shutdown event is indeed not triggered if the shutdown restart is performed by the scheduler We'll fix that with the next update!
Es scheint eine solche PID-Überwachung zu existieren!
Ahh, ok, dann ist zumindest dieses Rätsel schonmal gelüftet 
Unmittelbare Zusammenhänge sind nicht erkennbar. Es sieht jedoch so aus, als wäre die Wahrscheinlichkeit herauszufliegen bei Bautätigkeiten größer als beim Umherlaufen.
Leider fliegen alle die online sind immer zeitgleich vom Server. Erst nach einem Restart über die Browser-Konsole des Hosters kann man sich wieder einloggen.
Schade... dann wird vmtl. nur das Monitoring des nächsten Updates helfen können, um irgendeinen Anhaltspunkt zu liefern, was da los sein kann
Ich denke es lässt sich nachvollziehen.
Stimmt, die weiteren Logs stammen tatsächlich aus der Zeit, während der Server noch läuft Allerdings kann das eigentlich nicht durch den Scheduler-Restart verursacht werden 
Wenn der Server sich selbst neustartet, wird ausnahmslos immer ein -wasrestarted Parameter mitgegeben (und wenn dieser vorhanden ist, gibt der Server beim Start die Ausgabe Server was restarted before... aus). Es gibt nur eine zentrale Stelle für einen Restart (hier kann eigentlich nichts durcheinanderkommen oder dazwischenfunken). Das OS wird angewiesen, den bestehenden Prozess durch den neuen Serverprozess zu ersetzen (wenn das aus irgendeinem Grund OS-seitig nicht funktioniert, dann dürfte der Restart niemals korrekt funktionieren).
Es muss also eigentlich irgendwas externes sein, was den Server immer wieder startet (was natürlich nicht klappt, da der Server ja bereits läuft und die Ports belegt) Wahrscheinlich hat der Hoster eine Mechanik, die das auslöst (durch einen Restart ändert sich die PID - vll überwacht der Hoster diese und startet den Prozess dann neu, weil er denkt, dass der Server abgestürzt sei). In so einem Szenario ist es dann sinnvoll, den Server nicht durch die eingebaute Mechanik neuzustarten, sondern einfach einen shutdown durchzuführen (also im Scheduler die Zeile /restart einfach durch /shutdown ersetzen). Der erste Restart-Versuch seitens Hoster lt. Logs wurde aber erst 15 Min später durchgeführt (erst danach ja im 2 Min Takt), daher ist das vmtl. auch keine optimale Lösung (außer, das Webinterface des Hosters bietet da entsprechende Einstellungsmöglichkeiten)
Getting the ticks per seconds wouldn't be very helpful in RW unfortunately, because the RW server is a multi-threaded application. There is a main thread which performs some basic tasks, like saving the world, updating furnaces and growing plants, determines weather changes etc. The PluginAPI UpdateEvent is also invoked from the main thread atm. It has a getTpf() method to get the current time per frame (this is basically what you're looking for).
But things like world generation, player/npc sync, npc handling, networking etc run in separate threads, so even if the main thread is busy doing something specific, it wouldn't be very noticable. Only if the main thread is constantly extremely busy (tpf always > 5-10 seconds), something could be wrong (plugin timers and calls like "enqueue()" or "executeDelayed()" also run on the main thread, so they would have an impact on that)
