Posts by Devidian

Devidian · Jun 18th 2026

Quote from noci

Kannst du mir ein Zugang machen?

Habe noch ein Fehler gefunden
und es noch Bunter gemacht

Zugang ist schwierig da es sich um webspace handelt, ich gebe ungerne ftp zugriff für externe frei. Aber du kannst mir jederzeit updates schicken. Vielleicht richte ich mal ein upload formular ein das du es selbst aktualisieren kannst.

PS: Wenn man eine checkbox an oder abwählt wird die Sektion wieder geschlossen, das solltest du fixen.

Devidian · Jun 17th 2026

Ich kann es nachher mal auf meinen Webspace laden, den hab ich schon ewig und das wird auch so bleiben 😅

EDIT: https://rw.omega-zirkel.de/tools/permission-manager.html

Devidian · Jun 17th 2026

AdminUtils aktualisiert die chunk Oberflächen für die map, allerdings habe ich das erst kürzlich aktiviert, die crashes gab es schon vorher. Ich kann es aber Zeitweise mal wieder deaktivieren und dann noch mal logs generieren.

Die KI hatte mir auch vorgeschlagen UseParallelGC oder UseSerialGC zu verwenden, aktuell hab ich letzteres aktiviert seit 9:48 heute. Bisher gab es noch keinen crash. Sollte es einen weiteren geben werde ich die Mapping Funktion aus AdminUtils deaktivieren.

Bisher habe ich noch kein Plugin das auf blueprints lauscht.

Die chunk x z Ausgabe findet hier statt: https://github.com/Devidian/rw…dMapChunkCapture.java#L30

Hier mal aus der aktuellen log session, die noch nicht abgestürzt ist:

Code

[Java] [OZ.ThreadDiagnostics] Thread summary: current=59, peak=69, totalStarted=429, names={Cleaner-0=1, Common-Cleaner=1, FileSystemWatchService=1, Finalizer=1, JDA Gateway-Worker 1=1, JDA MainWS-ReadThread=1, JDA MainWS-WriteThread=1, JDA RateLimit-Elastic-Worker 2=1, JDA RateLimit-Scheduler-Worker 1=1, JDA RateLimit-Scheduler-Worker 2=1, Notification Thread=1, OZ-ThreadDiagnostics=1, OZAdminUtils-MapSource=1, OZDiscordConnect-ActivityTimer=1, OZDiscordConnect-RestartTimer=1, OZDiscordConnect-Transport=1, PluginFileWatcher-Thread=1, ReadingThread=1, Reference Handler=1, Signal Dispatcher=1, Thread-26=1, Thread-27=1, Thread-28=1, Thread-29=1, Thread-30=1, Thread-31=1, Thread-37=1, Thread-38=1, Thread-39=1, Thread-40=1, Thread-41=1, Thread-42=1, Thread-43=1, Thread-44=1, Thread-50=1, Thread-51=1, Thread-52=1, Thread-53=1, Thread-8=1, WebSocket-Reconnect=1, WritingThread=1, httpclient-dispatch-1=1, httpclient-dispatch-10=1, httpclient-dispatch-11=1, httpclient-dispatch-12=1, httpclient-dispatch-13=1, httpclient-dispatch-14=1, httpclient-dispatch-15=1, httpclient-dispatch-16=1, httpclient-dispatch-2=1, httpclient-dispatch-3=1, httpclient-dispatch-4=1, httpclient-dispatch-5=1, httpclient-dispatch-6=1, httpclient-dispatch-7=1, httpclient-dispatch-8=1, httpclient-dispatch-9=1, httpclient-main-1=1, main=1}

Die Session lief bis zum geplanten Neustart einwandfrei durch und es waren einige Spieler aktiv

Code

[Java] [OZ.ThreadDiagnostics] Thread summary: current=65, peak=69, totalStarted=626, names={Cleaner-0=1, Common-Cleaner=1, FileSystemWatchService=1, Finalizer=1, ForkJoinPool.commonPool-worker-80=1, JDA Gateway-Worker 1=1, JDA MainWS-ReadThread=1, JDA MainWS-WriteThread=1, JDA RateLimit-Elastic-Worker 2=1, JDA RateLimit-Scheduler-Worker 1=1, JDA RateLimit-Scheduler-Worker 2=1, Notification Thread=1, OZ-ThreadDiagnostics=1, OZAdminUtils-MapSource=1, OZDiscordConnect-ActivityTimer=1, OZDiscordConnect-RestartTimer=1, OZDiscordConnect-Transport=1, OkHttp TaskRunner=4, Okio Watchdog=1, PluginFileWatcher-Thread=1, ReadingThread=1, Reference Handler=1, Signal Dispatcher=1, Thread-26=1, Thread-27=1, Thread-28=1, Thread-29=1, Thread-30=1, Thread-31=1, Thread-37=1, Thread-38=1, Thread-39=1, Thread-40=1, Thread-41=1, Thread-42=1, Thread-43=1, Thread-44=1, Thread-50=1, Thread-51=1, Thread-52=1, Thread-53=1, Thread-8=1, WebSocket-Reconnect=1, WritingThread=1, httpclient-dispatch-1=1, httpclient-dispatch-10=1, httpclient-dispatch-11=1, httpclient-dispatch-12=1, httpclient-dispatch-13=1, httpclient-dispatch-14=1, httpclient-dispatch-15=1, httpclient-dispatch-16=1, httpclient-dispatch-2=1, httpclient-dispatch-3=1, httpclient-dispatch-4=1, httpclient-dispatch-5=1, httpclient-dispatch-6=1, httpclient-dispatch-7=1, httpclient-dispatch-8=1, httpclient-dispatch-9=1, httpclient-main-1=1, main=1}
...
Invoke shutdown via command...
[WARNING] [17:02:22] Exit (0)
[WARNING] [17:02:22] Q U I T   R I S I N G   W O R L D   S E R V E R
Stopping Webserver...
STEAM SERVER SHUTDOWN
...
JNI: DESTROY JAVA VM
Create new JNIEnv  (handle: 93843685619264, thread: 95460)
[Java] [OZLogger] Terminating Log4j framework globally.
NativeMemoryManager: Free 30855 memory pointers (305333707 B)...
[END]

Display More

