That is how the game works. Admin permissions > Area permissions > group permissions. In other words: Area permissions ALWAYS overwrite group permissions. If you want to give them more permissions you have to edit the ozlc-owner area permissions BUT then every player with a claim gets these permissions regardless of their group permissions. That is how it works, i cant change it. A workaround would be that you create a veteran-player area permission as copy from ozlc-owner and then change the players area permissions to that BUT then the plugin wont detect the player as owner and he cant manage his own claim anymore.
Posts by Devidian
The next update will be available on Monday, August 31, in the early evening (UTC+2)
-
-
Hmm... hast du das kürzlich erst aktiviert?
Laut den prod-crash.log sind die Optionen nicht aktiv, also die nöten Argumente werden nicht an die JVM übergeben... ist das ein anderer Server oder waren sie da noch nicht aktiv? Sonst ist es möglicherweise auch ein Bug 
auf prod war es nicht aktiv, nur auf dem dev server (ich hab 3 Server laufen, einen zum spielen 1 zum testen und einen auf einer kleineren Maschine für andere tests), der war aber auch in den scanns zu den abstürzen mit drin, trotzdem gab es hier keine neuen / anderen Erkenntnisse aus den Abstürzen.
-
Du könntest evtl. zusätzlich auch einmal folgende Einstellung zur server.properties hinzufügen:
Plugins_JNIVerbose=True
Dann werden zusätzliche Meldungen ausgegeben (gerade auch in dem oben genannten Fall, also wenn zu viele Local Refs vorhanden sind, müsste JNI dann eigentlich was ausgeben). Könnte den Log aber etwas zuspammen.
Ggf. könntest du auch Plugins_JNIXcheck=True hinzufügen, das könnte aber etwas Overhead mit sich bringen. Damit führt Java zusätzliche Validierungen und Prüfungen durch. Wichtiger wäre aber vmtl. obige JNIVerbose Einstellung
Gerade geprüft auf meinem dev server ist das sogar beides true schon

