JARVIS-ARENA

Update 2.130

16.6.2026

v2.130.0.0MINORJarvis-ARENA

Arena+ Multi Dark Aeon Tier-Lock-Bericht CLI (`--print-tier-lock`) + Sidecar-Schema v1

(neue Funktion: erster Offline-Bericht, der den Katalog v2 mit dem Sidecar-Fortschritt abgleicht; neues kanonisches Schema für den Snapshot LOCKED/READY/CLEARED). Neu RuntimeTools/ArenaMultiBossLab/TierLockReport.cs + 4 Flaggen auf Program.cs: --print-tier-lock, --progress <path>, --out <json>, --json. Im Standardmodus wird ein nach Tier gruppierter Bericht mit Gate-Grund (← needs: arena.dark.valefor, ... (in LOCKED-Zeilen) und Fallback rt2:<status> risk:<...> token:<mode> in Zeilen, die nicht bewiesen sind d. Modo --outou--jsonemite JSON estrito que casa com o novo schemamods/Spira Reforge/arena/spira-arena-tier-lock-state.schema.json v1 (Format, format_version, generated_utc, Zusammenfassung{Gesamt,gelöscht,bereit,gesperrt}, rows[]comZustandenumGESPERRT|BEREIT|GEKLÄRT+unlock_requires/missing_requires). **Regras de gating ja documentadas no schema** (sao as mesmas que o futuro hook de menu F7 vai aplicar). **Run atual contra catalog + sidecar vazio:** 13 rows total -> 9 READY (solos) + 4 LOCKED (duo/trio/quartet/penta gateados pelos solos), 0 CLEARED. **README de mods/Spira Reforge/arena/reescrito** com tabela completa dos 5 sidecars + comandos--print-tier-locke--validateexemplificados. Lints clean. Build PASS. [anterior:v2.129.0.0`]

v2.130.1.0PATCHJarvis-MAGIC

Ronso Mana (letzten 7.): Ich habe das `DIAG`/`BLOB-PATCH` aus dem RT2 `hudSafe=24` den ich ÜBERSPRUNGEN hatte → der Blob-Patch meldete „UNGÜLTIGER KNOTEN“ (`subIdx=0x00`); umgeschrieben, um einen GÜLTIGEN Knoten auszuwählen + `ODBLOB` Deep Dump

(behebt die fehlerhafte Heuristik des PatchCase2BlobForKimahri + neue schreibgeschützte Implementierung in einem bereits ausgelieferten Hook/RT2; Code fertig, Build/Deployment in der nächsten DLL-Version — wird bereits in einem anderen Raum verwendet). Die Entdeckung (Zeilen DIAG/BLOB-PATCH vom %TEMP%\ffx-hooks.log die ich noch nie gelesen hatte – ich habe sie nur übergreifend durchgesehen B0 resolve): BLOB-PATCH #1 treeId=43 set entry=0x00 (was 0xFF) + DIAG G0-ring-post blob2=0x1B5C8D70 hdr=[03 8A] maxE=138 treeId=43 entry=0x00 slots41/42/43=[FF FF 00] OK — das heißt, das PatchCase2BlobForKimahri es gab es bereits und lief bereits (setou blob[45] von 0xFF→0x00) aber der Resolve(2,1,43) weiterhin −1. ⇒ der alte Fallback (maxUsed→fast immer 0x00) wies die treeId 43 auf einen strukturell ungültigen Knoten hin: Er passiert das primäre Gate des WalkMenuBlobIndex (idx!=0xFF, 43<count), aber der sekundäre Selektor ringKind platzt (v4>=node.entryCount oder entry[v4]==0xFFFF) → *a3=−1. Weitere Belege aus demselben Protokoll: count=138 (43 liegt im Bereich → Es handelt sich NICHT um den Fall „geringe Anzahl“/43>=count); slots 41/42 = 0xFF (kein registrierter Party-OD in diesem Blob a2=1 → es gibt keinen Geschwister-Spender); DIAG G0-finalize slot=2 od=3065 3064 3066 311A (der Ringpuffer der Schicht A TEM 311A=cmd282 Ronso Rage** — bestätigt, dass das Gate zu 100 % die Lösung für die Menübaum-Ebene B ist, nicht der Inhalt). Der Fix (Code, hudSafe=25): (1) PatchCas e2BlobForKimahri reescrito — agora decodifica o nó no formato EXATO do WalkMenuBlobIndex (v6 = (count + 1) / 2 + 2 * subIdx; nodeOff=*(i16)(blob+2*v6+4); entryCount=*(u16)(blob+nodeOff); entry[k] = *(u16)(blob + nodeOff + 2 + 2*k), tudo bounds-clamped) e escolhe blob[2+43] por prioridade: (a) nó que contém 0x311A (assinatura exata do OD) e suporta ringKind=1; (b) sibling party-OD 41..47 já registrado com nó selector-capaz; (c) nó mais rico que suporta ringKind=1 (de preferência também 12). Se NADA qualifica, deixa 0xFF (a2=1 não tem nó OD usável → é fix-C/redirect pro a2=0) e loga NO – funktionsfähiger Knoten, em vez de escrever lixo 0x00 como antes. (2) novo DumpOdBlobStructureOnce (read-only, dispara 1× mesmo em log-only) — dumpa os índices party-OD 41..47 do a2=1, o entryCount+primeiras entradas dos nós 0..23 (marcando o que tem <<OD311A>>), e os índices 41..47/109..115 do a2=0 (MainRing) → 1 RT2 crava o subIdx certo OU revela que é redirect pro a2=0. Helpers novos (todos statisch, bounds-clamped, sem dep de PolyHook): OdBlobNode/OdBlobEntry/OdNodeSupportsSelector/OdNodeContainsEncodedOd/ReadMainRingBlobPtr (a2=0 = _BASE 0xD2A994). Banner hudSafe=24→25 (confirma DLL nova no log). NÃO buildei/deployei (DLL em uso por outra sala — respeitado); ReadLints clean; código pronto pro build_hooks.ps1 -WithPolyHook -Release. Arquivo tocado: RuntimeTools/FfxHooksDll/hooks/RonsoManaHook.cpp. Doc: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §13. [anterior: v2.130.0.0]

v2.130.2.0PATCHJarvis-MAGIC

Nul Ward: URSACHE dafür, dass „im White-Magic-Menü nichts angezeigt wurde“ GEFUNDEN + BEHOBEN — die partyweite Bank wird NEU GELADEN von der `party_data` Bei JEDEM Kampf-Init wird der Grant vor dem Reiten-Menü gelöscht

(behebt den Verhaltensfehler, der das Erscheinen des Nul Ward verhinderte – dieselbe Feature/Lab wie bei v2.123.4.0/v2.124.0.2; Entscheidende RE nachgewiesen in der .i64 real + neuer Umweg bei der erneuten Überprüfung in NulWardTeachHook; DLL von Halyson veröffentlicht, Rebuild und Deployment durchgeführt). Das Problem: Selbst nach dem Multi-Site-Fix für das Menü-Binding (v2.124.0.2) + Grant beim Laden (Protokoll NulWardTeach grant ch=0..6 radiant=1 umbral=1), die Wards tauchten in der weißen Magie im Kampf nicht auf. Die RE, die geschlossen wurde (idalib MCP, byte-verifiziert über disasm): sub_7817D0 ("* BTL INIT") heißt FFX_Btl_PrepareSaveCommandState@0x786BC0 ("-- SAVE RAM CLEAR -- Preparing save game data") bei jedem Kampfstart; in 0x786CA3 sie macht mov ecx,21h; mov edi,offset dst__0; rep movsd — Kopie 0x84(132) Bytes des Kernels party_data (Tabelle Nr. 4) für dst__0=0x11307D8, Titel [0x11307D8,0x113085C) das vollständig abdeckt das g_PartyWideCommandBank@0x11307FC (Offset +0x24 innerhalb der Kopie; Datenbank = 16 Wörter, IDs 96..351). ⇒ Die gesamte party-weite Datenbank wird überschrieben aus der party_data jede Schlacht, und party_data kein Ward-Bit → word14=0 → IsCommandAvailable(320/321)=0 → Der Platzierungszyklus überspringt die Wards → „Es ist nichts erschienen“. Ausgeschlossene Verdächtige: FFX_Btl_InitPartyWi aus CommandBank@0x784960 só dá ODER em bits 0..130 e é debug-gated (if(unk_112A905){ DebugMaxAll(); Init(); } — não roda em jogo normal); sub_78F0B0 (Lancet/blue) e o grant só mexem bit individual. Correção mental do §H: PrepareSaveCommandState não é só "persistência" — é o reload ATIVO por-batalha do banco a partir do party_data; qualquer grant de id≥96 ausente do party_data (sphere-grid teach incluído) reseta toda batalha. Categorização corrigida (empírica): dump do command.bin deployado mostra os doadores Nul (NulShock id48, NulTide id49) e as wards (320/321) todos com SubMenuCategorization (Byte +24) = 0x02 — wards são templatadas dos doadores, então caem na mesma categoria de magia branca dos Nul que já aparecem (categorização correta-por-construção; faltava só o bit de disponibilidade vivo). O FIX (lab teach_grant, deployado): NulWardTeachHook agora instala um PLH::x86Detour no FFX_Btl_PrepareSaveCommandState; o shim chama o original (deixa recarregar o banco do party_data) e re-afirma g_PartyWideCommandBank[word14] |= 0x3 (Radiant bit0 + Umbral bit1) no retorno — ou seja, logo após o wipe e antes do FFX_Btl_BuildActorCommandMenu semear o ator. Escrita direta no banco (não chamada de grant) pra não re-entrar no menu builder de dentro do init. Log diag (4 primeiros disparos): NulWardTeach setzt #n nach „PrepareSaveCmdState“ zurück: Bank Wort 14 0xPRE->0xPOST. Grant one-shot mantido pros menus de field/pré-batalha. Consequência de design (produção): como party_data é a fonte por-batalha pra ids≥96, o caminho limpo pra uma ward sempre-disponível é adicionar o bit no próprio kernel party_data (innata, party-wide), não no sphere grid — um id≥96 ensinado no grid não persiste pós-init sem (a) o bit do party_data ou (b) re-assert em runtime como esse detour de lab. Build/deploy: build_hooks.ps1 -WithPolyHook -Release PASS (12/12 cpp), deploy install_to_modules.ps1 -EnableApply -EnableTeach (backup ffx-hooks.dll.backup-nul-ward-20260616-081633, novo SHA-prefix 0DE302BDF13D5B14). Gate --nul-ward-static VERDICT: PASS (sem regressão; command.bin/exe/flags intactos). .i64 real: Kommentar verschiedene in 0x786BC0 + 0x786CA3 (GOLDENE REGEL). 2 neue RVAs in shared/ffx_addresses.h (RVA_FFX_BTL_PREPARE_SAVE_COMMAND_STATE, RVA_FFX_PARTY_WIDE_COMMAND_BANK). RT2 im Spiel: Kampf starten und „Radiant/Umbral Ward“ bei der weißen Magie bestätigen + Protokoll überprüfen reassert ... word14 0x0000->0x0003. Offene Spannweite: Breite der ply_save pro Bit 224/225 (§H) – wird bei jedem Ladevorgang erneut angewendet. Dateien: RuntimeTools/FfxHooksDll/hooks/NulWardTeachHook.cpp, shared/ffx_addresses.h. Dok.: docs/reverse/FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16.md §I. [zuvor: v2.130.1.0]

v2.130.2.1REVISIONJarvis-MAGIC

Spira Reforge: Erweiterte Schwarze Magie — Design-Lockdown (Multi-Skill-Familie > -ja-Tier; `-ja` wird zum Nischen-Backlog; Lulu Fury „Include-All“)

(Design-Dokument + Integration in VISION; in diesem Durchgang keine Writer/Verhalten/RT2). Halyson hat ein Brainstorming zur Entwicklung neuer Black Magic gestartet. Ich habe zwei Ansätze verglichen: (a) -ja Tier (Firaja/Blizzaja/Thundaja/Waterja = -ga-Klon mit +Power, ohne Fury) vs. (b) Multi-Skill (AoE-Versionen von Vanilla-Einzelziel-Zaubern, die keine AoE-Entsprechung haben). Entscheidung (Halyson): Multi-Skill gewinnt als Hauptweg; -ja als Nischen-Backlog zurückgestellt (1 pro Element, brutaler MP-Verbrauch ~80–120, nach „Celestial“, das Tüpfelchen auf dem i – konkurriert nicht mit dem Buff von -ga in VISION §10.5); Lulu Fury beinhaltet ALLES („Fury Drainga 16× ist wunderschönes Chaos, eine OD-Fantasie“). Warum Multi-Skill gewinnt: (1) TargetFlags.Multi ist bereits in der Engine integriert (FfxLib/Ability/Ability_Command.cs:125) — Single → Multi = 1 Bit in der Befehlszeile; (2) Zaubersprüche füllen die tatsächliche Lücke im Vanilla (ohne AoE-Gift, AoE-Entzug, AoE-Osmose) und verleihen dem Deck eine eigene Identität; (3) -ja ist redundant mit dem Plan VISION §10.5 das schon bald besser wird -ga mit „Ignore MD EF / Leistungsskalierung („Firaga neu geschmiedet“, nicht „Firaja“); (4) VISION §10.11 Er hat Holyra/Holyga/Wildra bereits aus demselben Grund als „lustig, vielleicht nie“ abgetan (Inflationspool ohne Identität); (5) Drainga/Osmose-ga versorgen andere Fronten (Capture Cascade T7 in langen Kämpfen, SIN-Modus mit Flüchen, Mob-OD-Multicast). Technisch validierte Zauber der ersten Welle (v0.5+): Biora (AoE-Gift + Schaden, Bio-Klon + Multi), Drainga (AoE-HP-Entzug, Obergrenze 9999/Zauber), Osmose-ga (AoE-MP-Entzug, Obergrenze 99 pro Zauber), Demita (AoE 50 % HP, Obergrenze 9999 pro Ziel), Multi-Firaga-Familie (3× Firaga AoE sequenziell, dreifacher MP-Verbrauch – direkte Idee von Halyson: „Multi-Firaga zum Beispiel>>>>>>“ – skalierbare Unterfamilie für Multi-Blizzaga/Thundaga/Waterga/Ultima). Zweite Welle (v0.6+): Slowga, Reflectga, Demi-Fall („Dimensional Crush“ 75 % HP, Einzelziel, hoher MP-Verbrauch), Quartera (25 % HP, AoE, geringer MP-Verbrauch). Dokumentierte echte Blockierungen: (a) Zauber-ID-Slot 0..95 — Gegenprüfung mit FFX_SPELL_FREE_ID_AUDIT_2026-06-12.md um Spender zu identifizieren; (b) Lulu Fury rudert #12408–#12422 Ausstehender Dump; (c) RT2-abhängige Cap-Auslastung (kein Cap = Heiler durch Angriff, knappes Cap = Zauber unwirksam); (d) Multi-Firaga hit_count player-cast RE Spike steht noch aus; (e) VFX-Darstellung identisch mit der Single-Version (ok für v0.5, Neufärbung ab v0.6+ über die bereits getestete Flan-Flood-Engine) v2.114.0.0); (f) Sphere Grid – gesonderte Entscheidung. Inkrementeller technischer Plan (§6.2 des Dokuments): Phase A: Überprüfung der ID-Spender (ohne Code, dieses Dokument), Phase B: Offline-Erstellung (Zeilen klonen + Multi umdrehen + Power/MP anpassen + Texteingaben), Phase C: Writer-LAB, Phase D: RT2 im Spiel, Phase E: Fury-Integration, Phase F -ja Backlog-Nische (v0.7+). Integration mit Mod: ergänzt §10.5 Schwarze Magie – Buff, stärkt §10.6 Lulu Fury, bewahre §10.11 Elementar-Rätsel, antworte §10.13 mob OD Multicast mit Drainga/Osmose-ga, unterstützt §11 Kämpfe in „Capture Cascade T7“ aufzeichnen. VISION_AND_ROADMAP.md aktualisiert: neuer Abschnitt 12 „Erweiterte Schwarze Magie – Multi-Skill-Familie“ (Designentscheidung + Zauber der ersten/zweiten Welle + Roadmap-Anbindung + vollständiges Dokument); Verweise in Abschnitt 13 neu nummeriert. Offene Fragen für fortlaufendes Brainstorming: Multi-Firaga-Mechanik A/B/C (fest programmiertes Doublecast vs. zufällige Verteilung vs. Hybrid-El ement — Empfehlung A), Drainga-Cap pro Ziel vs. pro Zauber, Sphere-Grid-Verbindung, Koexistenz von Demita und Demi (Vanilla), AoE der Weißen Magie (Esuna-ga?), Tier der Spender. Nicht behandelt: keine Writer, keine Hooks, keine Probes, keine DLLs, kein Offline-Gate/RT2. Nur Dokumente + Integration der Roadmap. Neues Dokument: docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md (10 Abschnitte, ca. 300 Zeilen). Betroffene Dateien: FFXProjectEditor/FFXProjectEditor.csproj (Bump-4-Tupel), mods/Spira Reforge/VISION_AND_ROADMAP.md (neuer § 12 + Umnummerierung der Verweise in § 13), CHANGELOG.md + changelogUS.md + docs/governance/VERSIONING.md + docs/ai/SESSION_HANDOFF.md. [vorherige Seite: v2.130.2.0]

v2.130.3.0PATCHJarvis-MAGIC

Ronso Mana CRASH HOTFIX (`hudSafe=26`): Das Schreiben des Blobs hat aufgehört, den Knoten zu stören (es war `via=rich>=1 subIdx=0x01` → Absturz); jetzt erfolgt die Schreiboperation nach dem OPT-IN-Prinzip + nur sicherer Knoten + durch SEH abgeschirmte Lesevorgänge

(behebt einen durch das hudSafe=25 von v2.130.1.0 als die DLL neu kompiliert/in der v2.130.2.0 aus der Lane „Nul Ward“). Grundursache (Protokoll RT2 %TEMP%\ffx-hooks.log): RonsoMana BLOB-PATCH2 #1 treeId=43 set subIdx=0x01 via=rich>=1 nodeOff=0x1B4 ec=24 (was 0xFF) — der Fallback (3) „reichster Knoten“ meines hudSafe=25 hat einen Knotenindex mit dem Namen „CHUTADO“ geschrieben (0x01, ec=24) in blob[2+43]. Das führte dazu, dass Resolve(2,1,43) „erfolgreich sein“ an einem Knoten, der nicht der OD-Ring ist → finishMenuTree hat falsche Inhalte geladen/angezeigt → das Spiel ist abgestürzt. (Das 0x00 früherer des hudSafe<=24 gab lediglich −1 zurück und stürzte daher NICHT ab: Es wurde nie aufgerufen finishMenuTree.) Mein Versuch „hat einen fehlerhaften, aber noch stabilen Zustand in einen Absturz verwandelt“. Der Hotfix (hudSafe=26): (1) Das Schreiben in den Blob erfolgt nun nach dem OPT-IN-Prinzip — es wird nur dann geschrieben blob[2+treeId] wenn die Sendung FFXHOOKS_RONSO_OD_BLOBWRITE=1 ist aktiviert; Standard = schreibt nichts (absturzsicherer Build, rein zu Diagnosezwecken über ODBLOB); (2) Selbst bei Opt-in wird nur der Knoten „PRINCIPIADO“ aufgezeichnet — (a) ein Knoten, dessen Einträge den kodierten OD-Befehl enthalten 0x311A, oder (b) eine bereits vom Spiel registrierte „Sibling Party“-OD 41..47; niemals wird das c automatisch gespeichert hute „reichster Knoten“ (dieser wird nur im Protokoll gespeichert, für eine eventuelle Hardcodierung nach dem Auslesen des Dumps); (3) alle Knotenwerte (OdBlobNode/OdBlobEntry) und der Block a2=0 aus dem DumpOdBlobStructureOnce sind nun mit SEH gepanzert (__try/__except) — Jede Zugriffsverletzung durch einen Offset außerhalb des zulässigen Bereichs (OOB) führt zu einem „ungültigen Knoten“, der bereinigt wird, anstatt einen Absturz auszulösen; (4) mainPtr a2=0 erhält einen Sanity-Check (> 0x10000). Das Protokoll gibt nun Folgendes aus BLOB-PATCH2 #n ... write=0|1 safe=0xXX(how) risky=0xXX(how,ec=..) (zeigt, was er tun würde, wenn er nicht schreiben würde) und wenn Opt-in + sicherer Knoten, BLOB-PATCH2 WROTE .... Banner hudSafe=25→26. Reversibilität: Ohne „env“ entspricht das Verhalten dem sicheren Standardverhalten (OD verborgen, kein Absturz). Ich habe es NICHT kompiliert/bereitgestellt (gemeinsam mit anderen Jarvis-MAGIC-Lanes genutzte DLL) — beim nächsten Neuaufbau von ffx-hooks.dll (auf jeder Lane) hol dir schon mal den Hotfix; ReadLints clean. Datei: RuntimeTools/FfxHooksDll/hooks/RonsoManaHook.cpp. Dok.: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md § 14. [zuvor: v2.130.2.1]

v2.130.3.1REVISIONJarvis-MAGIC

Spira Reforge: Erweiterte Schwarze Magie — 4 festgelegte Entscheidungen von Halyson (Multi-Firaga Option B, maximales Drainga-Limit pro Ziel, Demita koexistiert mit Demi, Fury „Include-All“ mit Nuancen)

Kaskade nachv2.130.3.0 (Ronso Mana – kleiner Hotfix einer weiteren parallelen Jarvis-MAGIC-Version). Unmittelbare Fortsetzung des Design-Dokuments von v2.130.2.1: Brainstorming mit H Halyson hat die letzten vier offenen Entscheidungen getroffen. (1) Multi-Firaga-Mechanik – Option B (zufällige Verteilung) + 3–5× MP der Basis: Halyson: „Option B, aber ‚Multi-Firaga‘, ‚Multi-Fodase‘ kostet das 3- bis 5-Fache der anfänglichen MP der Basis-Fähigkeit, um das auszugleichen – eine verdammt heftige Sache“. Mechanik = 1 Zauber → N Treffer (5–7), jeder Treffer trifft einen zufälligen Gegner (nativ in der Engine über die Holy/Comet/Doublecast-Formel). Gegner können je nach RNG 1, 2 oder 3+ Treffer desselben „Multi-Firaga“ erhalten. MP-Kosten = 4× Standardwert (Multi-Firaga = 64 MP), Multi-Ultima = 200 MP. Vorschlag von Jarvis: Beginne mit 4× MP + 6 Treffer, passe RT2 an. Skalierbare Familie (schrittweise Einführung): v0.5 Multi-Firaga + Multi-Blizzaga, v0.6 + Multi-Thundaga + Multi-Waterga, v0.7 + Multi-Ultima (nach Darkness §10.11), v0.8+ Rückstand bei Multi-Flare/Multi-Holy. (2) Drainga-Cap – pro Ziel 9999/Ziel (Multi-Cap): Halyson hat dies in voller Kenntnis der Auswirkungen implementiert. 4 lebende Gegner = bis zu 39.996 HP Heilung pro Zauber = ultimativer Heiler durch Angriff. ⚠ Kann lange Arena-Kämpfe sprengen – beabsichtigt, es ist ein Halyson-Mod, Endgame-Fantasie. Ausgleich: MP-Kosten können nach RT2 auf bis zu ~30 steigen, wenn alles überladen wird. (3) Demita vs. Demi Vanilla – koexistieren: BEIDE beibehalten. Demi single (16 MP, Boss-Killer) + Demita multi (24 MP, Wellenbeseitigung). Der Spieler wählt das Werkzeug. Kosten: 1 zusätzlicher ID-Slot. (4) Lulus „Fury“-All-Inclusive mit Nuancen (Entscheidungen §4 aktualisiert): Biora 16× = ok (Giftwelle); Drainga 16× = Fury-only-Cap 9999/Pick (nicht pro Ziel bei Fury, sonst bis zu 639.936 HP Heilung – „macht keinen Sinn mehr“); Osmose-ga 16× = ok (MP-Obergrenze 9999 = Hard-Wall); Demita 16× = ok (Demi trifft kein totes Ziel mehr); Multi-Firaga 16× = 96 potenzielle Treffer ⇒ Fury Multi- verwendet hit_count=1 (wird bei Fury zum Einzelzauber)* ODER schließt Multi-* aus dem Fury-Pool aus (einzige Ausnahme zu „include all“). Endgültige Entscheidung passt RT2 an. Aktualisierte offene Fragen in §8 des Dokuments: §8.1 entschieden (4 feststehend); §8.2 noch offen (Sphere Grid-Verbindung, Wirkungsbereich der weißen Magie, Verwirrung durch Elementabsorption, Stufe der Spender 0..95 blockiert Phase A**, Multi-* Zufallsverteilung command.bin Feld über Spike). Dokument aktualisiert: docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md §2.2 Drainga (festgelegtes Cap pro Ziel), §2.4 Entlassen (c (feststehend), §2.5 Multi-Firaga (Option B + MP 3–5× festgelegt + vollständige Elementartabelle), §4 Fury (Nuancen pro Zauber), §8 offene Fragen (4 markierte entschieden, 5 noch offen), §9 Aktualisierte Abgabeversion. Nächster sicherer Schritt: Phase A – Abgleich der Zauber-ID-Spender mit FFX_SPELL_FREE_ID_AUDIT_2026-06-12.md — Halyson entscheidet, ob es jetzt integriert wird oder bis kurz vor der Veröffentlichung von v0.5 zurückgestellt wird. Nicht berühren: writer/hook/probe/DLL/gate. Dateien: FFXProjectEditor/FFXProjectEditor.csproj (Kaskade v2.130.3.0 → v2.130.3.1), docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md (§2.2/§2.4/§2.5/§4/§8/§9 aktualisiert), CHANGELOG.md + changelogUS.md + docs/governance/VERSIONING.md + docs/ai/SESSION_HANDOFF.md. [vorherige Seite: v2.130.3.0]

v2.130.3.2REVISIONJarvis-MAGIC

Spira Reforge: ARCHITEKTONISCHER WENDEPUNKT — Abschnitt „Erweiterte Schwarze Magie“ umbenannt in „Erweiterte charakterbezogene Befehle“ (RE D01-Testversion + erweiterte Verteilung auf 7 Charaktere)

(unmittelbare Fortsetzung v2.130.3.1; kein Writer/Verhalten). Halyson schlug vor: „Was wäre, wenn wir statt dieser Ski „Wenn sie von ‚jedem‘ erworben werden können, lassen wir sie dann nicht ‚nur für Charakter X‘ sein?“ – Ich habe das mit der bestehenden RE abgeglichen und HABE HERAUSGEFUNDEN, dass die Vanilla-Engine die charakterbezogene Eigentümerschaft für IDs BEREITS NATIV UNTERSTÜTZT 0..95**. Der entscheidende Befund (RE D01 — FFX_SPELL_LEARN_ABIMAP_INFERNO_2026-06-15.md): FFX_GrantCommandToCharacter @ 0x785D10 enthält SPLIT AT INDEX 96: IDs < 96 Geht doch mal zur Bank, oder? word_11307FC[74*char+3151+(id&0xFFF)/16] (Stride 74 Wörter = ply_save pro Charakter); IDs >= 96 Sie werden in die party-weite FLAT-Bank verschoben (ohne Stride). ⇒ Der pro Charakter lernbare Speicherplatz beträgt GENAU 96 Bit, IDs 0..95. IDs ≥ 96 können nicht pro Charakter gelernt werden. Folge: Wiederverwendung von IDs 0..95 = Die Vanilla-Engine filtert, WER jeden Zauber sieht, ganz ohne Hook. Der alte Ansatz (IDs ≥96 + Umleitung im Stil von „Nul Ward“ zur Einschränkung) wurde verworfen. Erweiterte Verteilung (Entscheidung von Halyson vom 16.06.2026, Zitate beibehalten): Lulu (6 Zauber, Burst-Caster + HP-Entzug) — Multi-Firaga-Familie × 4 + Drainga + Osmose-ga (von Yuna auf Lulu übertragen), eventuell Demita; Yuna (5 Zauber, Weiß/Buff-AoE) — Reflectga + Protectga + Shellga + Esuna-ga + Dispelga („Reflectga, Protectga, Shellga, Esuna-ga, Dispelga für Yuna“); Rikku (3 Zauber, Steal-Meisterin) — „Copycat“ ist nun exklusiv bei ihr + Mugra (2-Treffer-Einzelangriff, 2× Steal) + Mugga (AoE-2-Treffer, geringer Schaden, „kann bis zu 6 Mal stehlen!!!!“); Wakka (TBD, „mehr Status-Fähigkeiten und noch verrücktere Sachen“); Kimahri (TBD, „Blauer Magier. Fähigkeiten von Monstern und sogar seine eigenen Overdrivers können erlernt und mit Mana eingesetzt werden“ – Koordination Ronso-Mana-Lane); Tidus (TBD, „0 Ideen, aber vielleicht Multi-Hit-Fähigkeiten“); Auron („DER VERDAMMTE TANK DES SPIELS. Weiterentwicklung des Sentinel, vielleicht stärkere Flächen-Breaks“). Geschätzte Gesamtzahl: 28–31 Zauber von 96 Slots = ~30 % des Budgets, es bleiben 65+ Slots übrig für -ja Backlog v0.7+ + Zukunft. 9 Entscheidungen festgehalten in §9.1 des Dokuments, 10 noch offen in §9.2 (Entlassung des Eigentümers, Wakka/Tidus/Auron-Pools, Rikku-Nachahmer als Ersatz, Sphere-Grid-Verbindung, Spender-Audit 0..95, Multi-Firaga-Feld mit zufälligen Treffern, „Steal-per-Hit“ bei Mugra/Mugga, Kimahri als Blauer Magier, Ronso-Spur). Vorteile des Modells: (a) Zero-Hook-Custom – nativer Vanilla-Engine; (b) Sphere-Grid-Bäume erhalten echte Bedeutung (Wechsel zu einem anderen Baum = echter Kompromiss); (c) Lulu Fury vereinfacht die Sache drastisch – der Fury-Pool ist Vanilla-spezifisch pro Charakter, „Multi-* aus Fury ausschließen“ ist kein Problem mehr; (d) „Capture Cascade“ §11 und „SIN-Modus“ §10.13 erhalten charakterbezogene taktische Reaktionen. Technischer Plan (§7.2): Phase 0: Pools festlegen (TBD) → Phase A: Spender-Audit (blockiert den Start) → Phase B: Erstellung pro Charakter (B: Lulu als Pilot, B.1: Yuna White AoE, B.2: Rikku Mug-Familie mit Spike-Steal-pro-Treffer, B.3: Pools (TBD)) → Phase C/D: RT0/RT1/RT2 → Phase E: Sphere Grid-Verknüpfung (Erweiterung des Spira Grid-Editors) → Phase F: Lulu-Fury-Reihen → Phase G: Kimahri als Blauer Magier (abhängig von der Ronso-Spur) → Phase H: -ja-Backlog v0.7+. VISION_AND_ROADMAP.md §12 überarbeitet: „Erweiterte Schwarze Magie“ → „Erweiterte Befehle pro Charakter“ + Tabelle zur Verteilung pro Charakter + Sperren + aktualisierte Roadmap. Dokument konzeptionell umbenannt (Dateipfad aus historischen Gründen beibehalten): docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md — 11 Abschnitte, §1 „Per-Character-Ownership“-Modell mit fest integriertem, byte-verifiziertem Dekompilierer RE D01, §3 Verteilung nach Charakteren (3.1 Lulu, 3.2 Yuna, 3.3 Wakka (noch offen), 3.4 Rikku, 3.5 Kimahri-Koordination, 3.6 Tidus (noch offen), 3.7 Auron (noch offen), 3.8 Zusammenfassung). Nicht betroffen: Writer/Hook/Probe/DLL/Gate. Nur Design + Roadmap-Integration. Dateien: FFXProjectEditor/FFXProjectEditor.csproj (v2.130.3.1 → v2.130.3.2), docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md (umfassende Überarbeitung: neuer §1 RE D01, §3 um 7 Zeichen erweitert, §5/§7/§8/§9/§10/§11 neu nummeriert und aktualisiert), mods/Spira Reforge/VISION_AND_ROADMAP.md (§ 12 in neuer Fassung), CHANGELOG.md + changelogUS.md + docs/governance/VERSIONING.md + docs/ai/SESSION_HANDOFF.md. [vorherige Seite: v2.130.3.1]

v2.130.3.3REVISIONJarvis-MAGIC

Spira Reforge: PHASE 0 ABGESCHLOSSEN A — Halyson hat ALLE TBD-Pools pro Charakter in einem einzigen Durchgang abgearbeitet (Demita→Kimahri, Wakka 5 Zaubersprüche, Auron MAX-Paket 6 Zaubersprüche, Tidus Multi-Hit + Selbst-Buff, Rikku +1 neue Diebes-Fähigkeit)

(dritter Durchgang vom 16.06.2026, direkte Fortsetzung v2.130.3.2; kein Writer/Verhalten). 4 zusätzliche Entscheidungen (von 9 → 13): (1) Owner entlassen = Kimahri (Gimmick „bizarre Monster“ + Blue-Mage-Thema; entlastet Lulu, damit sie sich auf den Elemental Burst konzentrieren kann); (2) Wakka-Pool = A+B kombiniert, 5 Zauber — Biora (AoE-Gift + Schaden) + Sleepra (Flächen-Schlaf) + „Quad Foul“ (Flächen-„Triple Foul“ + Gift = 4 Status-Effekte) + „Double Buster“ (2-Treffer-Einzelangriff, 2-Status-Kombination mit RNG) + „Tide Slash“ (2-Treffer-physischer Angriff) – „Status-Meister + Doppelschlag + verrückte Effekte“; (3) Auron-Pool = MAX-Paket, 6 Zauber — Mass Power Break + Mass Armor Break + Mass Magic Break + Mass Mental Break + Sentinel++ (Sentinel + blockiert physischen und magischen Schaden + partyweit für 1 Runde) + Provokeja (Provoke + Auto-Sentinel + alle Gegner provozieren) — „Auron ist der verdammte TANKER des Spiels“; (4) Tidus-Richtung = Mehrfachtreffer + Selbst-Buff, 4–5 Zauber — Spiral Slash (3-Treffer-Einzelangriff, +5 STR/Zauber-Cap 25) + Tidal Combo (4-Treffer-Flächenangriff, +5 AGI/Cast-Cap 20) + Bladestorm (5-Treffer, zufällig, +Haste für sich selbst für 1 Runde) + Aurochs Rush (Signature-Fähigkeit, solider +AGI-Buff + Haste für 3 Runden) + optional Cheer-Strike (2-Treffer + Cheer für sich selbst). „Tidus war schon immer der Schnellste. Quick Hit WIRD GESCHWÄCHT, daher sind Multi-Hit-Fähigkeiten, die Buffs gewähren, die die eigene Geschwindigkeit erhöhen, wichtig“ — direkter Ausgleich für den QH-Nerf §10.6; (5) Rikku +1 neue Diebesfertigkeit — Halyson bat um eine „selbst erfundene Diebesfertigkeit“, um den Pool zu vervollständigen; Vorschläge von Jarvis: Sleight of Hand (verfeinertes „Mug“), Pickpocket (Stehlen ohne Zugkosten; Jarvis-Standard), Sticky Fingers (Stack +25 % pro Zauber), Backstab (PDEF ignorieren), Cache (direkter Steal-Pool), Smoke Bomb (CTB für die Gruppe überspringen). Vollständige endgültige Verteilung (Phase 0): Lulu 6 + Yuna 5 + Wakka 5 + Rikku 4 + Kimahri 3 + Tidus 4–5 + Auron 6 = 33–34 Zauber von 96 Slots = ~35 % Budget (es bleiben 62+ übrig für -ja Backlog v0.7+ + White Magic Extras). Charakterübergreifende Combos: Auron – Mass Mental Break + Lulu – Multi-Firaga (Wave-Burst ohne MDEF); Auron – Sentinel++ + Yuna – P rotectga/Shellga (2 Runden nahezu vollständige Unverwundbarkeit); Auron „Provoke“ + Wakka „Quad Foul“ (Tank + Massen-Status); Tidus „Bladestorm“ + Auron „Mass Armor Break“ (Tidus-Burst + Ziele ohne DEF). Zusätzliches Risiko durch Tidus’ Selbst-Buff: unendlicher STR/AGI-Stack = QH-ähnliche Degeneration; Begrenzung des Stacks (5 STR / 4 AGI) + Abklingen am Ende des Kampfes (bleibt nicht zwischen den Kämpfen bestehen). 11 verbleibende offene Fragen in §9.2 — alle sind feine Teilentscheidungen (endgültiger Name der Diebes-Fähigkeit von Rikku, 4 vs. 5 Zauber von Tidus) oder technische Spitzenwerte (Multi-Firaga mit zufälligem Treffer) command.bin Feld, „Steal-per-Hit“ bei Mugra/Mugga, „Status-Rider“ pro Treffer bei Wakka, stapelbare Selbstverstärkung bei Tidus, gruppenweiter Buff „Sentinel++“ bei Auron, Persistenz bei Kimahri („Lancet+“) — beeinträchtigen das Gesamtdesign NICHT, sondern blockieren bestimmte Phasen der Authoring-Arbeit. Spenderprüfung 0..95 (§9.2 q18) hat nun einen konkreten Umfang: ~33–34 benötigte Slots. Aktualisiertes Dokument: §3.1.4 „Demita“ wird in §3.5.1 „Kimahri“ verschoben; §3.3 Wakka: 5 festgelegte Zaubersprüche; §3.4 Rikku: +1 Diebesfertigkeit mit 6 Vorschlägen; §3.5 Kimahri: vollständiger Pool (Demita + Erweiterung „Blauer Magier“ um 2–3); §3.6 Tidus: Pool mit 4–5 Multihits + Selbstverstärkung mit Combos gegen QH-Nerf; §3.7 Auron: MAX-Paket mit 6 Zaubern mit charakterübergreifenden Combos + Risiko/Schadensminderung; §3.8 Gesamtübersicht: 33–34 Zauber = 35 % Budget; §9.1 13 Entscheidungen; §9.2 11 Unterentscheidungen/Spikes; §10 Eintrag v2.130.3.3. VISION §12 aktualisiert: Tabelle mit der endgültigen Verteilung pro Zeichen + Pop-up-Kombinationen. Nicht betroffen: writer/hook/probe/DLL/gate. Dateien: FFXProjectEditor/FFXProjectEditor.csproj (v2.130.3.2 → v2.130.3.3), docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md (§ 3.1.4 verschoben + § 3.3/§ 3.4/§ 3.5/§ 3.6/§ 3.7/§ 3.8/§ 9/§ 10 aktualisiert), mods/Spira Reforge/VISION_AND_ROADMAP.md (§12 Billardtisch-Finale + Combos), CHANGELOG.md + changelogUS.md + docs/governance/VERSIONING.md + docs/ai/SESSION_HANDOFF.md. [vorherige Seite: v2.130.3.2]

v2.130.3.6REVISIONJarvis-MAGIC

Spira Reforge: REALITY CHECK + 3 Umkehrungen — Weg 4 (`CharacterUser` (nativ) festgesetzt + Lernfähigkeit über Sphere Grid festgesetzt. Halyson hat gesehen, was ich übersehen habe

(letzter Donnerstag, 16.06.2026, Fortsetzung v2.130.3.3; kein Writer/Verhalten). Abfolge der architektonischen Iterationen in dieser Sitzung: (1) v2.130.3.2 pivot: Ich habe die RE D01 entdeckt, bei der die IDs 0..95 Es handelt sich wohl um einheimische Fische, ich habe sie als „zero hook + 62 freie Plätze“ vermerkt. (2) Halyson hat eröffnet FFX_SPELL_FREE_ID_AUDIT_2026-06-12.md und fragte: „Was meinst du damit?“: Das Audit vom 12.06.2026 hat es bereits bewiesen 0/96 Freie Slots – alle 96 IDs sind mit Vanilla belegt. Meine Aussage „62 übrig“ war falsch. (3) v2.130.3.4 Weg 3: Ich habe „append“ vorgeschlagen ≥96 + Hook für die Charakter-Whitelist (im Stil von „Nul Ward“, verallgemeinert), von Halyson genehmigt. (4) Halyson hat Weg 4 erkannt: „Müsste ich im CommandBin nicht einfach dort CHARACTER USE (zum Beispiel TIDUS) für eine Fähigkeit auswählen, und schon wäre das Problem gelöst? Da bräuchte man gar keinen Hook.“ Ich hatte das native Feld nicht gesehen [Data] public Character_Enum CharacterUser in Ability_Command.cs:29** — vorzeichenbehaftetes Byte Nr. command.bin das festlegt, wer die einzelnen Befehle verwenden darf. Byte-genauer Nachweis: FFX_SPELL_FREE_ID_AUDIT_2026-06-12.md Zeile 86 verweist auf Yojimbo Dismiss (ID 87) und enthält CharacterUser=0x0E (14=Yojimbo) — Die Vanilla-Engine filtert das Menü automatisch nach diesem Feld. Bereits vorhandene Benutzeroberfläche (KernelCommands_Control.axaml:434 ComboBox). Methode 4 ersetzt 1/2/3 — append ≥96 mit CharacterUser pro Zeichen, das direkt über den UI-Editor festgelegt wird. KEIN Hook für den Menüfilter. (5) Halyson hat festgehalten: „Die Fähigkeiten können über das Sphere Grid erlernt werden“ – dies reaktiviert den Vorbehalt Nul Ward §H für IDs ≥96 (Das partyweite Reload-by-Init der Bank überschreibt das Grant-Grid). Lösung: 1 allgemeiner Hook, der NulWardTe erweitert achHook.cpp(já provado emv2.130.2.0) — (a) detour PrepareSaveCommandStatere-asserta bits ≥96 lendo sidecar; (b) detour panel_teach escreve sidecar quando node ativa. Net hook count: 1 (generalização, não hook novo). Sidecar JSON extendsspira-reforge-flags.schema.jsondo Capture Cascade. **Plano técnico atualizado (15 bloqueios honestos catalogados):** Fase 0 ✅ → Fase A appendcommand.bin≥96 comCharacterUser (A.1-A.7 por pool char) → Fase B sidecar schema → Fase C Sphere Grid editor scope expansion (LearnedMove = 0x3000 | id ≥ 96) → Fase D hook generalizado → Fase E RT0/RT1 writer LAB → Fase F RT2 in-game piloto → Fase G Lulu Fury rows → Fase H -jabacklog v0.7+. **Bloqueios pequenos pendentes (spikes):** addr panel_teach runtime, sidecar JSON schema design, side-effectsCharacterUserfilter (Trio of 9999, Doublecast cross-char), Multi-Firaga random-hit field, steal-per-hit Mugra/Mugga, Wakka status-rider per hit, Tidus self-buff stacking, Auron Sentinel++ party-wide buff. **Vantagens Caminho 4 vs alternativas:** (a) zero sacrifício vanilla (coexistência total Firaga + Multi-Firaga, Demi + Demita, Mug + Mugra/Mugga, Sentinel + Sentinel++); (b) net 1 hook (vs 0 do pivot falso, vs 2-3 do Caminho 3); (c) infra ALREADY EXISTING (NulWardTeach hook + sidecar Capture Cascade + editor UI ComboBox); (d) identity vanilla intocada. **Lição honesta documentada:** "sempre que sentir 'zero hook' soando bom demais, abrir os audits existentes antes de propagar a narrativa". **Doc atualizado:** §0 verdade curta (3 reversões + 4ª decisão grid), §1 ownership model (Caminho 4 + grid teach), §7.2 plano técnico (Fases 0-H), §7.3 15 bloqueios honestos, §10 entriesv2.130.3.5ev2.130.3.6. **Não toca:** writer/hook/probe/DLL. Arquivos: FFXProjectEditor/FFXProjectEditor.csproj (v2.130.3.3→v2.130.3.6, pulou .4/.5por terem sido reversões dentro da mesma sessão de design),docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md(§0/§1/§7.2/§7.3/§10 reescritos),CHANGELOG.md+changelogUS.md+docs/governance/VERSIONING.md+docs/ai/SESSION_HANDOFF.md. [anterior: v2.130.3.3`]

v2.130.3.7REVISIONJarvis-MAGIC

Referenzdokument: Konsolidierter Katalog der 96 Charakterfähigkeiten (IDs `0..95`) mit `Power`/`MP`/`Formula`/`Acc`/`Hits`/Element/Effekt + AbiMap-Architektur × party-weite Bank

(Protokoll-Dokument / Referenzkatalog; kein Autor/Verhalten/RT2; fasst lediglich das bereits verstreut vorhandene Wissen in einem Dokument zusammen FFX_SPELL_FREE_ID_AUDIT_2026-06-12.md + FFX_SPELL_LEARN_ABIMAP_INFERNO_2026-06-15.md + FFX_BATTLE_COMMAND_MENU_INFERNO_2026-06-15.md + CommandCharacter_Dictionary.cs + Ability_Command.cs). Halyson hat die Tabelle mit den 96 Fähigkeiten in MD als operative Referenz für den Mod angefordert. Neues Dokument docs/reverse/FFX_PLAYER_COMMAND_CATALOG_0_TO_95_2026-06-16.md (8 Abschnitte, ~250 Zeilen): §0 TL;DR: Ausnutzung der Obergrenze bei 95 (AbiMap 96 physikalische Bits) + RE-Kreuzprüfungen; §1 Wie die Engine das Menü festlegt (FFX_Btl_IsCommandAvailable @ 0x39BB70 pro Charakter vs. gruppenweit mit CharacterUser filter); §2 Kodierung LearnedMove = 0x3000 | id vom panel.bin (Verweis SphereGridExplorer_DataModel.cs:30-31); §3 Vollständiger Katalog 0..95, unterteilt in 9 Gruppen (Core/Menü 0–5, Fertigkeiten 6–21, Spezial 22–25, Cheer 26–31, Kimahri/Verteidigung/Soziales 32–42, Wht Magic 43–64, Blk Magic 65–83, Aeon-Menü 84–87, Rikku-Endgame 88–95) mit kanonischen Werten aus FFX HD Remaster (US/JP) — MP/Power/Formel/Treffsicherheit/Treffer/Element/Effekt; §4 entscheidendes Skript zu „What the Magic IS“ über 3 Flags (DamageFlags + DamageFormula_Enum + PreviewFlags) mit der Tabelle „Heilen/Wiederbeleben/Reinigen/Physisch/Magisch/Status/Buff/Schwerkraft/Energieentzug“; §5 die 11 IDs, die nicht über das Raster erlernt werden können (missing=[0,1,2,3,4,5,33,84,85,86,87] in allen 10 Regionen — system/Defend/Aeon/Yojimbo); §6 Party-weite IDs 96+ (Overdrives, Aeons, Mortes, Mix, Pseudo-KI) mit drei Gründen für die Trennung im Design; §7 Konsequenzen für Spira Reforge in Verbindung mit dem Caminh Nr. 4 des v2.130.3.6; §8 Querverweise. Nicht betroffen: writer/hook/probe/DLL/gate. Dateien: FFXProjectEditor/FFXProjectEditor.csproj (v2.130.3.6 → v2.130.3.7), docs/reverse/FFX_PLAYER_COMMAND_CATALOG_0_TO_95_2026-06-16.md (neu), CHANGELOG.md + changelogUS.md + docs/governance/VERSIONING.md + docs/ai/SESSION_HANDOFF.md. [vorherige Seite: v2.130.3.6]

v2.130.3.8REVISIONJarvis-MAGIC

Spira Reforge: Pass 1 „Vanilla Offensive Rebalance“ festgelegt — 16 offensive Fertigkeits-Buffs + Bereinigung der Auto-Fähigkeiten + Erhöhung der MP-Sphäre

(nur Design / von Halyson festgelegte Entscheidungen; keine Autorenbeiträge/Verhaltensänderungen in diesem Durchgang). Halyson hat eröffnet FFX_PLAYER_COMMAND_CATALOG_0_TO_95_2026-06-16.md und fügte hinzu: „Zauber erfüllen ihren Zweck, sogar Heilzauber. Aber der Rest? LÄCHERLICH. Full Break? Das kann mir mal, das trifft fast nie und der Schaden ist lächerlich für 99 MP.“ Knallharte Diagnose: 20 offensive Standard-Fähigkeiten mit Pow er = 16 (= multiplier 1.0× = Attack base) ou Leistung < 16 (= pior que Attack); Auron Full Break Power 16 / Acc 36 / MP 99 = crime contra o jogador. Pacote final cravado (3 frentes em 1 pass): (1) Damage buff de 16 skills (Extracts removed): Wakka 8 status-riders (Sleep/Silence/Dark Attack P16→20 Acc 50→60, Zombie Attack P16→24 Acc 50→60, Busters P16→26 Acc 100, Triple Foul P16→32 Acc 100→90 MP 24→28), Auron 4 Breaks (Power/Magic Break P16→22 Acc 50→80 MP 8→10, Armor/Mental Break P16→24 Acc 36→70 MP 12→14), Full Break P16→48 (3× damage cravado Halyson) Acc 36→90 MP 99→75, Tidus 2 Delays (Delay Attack P12→18 MP 5→6, Delay Buster P14→22 MP 10→12), Rikku Mug P16→20. Filosofia: Power ≥ 18 sempre quando skill paga MP; premium MP ⇒ premium Power; Breaks Acc 36-50% sobem 65-90%. (2) Auto-Ability cleanup: Slot 12 Half MP Cost MANTÉM (justificativa Halyson: Lulu Magic Booster + custos altos = ainda paga Ether/Elixir = balance natural). Slot 13 (ex-One MP Cost, cheese de 1 MP universal) REMOVIDO → vira Mana Spring (+5 MP/turno em batalha; regen tick passivo; substitui economia sem virar cheese — em battle de 10 turnos = +50 MP cumulativo). Slot 23 (ex-Break HP Limit) vira "Break Limits" (bits 0x0200 | 0x0400 OR em ability_flags_64, HP cap + MP cap juntos via engine vanilla; byte-edit puro, zero hook); §10.8 do VISION cravado. Slot 24 (ex-Break MP Limit) vira "Devil's Bargain" (+50% dano dado / +50% dano recebido — glass cannon switch simétrico; 2-pass: Pass 1 placeholder funcional agora com bit reassignment, Pass 2 hook damage calc depois com RT2). (3) MP Sphere node bump (escopo B cravado Halyson "B simplesmente B"): Standard Grid MP +40 → +60, Expert Grid MP +20 → +30 (escala proporcional 1.5× cross-grid). Edit trivial via SphereGridNodeTypeEntry.IncreaseAmount (offset 0x14, ushort) em SphereGrid_File.cs:519. In dieser Sitzung festgelegte Entscheidungen: (a) Halyson hat den Katalog geöffnet und das Problem identifiziert; (b) ich habe eine Tabelle mit 20 Buff-Fähigkeiten + 4 Kategorien von Auto-Fähigkeiten vorgeschlagen; (c) Halyson legte „Extracts“ heraus und „Full Break“ 3× fest; (d) er legte „One MP entfernt“ fest, „Mana Shield“ jedoch nicht (schafft neues Meta); (e) ich bestätigte §10.8, indem ich Slot 23 umkehrte, sodass er zu Br wird eak Limits und Slot 24 werden umfunktioniert („xereca“); (f) habe „Devil's Bargain“ in Slot 24 gesetzt + habe den Vorbehalt „2-Pass“ verstanden; (g) habe „Mana Spring“ in Slot 13 verfeinert + „Spell Spring“-Backlog. Katalogisierte technische Caveats: Devil's Bargain benötigt eine Hook-Schadensberechnung + RE-Adresse FFX_DamageCalc_* offen; „Mana Spring“ benötigt einen Turn-Tick-Hook + Identifizierung eines freien Bits in ability_flags_64; Treffergenauigkeit vs. Status-Rider-Genauigkeit – ausstehender Spike RT2; Triple-Foul-Genauigkeit 100→90 – ausstehender Spike (Bestätigung: „Dreifach-Garantie“ bricht nicht); Full-Break-MP-Skalierung im späten Spielverlauf OK (75 ist mit Half MP immer noch extrem teuer); die Neuzuweisung des Auto-Ability-Bits in Slot 24 erfordert freie Scan-Flags in AutoAbilityHardcodedFlagCatalog.cs. Technischer Plan Phase 1 (reines Byte-Edit v2.131.x PATCH): 1.1 command.bin 16 Offensiv-Buff, 1.2 Slot 23 „Break Limits“, 1.3 Slot 13 Platzhalter für „Mana Spring“, 1.4 Slot 24 Platzhalter für „Devil's Bargain“, 1.5 panel.bin MP-Knoten, 1.6 Textpool, 1.7 RT0/RT1-Gate-Byte-Identität, 1.8 RT2-Pilot. Phase 2 (Hooks LAB v2.133.x+): 2.1 Berechnung des RE-Schadens, 2.2 „Mana Spring“-Turn-Tick-Hook, 2.3 „Devil’s Bargain“-Schadens-Hook, 2.4 RT2-Hooks. Synergie mit VISION: §10.4 QH-Nerf (ergänzend – Buffs für Fähigkeiten + QH-Nerf = abwechslungsreiche Offensive), §10.5 Magie (bleibt unverändert, nächster Pass), §10.6 OD Lulu Fury (nächster Pass), §10.8 „Break“ HP+MP-Fusion (in diesem Pass 1.2 FESTGELEGT), §10.9 Aurons geheime Fähigkeit (VERSTÄRKT – „Break Limits“ + „Devil’s Bargain“ + „Breaks“-Buff = „Auron, der unbesiegbare Risikoträger“), §10.10 Magiegeschwindigkeit (Spell Spring-Rückstand), §10.11/§10.13 (nächster Durchgang), Pfad 4 Black Magic Extended (indirekt – Vanilla-Baseline schafft Kontext für ≥96 Zauber). Offene Fragen im Backlog: „Spell Spring“ wartet auf den nächsten freien Slot (Kandidaten für Opfer: Slot 18 „Double AP“, 19 „Triple AP“, 21 „Pickpocket“, 22 „Master Thief“ – Progressions-/Beute-Cheat); Status/Break Sharpness für kommende charakterbezogene Identitäten §10.9. Nicht berühren: Writer/Hook/Probe/DLL/csproj auf der Writer-Seite. Dateien: FFXProjectEditor/FFXProjectEditor.csproj (v2.130.3.7 → v2.130.3.8); docs/reverse/FFX_SPIRA_REFORGE_VANILLA_OFFENSIVE_REBALANCE_2026-06-16.md (neu, ~280 Zeilen, 7 Abschnitte: §0 kurze Wahrheit, §1 Diagnose „Vanilla-Gemetzel“, §2 konsolidiertes Paket c mit Tabelle 16: Fähigkeiten + Bereinigung der Auto-Fähigkeiten + MP-Sphäre, §3: Technische Hinweise (6 Punkte), §4: Implementierungsplan (Phase 1+2), §5: Offene Fragen, §6: Auslieferungsversion, §7: Querverweise); CHANGELOG.md + changelogUS.md + docs/governance/VERSIONING.md + docs/ai/SESSION_HANDOFF.md + mods/Spira Reforge/VISION_AND_ROADMAP.md (nächster Schritt). [vorheriger: v2.130.3.7 Referenzkatalog]

Zurück zu Updates