Posts by red51

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)

Quote from Weltentor

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)^^

Quote from ArcticuKitsu

Red51, you startled me with this Halloween claw hands in the radial menu. I went 'WTF?!'......

Hehe

Quote from agiser

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

Quote from Paks

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

Quote from XxCarnagexX

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:

Rising World
|__ Plugins
    |__ TestPlugin
        |__ TestPlugin.jar

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?

Quote from XxCarnagexX

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!

Quote from Hans Alfson

Es scheint eine solche PID-Überwachung zu existieren! Nachdem ich den Server mit einem Konsolen-Shutdown gestoppt hatte, ist er von alleine wieder gestartet. Es sei denn, die Befehle "shutdown" und "restart", über Konsole eingegeben, führen beide einen anschließenden Neustart aus.

Ahh, ok, dann ist zumindest dieses Rätsel schonmal gelüftet

Quote from Hans Alfson

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

Quote from Hans Alfson

Ich denke es lässt sich nachvollziehen. Nach dem Start 2024-10-22-23-02-34.log ist der Server bis zum Morgen durchgelaufen. In dieser Zeit wurde alle 2 Minuten versucht ein weiteres Mal zu starten. Am Morgen habe ich mir die Sache angeschaut und mich auf dem Server eingeloggt, was problemlos funktioniert hat. Während ich auf dem Server war, wurden im Hintergrund weiterhin Startversuche unternommen. Dann habe ich den Konsolen-Befehl shutdown eingegeben und den Server angehalten. Letzter Eintrag im Log: "[WARNING] [10:13:18] Exit (0)".

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)

Sorry für die späte Rückmeldung! Tut mir Leid zu hören, dass die Probleme weiterhin auftreten... offensichtlich liegt es nicht am Plugin. Es sieht trotzdem so aus, als wäre irgendwo eine Endlosschleife o.ä. Der Server verwendet mehrere Threads, und einer der Threads hängt offenbar fest - darum läuft zwar der Server an sich noch weiter (mit Speicherausgaben), aber niemand kann mehr connecten

Um wirklich herausfinden zu können, was da überhaupt hängt, bräuchten wir das nächste Update, was explizit ein Monitoring dafür haben wird... das nächste Update war eigentlich zusammen mit dem Storepage-Update geplant, aber evtl. ziehen wir es etwas vor. Das könnte etwas Licht ins Dunkel bringen.

Gibt es denn irgendeine Aktion, die das Verhalten hervorruft (also den Verbindungsverlust)? Wenn der betreffende Spieler rausfliegt (und du zufällig [noch] online bist), kannst du ggf. einmal serverinfo network in die Konsole eingeben? Die Ausgabe davon könnte interessant sein... du könntest dann vll entweder einen Screenshot hier posten oder alternativ einen Report danach senden (einfach anschließend report in die Konsole eingeben)

Quote from Hans Alfson

Mir waren in den Log-Files Warnungen aufgefallen, die sich auf fehlende Permission-Keys bezogen:

Diese Permission Keys gibt es tatsächlich nicht. Statt chatcolor_chatnamecolor ist vmtl. info_chatnamecolor gemeint. Auch ein chatcolor_deny gibt es nicht, vmtl. war info_chat gemeint (womit der Chat generell erlaubt/verboten werden kann)?

Quote from Hans Alfson

Anschließend habe ich eine neue Permission-Gruppe mit dem Namen "player" erstellt und versucht diese dem betroffenen Spieler zuzuweisen. Dabei ist es zu einer Fehlermeldung gekommen, ohne Absturz des Servers:

Danke für den Hinweis, das ist tatsächlich ein kleiner Bug! Allerdings ist der harmlos und hat keine Auswirkung auf den Server, der Befehl wird auch trotzdem ausgeführt - nur bekommt man in der Konsole keine Rückantwort durch diesen Bug

Quote from Hans Alfson

Allerdings wurde gleichzeitig bis zum Morgen alle 2 Minuten erfolglos versucht den Server erneut zu starten, wie die Log-Files zeigen.

[...]

Am Morgen habe ich den Server manuell gestoppt und wieder gestartet. Danach war wieder alles in Ordnung. Vermutlich hängt das irgendwie mit dem Scheduler zusammen

Das Problem ist, dass Steam einen Port nicht freigibt (4254 UDP)... die Situation scheint sich neuerdings leider etwas verschärft zu haben und der Port zu lange blockiert bleibt. Vor allem wenn der Server nicht ordnungsgemäß heruntergefahren wird.

Wahrscheinlich ist der Port aber effektiv gar nicht mehr unbedingt blockiert, sodass wir die Prüfung für den Steam-Port vmtl. einfach entfernen können. Das Problem können wir also evtl. mit dem nächsten Update fixen.

Quote from Hans Alfson

"Du wurdest vom Server gekicked! Illegale State-Limite überschritten! Bitte überprüfe deine Internetverbindung und stelle sicher, keine modifizierten Spieldaten zu verwenden."