interessant ist hier das er shutdown macht aber danach 5 mal neustarten muss weil er das problem mit dem port hat. Du hattest mal gesagt das man in den settings Server_RestartEnabled=False verwenden soll, aber geholfen hat es nicht

Da kommt dann immer das hier:

Code

Create Public Webserver IP: 0.0.0.0 Port: 4254
Add Prefix: /
Add Prefix: /info
Add Prefix: /playerlist
Add Prefix: /images/header
Add Prefix: /game/maptile
Add Prefix: /game/image
Add Prefix: /game/asset
Add Prefix: /game/chunkmultirequest
[ERROR] [17:04:05]  !!! UNCAUGHT EXCEPTION !!! 
    UnityEngine.DebugLogHandler:Internal_Log(LogType, LogOption, String, Object)
    RisingWorld.Server.Main:HandleError(Exception)
    RisingWorld.Common.JIWApplication:Update()


[ERROR] SocketException: Address already in use
    System.Net.Sockets.Socket.Bind (System.Net.EndPoint localEP) (at <00000000000000000000000000000000>:0)
    NetCoreServer.TcpServer.Start () (at <00000000000000000000000000000000>:0)
    RisingWorld.Server.Main.InitWebserver () (at <00000000000000000000000000000000>:0)
    RisingWorld.Server.Main.OnPostInitialize () (at <00000000000000000000000000000000>:0)
    RisingWorld.Common.JIWApplication.Update () (at <00000000000000000000000000000000>:0)
    ExceptionExtensions:PrintStackTrace(Exception)
    RisingWorld.Server.Main:HandleError(Exception)
    RisingWorld.Common.JIWApplication:Update()


[WARNING] [17:04:05] Exit (1)
[WARNING] [17:04:05] Q U I T   R I S I N G   W O R L D   S E R V E R
Stopping Webserver...
STEAM SERVER SHUTDOWN

Display More

Und im Discord sieht das so aus:

kann ich den Xms wert eigentlich auch über eine server property steuern oder muss ich den mit Plugins_VMOptions überschreiben? Die KI meint der Wert wäre etwas niedrig gewählt

PS: Die Nachtsession lief auch durch. Wenn der heutige Tag auch ohne SIGSEGV oder anderem Absturz läuft schalte ich morgen früh mal auf ParallelGC

Devidian · Jun 17th 2026

The game does not have any real groups, there is no function to invite other players to "YOUR" party/group so an admin has to decide which players are in which group. By default any player who joins is in the default group so all default group players share the default player group markers. If you as admin create a new group permission file called "super cool secret friends group" and add 5 people to it, they share their group markers. If they quit the game the markers are still there but if you as admin don't add new players to the abounded group, there is no posibillity for other players to see the markers of that group.

Devidian · Jun 17th 2026

ok, if you mean you see offline player marker ... this is intended, they are saved on the server and for the group so i dont get it. What is your problem?

You are always in some kind of group, even if it is the default or "null" group.

Devidian · Jun 17th 2026

Group markers are ... group markers so if you are in the same group as other players you will see all markers of that group, no matter who created it. Even as admin you should only see the group markers of your group. So for example if you have player A-F and put them in group A besides from your default player permission group, they wont see the default player group markers anymore but they ALL will see markers created from people in that group A.

If you dont have any permission groups and all players are in the default group (you too) then you will of course soo all players group markers because you are all in the same group.

Devidian · Jun 17th 2026

Gestern wars ganz schlimm, gefühlt gibt es mehr SIGSEGV seit ich das extra JNI logging aktiviert habe. Ich habe das 26MB log von gestern gesplittet und alle sessions mit SIGSEGV lade ich hier mal hoch. Auffällig war nur das ein Spieler auch sagte er habe vorher mit einer Blaupause hantiert direkt vor dem crash.

session6 war übrigens mit einer neuen Discord Plugin version, ich habe bei dem Plugin die veraltete JavaCord lib gegen JDA ausgetauscht in der Hoffnung auf Besserung aber ich war nur kurz da und hab ein paar Steine gehauen als er wieder abgeschmiert ist.

Devidian · Jun 16th 2026

Ich verstehe was du meinst, das ist jedoch kompliziert umzusetzen. Ich meine rein theoretisch ist alles möglich aber...

... wenn man das dynamisch gestalten will muss man Regeln definieren welche area-permissions als owner permissions gelten z.b. um sowas zu bestimmen wer die Spiellerrechte des Claims bearbeiten kann, das können nur owner, dabei kann er/sie natürlich keinen weiteren owner bestimmen und auch seine eigene permission nicht. Ein Admin muss außerdem dann irgendwo definieren können gruppeA=>areaOwnerA gruppeB=>areaGruppeB etc. und da die Zuordnung später nicht geändert werden kann würde jemand der vorher in gruppeA war und zu gruppeB promoted wurde nicht automatisch in allen areas auch areaGruppeB bekommen, dafür müsste man dann auch noch entsprechend sorgen.

... wenn man das ganze statisch handhaben würde müsste ich eine Anzahl X an verschiedenen Owner-Typen vorgeben und Admins müssten diese entsprechend anpassen nach ihren Bedürfnissen. Da ist halt die Frage wie viele slots definiere ich, wie viele braucht man? Ist sicher einfacher als eine dynamische Zuordnung trotzdem muss auch hier behandelt werden was passiert wenn eine spielergruppe geändert wird.

Devidian · Jun 16th 2026

Naja es soll eine Server Einstellung sein und du musst ja nicht auf einem Server spielen der nur Server Blaupausen erlaubt. Und ich möchte schon das man Blaupausen verwenden kann, wenn man z.b. Strassen oder Wege kopiert, es dürfen auch objekte dabei sein - vorrausgesetzt die Blaupausen kosten dann endlich mal Material - alles kein problem. Mein Problem ist eher das Leute frisch auf den Server kommen und einfach irgendwas hinstellen was sie vielleicht noch nicht einmal selbst erstellt haben, ich meine Sobald Materialkosten für Blaupausen implementiert sind ist das Hauptproblem schon mal beseitigt, das neulinge sich eine All-In-Wonder Blaupause hinstellen ohne Material zu beschaffen, dennoch wäre es gut wenn ich als Admin sagen könnte das Spieler in der default gruppe nur Blaupausen verwenden dürfen von dingen die sie bereits auf dem server gebaut haben.