-
Ich habe mal alle SIGSEGV events aus den docker logs extrahieren lassen mit ein wenig vor und nach offsets. Dann hab ich das der KI nochmal zur Analyse übergeben. Leider auch nicht so viel neues. Ich arbeite jetzt mal aus wie ich dem Verursacher auf die schliche kommen kann.
Gestern Nacht kam es 2 mal vor, das zweite mal war relativ kurz nach dem ersten, also war der Speicher sozusagen "fresh" die anderen beiden waren am Mittag. Scheinbar ist es auch egal ob 1 oder 7 Spieler online sind, manchmal läuft er mit 7 ohne Fehler.
Hier die KI Analyse:Display MoreCode| ---------- | ---------------------------------------------------------------------------------------------------------------------- || 2026-06-08 | Größerer gemeinsamer Release-Block, unter anderem Tools 0.21.0, Shop 0.2.0, Marketplace 0.2.0, Global Intercom 0.15.0 || 2026-06-13 | Callback-Thread-Safety-Releases: Tools 0.21.1, Discord Connect 0.22.1, Global Intercom 0.15.1; weitere Plugin-Releases || -------------------------- | ---------------------------------------------------------------------------------------- || Vor Shop/Marketplace 0.1.0 | Mindestens 8 sicher datierte Ereignisse plus ein nicht eindeutig datiertes Main-Ereignis |die analysierten logs im Anhang, vor den SIGSEGV 200 Zeilen und danach 100 jeweils
-
A custom height would not fit because in reality the plugin is not using a chunk, its using a chunk-part, a chunk itself is only defined by x/z and a part is a 64 block y height. A custom height would therefor not match the current logic.
-
By the way the jail Feature is Not a Land Claim Feature, its from Admin utils.
-
The area is safe for others of you dont configure the Base area wrong. The Plugin should teleport the Player Back . But the Feature is not fully tested because missing testers. So If you find a bug just report me
-
Ja der screenshot war im verdacht, der wurde wohl auch in einem thread erstellt der außerhalb lag, das ist aber gefixt. player.createScreenshot wird verwendet.
CodeDer Befehlt ließe sich schon deaktivieren aber der ist so alt, den gabs schon in der Java version und bisher hat er nie Probleme gemacht 😅, wenn dann ist es eher mit der Anzahl der Plugins als Nebenerscheinung dazu gekommen.
In der Regel gibt's eh nur 2-3 Spieler inklusive mir die das regelmäßig nutzen um bilder ins discord zu senden. Nur 1 mal war bisher direkt danach ein crash.
Die items aus dem Shop sind auf dem Main Server raus, da gibt es nur eine kleine globale liste mit 2 items. Ich habe zwar mittlerweile auch 3 lokale shops
... aber die haben jeweils nur ein kleines Sortiment und die meisten Spieler wissen noch nicht wo die stehen 🤣
Hmm spontan wüsste ich nicht welches Plugin öfter neue Threads generieren sollte. In einem log von vorgestern wo es zwischen den Neustarts (3:00-17:00 GMT) kein crash war, ist Create new JNIEnv 192 mal zu finden.
Ja es ist schwierig herauszufinden, ich hab schon alles an logging aktiviert aber es kommt kein hint auf den Verursacher.
PS: eine hs_err_pid wird aus irgend einem Grund nie angelegt.
-
Ich hab das feature jetzt auch auf unserem Hauptserver laufen da lief es derweil gut über Tag, jetzt habe ich einen konfigurierbaren scan radius von 0-5 eingebaut und auf meinem dev server getestet, die Aufklärungsreichweite ist jetzt schon echt nice mit 5er radius. Bin gespannt wie das unter last auf meinem Hauptserver performt
-
Ich habe heute wieder einen crash gehabt. Gestern hatte ich per KI alle Plugins auf unsichere threads und kritische Strukturen prüfen lassen und es wurden auch einige Stellen umgebaut. Jetzt habe ich das neuste crashlog mal von der KI analysieren lassen und das sagt sie:
Display MoreCodeDer Crash kommt sehr wahrscheinlich aus der nativen Rising-World-JVM/JNI-Integration und nicht direkt aus einer Java-Exception eines OZ-Plugins.Der relevante Stacktrace beginnt in [prod-crash-04-c.log](/wsl2development/privat/risingworld/local.res/prod-crash-04-c.log:27097):Die JVM stürzt während der G1-Garbage-Collector-Remark-Phase ab, während sie die registrierten JVM-Threads und deren SATB-Markierungsqueues verarbeitet.Der ältere Crash in [prod-crash-01.log](/wsl2development/privat/risingworld/local.res/prod-crash-01.log:3603) hat exakt denselben Stacktrace mit denselben Funktionsoffsets:Das spricht stark für eine beschädigte oder nicht korrekt abgemeldete JNI-Thread-Struktur. Im aktuellen Lauf wurden 56 verschiedene native Threads über `Create new JNIEnv` an die JVM angehängt. Der GC scheint später über mindestens eine ungültige Thread-/SATB-Queue zu laufen.Die heute installierten Versionen entsprechen den veröffentlichten Patch-Versionen, inklusive der Threading-Fixes:Es gibt keine Plugin-Exception unmittelbar vor dem Crash. Beim aktuellen Crash wurde auch kein Screenshot ausgelöst. Beim alten Crash geschah er direkt nach einem Screenshot, war damit vermutlich nur ein GC-/JNI-Trigger und nicht zwingend die Ursache.Admin Utils Mapping erzeugte bis etwa 90 Sekunden vor dem Crash regelmäßig Chunk-Snapshots. Die Rising-World-Zugriffe erfolgen aber serververwaltet; der eigene Worker persistiert nur kopierte Daten ([RisingWorldMapChunkCapture.java](/wsl2development/privat/risingworld/rw-plugin-oz-admin-utils/src/de/omegazirkel/risingworld/adminutils/mapsource/RisingWorldMapChunkCapture.java:58)). Das Mapping kann den GC-Druck erhöhen, erklärt aber keine beschädigte GC-Threadqueue.1. **Sehr wahrscheinlich:** Fehler im Rising-World-Native-Code beim Attach/Detach von Threads an die eingebettete JVM.2. **Möglich:** Ein Plugin-Callback erhöht durch viele native Callback-Threads oder starke Allokationen die Wahrscheinlichkeit, löst aber nicht selbst direkt den SIGSEGV aus.3. **Unwahrscheinlich:** Terrainabbau durch SCA, bestimmte Chunks oder eine normale Speicherknappheit.- Beide identischen Stacktraces zusammen mit Server-Version, Commit und Hinweis auf die vielen `Create new JNIEnv`-Einträge an den Rising-World-Entwickler melden.- Beim nächsten Crash den erzeugten Core-Dump aus dem Container sichern. Ein `hs_err_pid*.log` wurde hier nicht erzeugt.Und hier das Log dazu:
-
Das ist er eigentlich auch genau wie die Hölle oder der Untergrund aber das funktioniert ja gerade nicht so ganz, das hatte ich in irgend einem anderen Thema schon angesprochen und red wollte sich darum kümmern. Ist nur die Frage ob es dann da auch fanzy sachen gibt wie Schwerelosigkeit