Ein "Illegal State" tritt auf, wenn der Server irgendwas feststellt, was für ihn nicht plausibel ist. Grundsätzlich ist es so, dass fast alle Aktionen des Clients vom Server nochmal verifiziert werden. ZB dass beim Aufheben von Items oder Zerstören von Bauteilen der Spieler nicht zu weit entfernt ist. Wenn zu viele "Illegal States" auftreten, wird der entsprechende Spieler gekicked.

In dem konkreten Fall wurde versucht, Bauteile zu entfernen, doch der Spieler war lt. Server zu weit davon entfernt (die erste Koordinate ist die Position, wo das Bauteil geschlagen wurde, und die zweite Koordinate ist die Position des Bauteils selbst).

Wie das in dem Fall zustande kam ist nachträglich leider schwer zu sagen... das kann mit Desync zusammenhängen (dass neue Spielerpositionen nicht beim Server ankamen), oder aber natürlich kann auch ein Bug dafür verantwortlich sein. In der Vergangenheit gab es das Problem häufig bei besonders großen Bauteilen (das ist aber *eigentlich* gefixed). Waren in dem Fall evtl. extrem große Bauteile involviert?

Quote from Hans Alfson

Neues zum Scheduler!

Heute Nacht ist der gleiche Effekt aufgetreten, wie in der Nacht zuvor:

- Der Scheduler arbeitete wie vorgesehen und restartete den Server erfolgreich und dauerhaft.

- Gleichzeitig versucht er wohl im Hintergrund, alle zwei Minuten, eine zweite Server-Instanz zu starten, was aber zu einem Fehler führt. Übrig bleibt ein weiteres Log-File.

Am Morgen konnte ich mich problemlos auf dem Server anmelden, während weiterhin versucht wurde den Server ein zweites Mal zu starten. Aus dem Spiel heraus habe ich mittels Konsoleneingabe einen Shutdown ausgeführt. Daraufhin konnte der Prozess im Hintergrund den Server erfolgreich nachstarten. Danach wurden keine weiteren Start-Versuche mehr unternommen.

Hmm... aus den Log-Dateien geht das leider nicht direkt hervor Lt. 2024-10-22-11-02-29.log wird der Server nach exakt 12 Stunden (wie im Scheduler eingestellt) neugestartet (mit dem Hinweis "R E S T A R T S E R V E R" ganz am Ende). Soweit alles wie erwartet. Lt. 2024-10-22-23-02-34.log startet der Server dann korrekt neu (und erkennt auch, dass es ein Restart war). Nach dann aber knapp 11 Stunden wird der Server beendet ohne Hinweis auf einen Restart. Da der Server scheinbar nicht ordnungsgemäß beendet wurde, bleibt der Port blockiert (weshalb der Neustart fehlschlägt).

Auf mich wirkt es so, dass der 2. Restart extern durchgeführt wurde, also nicht vom Server selbst... denn es deutet nichts darauf hin, dass der Server den Restart initiiert hätte (und auch der Zeitpunkt stimmt wie gesagt nicht). Hat der Hoster vll so eine Mechanik?

Quote from Tyrolianer

red51 wann kann man den damit rechnen dass das werkzeug kaputt geht und Obst und Gemüse verdirbt?

Haltbarkeit von Werkzeugen wird wahrscheinlich schon bald kommen. Ich versuche es zum Storepage-Update rein zu bekommen, sonst wenn das nicht klappt, kommt das kurz danach

Das Verderben von Lebensmittel benötigt aber leider noch etwas mehr Zeit... vmtl. müssen wir erst einen Weg einbauen, Lebensmittel haltbar zu machen bzw. zu konservieren, damit nicht zu viel Frust unter den Spielern aufkommt

Quote from Tyrolianer

Kochen würde mich auch reizen.

Dafür braucht man nicht unbedingt Elektrezität, eig "nur" einen Kochtopf und die Rezepte😁

und mehr Obst und Gemüse😉

Nach dem Storepage-Update haben wir hoffentlich die Gelegenheit, einen größeren Fokus aufs Kochen zu legen

Quote from Forscherdrang

Bei der Gelegenheit bitte auch eine Pfanne, Olivenbäume & eine Saftpresse. Wodurch wir Öl gewinnen & leckere obstsäfte in die vorhandenen Flaschen füllen können.

Wie Kryssi_79 schon feststellt ist eine Saftpresse tatsächlich geplant bzw. auch teilweise schon vorbereitet worden

It depends on how you've added the PluginAPI.jar to your netbeans project

The platform manager (on your screenshot) is only relevant for the JDK (including the Javadoc for the JDK). To set up the API, I'd recommend to use this option (it's for the Java version, but mostly still relevant for the new version): https://forum.rising-world.net/thread/4743

In short, it's recommendable to add the Plugin API as Library. In Netbeans 17, go to the project Properties -> Libraries -> hit the + next to "Classpath" and select Add Library.... Click Create to create a new library (give it a name like "Rising World" or "Plugin API"). In the "Classpath" tab, hit Add JAR/Folder and add the PluginAPI.jar file. Then go to the "Javadoc" tab, hit Add URL and insert https://javadoc.rising-world.net/latest/. Confirm with Ok.

If you've added the PluginAPI.jar directly to the Classpath before (in project properties), remove it, so only your newly created "Rising World" (or "Plugin API") library is there. Now the Javadoc should work properly in Netbeans