Update 2.88

v2.88.0BETAMINORLulu

Magic DLLs (FFX): Value-Workbench für Kandidaten-Farb-, Geschwindigkeits-, Timer- und Vektorbearbeitungen

• Extras -> Magic DLLs (FFX) / Role Candidates enthält jetzt eine bearbeitbare Candidate Value Workbench, die die ausgewählte DLL nach float32, vec3f/vec4f und push imm8/imm32-Werten durchsucht, Kandidaten als alpha/color/scale/speed/timer/flag/count klassifiziert und dem Benutzer erlaubt, einen neuen Dezimal-, Float- und Komma-Vektorwert einzugeben, Stage Patch oder über Apply To Output eine Ausgabe-DLL zu erzeugen. Der Block Host Context / InitMagicPRX Fields wird jetzt ebenfalls unterstützt: Host-Feld auswählen, konkrete u32-Vorkommen in der DLL auflisten und eine echte Offset-Referenz patchen. Guardrail: Namen bleiben Kandidaten und jede Änderung benötigt weiterhin RT2, um die visuellen/Gameplay-Semantiken zu bestätigen. Editor auf 2.88.0.0 angehoben. Validierung: dotnet build FFXProjectEditor\FFXProjectEditor.csproj -c Release -o work\_build_magicdll_value_workbench_probe --no-restore mit 0 Fehlern / 366 Basiswarnungen. [previous: v2.87.1]

v2.88.1BETAPATCHLulu

Magic Viewer Web: Runtime-Simulationskandidat in der zentralen Bühne

• Der Viewer hat jetzt einen Simulate-Modus, der das Textur-Diashow-Verhalten durch eine kontinuierliche Schleife ersetzt, die von der umgekehrten Strukturkette gesteuert wird (sub_800530/590/950, sub_80CD60, sub_817200, root+84/root+88, Overlay-Slots und Phyre-Payloads). ps3data\magic-Texturen werden als visuelles Material behandelt, nicht als Takt-/Frame-Liste; das HUD zeigt Phasen, Root-Cursor, Code-/Daten-Callbacks und wiederholte DLL-Aliase. Guardrail: Dies ist ein Runtime Simulation Candidate, weniger unecht als Cycle Surface, aber immer noch kein Frame-genaues Timing, kein vollständiger Opcode-Interpreter und keine RT2 von Callbacks/Frames im Spiel. Editor auf 2.88.1.0 angehoben. Validierung: node --check RuntimeTools\FFXMagicViewerWeb\app.js; HTTP http://loopback:8766/index.html?magic=0688 200; Chromium headless klickte Simulate auf Desktop und 390px-Mobil ohne Seiten-/Konsolenfehler, kein horizontales Mobile-Overflow, Screenshots bei work/magic_viewer_runtime_simulation_0688.png und work/magic_viewer_runtime_simulation_0688_mobile.png; Build dotnet build FFXProjectEditor\FFXProjectEditor.csproj -c Release -o work\_build_magic_runtime_sim_2881 --no-restore mit 0 Fehlern / 366 Basiswarnungen. [previous: v2.88.0]

v2.88.1.1BETAREVISIONWakka

Arena+ pre-RT2: versioniertes Forschungspaket für eine neue NPC-Option per DLL

• im Repo persistierte Forschung/RE, ohne Produktverhaltensänderung. Versioniert den Monster-Arena/Arena+-Dossiersatz: neue Tabs/Kreationen, DLL-Einschleusung, Dark-Aeon/Der Richter-Besiegungsflags, NPC-Options-Routing und den finalen Scout sowie das nagi0700-pre-RT2. Kernbefund: Der Besitzer der Monster Arena lebt im Event nagi0700; w0E::f05 baut das Now what?-Menü über den Common.displayFieldChoice [013B]-String [4A], w0E::f07 öffnet den Selektor über SgEvent.showModularMenu [401D], startet Kämpfe über Battle.launchBattle [7002] und markiert besiegte Kreationen 0x0300..0x0322 über Common.setMonsterArenaUnlocked [0210]. Editor auf 2.88.1.1 angehoben. Guardrail: research-only/pre-RT2; ArenaUnlocks[35+] nicht erweitern, nagi0700.ebp nicht bearbeiten und keine Vanilla-Menüzeile vor dem Live-Tracing injizieren. Validierung: Test-Path + rg gegen Dossier, KB und Handoff-Anker; Build dotnet build FFXProjectEditor\FFXProjectEditor.csproj -c Release -o work\_build_versioning_28811 --no-restore mit 0 Fehlern / 366 Basiswarnungen. [previous: v2.88.1]