Und es gibt ja immer noch die Möglichkeit einen download anzubieten im falle der Server gespeicherten Blaupausen

Devidian · Jun 16th 2026

Moin, abgesehen von den schon angesprochenen Änderungen an Blaupausen kam mir noch folgender Gedanke ...

Ich würde es begrüßen die Möglichkeit zu haben das man Blaupausen auf die aktuelle Welt Begrenzen kann, oder anders gesagt das man nur Blaupausen verwenden kann die auf dem aktuellen Server auch erstellt wurden, um zu verhindern das irgendjemand seine Bauwerke die er woanders erstellt hat einfach platziert.

Manche Bauten sind zwar echt schön, aber als Admin hab ich es lieber wenn die Leute etwas neues Bauen und nicht einfach etwas von einem anderen Server kopieren (vielleicht sogar noch von einem anderen Spieler)

Am besten über die bestehende permissions section, so das man das von den Rechten abhängig machen kann, so kann man vertrauenswürdigen Bauern auch externe erlauben.

Eine andere Lösung wäre das die Blaupausen auf dem Server pro Spieler gespeichert werden, das hätte auch den Vorteil als Nebeneffekt das man Blaupausen über ein Plugin handelbar machen könnte ,

Devidian · Jun 15th 2026

Ich weiss nicht obs relevant ist aber eben habe ich eine Blaupause machen wollen und genau dann ist er abgeschmiert. Ist zumindest mal was anderes.

Devidian · Jun 15th 2026

Ich habe die logs mit docker compose logs --since ... > umgeleitet um auch die start und end echos vom entrypoint.sh script mit zu haben.

Das angehängte log hat 3 Sessions, eine kurze eine lange, beide mit SIGSEGV und eine "normale" danach die wegen fehlendem freien port beendet wurde.

An diesem log sieht man sehr schön das es komplett random erscheint wann der prozess abschmiert.

Devidian · Jun 15th 2026

Hier mal ein log von prod, über docker logs, da sind jetzt auch die JNI werte=true mit dabei. Es gab direkt einen Absturz nach dem ein Spieler rein kam, obwohl der Server erst kurz vorher neu gestartet wurde.

Hier sind auch die diagnose-tools dabei die ich hab einbauen lassen. diag-crash-01.log

Gestern hatte ich die Diagnose auf meinem development server aktiviert da war die session bis zum regulären Neustart ohne crash. 2026-06-14-21-08-41.log (game-logs, keine docker logs, kann ich aber nachreichen)

Aber es gab wohl ein paar native threads die nie beendet wurden

Ich habe die KI die logs analysieren lassen, das ist ihre Meinung:

Code

# Bugs 05 Thread Audit

## Verified PluginAPI Mechanism

PluginAPI `0.9.2` exposes:

- `Plugin.enqueue(Runnable)` for server-thread dispatch
- `Plugin.isMainThread()` for execution-context checks
- `Plugin.executeDelayed(float, Runnable)` for delayed server-managed work

Tools owns `ServerThreadDispatcher`, a lifecycle-bound wrapper around
`isMainThread()` and `enqueue(...)`. Foreign callbacks must pass immutable data
into this dispatcher and must not retain Rising World API objects.

## Initial Inventory

| Repository                                  | Foreign-thread entry point              | Current disposition                                                                                        |
| ------------------------------------------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| Tools                                       | `PluginFileWatcher` callbacks           | Remediated through server-thread dispatcher                                                                |
| Tools                                       | `PluginReloadDebouncer`                 | Remediated: worker dispatches before scheduling server-managed delayed execution                           |
| Tools                                       | `WSClientEndpoint` callbacks            | Foreign-thread transport callbacks; consumers must dispatch before game API access                         |
| Tools                                       | Log4j JVM shutdown hook                 | No game API access                                                                                         |
| Discord Connect                             | JavaCord message listener               | Remediated through server-thread dispatcher                                                                |
| Discord Connect                             | JavaCord slash-command listener         | Remediated through server-thread dispatcher; blocking Discord response waits removed                       |
| Discord Connect                             | restart `java.util.TimerTask`           | Remediated: timer enqueues game operations only                                                            |
| Discord Connect                             | activity `java.util.TimerTask`          | Remediated through server-thread dispatcher                                                                |
| Discord Connect                             | screenshot callbacks                    | Remediated: stable IDs/immutable values only; notifications dispatched                                     |
| Discord Connect                             | async HTTP callbacks and JavaCord sends | Remediated: immutable transport inputs on bounded lifecycle-owned worker; no retained game objects         |
| Global Intercom                             | Tools WebSocket callbacks               | Remediated through server-thread dispatcher                                                                |
| Global Intercom                             | screenshot callbacks                    | Remediated: transport-only callback, no retained player                                                    |
| Admin Utils                                 | map capture worker                      | Safe pattern: game reads before worker; immutable data persistence on worker                               |
| Shop, Land Claim, GPS, Tools UI             | PluginAPI `Timer` callbacks             | Managed by PluginAPI `PluginTimerManager`; explicit thread guarantee absent, runtime verification required |
| Tools                                       | `SQLiteCachedStore` flush timer         | PluginAPI timer; database/cache only, no game objects                                                      |
| Rewards, Shop, GPS, Marketplace, Land Claim | reflection bridges                      | Synchronous plugin-to-plugin calls from existing game/plugin call paths; no owned worker threads           |

## Completed Static Scan

The portfolio scan covered all Java sources outside generated `target/` and
`dist/` trees for:

- Java threads, executors, scheduled executors, futures, and `TimerTask`
- JavaCord message/slash listeners and asynchronous HTTP callbacks
- WebSocket handlers and reconnect workers
- screenshot callbacks
- PluginAPI `Timer` usage
- `FileChangeListener` implementations
- reflection/proxy plugin bridges

No additional owned Java worker was found that directly accesses Rising World
objects or static game APIs. Development runtime logging confirmed PluginAPI
`Timer` callbacks execute on the server thread.

## Lifecycle Inventory

Only thread termination or disappearance from JVM thread snapshots is
observable. The diagnostics cannot reliably determine whether a terminated
thread is already eligible for garbage collection or has been collected.

