Posts by Devidian

    This update has no real features regarding the plugin scope, but it has several internal code stability improvements.


    ## [0.15.1] - 2026-06-13 | Callback thread safety


    - fix: dispatch WebSocket-driven game operations onto the server thread

    - fix: parse WebSocket payloads before dispatching game operations

    - refactor: dispatch immutable relay message values instead of mutable parsed entities

    - test: cover broadcast and player-event relay parsing

    - fix: separate transport-only WebSocket sends from player-aware response handling

    - fix: avoid retaining `Player` objects in asynchronous screenshot callbacks


    ## [0.15.0] - 2026-06-08 | Persisted player settings


    - feat: add Global Intercom player shortcut visibility setting for `/ozt` and inventory shortcuts

    - change: persist Global Intercom player runtime settings through shared `PlayerSettings`

    - change: use one-time plugin i18n loading during enable

    This update focusses on a dependency change. JavaCord is replaced with JDA because development for JavaCord stopped. Zhis update also includes several code improvements.


    ## [0.23.0] - 2026-06-15 | JDA migration


    - change: replace JavaCord with lifecycle-bound JDA 6.4.2

    - feat: convert Discord chat and slash-command callbacks into immutable DTOs before server-thread dispatch

    - feat: defer slash-command replies immediately and answer results on the bounded Discord transport worker

    - fix: parse `botAdmins` as exact Discord snowflake IDs and reject legacy names or partial matches

    - fix: normalize all command and option names to Discord-compatible lowercase

    - feat: send oversized help and banned-player results as text files

    - fix: use one lifecycle-bound Apache async HTTP client for all webhook sends

    - fix: queue server-start status behind JDA startup, preserve the client for queued shutdown status, and keep webhook status independent from bot enablement

    - change: update HttpClient to 5.6.1, Gson to 2.14.0, JUnit to 4.13.2, and OZTools to 0.22.0


    ## [0.22.2] - 2026-06-14 | Timer lifecycle


    - fix: bind restart and activity timers to plugin enable/disable lifecycle

    - feat: log Discord transport worker lifecycle through Tools diagnostics


    ## [0.22.1] - 2026-06-13 | Callback thread safety


    - fix: dispatch JavaCord listeners, restart timers, activity updates, and screenshot notifications onto the server thread

    - fix: avoid retaining `Player` objects in asynchronous screenshot callbacks

    - fix: avoid blocking the server thread while waiting for Discord slash-command responses

    - fix: move webhook and text-channel transport onto a bounded lifecycle-owned worker


    ## [0.22.0] - 2026-06-08 | Chat shortcut parsing


    - fix: parse `+s`, `+sng`, and `+t` chat shortcuts at end-of-message or before whitespace

    - feat: add Discord Connect player shortcut visibility setting

    Ein kleines Update, eigentlich war das Ziel die Erkennung der Region beim Erkunden neuer Sektoren, ist aber noch nicht so zuverlässig, jedenfalls steht nicht mehr unknown dran... sobald die API die funktionalität her gibt wird das PRoblem gefixt.

    Ich habe dennoch ein Release gemacht weil man nun auch den shortcut button verstecken kann.


    ## [0.3.0] - 2026-06-08 | Region-based discovery


    - feat: resolve sector discovery regions through Tools `RegionHelper`

    - feat: add player setting to hide the Rewards shortcut from `/ozt` and the inventory shortcut panel

    Ein etwas größeres update ist nun offiziell von mir freigegeben. Mit diesem Update wird dynamische Wirtschaft eingeführt. Spieler können über den systemshop items kaufen und verkaufen.

    Admins können frei konfigurieren welche items angeboten werden. Sie können ausserdem für jeden shop eine eigene Konfiguration laden, so kann man z.b. einen Shop für Grundbedarf oder einen für Agrargüter anlegen, oder einen für Fundsachen.


    Admins können dabei für jedes item verschiedene Einstellungen vornehmen, unter anderem:


    - Initiale und Maximale Lagerbestände sowie Ziel-Lagerbestand

    - Grundpreis (der Preis den ein Item hat wenn es sich im Ziel-Lagerbestand befindet

    - Ob ein item nur von Spielern gehandelt werden kann ..

    - ... oder ob das system die items bis zum zielbestand langsam auffüllt oder verbraucht.

    - ob ein item nur gekauft oder nur verkauft werden kann oder beides


    Known issues:

    - das nachfüllen der items scheint noch nicht immer regelmäßig zu funktionieren.


    Wenn in der Session keiner online war macht er einen Neustart und gut ist, wenn jemand online war - auch wenn der schon länger offline war wie man hier sieht - gibt es immer das port problem. Vielleicht ist es auch ein docker problem, da bin ich überfragt.

    Hmm da durch meine Shop und Marketplace viele assets aus dem spiel geladen werden vielleicht? (also Case 2) Discord Connect lief ja schon länger ohne Probleme vorher, klar kann das ein zusätzlicher Faktor sein aber zuletzt kamen Shop und MArketplace dazu, die haben eigentlich keine Threads, höchstens ein paar Timer im Shop für den refill, aber der dürfte planmäßig nur einmal die Stunde laufen. Bin mir gerade nicht sicher ob er da einen eigenen Thread für macht. Laut KI jedenfalls nicht.


    Das mit dem ErrorFile kann ich mal probieren aber dann muss ich wieder umstellen, sonst kommt gar kein error mehr :D


    Klar ich hab ja noch die anderen logs eigentlich dürften die relativ identisch sein habe aber trotzdem mal 4 hinzugefügt.

    Shutdown macht er ja, trotzdem die Wiederholung. Allerdings ist mir aufgefallen das er auf dem Dev Server keine Wiederholung macht wenn in der Session kein Spieler online war


    PS bisher stabil mit anderem gc

    Kannst du mir ein Zugang machen?

    Habe noch ein Fehler gefunden8)
    :saint: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.

    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


    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 :D

    Da kommt dann immer das hier:


    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 :D


    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

    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.

    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.

    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.

    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.

    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