v2.88.1.2BETAREVISIONLulu

Magic DLLs: Ähnlich-Zauber-Muster-Forschung für sichereres Farb-/Geschwindigkeits-Jagen

• im Repo persistierte Forschung/RE, ohne Produktverhalten-Änderung. Kreuzt AiCommandMetadataCatalog.Generated.cs (979 Zeilen, 689 mit moveAnim), Overlay-CSV (581 Zeilen) und magicFiles\FFX\magic_####.dll-Binaries, um nach echtem visuellem Träger statt nur nach Zaubername zu gruppieren. Wichtigste Erkenntnisse: Power/hits/status leben in der Befehlszeile; Visuals leben in moveAnim; einfaches Feuer/Blitz/Wasser nutzt die einfachere nz9/u5-Familie, während Eis/Heilung/Flare-ähnliche Effekte breitere PPP-Familien nutzen; Vita/Potion und viele Mixes verwenden Visuals wieder; Death beweist, dass gleichnamige Zauber auf verschiedene DLLs zeigen können; das übliche Death magic_0098 und Mega Death magic_0351 teilen Overlay/Textur-Slots/Größen, aber nicht Hashes/Payload; Klone 0714/0715 bleiben der richtige Weg für Prism Flare, ohne Vanilla-Fira/Blitzra anzufassen. Guardrail: pppColor/pppColMove/pppAccele, Floats und Pushes bleiben Kandidaten, bis RT2/Probe Farb-, Geschwindigkeits- oder Timing-Semantik beweist. Editor auf 2.88.1.2 erhöht. Validierung: Dokument-Anker via Test-Path/rg; Build work\_build_magic_patterns_28812 mit 0 Fehlern / 366 Baseline-Warnungen

v2.88.1.1

v2.88.1.3BETAREVISIONSeymour

60fps / FPS-Unlock-Forschung: Frame-Generierung, Frame-Pacing und engine-exakte 60 trennen

• im Repo persistierte Forschung/RE, ohne Produktverhalten-Änderung. Das Dossier docs/reverse/FFX_60FPS_UNLOCK_FEASIBILITY_RESEARCH_2026-06-13.md kommt zu dem Schluss, dass es keine Belege für einen sicheren Ein-Wert-30→60-Cap-Unlock gibt; die ehrlichen Wege sind visual 60 durch externe Frame-Generierung/Interpolation, besseres 30fps-Frame-Pacing, 60Hz-Rendering über 30Hz-Simulation mit interner Interpolation und volles engine-exact 60fps als Moonshot/Research-only-Linie. Belege gekreuzt: UnX implementiert Speed-Hacks, indem es FFX_GameTick multipliziert, nicht durch Bewahrung normaler Zeit bei 60fps; Spezial K/UnX warnt, dass externe 30fps-Caps Ladezeiten beeinflussen können und einige Menüs mit 60 laufen; dieses Repo hat bereits DINPUT8/Main-Thread, einen Present-Hook und MSEQ frameRate=7680 (30fps*256), aber Magic-, Battle- und Cutscene-Timing ist noch nicht frame-akkurat. Sicherer nächster Schritt: ein Read-only-fps-scout in FfxHooksDll/FfxDinput8Probe, der Present, Tick, MSEQ-Cursor und Spielmodus vor jedem Patch misst. Editor auf 2.88.1.3 erhöht. Validierung: Dokument-Anker via Test-Path/rg; Build work\_build_fps_research_28813 mit 0 Fehlern / 366 Baseline-Warnungen

v2.88.1.2