| Owner/source                  | Thread name                      | Creation frequency                                                    | API access                                                    | Shutdown behavior                                      | Expected lifetime                  | Known risk                                      |
| ----------------------------- | -------------------------------- | --------------------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------ | ---------------------------------- | ----------------------------------------------- |
| Tools file watcher            | `PluginFileWatcher-Thread`       | once per Tools enable                                                 | filesystem only; callbacks dispatch to server thread          | watcher and executor closed on Tools disable           | Tools enable lifetime              | blocked watch or missed shutdown                |
| Tools reload debouncer        | `PluginReloadDebouncer-Thread`   | once per Tools enable, thread created on first task                   | dispatches reload request to server thread                    | scheduler stopped on Tools disable                     | idle/on-demand during Tools enable | delayed task retaining plugin callback          |
| Tools WebSocket reconnect     | `WebSocket-Reconnect`            | once per endpoint instance, thread created on first work              | transport callbacks only                                      | all endpoints stopped on Tools disable                 | endpoint lifetime                  | library threads or reconnect churn              |
| Tools Log4j shutdown hook     | `OZ-Log4j-Terminator`            | once per JVM                                                          | no game API access                                            | runs only during JVM shutdown                          | JVM lifetime                       | intentionally remains across plugin reloads     |
| Discord transport executor    | `OZDiscordConnect-Transport`     | once per Discord Connect enable, thread created on first work         | transport only                                                | bounded executor drained/stopped on disable            | Discord Connect enable lifetime    | blocking HTTP operations delaying shutdown      |
| Discord restart timer         | `OZDiscordConnect-RestartTimer`  | once per Discord Connect enable                                       | callback dispatches to server thread                          | tasks cancelled; timer cancelled and purged on disable | Discord Connect enable lifetime    | fixed: former classloader/reload retention      |
| Discord activity timer        | `OZDiscordConnect-ActivityTimer` | once per Discord Connect enable                                       | callback dispatches to server thread                          | tasks cancelled; timer cancelled and purged on disable | Discord Connect enable lifetime    | fixed: former classloader/reload retention      |
| Admin Utils map source worker | `OZAdminUtils-MapSource`         | once per Admin Utils enable, thread created on first persistence task | immutable data persistence only                               | executor interrupted and awaited on disable            | Admin Utils enable lifetime        | database operation can delay shutdown           |
| JavaCord                      | library-defined                  | library managed                                                       | Discord API only; listeners dispatch before game API access   | `JavaCordBot.disconnect()` on Discord disable          | bot connection lifetime            | library-owned thread churn must be measured     |
| WebSocket library             | library-defined                  | per socket/connection as managed by library                           | transport only                                                | socket disconnect through Tools endpoint shutdown      | connection lifetime                | library-owned thread churn must be measured     |
| Apache Async HTTP             | library-defined                  | currently per asynchronous client use                                 | transport only                                                | client closes after request scope                      | request lifetime                   | repeated client creation may cause thread churn |
| Screenshot callbacks          | API-defined                      | per screenshot request                                                | immutable values and transport; server notifications dispatch | API-managed completion                                 | request lifetime                   | callback thread lifecycle is API-owned          |
| PluginAPI timers              | API-defined server/timer threads | per registered PluginAPI timer                                        | plugin-specific; runtime observed on server thread            | PluginAPI/plugin lifecycle managed                     | timer/plugin lifetime              | explicit API thread guarantee is absent         |
| PluginAPI server threads      | API-defined                      | JVM/server managed                                                    | game API owner                                                | server lifecycle managed                               | server lifetime                    | JVM-wide behavior is measured only              |

## Diagnostic Instrumentation

OZTools `0.21.2` adds the default-disabled `threadDiagnosticsEnabled=false`
setting. When enabled, `OZ.ThreadDiagnostics` samples JVM threads every five
seconds, reports new and disappeared thread IDs, and writes grouped summaries
every minute. Tools-owned file watcher, reload debouncer, WebSocket reconnect,
Discord transport, and Admin Utils map source workers additionally log exact
creation, start, and end events through `DiagnosticThreadFactory`.

The Apache HTTP, JavaCord, WebSocket library, screenshot callback, and PluginAPI
thread implementations remain unchanged in this work package and are measured
only.

## Runtime Validation Still Required

- Enable diagnostics on Development and perform repeated plugin reloads.
- Verify both Discord timer threads disappear after every disable/reload.
- Record JavaCord, WebSocket, Apache HTTP, and screenshot callback thread churn.
- Optionally enable diagnostics on Main and correlate summaries with later
  SIGSEGV timestamps.

## Development Observation 2026-06-14

Source: `local.res/2026-06-14-21-08-41.log`, approximately 21:08:41 through
21:17:14, without a plugin reload or crash.

- Diagnostics started successfully. Controlled long-lived workers appeared
  exactly once: `PluginFileWatcher-Thread`, `WebSocket-Reconnect`,
  `OZDiscordConnect-Transport`, and both Discord timer threads.
- After startup transients ended, the steady JVM-visible thread count was 29.
  First screenshot/Java2D use raised the apparent steady count to about 31.
- Peak thread count was 35. Total-started count rose from 38 to 57 while
  Discord messages and screenshots were exercised, but transient workers
  subsequently disappeared and the current count returned toward the steady
  baseline. No unbounded thread-count growth was observed.
- JavaCord/Okio repeatedly created short-lived `Javacord - Handlers Processor`,
  `Javacord - Event Dispatch Queues Manager`, `Javacord - Central
ExecutorService - N`, and `Okio Watchdog` threads. Observed lifetimes were
  approximately 60 to 80 seconds. This is measurable churn, not a confirmed
  leak.
- Persistent JavaCord/WebSocket transport threads remained stable:
  `Javacord - Central Scheduler - 1`, request-member consumer, frame sender,
  `OkHttp discord.com`, one `OkHttp TaskRunner`, two `ReadingThread`, and two
  `WritingThread`.
- Generic daemon threads `Thread-8` through `Thread-12` appeared during player
  connect/world initialization. `Thread-13` appeared after the first screenshot
  and remained. Their stacks were empty at each sample, so ownership is not yet
  proven. Additional screenshots did not create further generic threads in
  this observation window.