-
Well i want to just get the Region (Default / Dry) and if i sail with a boat and cross sector borders it always detects default = forest instead of dry
-
Mein aktuelles experimentelles feature funktioniert bisher ganz gut, die Farben sind manchmal nicht ganz korrekt aber ich hab es so gut es geht optimiert, die Karte muss jetzt allerdings explored werden wie früher, was an sich ja nicht schlimm ist
In Action hier: OZ Server Manager for Rising World auf dedizierter server klicken falls die Auswahl kommt und dann im GS1 Development Server -
It didnt work that well, even my improved version that scans the sector for indicators did not match well with the region, in most cases it just returns forest as region
-
Display MoreCoderw-docker | [06/11 18:05:23] DestroyVegetation: Bärchen1009 (DbID: 166, UID: 76561197996155079 element: 41694037(type: 13, tex: 0, ownerDbID: 166) @ chunk 350 1 2179 (11202.13, 91.1, 69749.84)rw-docker | [06/11 18:05:27] DestroyConstruction: Bärchen1009 (DbID: 166, UID: 76561197996155079 element: 41694042(type: 0, tex: 608, ownerDbID: 166) @ chunk 350 1 2179 (11201.69, 91, 69748.25)rw-docker | [06/11 18:05:28] DestroyConstruction: Bärchen1009 (DbID: 166, UID: 76561197996155079 element: 41694039(type: 0, tex: 5, ownerDbID: 166) @ chunk 350 1 2179 (11202.13, 90.8, 69748.25)rw-docker | [06/11 18:05:31] DestroyConstruction: Bärchen1009 (DbID: 166, UID: 76561197996155079 element: 41694040(type: 0, tex: 608, ownerDbID: 166) @ chunk 350 1 2179 (11202.13, 90.75, 69748.25)rw-docker | #0 0x007f0753958b66 in PosixSignals::chained_handler(int, siginfo*, void*) [clone .part.0]
Hier wieder mit einer vermeintlich anderen Fehlerquelle
-
Display MoreCoderw-docker | [06/10 21:45:53] PlaceObject: Devidian (DbID: 1, UID: 76561197972223708 element: 41329840(type: 305, tex: 0, ownerDbID: 1) @ chunk 120 2 122 (3868, 166, 3909.75)
Eine Quelle könnte der screenshot befehl sein, schon das 2. mal direkt nach einem screenshot (aber ist nicht die einzige Ursache, screenshots hat auch bisher nie probleme gemacht also liegts evtl auch woanders)
-
Display MoreCoderw-development | [19:26:43] DEBUG DiscordConnect - ✅ Sent message to #dev-server-events: james1bow hat 12 Münzen für die tägliche Login Belohnung erhalten.rw-development | [19:26:43] DEBUG LandClaim - Player james1bow spawned. Current chunk position: (104, 1, 24)rw-development | [19:26:43] [PLUGIN API] EVENT RisingWorld.PluginAPI.Events.Player.PlayerSpawnEvent TOOK 231 MS!rw-development | [12326.415s][debug][jni,resolve] Checked JNI functions are being used to validate JNI usagerw-development | [12334.861s][debug][jni,resolve] Checked JNI functions are being used to validate JNI usagerw-development | [12334.873s][debug][jni,resolve] Checked JNI functions are being used to validate JNI usagerw-development | [12335.002s][debug][jni,resolve] Checked JNI functions are being used to validate JNI usagerw-development | [12335.008s][debug][jni,resolve] Checked JNI functions are being used to validate JNI usagerw-development | [12335.008s][debug][jni,resolve] Checked JNI functions are being used to validate JNI usagerw-development | [12335.009s][debug][jni,resolve] Checked JNI functions are being used to validate JNI usagerw-development | [12338.571s][debug][jni,resolve] Checked JNI functions are being used to validate JNI usagerw-development | [19:27:16] DEBUG DiscordConnect - ✅ Sent message to #dev-server-chat: [🕹️:en] james1bow: hellorw-development | [19:27:16] [PLUGIN API] EVENT RisingWorld.PluginAPI.Events.Player.PlayerChatEvent TOOK 302 MS!rw-development | [19:27:23] DEBUG LandClaim - Player james1bow entered chunk (105, 1, 24) from chunk (104, 1, 24)rw-development | [19:27:23] DEBUG DiscordConnect - ✅ Sent message to #dev-server-chat: [🕹️:de] Devidian: hirw-development | [19:27:23] [PLUGIN API] EVENT RisingWorld.PluginAPI.Events.Player.PlayerChatEvent TOOK 241 MS!rw-development | [19:27:23] DEBUG DiscordConnect - ✅ Sent message to #dev-server-status: OZ - Discord Connect ist nun deaktiviert [Server stop] Version: 0.22.0rw-development | [12358.887s][debug][jni,resolve] Checked JNI functions are being used to validate JNI usagerw-development | [12358.888s][debug][jni,resolve] Checked JNI functions are being used to validate JNI usagerw-development | [12359.035s][debug][jni,resolve] Checked JNI functions are being used to validate JNI usagerw-development | [12359.038s][debug][jni,resolve] Checked JNI functions are being used to validate JNI usage
Wieder ein timeout auf dem dev server aber diesmal anders, james1bow kam gerade rein und kurz darauf gabs einen timeout. Sieht aus als hätte sich der Plugin Manager resettet
-
Gerne

Ansicht bearbeiten, Einträge löschen, eigene Icons, Pfeile etc. sind auch möglich - "snipping tool" kann das nicht

ok gut, aber ehrlich gesagt bin ich auch zu faul für doku, das lass ich nur noch die KI machen - dafür ist die Community zu klein das ich mir da noch selbst die Mühe mache 😅vielleicht wenn sich das mal ändern sollte. Ich behalte es im Hinterkopf
-
-
Heute war wieder ein crash, gestern lief der server den ganzen tag ohne probleme, zeitweise mit 7 Spielern. In der Nacht ist er neu gestartet, heute kaum jemand drauf gewesen doch dann wieder abgeschmiert. Ich hab ein log export über die container logs gemacht so das nicht nur die game-logs drin sind. Crash ab Zeile ~3600