v2.88.1.4BETAREVISIONSeymour

Tiefe Gameplay-60-Forschung, wobei Cutscenes/FMV bei 30fps bleiben dürfen

• im Repo persistierte Forschung/RE, ohne Produktverhalten-Änderung. Das Dossier docs/reverse/FFX_GAMEPLAY_60FPS_DEEP_RESEARCH_2026-06-13.md beantwortet den neuen Umfang des Nutzers: Cutscenes dürfen bei 30fps bleiben, Gameplay ist das Ziel. Urteil: Das entfernt eine große audiovisuelle Sync-Klasse aus dem ersten Meilenstein, verwandelt das Problem aber nicht in einen einfachen Cap-Tausch; Gameplay braucht weiterhin getrennte Behandlung für Feld, Kampf, MSEQ, Kamera, CTB, Magic/VFX, Menüs, Ladezeiten und Minigames. Die Forschung beschreibt vier Routen: visual 60 durch Frame-Generierung/Interpolation, Frame-Pacing/VRR/Present-Doctor, 60Hz-Rendering über 30Hz-Simulation mit internem Interpolator und volle engine-exact 60fps als Moonshot, bis Scouting isolierbare Uhren beweist. Sicherer nächster technischer Schritt: ein Read-only-fps-scout mit CSV/Summary für Present-Kadenz, Heartbeat/Tick, Spielmodus, MSEQ-Cursor und UnX/SpecialK-Kompatibilität vor jedem Patch. Editor auf 2.88.1.4 erhöht. Validierung: Dokument-Anker via Test-Path/rg; Build work\_build_gameplay60_research_28814 mit 0 Fehlern / 366 Baseline-Warnungen

v2.88.1.3

v2.88.1.5BETAREVISIONLulu

Magic-DLLs: echte Hex-Rays-Dekompilierung enthüllt ZWEI Effektarchitekturen + bewiesene Host-Felder

• repo-persistente RE (Dekompilierung + Umbenennung/Kommentare in den .i64s), ohne Verhaltensänderung am Produkt. Ich habe mich von der positionsbasierten Benennung (der MagicDllSemanticAnalyzer-Heuristik) gelöst und magic_0084 und magic_0148 tatsächlich in IDA dekompiliert. Kernbefund: das Korpus enthält ≥2 unterschiedliche Architekturen, die die Slot-Kind-Signatur NICHT trennt (beide haben code in jedem Slot): Familie A „eigenständiges Partikel" (magic_0084: lokaler 1023-Partikel-Pool + 256-Paket-Ring, ohne dat_et-Wurzel; Slot 1 ist der Draw-Tick; Slot 4 überschreibt seine eigene Overlay-Tabelle, um die Phase voranzutreiben — auch in magic_0688 bestätigt) und Familie B „Wurzel-/Record-Interpreter" (magic_0148: allokiert die 1.024.000-Byte-Wurzel über host+3212, materialisiert über host+2860 und ruft host+2864=sub_80CD60 und host+2884=sub_80BEA0 direkt auf). ~20 Host-Felder von candidate zu durch dekompilierten DLL-übergreifenden Aufruf bewiesen befördert (host+672 Actor, +884/+888 Timer, +900/+904/+908 Phase/Start/Fortschritt, +2860 Materialize, +2864 Interpreter, +2872/+2876 Ego-Objekt, +2908 Make-Packet) und das neue host+3216 (free)-Paar zu host+3212 gefunden. Doku: docs/reverse/FFX_MAGIC_DLL_DECOMPILED_FAMILIES_2026-06-13.md. Editor auf 2.88.1.5 angehoben. Leitplanke: weiterhin Byte-Ebene-RE, Namen beschreiben die Rolle (nicht das Originalsymbol); die Slot-Kind-Signatur ist ein schwacher Proxy — der echte Familienklassifizierer ist „ruft Slot 0 host+2860 auf?". Validierung: 2 .i64 in magicFiles\FFX mit Umbenennung+Kommentar gespeichert; Umbenennungen 17/17 (0084) und 10/10 (0148) OK

v2.88.1.4