- No Apache Async HTTP worker was long-lived enough to appear under an
  identifiable Apache thread name at the five-second sampling interval.
- No Admin Utils map-source worker appeared, so that worker lifecycle was not
  exercised.
- No reload occurred, so disappearance and recreation of the fixed Discord
  timer threads remains unverified by runtime logs.
- The only server warnings were three `ChunkMultiRequest: Unable to create
chunk!` messages during player/world loading. No Java exception, fatal error,
  rejected transport task, queue overflow, or crash marker was present.

### First Plugin Reload

At 21:21:03, `rp` successfully initiated a full plugin reload. The captured log
continues only until approximately 21:21:16, while plugin enable was still in
progress.

- Controlled Tools and Discord executor workers logged exact shutdown:
  `OZ-ThreadDiagnostics`, `PluginFileWatcher-Thread`, `WebSocket-Reconnect`,
  and `OZDiscordConnect-Transport` all emitted `Thread ended`.
- The pre-reload Discord timers had IDs 43 and 44. Neither was present in the
  first post-reload snapshot. New lifecycle-bound timers appeared with IDs 108
  and 109. This runtime observation confirms the Discord timer leak fix for one
  reload cycle.
- New controlled workers were created after reload with new IDs:
  `OZDiscordConnect-Transport` 132, diagnostics 133, file watcher 136, and
  WebSocket reconnect 137.
- The first post-reload snapshot still contained four old JavaCord/OkHttp
  threads alongside newly created equivalents: `OkHttp discord.com` 59,
  `OkHttp TaskRunner` 61, JavaCord request-member consumer 71, and JavaCord
  frame sender 72. Later snapshots confirmed that all four disappeared. The
  request-member consumer and frame sender ended after approximately 45 to 60
  seconds; the old OkHttp connection and task runner remained for approximately
  six minutes. This confirms delayed cleanup rather than a retained reload leak
  in this observation.
- The old JavaCord scheduler and Discord WebSocket `ReadingThread` /
  `WritingThread` IDs were absent and were replaced by new IDs, indicating that
  most Discord connection lifecycle threads did terminate.
- Tools shuts down all logger contexts before later plugins finish disable and
  before all plugins complete re-enable. This produced extensive
  `OZTools.s is null` fallback messages and one Log4j default-configuration
  warning from `Thread-13`. This is a confirmed reload-order logging problem,
  separate from the Discord timer fix.
- File-watcher interruption during expected shutdown is logged as
  `InterruptedException: null`; this is harmless shutdown noise but should not
  be emitted at fatal/error severity.

### Extended Post-Reload Observation

The log continues through approximately 22:01:43, around 40 minutes after the
reload.

- Controlled plugin threads remained singular and stable. No duplicate Tools,
  Discord timer, Discord transport, WebSocket reconnect, or Admin Utils map
  worker remained after transients settled.
- JavaCord/OkHttp activity repeatedly raised the current count to 43-48 and the
  total-started count to 131. The short-lived workers consistently disappeared
  after roughly 60-95 seconds. Long-lived OkHttp connection/task pairs remained
  for approximately 6-11 minutes before disappearing. This remains churn, not
  an observed leak.
- The stable current count after reload rose from approximately 34 to 38-40.
  `OZAdminUtils-MapSource` accounts for one expected persistent thread.
- The remaining increase is a set of generic daemon threads with empty sampled
  stacks: `Thread-24` through `Thread-30`. They appeared during ordinary world
  interaction such as object/furnace use, damage, chunk/world-part generation,
  terrain/vegetation changes, and storage work. `Thread-31` appeared when the
  player disconnected.
- Each new generic `Thread-N` was preceded by the server's native
  `Create new JNIEnv` output on a previously observed native server thread.
  This strongly suggests Rising World or PluginAPI-attached native callback
  threads rather than plugin-owned Java executors. None of these generic
  threads disappeared during the observation window. Their continuing
  accumulation is the primary thread-lifecycle anomaly to correlate with
  longer runs and future crashes.
- Managed memory remained broadly stable around 133-143 MB. Committed JVM
  memory increased from approximately 128 MB to 175 MB but stayed far below the
  2 GB maximum. Reported current native memory oscillated between approximately
  9 MB and 480 MB, primarily because the reported active `Cpp` allocation
  switched between zero and approximately 470 MB; it repeatedly returned to
  the low state. The log does not demonstrate monotonic current-memory growth.
- No Java exception, fatal error, deadlock, rejected task, queue overflow,
  SIGSEGV marker, or crash was logged in the extended window.

### Complete Run Through Regular Shutdown

The completed log continues through the scheduled shutdown at 00:00:09.

- `Thread-24` through `Thread-31` remained present in every final diagnostic
  summary, including the last summary at approximately 23:59:54. No
  `Thread disappeared` event was logged for any of them. They therefore
  remained alive for hours after the player disconnected and until diagnostics
  stopped during regular JVM shutdown.
- The steady pre-shutdown count remained at 39 threads. The generic daemon
  threads account for the persistent increase observed after player activity;
  the completed run does not support interpreting them as short-lived callback
  workers.
- The controlled `OZ-ThreadDiagnostics` worker ended during plugin-manager
  shutdown before Log4j termination. The completed run therefore confirms the
  intended Tools diagnostic lifecycle on regular server shutdown.
- Discord/JavaCord initiated a fresh OkHttp connection and additional
  JavaCord/OkHttp workers immediately before and during shutdown. The log ends
  before diagnostics can observe their cleanup. This is shutdown-time churn,
  not evidence of a retained thread after JVM termination, but should be
  correlated with future shutdown and crash logs.
- The server reached `[END]` without a SIGSEGV or other crash marker.

## Main Crash Observation 2026-06-15

Sources: `local.res/2026-06-15-06-27-01.log` and
`local.res/diag-crash-01.log`.

- The diagnosed Main session crashed at 06:43:47, approximately 0.15 to
  0.20 seconds after player `Boss` connected.
- The last summary before the crash was stable at `current=23`, `peak=32`, and
  `totalStarted=41`. Every controlled Tools and Discord thread was singular.
- Only generic daemon `Thread-8` was present. The Development accumulation of
  generic `Thread-24` through `Thread-31` was not present in this session.
- Native server threads created new `JNIEnv` handles during the player-connect
  path immediately before the SIGSEGV. The full native trace enters
  `checked_jni_SetObjectArrayElement` and the G1 SATB post-write barrier while a
  native caller invokes a static Java boolean method.
- The crash therefore does not correlate with Java-visible thread-count growth
  or an owned-plugin-thread leak. It remains compatible with a native
  PluginAPI/JNI callback race or previously corrupted JNI state.
- The crash occurred before the next five-second sample, so diagnostics could
  not determine whether either newly attached native thread would have appeared
  as another persistent generic Java thread.
- A following clean session again created a single generic `Thread-8`, making
  that thread routine rather than uniquely predictive of the crash.
- The previous Docker session reached `[END]` during a regular restart and then
  received `SIGABRT`. This is a separate native shutdown-lifecycle anomaly.

## Remaining Inventory Work

- Complete the Discord slash-command request/result DTO split. Blocking
  JavaCord response waits have already been removed.
- Replace parsed Global Intercom entity DTOs with immutable message values;
  JSON parsing already occurs before server-thread dispatch.
- Add focused regression tests for remaining plugin-specific callback
  boundaries. Dispatcher lifecycle and exception isolation are covered.

Display More

Devidian · Jun 15th 2026

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.

Devidian · Jun 15th 2026

Quote from red51

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.

Devidian · Jun 14th 2026

Quote from red51

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

Devidian · Jun 14th 2026

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:

Code

# SIGSEGV-Analyse Main- und Development-Server

Stand: 2026-06-14  
Quellen: `local.res/SIGSEGV-A.log`, `local.res/DEV-SIGSEGV-A.log`, Plugin-`HISTORY.md`-Dateien

## Kurzfazit

- Die beiden Dateien enthalten **41 echte SIGSEGV-Ereignisse**:
  - Main-Server: **19**
  - Development-Server: **22**
- Die Rohzahl der Zeilen `Received signal SIGSEGV` ist höher (**54**), weil zwei
  Abstürze das Signal mehrfach ausgegeben haben. Als Ereigniszähler wurde deshalb
  jeweils `Obtained ... stack frames` verwendet.
- Das erste nachgewiesene Ereignis trat am **2026-03-10 um ca. 11:30:57** auf dem
  Main-Server auf.
- **39 von 41 Ereignissen (95,1 %) sind G1-Garbage-Collector-bezogen.**
- **37 von 41 Ereignissen (90,2 %) zeigen dieselbe dominante Signatur:**
  `G1SATBMarkQueueSet::filter(SATBMarkQueue&)`.
- Zwei Ereignisse bilden eine klar abweichende Klasse und traten während eines
  Server-Shutdowns beziehungsweise Restarts auf.
- Shop und Marketplace können nicht die ursprüngliche Ursache sein: Das erste
  Ereignis liegt mehr als zwei Monate vor deren Erstveröffentlichung am
  2026-05-26.
- Ein direkter Zusammenhang zwischen einzelnen Plugin-Releases und dem gesamten
  Auftreten ist aus diesen Daten **nicht nachweisbar**. Plugin-Last, Plugin-Reloads
  und fremde Callback-Threads bleiben aber plausible indirekte Verstärker.

## Methodik und Einschränkungen

- Ein echtes Ereignis wurde über genau einen Stacktrace-Eintrag
  `Obtained ... stack frames` gezählt.
- Datum und Uhrzeit wurden primär aus dem unmittelbar folgenden Server-Neustart
  und ergänzend aus Zeitstempeln vor dem Signal abgeleitet.
- Die Dateien enthalten pro Treffer nur ungefähr 200 Zeilen vor und 100 Zeilen
  nach dem Signal. Bei längeren Starts fehlt deshalb teilweise die datierte
  Versionszeile.
- Einige Daten sind anhand der chronologischen Position und benachbarter
  Ereignisse eingegrenzt, aber nicht sekundengenau beweisbar.
- Release-Daten zeigen nicht zwingend den tatsächlichen Installationszeitpunkt auf
  Main oder Development.
- Die Logs erlauben Korrelationen, aber keinen kausalen Beweis.

## Gesamtstatistik

| Kennzahl                                        | Main | Development | Gesamt |
| ----------------------------------------------- | ---: | ----------: | -----: |
| Echte SIGSEGV-Ereignisse                        |   19 |          22 |     41 |
| Rohzeilen `Received signal SIGSEGV`             |   31 |          23 |     54 |
| Dominante `G1SATBMarkQueueSet::filter`-Signatur |   17 |          20 |     37 |
| Andere G1-GC-Signatur                           |    1 |           1 |      2 |
| Abweichende Shutdown-/Restart-Signatur          |    1 |           1 |      2 |

## Zeitliche Verteilung

### Main-Server

| Datum                     | Anzahl | Bemerkung                                    |
| ------------------------- | -----: | -------------------------------------------- |
| 2026-03-10                |      1 | Erstes nachgewiesenes Ereignis; Server 0.9.1 |
| 2026-05-02                |      1 | Server 0.9.2                                 |
| 2026-05-14                |      1 | Shutdown/Restart-Sonderfall; Server 0.9.2.1  |
| 2026-05-14 bis 2026-05-30 |      1 | Exaktes Datum im Ausschnitt nicht enthalten  |
| 2026-05-30                |      1 | Dominante G1-Signatur                        |
| 2026-06-02                |      2 | Dominante G1-Signatur                        |
| 2026-06-05                |      1 | Dominante G1-Signatur                        |
| 2026-06-08 bis 2026-06-09 |      3 | Zwei Daten aus Logfolge eingegrenzt          |
| 2026-06-10                |      2 | Dominante G1-Signatur                        |
| 2026-06-11                |      1 | Dominante G1-Signatur                        |
| 2026-06-13                |      1 | Dominante G1-Signatur                        |
| 2026-06-14                |      4 | 01:08, 01:29, 11:29 und 12:21                |

### Development-Server

| Datum                      | Anzahl | Bemerkung                                              |
| -------------------------- | -----: | ------------------------------------------------------ |
| 2026-05-22                 |      2 | Beide während hoher i18n-/Plugin-Aktivität             |
| 2026-05-24                 |      1 | Dominante G1-Signatur                                  |
| 2026-05-25                 |      2 | Mindestens eines während Plugin-Deaktivierung          |
| 2026-05-26                 |      2 | Plugin-Start-/Reload-Aktivität                         |
| 2026-06-01                 |      1 | Dominante G1-Signatur                                  |
| 2026-06-03                 |      5 | Auffälliger Cluster; ein abweichender G1-ParScan-Trace |
| 2026-06-05, wahrscheinlich |      1 | Datum im Ausschnitt nicht vollständig enthalten        |
| 2026-06-06                 |      1 | Dominante G1-Signatur                                  |
| 2026-06-07                 |      3 | Cluster innerhalb weniger Stunden                      |
| 2026-06-08                 |      1 | Dominante G1-Signatur                                  |
| 2026-06-09                 |      1 | Dominante G1-Signatur                                  |
| 2026-06-11, wahrscheinlich |      1 | Datum im Ausschnitt nicht vollständig enthalten        |
| 2026-06-12                 |      1 | Shutdown/Restart-Sonderfall                            |

## Stacktrace-Klassen

### Klasse A: G1 SATB Mark Queue

**37 Ereignisse, 90,2 %**

Typischer Trace:

```text
JVM_handle_linux_signal
G1SATBMarkQueueSet::filter(SATBMarkQueue&)
SATBMarkQueueSet::flush_queue(SATBMarkQueue&)
G1RemarkThreadsClosure::do_thread(Thread*)
G1CMRemarkTask::work(unsigned int)
WorkerThread::run()
```

Diese starke Wiederholung spricht gegen 37 unabhängige Pluginfehler. Der
unmittelbare Crash liegt im nativen JVM-G1-Garbage-Collector während der
Remark-/SATB-Verarbeitung.

Mögliche Erklärungen:

1. Fehler in der eingebetteten JVM oder ihrer Integration in den nativen
   Rising-World-Server.
2. Bereits zuvor beschädigter JVM-/JNI-Zustand, der erst während G1-GC sichtbar
   wird.
3. Race Condition durch PluginAPI-, Callback- oder Lifecycle-Aufrufe von fremden
   Threads.
4. Hohe Allokations- oder Objektlebenszyklus-Last als Auslöser, ohne selbst die
   Grundursache zu sein.

### Klasse B: Andere G1-GC-Pfade

**2 Ereignisse, 4,9 %**

- Main, 2026-06-14 01:29:
  `G1ParScanThreadState::steal_and_trim_queue(...)`
- Development, 2026-06-03 14:52:
  `G1ParScanThreadState::trim_queue_to_threshold(...)`

Beide Ereignisse bleiben G1-GC-bezogen und stützen die JVM-/JNI-/Threading-
Hypothese. Beim Main-Ereignis wurde dieselbe Signalzeile 13-mal ausgegeben; dies
ist ein einzelner Absturz, kein 13-facher Cluster.

### Klasse C: Shutdown-/Restart-Sonderfälle

**2 Ereignisse, 4,9 %**

1. Main, 2026-05-14 ca. 17:00:
   - geplanter Neustart
   - Plugin-Deaktivierung und Logger-Shutdown
   - `JNI: DESTROY JAVA VM`
   - anschließend `OZ.DiscordConnect Force server restart now!`
   - Crash in `oopDesc::metadata_field` / `jni_NewObjectArray`

2. Development, 2026-06-12 ca. 22:03:
   - Spieler löst Server-Restart aus
   - Server befindet sich bereits im Quit-/Disconnect-Ablauf
   - abweichender 4-Frame-Trace mit unbekannter Zieladresse

Diese beiden Ereignisse sehen nach Aufrufen gegen eine bereits herunterfahrende
oder zerstörte Java-/JNI-Runtime aus. Sie sollten separat von den dominanten
G1-Runtime-Abstürzen behandelt werden.

## Kontext unmittelbar vor den Abstürzen

- Mindestens **13 Ereignisse** zeigen im begrenzten Vorlauf deutliche
  Plugin-Start-, Plugin-Reload-, i18n-Lade- oder Deaktivierungsaktivität.
- Besonders der Development-Server zeigt mehrere Abstürze direkt während großer
  Plugin-Lade-/Reload-Sequenzen.
- Zwei Ereignisse treten eindeutig während Shutdown/Restart auf.
- Viele Main-Ereignisse passieren während normalem Spielbetrieb. Die letzten
  Aktionen unterscheiden sich stark, zum Beispiel Chat, Platzieren, Crafting
  oder allgemeine Serveraktivität.
- Es gibt daher keinen einzelnen Spielbefehl oder ein einzelnes Plugin-Feature,
  das allen Ereignissen unmittelbar vorausgeht.

Die wiederholten Meldungen `OZTools.s is null` während Plugin-Initialisierung sind
auffällig, beweisen aber keinen Zusammenhang mit dem SIGSEGV. Sie zeigen vor allem
komplexe Plugin-Initialisierung und potenziell ungünstige Lifecycle-Reihenfolgen.

## Vergleich mit Plugin-Releases

### Relevante Release-Daten

| Datum      | Releases mit möglicher Relevanz                                                                                        |
| ---------- | ---------------------------------------------------------------------------------------------------------------------- |
| 2026-03-10 | Discord Connect 0.20.0                                                                                                 |
| 2026-05-26 | Shop 0.1.0, Marketplace 0.1.0 sowie mehrere Shared-UI-Releases                                                         |
| 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 |

### Bewertung

#### Shop und Marketplace

- Das erste SIGSEGV-Ereignis ist vom **2026-03-10**.
- Shop und Marketplace wurden laut Changelog erstmals am **2026-05-26**
  veröffentlicht.
- Damit sind beide als ursprüngliche Ursache ausgeschlossen.
- Ein indirekter Einfluss durch zusätzliche Allokationen, UI-Objekte,
  Datei-Reloads oder Plugin-Interaktionen bleibt möglich.

#### Global Intercom

- Global Intercom besitzt laut Changelog bereits Releases aus 2019 und 2025.
- Aus den vorliegenden Dateien lässt sich deshalb nicht belegen, dass das erste
  SIGSEGV vor jeder Global-Intercom-Nutzung lag.
- Die Release-Reihe ab 2026-05-26 kann indirekt relevant sein, insbesondere wegen
  WebSocket-Callbacks und spielseitigen Operationen aus fremden Threads.

#### Releases vom 2026-06-08

- Nach diesem größeren Release-Block treten auf beiden Servern weiterhin
  zahlreiche Ereignisse auf.
- Das ist mit einem indirekten Last- oder Threading-Einfluss vereinbar, beweist
  ihn aber nicht, da die dominante G1-Signatur bereits vorher vorhanden war.

#### Callback-Thread-Safety-Releases vom 2026-06-13

- Diese Releases adressieren genau eine plausible Risikoklasse:
  spielseitige API-Aufrufe aus JavaCord-, WebSocket-, File-Watcher- und
  Timer-Callbacks.
- Der Main-Server hatte danach dennoch fünf Ereignisse: eines am 2026-06-13 und
  vier am 2026-06-14.
- Daraus folgt:
  - Die Änderungen haben das Problem nicht vollständig beseitigt.
  - Es ist nicht belegt, dass auf dem Main-Server bei allen fünf Ereignissen
    bereits sämtliche neuen Versionen aktiv waren.
  - Der Beobachtungszeitraum nach Release ist zu kurz für eine belastbare
    Frequenzbewertung.

### Zeitfenster-Bewertung

| Zeitraum                   | Beobachtung                                                                              |
| -------------------------- | ---------------------------------------------------------------------------------------- |
| Vor Shop/Marketplace 0.1.0 | Mindestens 8 sicher datierte Ereignisse plus ein nicht eindeutig datiertes Main-Ereignis |
| 2026-05-26 bis 2026-06-07  | Deutliche Häufung auf Development; viele Reload-/Initialisierungskontexte                |
| 2026-06-08 bis 2026-06-12  | Ereignisse auf beiden Servern trotz gemeinsamem Release-Block                            |
| 2026-06-13 bis 2026-06-14  | Fünf Main-Ereignisse; keine ausreichende Nachbeobachtungszeit                            |

Es gibt eine zeitliche Häufung mit wachsender Plugin-Aktivität und häufigeren
Releases. Es gibt aber keinen klaren Sprung, der einem einzelnen Plugin-Release
zugeordnet werden kann.

## Wahrscheinlichste technische Bewertung

Die unmittelbare Absturzstelle liegt fast immer im nativen G1-GC der JVM und
nicht in einem Java-Stackframe eines konkreten Plugins. Die Daten sprechen am
stärksten für eine der folgenden Ursachen:

1. **Rising-World-/JVM-nativer Fehler im G1-GC oder JNI-Lifecycle.**
2. **Speicher- oder JVM-Zustandsbeschädigung durch JNI oder PluginAPI**, die erst
   beim GC sichtbar wird.
3. **Threading-/Lifecycle-Race durch Plugins als indirekter Trigger.**

Die dritte Hypothese wird durch die Häufung bei Development-Reloads und die
separaten Shutdown-Abstürze gestützt. Sie erklärt aber nicht allein, warum viele
Main-Abstürze im normalen Betrieb mit derselben G1-Signatur auftreten.

## Empfohlene nächste Schritte

1. Bei jedem Ereignis den vollständigen nativen Crashdump beziehungsweise
   Core-Dump und vorhandene JVM-Fehlerdateien sichern.
2. Rising-World-Entwicklern die dominante Signatur, Serverversionen und mindestens
   einen vollständigen Core-Dump melden.
3. Für Main und Development eine maschinenlesbare Ereignisliste mit exaktem
   Docker-Zeitstempel, laufenden Plugin-Versionen, Uptime und Speicherwerten
   erzeugen.
4. Shutdown/Restart-Aufrufe gegen bereits gestarteten Shutdown verhindern und
   Restart-Timer beim Disable zuverlässig abbrechen.
5. Alle verbliebenen fremden Callback-, Timer-, File-Watcher- und
   WebSocket-Threads darauf prüfen, ob sie direkt PluginAPI-, `Player`-,
   `Server`- oder UI-Operationen ausführen.
6. Plugin-Reloads auf Development getrennt beobachten, da dort eine deutliche
   Korrelation besteht.
7. Optional kontrollierte Vergleichsläufe mit identischer Welt und reduzierten
   Plugin-Sets durchführen. Wegen der unregelmäßigen Ereignisse müssen diese
   ausreichend lange laufen.

## Wichtigste Risiken

- Ein Plugin-Bisect kann einen indirekten Verstärker identifizieren, aber bei
  unregelmäßigen nativen GC-Abstürzen leicht falsche Sicherheit erzeugen.
- Ohne vollständige Docker-Zeitstempel und installierte Plugin-Versionen pro
  Ereignis bleibt die Release-Korrelation unscharf.
- Die zwei Shutdown-Abstürze sind wahrscheinlich separat behebbar; ihre Behebung
  löst voraussichtlich nicht die dominante G1-GC-Klasse.

Display More

die analysierten logs im Anhang, vor den SIGSEGV 200 Zeilen und danach 100 jeweils

Devidian · Jun 14th 2026

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.

Devidian · Jun 14th 2026

By the way the jail Feature is Not a Land Claim Feature, its from Admin utils.

Devidian · Jun 14th 2026

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

Posts by Devidian

Wiki zur neuen Version [Momentan im Umzug!]

Wiki zur neuen Version [Momentan im Umzug!]

Steam Client Timeout auf Server

🛰️OZ - GPS v0.6.0 | Access rules and sector pricing

🛰️OZ - GPS v0.6.0 | Access rules and sector pricing

🛰️OZ - GPS v0.6.0 | Access rules and sector pricing

Steam Client Timeout auf Server

Server/World Blueprints

Server/World Blueprints

Server/World Blueprints

Steam Client Timeout auf Server

Steam Client Timeout auf Server

Steam Client Timeout auf Server

🚩OZ - Land Claim v0.12.0 | New area type: renew area

Steam Client Timeout auf Server

Steam Client Timeout auf Server

Steam Client Timeout auf Server

🚩OZ - Land Claim v0.12.0 | New area type: renew area

🚩OZ - Land Claim v0.12.0 | New area type: renew area

🚩OZ - Land Claim v0.12.0 | New area type: renew area