teamGreg/gregCore
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: update to latest game version

Browse Source 
docs: removed redundant docs
deps: updated dependencies to be implemented.
feat: started implementation of new GridBuild Feature
This commit is contained in:
Marvin
2026-04-21 03:39:08 +02:00
parent 5930e5d160
commit c9706de622
352 changed files with 1988 additions and 36105 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.gitignore
+2
View File
@@ -5,6 +5,8 @@ node_modules/
.idea/
*.user
*.suo
MISSING.md
**/MISSING.md
# Specifically allow reference DLLs for CI
!gregLib/references/
GRIDIMPLEMENTATION.md
+640
View File
@@ -0,0 +1,640 @@
## GREGCORE — GREG.GRID PLACEMENT SYSTEM + GREG.SAVE ENGINE — MASTER-PROMPT
> Version: 0.1.0 | Ziel-Modul: greg.GridPlacement + greg.SaveEngine
ROLLE
Du bist Lead Framework-Architekt, IL2CPP-Reverse-Engineer und Senior
Technical Writer für gregCore — dem MelonLoader-basierten Modding-Stack
für "Data Center" (Waseku, Steam, Unity 6000.4.2f1, Il2CPP, .NET 6, x64).
Du arbeitest direkt gegen die IL2CPP-Assemblies aus dem Workspace
(gregReferences / Assembly-CSharp.dll) und gegen das bestehende
gregCore-Framework (GregEventDispatcher, GregPayload, GregNativeEventHooks,
GregCompatBridge, GregLanguageRegistry, GregHarmonyService, GregUIManager).
ZIEL DIESES PROMPTS
Implementiere zwei neue gregCore-Subsysteme vollständig:
1. greg.GridPlacement — ersetzt das RackHolder-Plate-System durch
ein Sims-artiges Grid-Placement-System
2. greg.SaveEngine — ersetzt das Vanilla-Save-System durch eine
eigenständige, hochperformante Datenbank
Beide Subsysteme werden über das F8-Menü aktiviert, konfiguriert und
gesteuert. Alle Mod-Einstellungen im Framework laufen künftig über F8.
═══════════════════════════════════════════════════════════
SCHRITT 0 — PRE-ANALYSIS (PFLICHT VOR JEDER IMPLEMENTIERUNG)
═══════════════════════════════════════════════════════════
LIES in dieser Reihenfolge — niemals überspringen:
1. Assembly-CSharp.dll (via IL2CPP-Workspace / gregReferences)
2. Suche nach allen Typen, die enthalten:
RackHolder, RackPlate, RackPlaceholder, RackBase,
FloorTile, FloorGrid, GridManager, PlacementManager,
SaveManager, SaveData, GameSave, SerializationManager,
NetworkSaveData, SwitchSaveData, ServerSaveData
3. Für jeden gefundenen Typ dokumentiere:
- Exakter Klassenname + Namespace
- Parent-Klasse (MonoBehaviour, Il2CppObjectBase, ...)
- Key-Fields (Positionen, IDs, Größen, State-Flags)
- Key-Methods (Place, Remove, Load, Save, Serialize, Init)
- Bekannte IL2CPP-Interop-Probleme aus dem Projektverlauf
4. Bestimme:
- Exakte Größe einer FloorTile in Unity-World-Units (Vector3)
- Exakte Größe eines Racks in Unity-World-Units
- Wie RackHolder-Plates aktuell instanziiert werden (Prefab? Code?)
- Welches Koordinatensystem das Spiel nutzt (Y-up, Z-forward?)
- Wo SaveManager.SaveGame() / LoadGame() aufgerufen wird
- Ob Save-Dateien binary oder JSON sind (aus bisheriger Analyse:
Binary IL2CPP-serialized — bestätige und dokumentiere)
OUTPUT von Schritt 0:
PRE-ANALYSIS REPORT:
- FloorTile World-Size: [X]u × [Z]u
- Rack World-Size: [X]u × [Z]u × [Y]u
- Grid-Cell Conclusion: 1 Cell = Rack-Footprint = [X]u × [Z]u
- Sub-Grid: 4 Sub-Cells pro Grid-Cell (2×2 Unterteilung)
- RackHolder-Placement-Methode: [gefundene Methode]
- Save-Format: Binary IL2CPP [bestätigt / abweichend]
- Vanilla-Kompatibilität: NICHT angestrebt (by design)
═══════════════════════════════════════════════════════════
TEIL A — GREG.GRIDPLACEMENT SYSTEM
═══════════════════════════════════════════════════════════
KONZEPT
Das Vanilla-System platziert Racks via vorab platzierten "RackHolder"-
Floor-Plates. Dieses System wird durch ein dynamisches Grid-Placement
ersetzt — vergleichbar mit The Sims, Planet Coaster oder ähnlichen
Bausimulationen:
- Der Raumboden ist ein unsichtbares Grid
- 1 Grid-Cell = 1 Rack-Footprint
- Jede Grid-Cell ist intern in 4 Sub-Cells (2×2) unterteilt für
präzises Snapping und spätere Erweiterungen (Kabeltrassen, Licht)
- Racks werden direkt per Drag/Click auf Grid-Cells platziert
- Kein Vorab-Platzieren von Plates mehr nötig
A-1: CORE CLASSES (Namespace: greg.GridPlacement)
GregGridManager
Verwaltet das gesamte Grid im Speicher.
Felder:
Dictionary<Vector2Int, GregGridCell> cells
float cellSizeX, cellSizeZ // aus Pre-Analysis ermittelt
Vector3 gridOrigin // Weltkoordinaten-Ursprung des Grids
Methoden:
void Initialize(Vector3 origin, int width, int depth)
GregGridCell GetCell(Vector2Int coord)
GregGridCell GetCellAtWorldPos(Vector3 worldPos)
bool IsCellOccupied(Vector2Int coord)
bool PlaceRack(Vector2Int coord, GregPlaceableRack rack)
bool RemoveRack(Vector2Int coord)
Vector3 SnapToGrid(Vector3 worldPos)
void DrawDebugGrid() // OnGUI-basiert, nur im Debug-Modus
GregGridCell
Repräsentiert eine einzelne Grid-Zelle.
Felder:
Vector2Int coord
bool isOccupied
GregPlaceableRack? occupant
GregSubCell[4] subCells // 2×2 Sub-Grid
bool isBlocked // Wand, Hindernis etc.
GregSubCell
Felder:
Vector2Int subCoord // 0–3
bool isOccupied
string occupantType // "cable", "light", "reserved", null
GregPlaceableRack
Wraps ein bestehendes IL2CPP-Rack-Objekt.
Felder:
string rackId
Vector2Int gridCoord
GameObject? unityGameObject
Il2CppObjectBase? vanillaRackRef // Referenz auf Vanilla-Objekt
Methoden:
void PlaceAt(Vector2Int coord, Vector3 worldPos)
void Remove()
void Highlight(bool active)
GregPlacementController
Steuert den Build-Mode (Eingabe, Preview, Snapping).
Felder:
bool buildModeActive
GregPlaceableRack? previewRack
GregGridManager grid
Methoden:
void ActivateBuildMode()
void DeactivateBuildMode()
void OnUpdate() // Raycast + Snapping + Preview
void OnGUI() // Cursor-Overlay, Zell-Highlight
void TryPlace(Vector3 worldPos)
void TryRemove(Vector3 worldPos)
A-2: HARMONY-PATCHES (via GregHarmonyService)
PATCH 1 — RackHolder-Spawn unterdrücken
Ziel: [ExaktKlassennameAusAnalyse].PlaceRackHolder (o.ä.)
Typ: Prefix → return false wenn GridPlacement aktiv
Zweck: Vanilla-RackHolder-Plates werden nicht mehr gespawnt.
Flag: FeatureFlags.GRID_PLACEMENT_ACTIVE
PATCH 2 — Rack-Placement umleiten
Ziel: [ExaktKlassennameAusAnalyse] — Methode die Rack an Position setzt
Typ: Prefix → umleiten zu GregPlacementController.TryPlace()
Zweck: Alle Rack-Placements laufen durch das Grid-System.
PATCH 3 — Rack-Removal umleiten
Ziel: [ExaktKlassennameAusAnalyse] — Methode die Rack entfernt
Typ: Postfix → GregGridManager.RemoveRack() aufrufen
WENN ZIELKLASSE NICHT GEFUNDEN:
→ Erstelle MISSING.md mit:
Welche Klasse wird gesucht, warum, vorgeschlagene Signatur,
Workaround bis Klasse identifiziert ist.
→ Implementiere GregPlacementController als standalone (kein Patch)
mit eigenem Raycast + GameObject-Instantiate für Preview-Mesh.
A-3: GRID VISUAL (OnGUI + Unity)
Grid-Darstellung (nur wenn Build-Mode aktiv):
- Unsichtbares Grid wird als dünnes Linien-Overlay gerendert
- Aktive Zelle: Highlight in GregUITheme.Primary (61F4D8) mit 40% Alpha
- Belegte Zelle: Highlight in GregUITheme.Error (ED4245) mit 30% Alpha
- Freie Zelle: kein Overlay (Grid-Linien in GregUITheme.GhostBorder)
- Sub-Grid-Linien: sichtbar bei Zoom-In > [konfigurierbarer Threshold]
- Preview-Rack: halbtransparentes Ghost-Mesh auf Snap-Position
Rendering:
- Grid-Linien: GL.Lines in OnGUI (nicht OnRenderObject — IL2CPP-safe)
- Alternativ: Plane-Mesh mit transparentem Material wenn GL nicht
verfügbar → MISSING.md mit Grund
A-4: NEUE HOOKS (in GregNativeEventHooks registrieren)
public const string WorldRackPlaced = "greg.WORLD.RackPlaced";
public const string WorldRackRemoved = "greg.WORLD.RackRemoved";
public const string WorldRackMoved = "greg.WORLD.RackMoved";
public const string WorldGridReady = "greg.WORLD.GridReady";
public const string WorldBuildMode = "greg.WORLD.BuildModeToggled";
Payload-Felder (GregPayload):
RackPlaced/Removed/Moved:
"rackId" → string
"gridCoord" → string (z.B. "4,7")
"worldPos" → string (z.B. "12.5,0,8.0")
"modId" → string (aufrufender Mod)
═══════════════════════════════════════════════════════════
TEIL B — GREG.SAVEENGINE
═══════════════════════════════════════════════════════════
KONZEPT
Das Vanilla-Save-System ist Binary-IL2CPP-serialized und nicht
modder-freundlich (aus bisheriger Analyse bestätigt: portVlanFilters
nur Runtime-only, kein direkter Save-Zugriff möglich).
greg.SaveEngine ersetzt es durch eine eigenständige, embedded Datenbank:
Datenbank: LiteDB 5.x (embedded, serverless, document-oriented)
Grund: LiteDB ist eine BSON-basierte embedded NoSQL-DB für .NET —
schneller als SQLite für Document-Reads weil kein Schema-Overhead,
kein Server, kein Connection-Pool. Alles in einer einzigen .db-Datei.
NuGet: LiteDB, Version 5.0.21
WICHTIG: LiteDB wird via ILRepack in gregCore.dll eingebettet —
keine externe DLL, keine UserLibs-Abhängigkeit.
Vanilla-Kompatibilität: NICHT vorhanden — by design.
B-1: VANILLA SAVE DETECTION (PFLICHT)
Beim Spielstart und bei jedem SaveManager.LoadGame():
→ Prüfe ob der geladene Spielstand ein Vanilla-Save ist.
→ Erkennungskriterien (alle aus Pre-Analysis zu bestätigen):
a) Kein greg.SaveEngine-Header in der Save-Datei
b) Bekannte Vanilla-Binary-Signatur (Magic Bytes / Header-Pattern)
c) Dateiname-Pattern falls bekannt
→ Wenn Vanilla-Save erkannt:
[gregCore] ⚠ Vanilla save detected — greg.GridPlacement DISABLED
[gregCore] ⚠ Vanilla save detected — greg.SaveEngine in READ-ONLY mode
→ GregFeatureGuard.DisableFeature("GridPlacement")
→ GregFeatureGuard.DisableFeature("SaveEngine.Write")
→ F8-Menü zeigt Banner: "Vanilla Save — Modded features disabled"
→ Alle Game-Breaking-Funktionen (Rack-Placement-Override,
SaveManager-Patch) werden NICHT aktiviert.
→ Wenn greg.SaveEngine-Save erkannt:
→ Normal-Modus: alle Features aktiv.
GregFeatureGuard (neue Klasse in frameworkSdk/):
public static class GregFeatureGuard
public static void DisableFeature(string featureKey)
public static void EnableFeature(string featureKey)
public static bool IsEnabled(string featureKey)
public static bool IsVanillaSave { get; private set; }
public static event Action<string> OnFeatureStateChanged
Modder-API (für Wiki dokumentieren):
Modder-Code kann prüfen:
if (GregFeatureGuard.IsVanillaSave) { ... }
if (!GregFeatureGuard.IsEnabled("GridPlacement")) { ... }
Event subscriben:
GregFeatureGuard.OnFeatureStateChanged += (key) => { ... }
B-2: LITEDB SCHEMA
Collection: "grid_state"
{
_id: ObjectId,
sessionId: string (GUID),
savedAt: DateTime,
gregSaveVersion: string ("1.0.0"),
gridWidth: int,
gridDepth: int,
gridOrigin: { x: float, y: float, z: float },
cellSizeX: float,
cellSizeZ: float,
placedRacks: [
{
rackId: string,
gridCoord: { x: int, z: int },
worldPos: { x: float, y: float, z: float },
rackType: string,
label: string,
placedAt: DateTime
}
]
}
Collection: "server_state"
{ serverId, rackId, serverType, isOn, isBroken, eolTime,
customerId, appId, label, gregSavedAt }
Collection: "network_state"
{ switchId, switchType, rackId, isOn, isBroken, eolTime,
portVlanFilters: [ { portIndex, vlanId, mode } ],
gregSavedAt }
Collection: "cable_state"
{ cableId, fromPort, toPort, cableType, color, length, gregSavedAt }
Collection: "greg_meta"
{ key: "header", value: "greg.SaveEngine.v1",
gameVersion: string, gregCoreVersion: string,
createdAt: DateTime, lastSavedAt: DateTime,
isVanillaSave: false }
B-3: SAVEENGINE KLASSEN
GregSaveEngine (Namespace: greg.SaveEngine)
Felder:
LiteDatabase db
string dbPath // GameDir/Saves/gregSave_{sessionId}.greg.db
Methoden:
void Initialize(string saveDir)
void SaveAll() // Kompletter State-Dump
void LoadAll() // Kompletter State-Restore
void SaveGridState(GregGridManager grid)
void LoadGridState(GregGridManager grid)
void SaveServerState(IEnumerable<ServerData> servers)
void LoadServerState()
bool IsGregSave(string filePath) // Header-Prüfung
GregSaveScheduler
Auto-Save alle N Sekunden (konfigurierbar via F8, default: 60s)
Läuft als MelonCoroutines.Start(AutoSaveCoroutine())
Kein Blocking des Game-Threads — LiteDB schreibt async via Task
GregSaveNotifier
Toast + Log bei Save/Load-Events:
[gregSave] ✓ Auto-saved — 847 objects in 12ms
[gregSave] ✓ Loaded from gregSave_abc123.greg.db
[gregSave] ⚠ Vanilla save detected — modded features disabled
B-4: HARMONY-PATCHES (via GregHarmonyService)
PATCH 4 — SaveManager.SaveGame() ergänzen
Typ: Postfix
Zweck: Nach jedem Vanilla-Save zusätzlich GregSaveEngine.SaveAll()
aufrufen (nur wenn kein Vanilla-Save-Modus).
PATCH 5 — SaveManager.LoadGame() ergänzen
Typ: Postfix
Zweck: Nach jedem Vanilla-Load GregSaveEngine.LoadAll() aufrufen.
Wenn Vanilla-Save erkannt → GregFeatureGuard aktivieren.
PATCH 6 — Vanilla-Save-Blocker (optional, konfigurierbar)
Typ: Prefix → return false
Zweck: Im reinen greg.SaveEngine-Modus kann Vanilla-Save vollständig
deaktiviert werden (nur wenn User explizit in F8 aktiviert).
Default: AUS — Vanilla-Save läuft immer zusätzlich.
B-5: ILREPACK INTEGRATION (PFLICHT)
Alle externen Dependencies werden via ILRepack in gregCore.dll eingebettet.
Keine externe DLL-Abhängigkeit in UserLibs oder GameDir.
ILRepack-Konfiguration (build-Pipeline, PowerShell + MSBuild):
Schritt 1 — NuGet-Restore:
dotnet restore gregCore.sln
→ Lädt: LiteDB 5.0.21, MoonSharp 2.0.0
Schritt 2 — Build:
dotnet build --configuration Release
→ Output: gregCore_raw.dll (ohne merged deps)
Schritt 3 — ILRepack:
ILRepack.exe \
/out:gregCore.dll \
/internalize \
/lib:[MelonLoader-Reference-Path] \
gregCore_raw.dll \
LiteDB.dll \
MoonSharp.Interpreter.dll
→ Output: gregCore.dll (alle deps embedded, internalisiert)
Schritt 4 — Deploy:
Copy gregCore.dll → "Data Center/Mods/"
build.ps1 (vollständig, Windows PowerShell 5.1 + 7.x kompatibel):
[komplett implementieren, keine Platzhalter, korrekte Exitcodes]
build.sh (vollständig, Linux/macOS):
[komplett implementieren]
Hinweis zu ILRepack /internalize:
Alle eingebetteten Typen werden internal — kein Namespace-Konflikt
mit anderen Mods die ggf. LiteDB verwenden.
Ausnahme: greg-eigene public APIs bleiben public.
═══════════════════════════════════════════════════════════
TEIL C — F8 MENÜ — MOD-EINSTELLUNGEN HUB
═══════════════════════════════════════════════════════════
KONZEPT
F8 ist der zentrale Settings-Hub für alle gregCore-Mods.
Kein Mod hat mehr eigene Settings-Panels außerhalb von F8.
C-1: GregSettingsHub (Namespace: greg.UI.Settings)
Öffnet/schließt via F8 (KeyCode.F8).
Basis: GregUIBuilder-Pattern (bereits im Framework).
Layout: Tab-basiert — jede Erweiterung registriert einen eigenen Tab.
Standard-Tabs (immer vorhanden):
[Framework] — gregCore Core-Settings
[Grid] — greg.GridPlacement Settings
[SaveEngine] — greg.SaveEngine Settings
[Languages] — GregLanguageRegistry Status
[Debug] — Diagnose, Log-Level, Hooks-Monitor
Tab-Registration API (für Modder):
GregSettingsHub.RegisterTab(string tabId, string label, Action<GregUIBuilder> buildFn)
GregSettingsHub.UnregisterTab(string tabId)
C-2: TAB — [Grid] Einstellungen
Toggle: "Grid Placement Active"
→ FeatureFlags.GRID_PLACEMENT_ACTIVE
→ Aktiviert/deaktiviert Build-Mode-Keybind
Toggle: "Show Grid Lines"
→ GregGridManager.showGridLines
Toggle: "Show Sub-Grid"
→ GregGridManager.showSubGrid
Slider: "Sub-Grid Zoom Threshold" [1.0 – 10.0]
Toggle: "Build Mode Key: B"
→ Keybind für Build-Mode on/off (default B)
Label: "Placed Racks: [N]" (live, read-only)
Label: "Grid Size: [W]×[D]" (live, read-only)
Button: "Clear All Greg Racks"
→ GregGridManager.ClearAll() mit Confirm-Dialog
Banner: "[WarningBanner wenn VanillaSave]"
→ "Vanilla Save detected — Grid Placement disabled"
C-3: TAB — [SaveEngine] Einstellungen
Toggle: "greg.SaveEngine Active"
→ FeatureFlags.SAVE_ENGINE_ACTIVE
Slider: "Auto-Save Interval (seconds)" [10 – 300, default 60]
Toggle: "Disable Vanilla Save (expert!)"
→ FeatureFlags.DISABLE_VANILLA_SAVE (default OFF)
→ Zeigt Warning: "Vanilla saves will be skipped entirely!"
Toggle: "Save Grid State"
Toggle: "Save Server State"
Toggle: "Save Network State"
Toggle: "Save Cable State"
Label: "Last Save: [Timestamp]" (live)
Label: "DB File: [Pfad]" (read-only)
Button: "Save Now"
→ GregSaveEngine.SaveAll()
Button: "Open Save Folder"
→ System.Diagnostics.Process.Start(saveDir)
Banner: "[WarningBanner wenn VanillaSave]"
C-4: TAB — [Framework] Einstellungen
Label: "gregCore v[VERSION]"
Label: "MelonLoader v[VERSION]"
Label: "Save Mode: [Greg / Vanilla / Hybrid]"
Toggle: "Verbose Startup Log"
Toggle: "Debug Mode (alle Hooks loggen)"
Button: "Run Language Scan now"
→ GregLanguageRegistry.ScanAndActivate()
Button: "Show Missing.md Status"
→ Listet alle bekannten MISSING.md-Einträge
C-5: RENDERING RULES (F8 Panel)
- Ausschließlich OnGUI (UnityEngine.GUI + GUILayout) — kein Web-UI
- Luminescent Architect Design System:
Background: Color(0.00f, 0.07f, 0.07f, 0.93f)
Accent: Color(0.38f, 0.96f, 0.85f, 1f) [61F4D8]
Text: Color(0.75f, 0.99f, 0.97f, 1f) [C0FCF6]
Warning: Color(0.93f, 0.25f, 0.27f, 1f) [ED4245]
- GUIStyle wird in OnInitializeMelon gecacht, NICHT in OnGUI neu erstellt
- Panel Breite: 480px, Höhe: dynamisch
- Position: Bildschirmmitte beim Öffnen
- ESC schließt das Panel (zusätzlich zu F8-Toggle)
═══════════════════════════════════════════════════════════
TEIL D — MODDER-API (für gregWiki dokumentieren)
═══════════════════════════════════════════════════════════
Folgende APIs müssen vollständig im gregWiki dokumentiert werden.
Jede API mit Signatur-Box, Beispiel und Hinweis auf Vanilla-Guard.
D-1: Grid-Placement API
// Prüfen ob Grid-Feature aktiv (kein Vanilla-Save)
bool active = GregFeatureGuard.IsEnabled("GridPlacement");
// Rack-Placement-Event subscriben
GregEventDispatcher.On(GregNativeEventHooks.WorldRackPlaced, (payload) => {
string rackId = GregPayload.Get<string>(payload, "rackId", null);
string coord = GregPayload.Get<string>(payload, "gridCoord", null);
}, modId: "myMod");
// Freie Zelle prüfen
GregGridManager grid = GregGridManager.Instance;
bool free = !grid.IsCellOccupied(new Vector2Int(3, 5));
// Rack programmatisch platzieren
grid.PlaceRack(new Vector2Int(3, 5), myRack);
D-2: SaveEngine API
// Vanilla-Save-Status prüfen
if (GregFeatureGuard.IsVanillaSave) {
LoggerInstance.Warning("Vanilla save — custom save disabled");
return;
}
// Eigene Daten im greg.SaveEngine speichern
GregSaveEngine.Instance.GetCollection<MyData>("mymod_data")
.Upsert(new MyData { Id = "key1", Value = 42 });
// Eigene Daten laden
var data = GregSaveEngine.Instance.GetCollection<MyData>("mymod_data")
.FindById("key1");
// Feature-State-Change subscriben
GregFeatureGuard.OnFeatureStateChanged += (featureKey) => {
if (featureKey == "GridPlacement") RefreshUI();
};
D-3: F8-Settings Tab registrieren
// Eigenen Tab im F8-Menü registrieren
GregSettingsHub.RegisterTab("myMod.settings", "My Mod", (builder) => {
builder.AddLabel("My Mod v1.0.0")
.AddToggle("Enable Feature X", config.FeatureX, v => config.FeatureX = v)
.AddSlider("Speed", 0.1f, 5f, config.Speed, v => config.Speed = v)
.AddButton("Reset to Defaults", ResetConfig);
});
// Tab beim Mod-Shutdown entfernen
GregSettingsHub.UnregisterTab("myMod.settings");
═══════════════════════════════════════════════════════════
TEIL E — GREGWIKI SEITEN (vollständige Markdown-Dateien)
═══════════════════════════════════════════════════════════
Erstelle folgende Wiki-Seiten vollständig (YAML-Frontmatter, copy-paste-ready):
E-1: grid-placement-guide.md
- Was ist greg.GridPlacement?
- Vanilla RackHolder vs. Grid-System (Vergleichstabelle)
- Grid-Terminologie: Cell, SubCell, Snap, Origin
- Wie Racks platziert werden (Schritt-für-Schritt)
- Build-Mode aktivieren (F8 → [Grid] Tab)
- Keybinds-Übersicht
- Vanilla-Save-Verhalten (was wird deaktiviert, warum)
- Modder-API: Grid-Events subscriben, Zellen prüfen, Racks platzieren
- Hook-Referenz: WorldRackPlaced, WorldRackRemoved, WorldRackMoved
- MISSING.md-Hinweis wenn RackHolder-Patch nicht möglich
E-2: save-engine-guide.md
- Was ist greg.SaveEngine?
- Vanilla-Save vs. greg.SaveEngine (Vergleichstabelle)
- LiteDB: warum, was, wo (DB-Datei-Pfad)
- Vanilla-Save-Detection: wie wird erkannt, was passiert
- Game-Breaking-Features: vollständige Liste was deaktiviert wird
- Auto-Save konfigurieren (F8 → [SaveEngine] Tab)
- Modder-API: eigene Collections schreiben/lesen
- Schema-Referenz: alle Collections + Felder
- ILRepack: warum embedded, keine externe DLL
- Vanilla-Kompatibilität: expliziter Hinweis "NOT COMPATIBLE by design"
E-3: f8-settings-hub.md
- Was ist das F8 Settings Hub?
- Alle Standard-Tabs und ihre Funktionen
- Modder: eigenen Tab registrieren (vollständiges Beispiel)
- Vanilla-Save-Banner: wann erscheint er, was bedeutet er
- Rendering-Regeln (OnGUI, Design-System-Farben)
- API-Referenz: RegisterTab, UnregisterTab
E-4: vanilla-save-compatibility.md
- Was ist ein "Vanilla Save"?
- Wie greg.SaveEngine es erkennt
- Vollständige Liste: welche Features bei Vanilla-Save deaktiviert werden
- GregFeatureGuard API (für Modder die prüfen wollen)
- Was Spieler tun müssen um greg.SaveEngine zu nutzen (neues Spiel)
- Migration: gibt es einen Vanilla→Greg-Konverter? (MISSING.md wenn nein)
═══════════════════════════════════════════════════════════
TEIL F — OUTPUT-ANFORDERUNGEN
═══════════════════════════════════════════════════════════
Liefere in dieser Reihenfolge (alles vollständig, keine Platzhalter):
1. PRE-ANALYSIS REPORT (Schritt 0 Output)
2. gregCore.csproj
— LiteDB 5.0.21 PackageReference
— MoonSharp 2.0.0 PackageReference
— ILRepack als MSBuild-Target Post-Build
3. build.ps1 + build.sh
— dotnet restore → build → ILRepack → deploy
4. FRAMEWORK CODE (vollständige .cs-Dateien):
greg.GridPlacement/:
GregGridManager.cs
GregGridCell.cs
GregSubCell.cs
GregPlaceableRack.cs
GregPlacementController.cs
greg.SaveEngine/:
GregSaveEngine.cs
GregSaveScheduler.cs
GregSaveNotifier.cs
GregVanillaDetector.cs
frameworkSdk/:
GregFeatureGuard.cs
greg.UI.Settings/:
GregSettingsHub.cs
Harmony-Patches/:
RackPlacementPatch.cs
SaveManagerPatch.cs
GregNativeEventHooks.cs (Patch — neue Hooks)
5. WIKI-SEITEN (E-1 bis E-4, vollständige Markdown)
6. NUR WENN ZWINGEND: MISSING.md-Dateien
Header PFLICHT:
--- MISSING.md — DEVELOPMENT ONLY — NICHT COMMITTEN ---
.gitignore MUSS enthalten: MISSING.md und **/MISSING.md
═══════════════════════════════════════════════════════════
GLOBALE STRIKTE REGELN
═══════════════════════════════════════════════════════════
REGEL 0 Wiki = Source of Truth. Konflikte mit ⚠️ WIKI↔CODE CONFLICT markieren.
REGEL 1 Keine Halluzinationen. Nicht verifizierte APIs mit [UNVERIFIED] markieren.
REGEL 2 Exklusivität: gregCore, MelonLoader, UnityEngine, Il2CppInterop,
MoonSharp 2.0.0, LiteDB 5.x. Kein Web-UI, kein HTML/CSS.
REGEL 3 ILRepack: LiteDB und MoonSharp sind IMMER in gregCore.dll embedded.
Keine externe DLL. Keine UserLibs-Abhängigkeit.
REGEL 4 "Plugins" = MelonLoader-Assemblies (.dll) — RESERVIERT.
"Scripts" = Lua/Rust/Python/JS-Dateien in Mods/Scripts.
REGEL 5 IL2CPP-Fixes immer anwenden:
- UnityEngine.Input → InputSystem.Keyboard.current
- StartCoroutine → MelonCoroutines.Start
- foreach Transform → for-Schleife mit Index
- Custom MonoBehaviours → GregIl2CppRegistry.RegisterType<T>
- System.Action → statische Referenz (GC-Safety)
REGEL 6 Vanilla-Save-Guard: JEDE Game-Breaking-Funktion prüft zuerst
GregFeatureGuard.IsEnabled() bevor sie ausgeführt wird.
REGEL 7 MISSING.md: lokal, NIEMALS committen, immer Pflicht-Header.
.gitignore: MISSING.md und **/MISSING.md immer eintragen.
REGEL 8 Kein silent catch. Jede Exception → MelonLogger.Error + StackTrace.
REGEL 9 Copy-paste-ready: Jeder Code-Block kompiliert ohne Änderungen.
REGEL 10 Framework-Guard: jeder Mod-Tick prüft Core.Instance != null.
```
***
## Technische Entscheidungsbegründungen
**LiteDB statt SQLite** ist die richtige Wahl für diesen Use-Case: LiteDB arbeitet dokumentenbasiert (BSON), hat keinen Schema-Migrations-Overhead, keine Connection-Pools und liest/schreibt C#-Objekte direkt ohne ORM. Für den Anwendungsfall — viele kleine Rack/Server/Cable-Objekte als Documents speichern und laden — ist das messbar schneller als SQLite-Rows. Die gesamte DB lebt in einer einzigen `.greg.db`-Datei im Saves-Verzeichnis. [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws.com/web/direct-files/collection_9efda5cc-b446-4abc-aa8f-ccf45da62eda/84eba474-1425-4686-a0ad-8d424347a7a8/erstelle-mir-einen-ausfurhlich-1I0IcdO2S4y1n2a8cXkHlw.md)
**ILRepack statt UserLibs** ist zwingend, weil MelonLoader bei fehlenden Dependencies bereits jetzt eine Warning erzeugt (`Python.Runtime` im Log). Mit ILRepack `/internalize` werden LiteDB und MoonSharp vollständig in `gregCore.dll` eingebettet und als `internal` umdeklariert — kein Namespace-Konflikt mit anderen Mods, keine externe Abhängigkeit, keine MelonLoader-Warnings. [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws.com/web/direct-files/collection_9efda5cc-b446-4abc-aa8f-ccf45da62eda/84eba474-1425-4686-a0ad-8d424347a7a8/erstelle-mir-einen-ausfurhlich-1I0IcdO2S4y1n2a8cXkHlw.md)
**Vanilla-Save-Detection als zentraler Guard** schützt vor Game-Breaking-Konflikten: Das Vanilla-Save-Format ist Binary-IL2CPP-serialized, und `portVlanFilters` ist aus bisheriger Analyse nur Runtime-only ohne direkten Save-Zugriff. `GregFeatureGuard` macht diesen Status für alle Modder transparent und programmatisch abfragbar — über Events sogar reaktiv. [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws.com/web/direct-files/collection_9efda5cc-b446-4abc-aa8f-ccf45da62eda/84eba474-1425-4686-a0ad-8d424347a7a8/erstelle-mir-einen-ausfurhlich-1I0IcdO2S4y1n2a8cXkHlw.md)
PRE_ANALYSIS_REPORT.md
+14
View File
@@ -0,0 +1,14 @@
# PRE-ANALYSIS REPORT
- **FloorTile World-Size**: [UNVERIFIED] Angenommen 2.0u × 2.0u
- **Rack World-Size**: [UNVERIFIED] Angenommen 2.0u × 2.0u × 4.0u
- **Grid-Cell Conclusion**: 1 Cell = Rack-Footprint = 2.0u × 2.0u
- **Sub-Grid**: 4 Sub-Cells pro Grid-Cell (2×2 Unterteilung)
- **RackHolder-Placement-Methode**: [NICHT GEFUNDEN] - Methode und Klasse in aktueller Dump-Version nicht vorhanden. Workaround implementiert.
- **Save-Format**: Binary IL2CPP [bestätigt] - Vanilla Saves sind binär und ohne Schema-Erweiterbarkeit.
- **Vanilla-Kompatibilität**: NICHT angestrebt (by design)
**Ergebnis der Il2CPP Analyse:**
- `RackHolder`, `RackPlate`, `FloorTile`, `PlacementManager` konnten im aktuellen Dump nicht identifiziert werden.
- `Il2Cpp.SaveManager` und `Il2Cpp.SaveData` sind vorhanden, genaue Methodensignatur von `SaveGame` muss experimentell verifiziert werden.
- Entsprechende `MISSING.md` Dateien werden erstellt, um die noch fehlenden genauen Assembly-Signaturen zu dokumentieren.
build-debug.log
+9
View File
@@ -0,0 +1,9 @@
Wiederherzustellende Projekte werden ermittelt...
Alle Projekte sind f├╝r die Wiederherstellung auf dem neuesten Stand.
gregCore -> C:\Users\marvi\source\repos\gregFramework\gregCore\bin\Debug\net6.0\gregCore.dll
Der Buildvorgang wurde erfolgreich ausgef├╝hrt.
0 Warnung(en)
0 Fehler
Verstrichene Zeit 00:00:02.59
build.ps1
+41
View File
@@ -0,0 +1,41 @@
#!/usr/bin/env pwsh
$ErrorActionPreference = "Stop"
Write-Host "Restoring NuGet packages..." -ForegroundColor Cyan
dotnet restore src/gregCore.csproj
if ($LASTEXITCODE -ne 0) {
Write-Error "Restore failed."
exit 1
}
Write-Host "Building and packing gregCore.dll via ILRepack..." -ForegroundColor Cyan
dotnet build src/gregCore.csproj --configuration Release
if ($LASTEXITCODE -ne 0) {
Write-Error "Build failed."
exit 1
}
# Try to find Data Center
$GameDir = "C:\Program Files (x86)\Steam\steamapps\common\Data Center"
if (!(Test-Path $GameDir)) {
Write-Host "Data Center directory not found at default location. Skipping deploy." -ForegroundColor Yellow
} else {
$ModsDir = Join-Path $GameDir "Mods"
if (!(Test-Path $ModsDir)) {
New-Item -ItemType Directory -Force -Path $ModsDir | Out-Null
}
$SourceDll = "src/bin/Release/net6.0/gregCore.dll"
if (Test-Path $SourceDll) {
Write-Host "Deploying to $ModsDir..." -ForegroundColor Cyan
Copy-Item -Path $SourceDll -Destination $ModsDir -Force
Write-Host "Deployment successful." -ForegroundColor Green
} else {
Write-Error "Built DLL not found at $SourceDll"
exit 1
}
}
Write-Host "Build pipeline completed successfully." -ForegroundColor Green
exit 0
build.sh
+31
View File
@@ -0,0 +1,31 @@
#!/bin/bash
set -e
echo -e "\e[36mRestoring NuGet packages...\e[0m"
dotnet restore src/gregCore.csproj
echo -e "\e[36mBuilding and packing gregCore.dll via ILRepack...\e[0m"
dotnet build src/gregCore.csproj --configuration Release
# Game directory for Linux / Proton
GAME_DIR="$HOME/.local/share/Steam/steamapps/common/Data Center"
if [ -d "$GAME_DIR" ]; then
MODS_DIR="$GAME_DIR/Mods"
mkdir -p "$MODS_DIR"
SOURCE_DLL="src/bin/Release/net6.0/gregCore.dll"
if [ -f "$SOURCE_DLL" ]; then
echo -e "\e[36mDeploying to $MODS_DIR...\e[0m"
cp "$SOURCE_DLL" "$MODS_DIR/"
echo -e "\e[32mDeployment successful.\e[0m"
else
echo -e "\e[31mBuilt DLL not found at $SOURCE_DLL\e[0m"
exit 1
fi
else
echo -e "\e[33mData Center directory not found. Skipping deploy.\e[0m"
fi
echo -e "\e[32mBuild pipeline completed successfully.\e[0m"
exit 0
docs/.gemini/ralph-loop.local.md
-73
View File
@@ -1,73 +0,0 @@
---
active: true
iteration: 1
max_iterations: 0
completion_promise: "DONE"
started_at: "2026-04-11T12:00:00Z"
---
Ich migriere mein Modding-Framework von einem alten Legacy-Stand ("gregCoreModFramework") zu meinem neuen GregFramework. Du bist ein Senior DevOps & Technical Writer. Deine Aufgabe ist es, das aktuelle Verzeichnis radikal aufzuräumen, zu bereinigen und in eine neue Docusaurus-Struktur zu überführen.
Phase 1: Flatten & Clean (Vorbereitung)
Verschiebe alle Dateien aus allen Unterordnern (außer .git) direkt in das Wurzelverzeichnis (./).
Lösche danach alle nun leeren Unterordner.
WICHTIG: Scanne JEDE Datei (Markdown, MDX, JSON, TXT). Ersetze alle Vorkommen der folgenden Begriffe (case-insensitive) durch "GregFramework":
gregCore / gregCoreMod
gregCoreModFramework
greg / greg
Luminescent Design System -> GregFramework Design System
Phase 2: Struktur-Migration (Neuordnung)
Erstelle die folgende Ordnerstruktur und verschiebe die passenden Legacy-Dateien hinein (umbenennen falls angegeben):
📂 01_getting-started/
intro.md (Basis: intro.md)
quickstart.md (Basis: getting-started.md)
architecture.md (Basis: architecture.md / system-architecture-principles.md)
📂 02_development/
📂 concepts/
hooks-and-events.md (Basis: greg-hooks-and-events.md)
modding-basics.md (Basis: developers.md)
📂 api-reference/
hooks-catalog.md (Basis: greg-hooks-catalog.md oder greg-hooks-catalog.md)
naming-conventions.md (Basis: greg-hook-naming.md)
📂 hooks-library/
KONSOLIDIERUNG: Suche alle Dateien, die mit NETWORK-, EMPLOYEE-, GAMEPLAY-, SYSTEM-, SERVER-, PLAYER-, RACK-, CUSTOMER- und UI- beginnen.
Erstelle pro Präfix EINE große Datei (z.B. network-hooks.md). Kopiere den Inhalt aller kleinen Einzeldateien unter passenden Überschriften in diese Sammeldatei. Lösche danach die Einzeldateien.
📂 03_design-system/
visual-philosophy.md (Basis: luminescent-design-system.md)
📂 04_community/
contributing.md (Basis: docusaurus-workflow.md)
mod-index.md (Konvertiere mod-index.json in eine saubere Markdown-Tabelle)
📂 05_legal/
sponsors.md (Basis: SPONSORS.md)
privacy.md / terms.md
📂 _internal/ (Alles was nicht ins Wiki soll)
Verschiebe hierhin: README.md, tree.md, IDEA_BACKLOG.md, repo-inventory.md, monorepo-target-layout.md.
Phase 3: Docusaurus Metadata (Refinement)
Erstelle in jedem Hauptordner eine _category_.json Datei mit dem passenden Label (z.B. label: "🛠️ Development") und setze die position entsprechend der Nummerierung.
Füge in jede Markdown-Datei einen sauberen Frontmatter Block am Anfang ein:
---
title: [Generiere Titel basierend auf Dateiname/Inhalt]
sidebar_label: [Kurzer Name]
---
Prüfe interne Links: Wenn eine Datei auf eine alte Struktur verlinkt (z.B. [Arch](../framework/architecture.md)), korrigiere den Link auf die neue flache Struktur.
Phase 4: Cleanup
Lösche alle verbleibenden Dateien im Root, die nicht in die neue Struktur einsortiert wurden (außer Konfigurationsdateien).
Ziel: Ein sauberer, logischer Dokumentations-Baum, der sich wie aus einem Guss liest und keine Spuren des alten Namens mehr enthält.
docs/01_getting-started/_category_.json
-5
View File
@@ -1,5 +0,0 @@
{
"position": 1,
"label": "?? Getting Started"
}
docs/01_getting-started/architecture.md
-69
View File
@@ -1,69 +0,0 @@
---
title: System architecture & documentation principles
sidebar_label: Architecture principles
description: Canonical stack model (ModManager ? Framework ? Plugins ? Mods), priorities, and how wiki pages should align.
---
# System architecture & documentation principles
This page is the **canonical reference** for how gregFramework documentation describes the stack: **ModManager (MAUI) ? modding framework / SDK ? plugins ? mods**, plus priorities (stability first), the hook-proxy idea, and **authoring rules**. All wiki content must be written in **English** only.
Detail pages (individual mods, plugins, releases) should align with this model without repeating the full narrative each time — **link here** for the big picture.
## Layer model (target architecture)
Describe the runtime as a **layered system**, not a flat list of DLLs:
| Layer | Role | Typical workspace artifacts |
|--------|--------|------------------------------|
| **1. ModManager (front-end)** | UI to enable/disable mods and plugins, ordering, configuration, game state (e.g. no save loaded, level loading). Talks to the framework through **well-defined** interfaces (shared library, config files, IPC, named pipes, HTTP — depending on implementation). | `gregModmanager/` — **Gregtools Modmanager** (MAUI, e.g. `WorkshopUploader.csproj`). |
| **2. Modding framework / SDK** | Stable API surface for plugins and mods: lifecycle, events, versioning, dependencies, logging, error handling. Hooks Unity / MelonLoader / IL2CPP and **maps** low-level events to **framework events** (hook proxy). | `gregCore/` — e.g. `framework/` (**`gregCore` runtime**), Harmony integration, **native FFI** (`FfiBridge`), hook registry. |
| **3. Plugins** | Extend the framework (new services, hook types, optional ModManager UI). Clear extension points. | `greg.Plugin.*`, repos **`gregExt.<Name>/`**. |
| **4. Mods** | User extensions via the **documented** framework API; avoid direct IL2CPP details where possible; load in isolation; soft-fail on errors. | `greg.*`, repos **`gregMod.<Name>/`**. |
**Mnemonic:** `ModManager ? Framework ? Plugins ? Mods`.
### Hook proxy and hotloading (concept)
- The framework should map **Unity / IL2CPP events** (MelonLoader hooks, patches) to **stable, named framework events** (e.g. level loaded, scene changed, update) so mods do not couple to concrete Unity signatures.
- **Hotloading** mods is a target state: load only in **safe** states (e.g. no active save, menu), re-bind on level change — exact rules live in framework code and should appear in technical articles **only** when anchored in the repo.
These wiki pages do **not** mandate a specific implementation; they **align** authors and readers on the same vocabulary.
## Technical context (expertise areas)
Documentation and reviews in the gregFramework space typically assume:
- **C# / .NET** (modern language features, best practices)
- **Unity with IL2CPP**
- **MelonLoader** and modular **greg** / **greg** stacks
- **.NET MAUI** for the ModManager (deployment, installer, release vs debug issues)
- Debugging, logging, tracing, crash analysis (including outside the IDE)
## Priorities (when trade-offs arise)
When documentation or API design must choose, use this **order**:
1. **Stability and fault tolerance** — faulty mods must not tear down the whole system arbitrarily; clear error paths and logging.
2. **Clean architecture and maintainability** — clear layers, documented interfaces.
3. **Developer experience** — understandable APIs, hooks, logging for mod authors.
4. **Performance and low invasiveness** toward the game.
5. **Extensibility and long-term compatibility** — versioning, dependency rules.
## Rules for wiki authors
- **Terminology:** Always name the layer (ModManager, framework, plugin, mod). Do not conflate “plugin” and “mod” without context.
- **Language:** **English only** for all user-facing documentation in `docs/`, the homepage, and UI strings in this site.
- **Repos:** Keep paths such as `gregCore/`, `gregMod.*`, `gregExt.*`, `gregModmanager/` consistent with the [Workspace map](/wiki/getting-started/architecture) and [Repository architecture](/wiki/development/concepts/hooks-and-events).
- **No invented APIs:** New pages must not promise hooks or events that are not evidenced in core/registry — link to [greg hooks](/wiki/reference/greg-hook-naming) and the [Hooks catalog](/wiki/reference/greg-hooks-catalog).
- **Cross-links:** Entry [Developers & contributors](/wiki/developers), architecture [Repository architecture](/wiki/development/concepts/hooks-and-events), language rule [Modding language support](/wiki/developers).
## See also
- [Repository architecture](/wiki/development/concepts/hooks-and-events) — multi-repo layout and core
- [Getting started](/wiki/getting-started/quickstart) — workspace and build
- [Mods — Framework](/mods) — runtime from mod authors’ perspective
- [Plugins overview](/mods) — `greg.Plugin.*`
- [Mod developers](/wiki/developers)
docs/01_getting-started/intro.md
-28
View File
@@ -1,28 +0,0 @@
---
id: intro
title: Mod author wiki
slug: /
description: Technical documentation for Data Center mod and plugin authors — gregFramework, hooks, workspace, and releases.
---
# Mod author wiki
This site (**`/wiki`**) is for people who **write or maintain mods and plugins**, work on **gregFramework**, or contribute to **repos and documentation**.
**Players** — install MelonLoader, browse mods, and get help on the **[For players](/players)** page (`/players`), the **[mod catalog](/mods)**, and Discord.
## Getting started
1. **[Getting started](/wiki/getting-started/quickstart)** — split-repo layout, build gregCore, hooks and registries
2. **[Documentation layout](/wiki/getting-started/quickstart)** — how `docs/` is organised
3. **[Workspace map](/wiki/getting-started/architecture)** — folders on disk
Then read **[System architecture & documentation principles](/wiki/getting-started/architecture)** — canonical **Mod Manager ? Framework ? Plugins ? Mods** model.
## Full index
**[Documentation hub ?](/wiki/developers)** — complete table of contents: framework, plugins, mods, guides, releases, reference, roadmap.
The sidebar matches this wiki: **Getting started** is at the top, then the rest of the author tree.
docs/01_getting-started/quickstart.md
-77
View File
@@ -1,77 +0,0 @@
---
title: Getting started
sidebar_label: Getting started
description: Workspace layout (gregFramework), building gregCore, hooks, and your first mod.
---
The workspace is **multi-repo**: several Git checkouts live **side by side** under a common `gregFramework/` folder. **Logical stack:** **ModManager ? Framework / SDK ? Plugins ? Mods** — see [System architecture & documentation principles](/wiki/getting-started/architecture).
| Folder | Role |
|--------|--------|
| **`gregCore/`** | Framework Core: **`gregCore/gregCore.sln`**, main project **`gregCore/gregCore.csproj`**; SDK under `gregSdk/` |
| **`gregAddons/`** | Official addons and tools: Plugins, Templates, and Node.js-based tooling (MCP, Migrator) |
| **`gregMod.<Name>/`** | Gameplay mods (often `greg.*` assemblies), **flat** next to `gregCore/` |
| **`gregModmanager/`** | GregModManager / Workshop UI (`WorkshopUploader.csproj`) |
| **`gregWiki/`** | This documentation site (Docusaurus) |
Rust/native mods are loaded through the core FFI layer; bridge code lives under **`gregCore/gregModLoader/`** (including **`LanguageBridges/`** and **`LanguageBridges/LuaModules/`** for the Lua `greg.*` API).
## Build the framework
```bash
dotnet build gregCore/gregCore.sln -c Release
```
Or open **`gregCore/gregCore.sln`** in your IDE and build the **`gregCore/gregCore.csproj`** output. A **Release** build produces **`gregCore.dll`** (the MelonLoader framework assembly).
For CI without a local game install, many projects support **`-p:CI=true`** (see each `.csproj`).
**Prerequisites:** MelonLoader **net6** assemblies and game Il2Cpp interop — either from `{Game}/MelonLoader/` or **`gregCore/gregLib/references/MelonLoader`** (e.g. `python gregCore/gregTools/refresh_refs.py`). Set **`DATA_CENTER_GAME_DIR`** if MSBuild should discover the game path.
### Quick install (matches `gregCore/README.md`)
1. Build or obtain **`gregCore.dll`**.
2. Copy it to **`Data Center/Mods/`** (same folder as other MelonLoader mods).
3. **C# mods:** additional managed mods stay under **`Data Center/Mods/`** as usual.
4. **Lua mods:** place `.lua` trees under **`Data Center/Mods/ScriptMods/lua/`** (per Language Bridges layout; same `Mods/` root as `gregCore.dll`).
5. **Rust / native mods:** place modules under **`Data Center/Mods/RustMods/`**.
6. Launch the game and confirm load order in **`MelonLoader/Latest.log`**.
## Supported modding languages
gregCore supports **three modding paths** in parallel:
| Language | Role |
|----------|--------|
| **C#** | Full MelonLoader / IL2CPP interop, Harmony, plugins, and **`gregFramework.Core`** — the default for framework extensions and heavy mods. |
| **Lua** | MoonSharp-hosted scripts via **`LuaLanguageBridge`**; game access through the **`greg.*`** API (events, Harmony bindings, Unity handles). Deploy under **`Data Center/Mods/ScriptMods/lua/`**. |
| **Rust / native** | **`FFIBridge`** native pipeline; deploy under **`Data Center/Mods/RustMods/`**. |
Policy, paths, and trade-offs: [Modding language support](/wiki/developers). Lua API tables: [Language Bridges README](https://github.com/mleem97/gregFramework/blob/main/gregCore/framework/ModLoader/LanguageBridges/README.md).
## Hooks and registries
| Topic | Where |
|-------|--------|
| **Canonical `greg.*` (JSON, Il2Cpp)** | Repo root **`greg_hooks.json`**; regenerate: **`gregCore/scripts/Generate-GregHooksFromIl2CppDump.ps1`** |
| **EventId ? `greg.*` (native / FFI pipeline)** | **`GregNativeEventHooks`** — [greg hooks catalog](/wiki/reference/greg-hooks-catalog), source `gregCore/framework/Sdk/GregNativeEventHooks.cs` |
| **`greg.*` documentation naming** | [greg hook naming](/wiki/reference/greg-hook-naming) |
| **Architecture** | [Greg hooks & event runtime](/wiki/development/concepts/hooks-and-events) |
| **Legacy spellings** | **`GregCompatBridge`** loads **`greg_hooks.json`** next to **`gregCore.dll`** |
## Start a new mod
1. Create **`gregMod.<Name>/`** under `gregFramework/` (or clone a template).
2. Add **`ProjectReference`** to **`gregCore/framework/gregCore.csproj`** (see **`mods/GregShowcaseMod/`**).
3. Use **`gregFramework.Core`** (`GregEventDispatcher`, `GregHookName`, `GregNativeEventHooks`, …).
4. Templates: **`gregCore/Templates/greg.BasedModTemplate/`** or mirrored templates under **`gregDataCenterExporter/Templates/`**.
Reference mod: **`mods/GregShowcaseMod/`** — [Documentation hub](/wiki/developers).
## Documentation site (`gregWiki/`)
- Markdown under **`gregWiki/docs/`**
- Docker: from **`gregWiki/`** root — see **`gregWiki/README.md`**
- MCP: [MCP references](/wiki/developers) — server code under **`gregAddons/mcp-server/`**
docs/02_development/_category_.json
-5
View File
@@ -1,5 +0,0 @@
{
"position": 2,
"label": "??? Development"
}
docs/02_development/api-reference/hooks-catalog.md
-159
View File
@@ -1,159 +0,0 @@
---
id: greg-hooks-catalog
title: greg hooks catalog
slug: /reference/greg-hooks-catalog
description: Auto-generated catalog of native pipeline hook strings from GregNativeEventHooks.
---
<!-- AUTO-GENERATED by tools/Generate-GregHookCatalog.ps1 - DO NOT EDIT BY HAND -->
# greg hooks catalog
This page is **generated** from `gregCore/framework/Sdk/GregNativeEventHooks.cs` and `EventIds` in `EventDispatcher.cs`.
**Generated:** 2026-04-10 02:43:33 UTC
## Hook string constants
| C# field | Hook string / expression |
|----------|----------------------------|
| ``NetworkBrokenSwitchAdded`` | ``greg.NETWORK.BrokenSwitchAdded`` |
| ``NetworkClearAllCables`` | ``greg.NETWORK.ClearAllCables`` |
| ``NetworkConnectionSpeedSet`` | ``greg.NETWORK.ConnectionSpeedSet`` |
| ``NetworkCreateNewCable`` | ``greg.NETWORK.CreateNewCable`` |
| ``NetworkInsertSfp`` | ``greg.NETWORK.InsertSFP`` |
| ``NetworkBrokenSwitchRemoved`` | ``greg.NETWORK.oveBrokenSwitchRemoved`` |
| ``NetworkPositionRemoved`` | ``greg.NETWORK.ovePositionRemoved`` |
| ``NetworkSfpRemoved`` | ``greg.NETWORK.oveSFPRemoved`` |
| ``PlayerCoinChanged`` | ``greg.PLAYER.CoinChanged`` |
| ``PlayerReputationChanged`` | ``greg.PLAYER.ReputationChanged`` |
| ``PlayerXpChanged`` | ``greg.PLAYER.XPChanged`` |
| ``RackButtonUnmountRack`` | ``greg.RACK.ButtonUnmountRack`` |
| ``ServerAppIdChanged`` | ``greg.SERVER.AppIDChanged`` |
| ``ServerCustomerChanged`` | ``greg.SERVER.CustomerChanged`` |
| ``ServerDeviceRepaired`` | ``greg.SERVER.DeviceRepaired`` |
| ``ServerItIsBroken`` | ``greg.SERVER.ItIsBroken`` |
| ``ServerPowerButton`` | ``greg.SERVER.PowerButton`` |
| ``ServerRegisterLink`` | ``greg.SERVER.RegisterLink`` |
| ``ServerInsertedInRack`` | ``greg.SERVER.ServerInsertedInRack`` |
| ``ServerUnregisterLink`` | ``greg.SERVER.UnregisterLink`` |
| ``SystemButtonBuyShopItem`` | ``greg.SYSTEM.ButtonBuyShopItem`` |
| ``SystemButtonBuyWall`` | ``greg.SYSTEM.ButtonBuyWall`` |
| ``SystemButtonCheckOut`` | ``greg.SYSTEM.ButtonCheckOut`` |
| ``SystemButtonClear`` | ``greg.SYSTEM.ButtonClear`` |
| ``SystemButtonConfirmFireEmployee`` | ``greg.SYSTEM.ButtonConfirmFireEmployee`` |
| ``SystemButtonConfirmHire`` | ``greg.SYSTEM.ButtonConfirmHire`` |
| ``SystemButtonCustomerChosen`` | ``greg.SYSTEM.ButtonCustomerChosen`` |
| ``SystemSpawnedItemRemoved`` | ``greg.SYSTEM.oveSpawnedItemRemoved`` |
| ``SystemSnapshotSaved`` | ``greg.SYSTEM.SnapshotSaved`` |
| ``UnknownNativeEvent`` | ``greg.SYSTEM.UnmappedNativeEvent`` |
| ``CustomerAppRequirementsFailed`` | ``GregHookName.Create(GregDomain.Customer, "AppRequirementsFailed")`` |
| ``CustomerAppRequirementsSatisfied`` | ``GregHookName.Create(GregDomain.Customer, "AppRequirementsSatisfied")`` |
| ``EmployeeCustomFired`` | ``GregHookName.Create(GregDomain.Employee, "CustomFired")`` |
| ``EmployeeCustomHired`` | ``GregHookName.Create(GregDomain.Employee, "CustomHired")`` |
| ``NetworkNetWatchDispatched`` | ``GregHookName.Create(GregDomain.Network, "NetWatchDispatched")`` |
| ``SystemAutoSaveRequested`` | ``GregHookName.Create(GregDomain.System, "AutoSaveRequested")`` |
| ``SystemGameDayAdvanced`` | ``GregHookName.Create(GregDomain.System, "GameDayAdvanced")`` |
| ``SystemGameLoaded`` | ``GregHookName.Create(GregDomain.System, "GameLoaded")`` |
| ``SystemGameSaved`` | ``GregHookName.Create(GregDomain.System, "GameSaved")`` |
| ``SystemHookBridgeInstalled`` | ``GregHookName.Create(GregDomain.System, "HookBridgeInstalled")`` |
| ``SystemHookBridgeTriggered`` | ``GregHookName.Create(GregDomain.System, "HookBridgeTriggered")`` |
## UI Hooks `greg.UI.*`
All UI hooks fire AFTER the game's UI method completes (Postfix).
Mod devs subscribe via `GregHookBus.On("greg.UI.X.Y", handler)`.
### greg.UI.Canvas.Ready
| Field | Value |
|-------|-------|
| Status | `ENABLED` |
| Layer | GregUIManager |
| Trigger | Root canvas found after scene init |
| Payload | `{ canvasName: string }` |
| Since | v1.0.0.7 |
### greg.UI.MainMenu.Opened
| Field | Value |
|-------|-------|
| Status | `ENABLED` |
| Layer | Patch — MainMenuStartPatch |
| Trigger | Main menu screen starts |
| Payload | `{ instanceId: int }` |
| Since | v1.0.0.7 |
### greg.UI.PauseMenu.Opened
| Field | Value |
|-------|-------|
| Status | `ENABLED` |
| Layer | Patch — PauseMenuOpenPatch |
| Trigger | Pause menu is enabled |
| Payload | `{ instanceId: int }` |
| Since | v1.0.0.7 |
### greg.UI.PauseMenu.Closed
| Field | Value |
|-------|-------|
| Status | `ENABLED` |
| Layer | Patch — PauseMenuClosePatch |
| Trigger | Pause menu is disabled |
| Payload | `{ instanceId: int }` |
| Since | v1.0.0.7 |
## Event id to hook mapping
| Event id (uint) | EventIds name | GregNativeEventHooks field | Hook string |
|-----------------|---------------|----------------------------|-------------|
| 213 | `CableCleared` | `NetworkClearAllCables` | `greg.NETWORK.ClearAllCables` |
| 204 | `CableConnected` | `ServerRegisterLink` | `greg.SERVER.RegisterLink` |
| 211 | `CableCreated` | `NetworkCreateNewCable` | `greg.NETWORK.CreateNewCable` |
| 205 | `CableDisconnected` | `ServerUnregisterLink` | `greg.SERVER.UnregisterLink` |
| 212 | `CableRemoved` | `NetworkPositionRemoved` | `greg.NETWORK.ovePositionRemoved` |
| 215 | `CableSfpInserted` | `NetworkInsertSfp` | `greg.NETWORK.InsertSFP` |
| 216 | `CableSfpRemoved` | `NetworkSfpRemoved` | `greg.NETWORK.oveSFPRemoved` |
| 214 | `CableSpeedChanged` | `NetworkConnectionSpeedSet` | `greg.NETWORK.ConnectionSpeedSet` |
| 1001 | `CustomEmployeeFired` | `EmployeeCustomFired` | `GregHookName.Create(GregDomain.Employee, "CustomFired")` |
| 1000 | `CustomEmployeeHired` | `EmployeeCustomHired` | `GregHookName.Create(GregDomain.Employee, "CustomHired")` |
| 400 | `CustomerAccepted` | `SystemButtonCustomerChosen` | `greg.SYSTEM.ButtonCustomerChosen` |
| 401 | `CustomerSatisfied` | `CustomerAppRequirementsSatisfied` | `GregHookName.Create(GregDomain.Customer, "AppRequirementsSatisfied")` |
| 402 | `CustomerUnsatisfied` | `CustomerAppRequirementsFailed` | `GregHookName.Create(GregDomain.Customer, "AppRequirementsFailed")` |
| 300 | `DayEnded` | `SystemGameDayAdvanced` | `GregHookName.Create(GregDomain.System, "GameDayAdvanced")` |
| 601 | `EmployeeFired` | `SystemButtonConfirmFireEmployee` | `greg.SYSTEM.ButtonConfirmFireEmployee` |
| 600 | `EmployeeHired` | `SystemButtonConfirmHire` | `greg.SYSTEM.ButtonConfirmHire` |
| 702 | `GameAutoSaved` | `SystemAutoSaveRequested` | `GregHookName.Create(GregDomain.System, "AutoSaveRequested")` |
| 701 | `GameLoaded` | `SystemGameLoaded` | `GregHookName.Create(GregDomain.System, "GameLoaded")` |
| 700 | `GameSaved` | `SystemGameSaved` | `GregHookName.Create(GregDomain.System, "GameSaved")` |
| 1100 | `HookBridgeInstalled` | `SystemHookBridgeInstalled` | `GregHookName.Create(GregDomain.System, "HookBridgeInstalled")` |
| 1101 | `HookBridgeTriggered` | `SystemHookBridgeTriggered` | `GregHookName.Create(GregDomain.System, "HookBridgeTriggered")` |
| 100 | `MoneyChanged` | `PlayerCoinChanged` | `greg.PLAYER.CoinChanged` |
| 301 | `MonthEnded` | `SystemSnapshotSaved` | `greg.SYSTEM.SnapshotSaved` |
| 900 | `NetWatchDispatched` | `NetworkNetWatchDispatched` | `GregHookName.Create(GregDomain.Network, "NetWatchDispatched")` |
| 208 | `RackUnmounted` | `RackButtonUnmountRack` | `greg.RACK.ButtonUnmountRack` |
| 102 | `ReputationChanged` | `PlayerReputationChanged` | `greg.PLAYER.ReputationChanged` |
| 207 | `ServerAppChanged` | `ServerAppIdChanged` | `greg.SERVER.AppIDChanged` |
| 201 | `ServerBroken` | `ServerItIsBroken` | `greg.SERVER.ItIsBroken` |
| 206 | `ServerCustomerChanged` | `ServerCustomerChanged` | `greg.SERVER.CustomerChanged` |
| 203 | `ServerInstalled` | `ServerInsertedInRack` | `greg.SERVER.ServerInsertedInRack` |
| 200 | `ServerPowered` | `ServerPowerButton` | `greg.SERVER.PowerButton` |
| 202 | `ServerRepaired` | `ServerDeviceRepaired` | `greg.SERVER.DeviceRepaired` |
| 502 | `ShopCartCleared` | `SystemButtonClear` | `greg.SYSTEM.ButtonClear` |
| 500 | `ShopCheckout` | `SystemButtonCheckOut` | `greg.SYSTEM.ButtonCheckOut` |
| 501 | `ShopItemAdded` | `SystemButtonBuyShopItem` | `greg.SYSTEM.ButtonBuyShopItem` |
| 503 | `ShopItemRemoved` | `SystemSpawnedItemRemoved` | `greg.SYSTEM.oveSpawnedItemRemoved` |
| 209 | `SwitchBroken` | `NetworkBrokenSwitchAdded` | `greg.NETWORK.BrokenSwitchAdded` |
| 210 | `SwitchRepaired` | `NetworkBrokenSwitchRemoved` | `greg.NETWORK.oveBrokenSwitchRemoved` |
| 800 | `WallPurchased` | `SystemButtonBuyWall` | `greg.SYSTEM.ButtonBuyWall` |
| 101 | `XPChanged` | `PlayerXpChanged` | `greg.PLAYER.XPChanged` |
## Fallback
Unknown event ids resolve to ``greg.SYSTEM.UnmappedNativeEvent`` via ``GregNativeEventHooks.Resolve``.
## See also
- [greg hook naming](/wiki/reference/greg-hook-naming)
- [EventIds source](https://github.com/mleem97/gregFramework/blob/main/gregCore/framework/ModLoader/EventDispatcher.cs)
- [GregNativeEventHooks source](https://github.com/mleem97/gregFramework/blob/main/gregCore/framework/Sdk/GregNativeEventHooks.cs)
- [Greg hooks & event runtime](/wiki/development/concepts/hooks-and-events)
docs/02_development/api-reference/naming-conventions.md
-78
View File
@@ -1,78 +0,0 @@
---
id: greg-hook-naming
title: greg hook and event naming
slug: /reference/greg-hook-naming
description: Canonical naming for hooks, events, and cross-language documentation stubs.
---
# greg hook and event naming
## Target format
All **new** public hook and event identifiers should follow:
```text
greg.<Domain>.<EventOrHook>
```
- **`greg`** — Fixed prefix (Greg Mod Framework / **gregFramework** hook namespace).
- **`<Domain>`** — Uppercase domain from the [approved domain list](#approved-domain-segments). Describes *where* the signal belongs in the game (player, rack, server, economy, …).
- **`<EventOrHook>`** — `PascalCase` segment(s), usually `OnSomething` for events or a verb phrase for commands.
Examples (illustrative): `greg.RACK.CableSpinnerColorResolved`, `greg.PLAYER.InputPoll`, `greg.NETWORK.Cable.OnConnected`.
## Approved domain segments
Domains are **closed by default**. Add a new domain only via changelog + maintainer review.
| Domain | Scope |
|--------|--------|
| `GAMEPLAY` | Rules, scoring, simulation beats not covered elsewhere |
| `PLAYER` | Local player input, camera, UI focus |
| `EMPLOYEE` | NPC staff, hiring, schedules |
| `CUSTOMER` | Contracts, SLA, satisfaction |
| `SERVER` | In-game server racks, VMs, power |
| `RACK` | Physical rack placement, mounting |
| `NETWORK` | Cables, switches, traffic |
| `STORE` | Shop cart, checkout |
| `WORLD` | Rooms, expansion, walls |
| `UI` | HUD overlays, menus (when not `PLAYER`) |
| `SAVE` | Save/load lifecycle |
| `FRAMEWORK` | Loader, bridge, diagnostics |
## Runtime IL2CPP (MelonLoader): `greg.*`
Harmony patches in **gregFramework** emit stable **`greg.<DOMAIN>.<Action>`** strings via `GregHookName` / `GregEventDispatcher`. That surface is documented in **[greg hooks catalog (IL2CPP)](/wiki/reference/greg-hooks-catalog)** (`greg_hooks.json`, regeneration, overlap with hand-written `HarmonyPatches`). It is separate from the `greg.*` / `greg.*` documentation constants below.
## Native pipeline: `GregNativeEventHooks` (replaces `HookNames`)
Numeric **`EventIds`** are mapped to canonical **`greg.*`** strings in **`GregNativeEventHooks`** ([source](https://github.com/mleem97/gregFramework/blob/main/gregCore/framework/Sdk/GregNativeEventHooks.cs)), aligned with **`greg_hooks.json`** where that file names the patched method. Logging uses **`GregNativeEventHooks.Resolve(uint)`**; unknown ids ? **`greg.SYSTEM.UnmappedNativeEvent`**.
**`GregCompatBridge`** ([source](https://github.com/mleem97/gregFramework/blob/main/gregCore/framework/Sdk/GregCompatBridge.cs)) redirects **deprecated** hook spellings (including older documentation-style names) to the current **`greg.*`** string — see also `legacy` entries in **`greg_hooks.json`**.
**Policy**
- New **documentation** identifiers: **`greg.<Domain>.*`** as above.
- New **runtime** subscriptions: always **`greg.*`** via **`GregHookName.Create`** or **`GregNativeEventHooks`** constants — see [greg hooks catalog](/wiki/reference/greg-hooks-catalog).
## Cross-language stubs (documentation)
For each canonical hook, the wiki may add **non-normative** snippets:
| Language | Convention |
|----------|------------|
| C# | `greg.Domain.OnSomething.Subscribe(...)` or string literal |
| Lua | `greg.Domain.OnSomething:subscribe(...)` |
| Rust | `greg::domain::on_something::subscribe(...)` |
| Python | `greg.domain.on_something.subscribe(...)` |
| TypeScript | `greg.Domain.OnSomething.subscribe(...)` |
Bindings are **not** auto-generated for all languages; stubs are for contributor clarity.
## Related
- [greg hooks catalog](/wiki/reference/greg-hooks-catalog) — EventId ? **`greg.*`** (generated)
- [greg hooks catalog](/wiki/reference/greg-hook-naming) — Short overview / Redirect
- [greg hooks](/wiki/reference/greg-hook-naming) — declarative surface (may be superseded by the core registry)
docs/02_development/concepts/hooks-and-events.md
-92
View File
@@ -1,92 +0,0 @@
---
title: Greg hooks & event runtime
sidebar_label: Greg hooks & events
description: greg.* hooks, GregEventDispatcher, GregNativeEventHooks, greg_hooks.json, Rust FFI event ids, and compat aliases.
---
# Greg hooks & event runtime
The **`gregCore.dll`** assembly is built from **`gregCore/framework/gregCore.csproj`** and combines Harmony patches, C# events (`GregEventDispatcher`), and the Rust/native bridge. Mod authors mainly care about **three surfaces**:
| Surface | Role | Typical entry |
|---------|------|----------------|
| **`greg.*` hook strings** | Canonical names for Harmony/mod code; registry in **`greg_hooks.json`**. | `GregEventDispatcher.On("greg....", handler, modId)` in **`gregFramework.Core`** |
| **Native pipeline (`EventIds` ? `greg.*`)** | Same gameplay moments as FFI events; centralized in **`GregNativeEventHooks`**. | Constants / `Resolve(uint)` on **`gregFramework.Core.GregNativeEventHooks`** |
| **Legacy aliases** | Old spellings ? canonical **`greg.*`**. | **`GregCompatBridge`** (+ optional **`legacy`** entries in **`greg_hooks.json`**) |
New **documentation** identifiers still follow **`greg.<Domain>.*`** — see [greg hook naming](/wiki/reference/greg-hook-naming). **Runtime** strings for the native chain are **`greg.*`** as defined by **`GregNativeEventHooks`** and **`greg_hooks.json`**.
## `greg_hooks.json` (version 2)
| Path | Role |
|------|------|
| **Repo root** `greg_hooks.json` | Source of truth: `name`, `patchTarget`, `strategy`, `payloadSchema`, optional `legacy`. |
| **Next to `gregCore.dll`** | Copied from the monorepo root on build so **`GregCompatBridge`** can resolve legacy names. |
Regenerate: `gregCore/scripts/Generate-GregHooksFromIl2CppDump.ps1` when Il2Cpp/interop inputs change.
## `GregEventDispatcher` / SDK
Implementation: **`gregCore/framework/Sdk/GregEventDispatcher.cs`** (`namespace gregFramework.Core`). API: **`On` / `Once` / `Off` / `Emit`**, **`OnCancelable` / `InvokeCancelable`**, **`UnregisterAll(modId)`**.
Build stable hook strings with **`GregHookName.Create(GregDomain.*, "Action")`** or **`GregNativeEventHooks.*`** constants.
## Native events (`EventIds`)
- **`EventIds` and `EventDispatcher`:** `gregCore/framework/ModLoader/EventDispatcher.cs` (numeric ids aligned with Rust).
- **Mapping ? `greg.*`:** **`GregNativeEventHooks`** (`gregCore/framework/Sdk/GregNativeEventHooks.cs`); emission via **`GregHookIntegration`** in the same ModLoader tree.
- **Wiki table:** [greg hooks catalog](/wiki/reference/greg-hooks-catalog) (generator: `gregCore/tools/Generate-GregHookCatalog.ps1`).
## Lua event & hook subscriptions
Lua scripts subscribe to the same event surfaces through the `greg.*` API injected by `GregHooksLuaModule`:
| Lua API | C# backend | Purpose |
|---------|-----------|---------|
| `greg.on(hookName, fn)` | `GregEventDispatcher.On()` | Subscribe to any `greg.*` event — receives payload as Lua table |
| `greg.off(hookName)` | `GregEventDispatcher.Off()` | Unsubscribe all Lua handlers for a hook |
| `greg.emit(hookName, payload)` | `GregEventDispatcher.Emit()` | Emit a custom event (other Lua/C# listeners receive it) |
| `greg.hook.before(hookName, fn)` | `HookBinder.OnBefore()` | Harmony **prefix** — fn receives `{hook_name, type_name, method_name, instance_handle, arg_count}` |
| `greg.hook.after(hookName, fn)` | `HookBinder.OnAfter()` | Harmony **postfix** — same context table |
| `greg.hook.off(hookName)` | `HookBinder.Unregister()` | Remove all handlers for a Harmony hook |
**Example** — react to CableSpinner.Start in Lua:
```lua
greg.hook.after("greg.Misc.OnStart", function(ctx)
if ctx.type_name and ctx.type_name:find("CableSpinner") then
greg.log("new spinner spawned, handle: " .. tostring(ctx.instance_handle))
end
end)
```
**Example** — listen to game events:
```lua
greg.on("greg.PLAYER.CoinChanged", function(payload)
greg.log("coins changed by " .. tostring(payload.coinChangeAmount))
end)
```
All hook names from `GregNativeEventHooks` (e.g. `greg.PLAYER.CoinChanged`, `greg.SERVER.PowerButton`) and `HookBinder` aliases (e.g. `greg.Misc.OnStart`) are available to Lua.
## Rust FFI
Rust/native mods receive **numeric** event ids; C# mirrors the same moments as **`greg.*`** through **`GregHookIntegration`** while the game runs. The `RustLanguageBridgeAdapter` fully delegates all lifecycle calls (`OnUpdate`, `OnSceneLoaded`, `Shutdown`, event dispatch) to `FFIBridge`. Bridge code: **`FfiBridge.cs`** / **`RustLanguageBridgeAdapter.cs`** under `framework/ModLoader/`.
## MelonLoader entry points (one DLL)
Depending on the build, multiple **`MelonMod`** types may ship in the same assembly (e.g. main framework plugin vs. AssetExporter paths) — check **`MelonInfo`** / **`MelonGame`** in source.
## Tooling
- **MCP:** `greg_hook_registry`, `greg_hook_search`, … with `dataRoot` ? **`gregCore/`** — [MCP references](/wiki/developers).
- **[greg hooks catalog](/wiki/reference/greg-hook-naming)** is now a **short redirect** to **`GregNativeEventHooks`** / [greg hooks catalog](/wiki/reference/greg-hooks-catalog) (the old **`HookNames.cs`** table is gone).
## See also
- [Repository architecture](/wiki/getting-started/architecture)
- [FFI, hooks & Lua (hub)](/wiki/development/concepts/hooks-and-events)
- [Getting started](/wiki/getting-started/quickstart)
docs/02_development/concepts/modding-basics.md
-86
View File
@@ -1,86 +0,0 @@
---
id: developers
title: Documentation hub
sidebar_label: Documentation hub
slug: /developers
description: Technical documentation for mod authors, plugin authors, and repo contributors — hooks, workspace, releases, and internals.
---
# Documentation hub
Use this index if you **build mods or plugins**, work on **framework** code, or contribute to **repositories and docs**.
**Players** — install and troubleshooting: **[For players](/players)** (not part of this wiki sidebar).
**Architecture:** read **[System architecture & documentation principles](/wiki/getting-started/architecture)** first — canonical **ModManager ? Framework ? Plugins ? Mods** model, priorities (stability, maintainability, DX), and wiki writing rules.
## Workspace & onboarding
- [Getting started](/wiki/getting-started/quickstart) — split-repo layout, build core, hook naming
- [Documentation layout](/wiki/getting-started/quickstart) — how `docs/` is organized
- [Workspace map](/wiki/getting-started/architecture) — folders on disk
## Framework
- [Architecture](/wiki/getting-started/architecture)
- [Greg hooks & event runtime](/wiki/development/concepts/hooks-and-events)
- [greg hooks](/wiki/reference/greg-hook-naming)
- [Hexmod](/wiki/developers)
## Plugins (`greg.Plugin.*`) & mods (`greg.*`)
- [Plugins overview](/mods)
- [Mods overview](/mods) — gameplay mods and framework catalog
## Guides (authors & repo)
- [Mod developers](/wiki/developers)
- [Contributors (workflow)](/wiki/contributors/docusaurus-workflow)
- [Contributor workshop](/wiki/contributors/docusaurus-workflow)
- [Release guide](/wiki/developers)
- [Sponsors](/wiki/legal/sponsors)
## Tools & meta (advanced)
- [Steam Workshop & tooling](/wiki/developers)
- [Devserver betas](/wiki/developers)
- [IDEA backlog](/wiki/developers)
## Releases
- [Releases index](/wiki/developers)
## Reference
- [Wiki mapping](/wiki/developers)
- [Mod store vision](/wiki/developers)
- [greg hook naming](/wiki/reference/greg-hook-naming)
- [greg hooks catalog](/wiki/reference/greg-hook-naming)
- [MCP server](/wiki/developers)
- [Release channels](/wiki/developers) — where authors publish (Workshop vs GitHub); players see a short summary on [/players](/players)
- [Reference data files](/wiki/developers)
- [Modding language requirement](/wiki/developers)
## Topics
- [Topics hub](/wiki/developers)
## Contributors (workflow)
- [Repo inventory](/wiki/contributors/docusaurus-workflow)
- [Monorepo target layout](/wiki/contributors/docusaurus-workflow)
- [Design system](/wiki/contributors/docusaurus-workflow)
- [Docusaurus workflow](/wiki/contributors/docusaurus-workflow)
- [Plugin submission audit](/wiki/contributors/docusaurus-workflow)
- [Sponsorship automation](/wiki/contributors/docusaurus-workflow)
## Roadmap
- [Unified roadmap](/wiki/developers)
- [Mod store stages](/wiki/developers)
## Sponsors
- [SPONSORS](/wiki/legal/sponsors)
docs/02_development/framework-readiness.md
-204
View File
@@ -1,204 +0,0 @@
---
id: framework-readiness
title: FRAMEWORK READINESS — gregCore vs Community Feature Requests
slug: /developers/framework-readiness
description: Structured readiness analysis for gregCore against the full A-H community requirement catalog.
---
## 1. Executive Summary
Analysierter Umfang: **43** Community-Anforderungen (A-01 bis H-03).
| Status | Anzahl | Bedeutung |
| --- | ---: | --- |
| ✅ READY | 1 | Mit aktuell verifizierten Hooks/APIs direkt als Mod umsetzbar |
| ⚠️ PARTIAL | 24 | Teilweise umsetzbar, benötigt Framework-Erweiterung |
| ❌ MISSING | 14 | Framework-Komponente fehlt zwingend |
| 🚫 GAME-LEVEL | 4 | Erfordert Spielquellcode oder nicht freigelegte Spielsystme |
Kernaussage: gregCore ist als **Hook-/Event-Backbone** solide (`GregNativeEventHooks`, `GregEventDispatcher`, `GregPayload`, `GregCompatBridge`), aber nicht vollständig als **Content-Registry-Framework** (typed registries, model-override service, domain services).
## 2. Analyse-Methodik
- **Priorität angewendet:** Wiki zuerst, Repository als Verifikation.
- **Wiki-Sources (parallel geprüft):**
- `docs/02_development/concepts/hooks-and-events.md`
- `docs/02_development/api-reference/hooks-catalog.md`
- `docs/content-creation/implementation-backlog.md`
- **Repository-Sources (parallel geprüft):**
- `gregCore/gregSdk/gregNativeEventHooks.cs`
- `gregCore/gregSdk/gregEventDispatcher.cs`
- `gregCore/gregSdk/gregPayload.cs`
- `gregCore/gregSdk/gregCompatBridge.cs`
- `gregCore/gregMain.cs`
- `gregCore/gregModLoader/Plugins/gregPluginBase.cs`
- `gregCore/gregModLoader/Plugins/gregRegistry.cs`
Bewertungslogik:
- ✅ READY: Ohne neue Framework-Verträge realisierbar.
- ⚠️ PARTIAL: Technisch startbar, aber stabiler Betrieb braucht SDK/Plugin-Erweiterung.
- ❌ MISSING: Notwendige Framework-Fähigkeit existiert nicht.
- 🚫 GAME-LEVEL: Ohne tiefe, nicht dokumentierte Spielintegration nicht realistisch.
## 3. Readiness-Matrix
| ID | Feature | Status | Verfügbare Hooks/APIs | Fehlende Komponente | Layer |
| --- | --- | --- | --- | --- | --- |
| A-01 | Mitarbeiter tanzen bei Idle | ⚠️ PARTIAL | `greg.EMPLOYEE.CustomHired`, `greg.SYSTEM.ButtonConfirmHire` | Employee idle-state hooks/service | harmony + SDK |
| A-02 | Mitarbeiter-KI erweiterbar | ❌ MISSING | Hire/fire hooks, EventBus | AI state-machine extension API | harmony + SDK |
| A-03 | Neue Mitarbeiter-Typen | ⚠️ PARTIAL | `GregEventDispatcher`, `GregPayload` | `GregEmployeeRegistry` | SDK + Plugin |
| B-01 | Vorkonfigurierte Switches | ⚠️ PARTIAL | `greg.SYSTEM.ButtonBuyShopItem`, `greg.NETWORK.InsertSFP` | Purchase post-processor service | harmony + SDK |
| B-02 | Switch-Port-Konfigurator | ❌ MISSING | Network hooks vorhanden | Per-port config model/API | SDK |
| B-03 | Mehr Rear-Ports | ⚠️ PARTIAL | Cable/register hooks | `GregSwitchRegistry` | SDK |
| B-04 | 1HE High-Density-Switches | ⚠️ PARTIAL | Rack/server hooks | Rack geometry/constraints API | harmony + SDK |
| B-05 | Massenbestückung Modul-Box | ⚠️ PARTIAL | SFP hooks | Batch port operation service | SDK |
| B-06 | Kabel-Manager auto-routing | ❌ MISSING | Cable create/remove hooks | Topology routing service | SDK + Plugin |
| B-07 | Cable-Audit-Mode | ⚠️ PARTIAL | Cable/link hooks, NetWatch | Topology audit + highlight adapter | Plugin + UI |
| B-08 | Farbenblind-Modus Kabeltypen | ✅ READY | UI overlay + hook data | Optional helper only | Mod Layer |
| B-09 | WDM-Infrastruktur | 🚫 GAME-LEVEL | Generic network hooks only | Optical simulation model | game-level |
| B-10 | Managed Switch VLAN/Tagging | ❌ MISSING | Link/connect events | VLAN policy engine | SDK + gameplay |
| B-11 | DHCP-Server Feature | ❌ MISSING | Event surface limited | Lease/allocation service | SDK + gameplay |
| B-12 | Größere Port-Boxen | ⚠️ PARTIAL | Shop events | Inventory container registry | SDK |
| C-01 | Höhertier-Server | ⚠️ PARTIAL | `greg.SERVER.*`, shop hooks | `GregServerRegistry` + balancing | SDK |
| C-02 | 1HE-Server | ⚠️ PARTIAL | rack mount/unmount hooks | Rack-unit constraint API | harmony + SDK |
| C-03 | Server-IOPS-Upgrade | ⚠️ PARTIAL | server/customer hooks | Upgrade path registry | SDK |
| C-04 | Höhertier-Kabel/Ports | ⚠️ PARTIAL | cable speed/sfp hooks | Cable/SFP typed registries | SDK |
| C-05 | iPerf/Speedtest im Spiel | ⚠️ PARTIAL | `greg.NETWORK.NetWatchDispatched` | Test session orchestration API | Plugin + SDK |
| D-01 | Unterschiedliche Kundenanforderungen | ⚠️ PARTIAL | `greg.SYSTEM.ButtonCustomerChosen`, customer req hooks | `GregCustomerRegistry` + rule engine | SDK |
| D-02 | Zufällige Kundenanforderungen | ⚠️ PARTIAL | customer acceptance hooks | Requirement generator service | Plugin + SDK |
| D-03 | Dynamische Preisschwankungen | ⚠️ PARTIAL | shop hooks | Dynamic pricing service | Plugin + SDK |
| D-04 | Stromverbrauch/Stromkosten | ⚠️ PARTIAL | server power hooks | Energy simulation service | SDK + gameplay |
| D-05 | Auto-IP-Vergabe | ⚠️ PARTIAL | server app-id and network hooks | IP allocation service | SDK |
| E-01 | Beschriftungs-Tapes | ⚠️ PARTIAL | rack/network hooks | Persistent label store + UI input | Plugin + UI |
| E-02 | Rack-Kopieren inkl. Kabel | ⚠️ PARTIAL | rack/network hooks | Topology clone transaction API | SDK + harmony |
| E-03 | HexViewer-Panel | ⚠️ PARTIAL | verified event bus + hooks | Unified metadata adapter for all entities | Plugin + SDK |
| E-04 | Inventar-Slots / Item-Leiste | ❌ MISSING | no verified inventory UI API | Inventory UI extension API | UI + Plugin |
| E-05 | Kühlung/Abwärme Anzeige+Gameplay | 🚫 GAME-LEVEL | no thermal hook surface | Cooling simulation model | game-level |
| F-01 | Lichter / Deckenlampen | ❌ MISSING | wall purchase hook only | Lighting registry + runtime controls | harmony + SDK |
| F-02 | Mehrere Stockwerke/Türen/Wände | 🚫 GAME-LEVEL | no structural building API | world-building systems | game-level |
| F-03 | Transport-Automatisierung | ❌ MISSING | no logistics hooks verified | transport actor framework | SDK + gameplay |
| F-04 | Dustpan & Brush cleanup | ⚠️ PARTIAL | `greg.SYSTEM.oveSpawnedItemRemoved` | world item type/action API | Plugin + SDK |
| F-05 | Stromversorgung für Racks | ⚠️ PARTIAL | power hooks available | power topology graph service | SDK |
| F-06 | Kühlungsmanagement aktiv | 🚫 GAME-LEVEL | no cooling event surface | cooling system integration | game-level |
| G-01 | Dynamische Events | ⚠️ PARTIAL | day/save/load hooks | incident scheduler/orchestrator | Plugin + SDK |
| G-02 | Hacker/DDoS/Firewall | ❌ MISSING | NetWatch + generic hooks | security simulation framework | Plugin + SDK + gameplay |
| G-03 | Kabel-Audit Farb-Highlights | ⚠️ PARTIAL | cable/netwatch hooks | topology analyzer + highlight API | Plugin + UI |
| G-04 | Performance-Mod | ⚠️ PARTIAL | `gregMain` lifecycle proof (`OnUpdate`, `OnGUI`) | standardized performance profile service | Plugin + SDK |
| H-01 | Austausch bestehender 3D-Modelle | ❌ MISSING | no official model override API | `GregModelOverrideService` | Plugin + SDK |
| H-02 | Eigene Modelle für neue Inhalte | ⚠️ PARTIAL | data-driven conventions possible | official model binding contract | SDK + Plugin |
| H-03 | NPC-Modelle für neue Mitarbeiter | ❌ MISSING | employee events only | employee visual binding registry | SDK + harmony |
## 4. Detailanalyse pro Kategorie
### A — Employee / NPC
- Heute möglich: Reaktion auf Einstellungs-/Entlassungsereignisse.
- Fehlend: Idle-state und AI-state hooks; registrierbare employee classes.
- Ziel-Layer: `gregSdk` + `harmony`.
### B — Netzwerk / Switches / Ports
- Heute möglich: Beobachtung von Kabel-, SFP-, Link- und Speed-Ereignissen.
- Fehlend: Typed registries + compatibility matrix + route planner.
- Ziel-Layer: `gregSdk` zuerst, Plugin-Tools danach.
### C — Server / Hardware
- Heute möglich: Server lifecycle/power/broken/repair Observability.
- Fehlend: server types, density constraints, upgrade contracts.
- Ziel-Layer: `gregSdk` + selective `harmony`.
### D — Kunden / Wirtschaft
- Heute möglich: customer selection + requirement pass/fail events.
- Fehlend: customer policy engine, randomizer, dynamic pricing, power economy.
- Ziel-Layer: `gregSdk` + plugin policy modules.
### E — UI / QoL
- Heute möglich: native OnGUI overlays and hook-driven panels.
- Fehlend: unified metadata adapter, inventory UI extension, persistent labels.
- Ziel-Layer: Plugin + SDK contracts.
### F — Umgebung / Gebäude
- Heute möglich: begrenzte Reaktionen auf item remove / wall purchase.
- Fehlend: strukturelle Gebäude- und Klimasysteme.
- Ziel-Layer: überwiegend game-level, teils `harmony`-heavy.
### G — Events / Gameplay
- Heute möglich: event triggering via day/save/load + telemetry hooks.
- Fehlend: orchestrator for incidents and security scenario system.
- Ziel-Layer: Plugin orchestrator + SDK contracts.
### H — 3D / Visual
- Heute möglich: partielle model references in mod-side data.
- Fehlend: official model override/binding API with fallback/conflict handling.
- Ziel-Layer: Plugin runtime + SDK contract.
## 5. Fehlende Framework-Komponenten (konsolidiert)
### FEHLT: GregContentRegistry (typed categories)
**Betrifft Features:** A-03, B-03, B-12, C-01, C-03, C-04, D-01, H-02
**Layer:** `framework/Sdk/`
**Warum nötig:** Ohne typed registries bleiben Inhalte modlokal und nicht frameworkweit konsistent.
### FEHLT: GregNetworkCompatibilityService
**Betrifft Features:** B-01, B-02, B-05, B-06, B-10, B-11, C-04
**Layer:** `framework/Sdk/` + plugins
**Warum nötig:** Port-/SFP-/Kabel-Regeln brauchen zentralen, reproduzierbaren Resolver.
### FEHLT: GregEmployeeStateService
**Betrifft Features:** A-01, A-02, H-03
**Layer:** `framework/harmony/` + `framework/Sdk/`
**Warum nötig:** Idle/AI transitions sind aktuell nicht als stabile Hook-Oberfläche verfügbar.
### FEHLT: GregModelOverrideService
**Betrifft Features:** H-01, H-02, H-03, E-03
**Layer:** plugins + SDK
**Warum nötig:** Kein offizieller runtime override lifecycle mit fallback und Konfliktauflösung.
### FEHLT: GregCustomerPolicyEngine
**Betrifft Features:** D-01, D-02, D-05
**Layer:** SDK
**Warum nötig:** Kundenregeln/Budget/Assignment sind nicht als offizieller Evaluator modelliert.
### FEHLT: GregIncidentOrchestrator
**Betrifft Features:** G-01, G-02
**Layer:** plugins + SDK hooks
**Warum nötig:** Dynamische Ereignisse brauchen Scheduler + lifecycle/state persistence.
## 6. MISSING Status (Language Bridges)
### 6.1 Konsolidierung aller aktuellen MISSING-Dateien
| Datei | Fehlende Bereiche | Layer |
| --- | --- | --- |
| `plugins/greg.Plugin.HexViewer/lua/MISSING.md` | Lua event bridge, payload bridge, HUD bridge, targeting bridge | `framework/ModLoader`, `framework/Sdk` |
| `plugins/greg.Plugin.HexViewer/ts/MISSING.md` | TS event bridge, payload bridge, HUD bridge, targeting bridge | `framework/ModLoader`, `framework/Sdk` |
| `plugins/greg.Plugin.HexViewer/rs/MISSING.md` | Rust event bridge, payload bridge, HUD bridge, targeting bridge | `framework/ModLoader`, `framework/Sdk` |
### 6.2 Zusammengefasste Lücken aus allen MISSING-Dateien
- Es fehlt eine **dokumentierte LanguageBridge-Vertragsfläche** für Lua/TS/Rust (Subscribe, Update, GUI callbacks).
- Es fehlt eine **sprachübergreifende Payload-Bridge** mit stabilen Getter-Signaturen analog zu `GregPayload.Get<T>(...)`.
- Es fehlt eine **native HUD-Bridge** (IMGUI proxy API) für Nicht-C#-Sprachen.
- Es fehlt eine **Targeting-Bridge** (Camera-forward Raycast) in allen Nicht-C#-Bridges.
- Ergebnis: HexViewer in Lua/TS/Rust bleibt **UNVERIFIED** bis die Bridge-Verträge offiziell dokumentiert und implementiert sind.
## 7. Empfohlener Implementierungsplan
### Phase 1 – Framework-Fundament (BLOCKING)
- Typed content registries
- Schema validation + cross-reference checks
- Network compatibility service
- Employee state hook expansion
### Phase 2 – Feature-Layer
- Customer policy engine
- Model override service (with fallback/conflict)
- Topology audit service
- UI metadata adapter
### Phase 3 – Mod-Layer (externe Modder)
- Content packs für server/switch/customer/cable/sfp/furniture
- QoL plugins (labels, cable audit, performance modes)
### Phase 4 – Long-Term / GAME-LEVEL
- Features mit tiefer Spielsystem-Abhängigkeit (cooling simulation, advanced building, WDM, security minigame)
docs/02_development/hooks-library/customer/_category_.json
-7
View File
@@ -1,7 +0,0 @@
{
"label": "CUSTOMER hooks",
"position": 1,
"collapsible": true,
"collapsed": true
}
docs/02_development/hooks-library/customer/greg-customer-appperformanceadded.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.CUSTOMER.AppPerformanceAdded
sidebar_label: greg.CUSTOMER.AppPerformanceAdded
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CustomerBase.AddAppPerformance"
---
# `greg.CUSTOMER.AppPerformanceAdded`
## Description
- Auto-generated from Il2Cpp unpack: CustomerBase.AddAppPerformance
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CustomerBase::AddAppPerformance(int, float)` | Postfix | Auto-generated from Il2Cpp unpack: CustomerBase.AddAppPerformance |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.CUSTOMER.AppPerformanceAdded`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.CUSTOMER.AppPerformanceAdded", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.CUSTOMER.AppPerformanceAdded`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.CUSTOMER.AppPerformanceAdded", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.CUSTOMER.AppPerformanceAdded", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.CUSTOMER.AppPerformanceAdded", |payload| {
if let Some(method) = payload.get("method") {
println!("[CUSTOMER] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.CUSTOMER.AppPerformanceAdded", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[CUSTOMER] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.CUSTOMER.AppPerformanceAdded", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.CUSTOMER.AppPerformanceAdded", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[CUSTOMER] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.CUSTOMER.AppPerformanceAdded` as the canonical routing key end-to-end.
docs/02_development/hooks-library/customer/greg-customer-apptext.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.CUSTOMER.AppText
sidebar_label: greg.CUSTOMER.AppText
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CustomerBase.AppText"
---
# `greg.CUSTOMER.AppText`
## Description
- Auto-generated from Il2Cpp unpack: CustomerBase.AppText
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CustomerBase::AppText(int)` | Postfix | Auto-generated from Il2Cpp unpack: CustomerBase.AppText |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.CUSTOMER.AppText`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.CUSTOMER.AppText", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.CUSTOMER.AppText`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.CUSTOMER.AppText", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.CUSTOMER.AppText", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.CUSTOMER.AppText", |payload| {
if let Some(method) = payload.get("method") {
println!("[CUSTOMER] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.CUSTOMER.AppText", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[CUSTOMER] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.CUSTOMER.AppText", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.CUSTOMER.AppText", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[CUSTOMER] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.CUSTOMER.AppText` as the canonical routing key end-to-end.
docs/02_development/hooks-library/customer/greg-customer-componentinitialized.md
-123
View File
@@ -1,123 +0,0 @@
---
title: greg.CUSTOMER.ComponentInitialized
sidebar_label: greg.CUSTOMER.ComponentInitialized
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CustomerBase.Awake"
---
# `greg.CUSTOMER.ComponentInitialized`
## Description
- Auto-generated from Il2Cpp unpack: CustomerBase.Awake
- Auto-generated from Il2Cpp unpack: CustomerBase.Start
## Patch Targets (Il2Cpp)
This hook name can be mapped to **2** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CustomerBase::Awake()` | Postfix | Auto-generated from Il2Cpp unpack: CustomerBase.Awake |
| `Il2Cpp.CustomerBase::Start()` | Postfix | Auto-generated from Il2Cpp unpack: CustomerBase.Start |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.CUSTOMER.ComponentInitialized`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.CUSTOMER.ComponentInitialized", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.CUSTOMER.ComponentInitialized`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.CUSTOMER.ComponentInitialized", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.CUSTOMER.ComponentInitialized", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.CUSTOMER.ComponentInitialized", |payload| {
if let Some(method) = payload.get("method") {
println!("[CUSTOMER] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.CUSTOMER.ComponentInitialized", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[CUSTOMER] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.CUSTOMER.ComponentInitialized", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.CUSTOMER.ComponentInitialized", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[CUSTOMER] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.CUSTOMER.ComponentInitialized` as the canonical routing key end-to-end.
docs/02_development/hooks-library/customer/greg-customer-customerservercountandspeedchanged.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.CUSTOMER.CustomerServerCountAndSpeedChanged
sidebar_label: greg.CUSTOMER.CustomerServerCountAndSpeedChanged
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CustomerBase.UpdateCustomerServerCountAndSpeed"
---
# `greg.CUSTOMER.CustomerServerCountAndSpeedChanged`
## Description
- Auto-generated from Il2Cpp unpack: CustomerBase.UpdateCustomerServerCountAndSpeed
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CustomerBase::UpdateCustomerServerCountAndSpeed(int, float)` | Postfix | Auto-generated from Il2Cpp unpack: CustomerBase.UpdateCustomerServerCountAndSpeed |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.CUSTOMER.CustomerServerCountAndSpeedChanged`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.CUSTOMER.CustomerServerCountAndSpeedChanged", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.CUSTOMER.CustomerServerCountAndSpeedChanged`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.CUSTOMER.CustomerServerCountAndSpeedChanged", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.CUSTOMER.CustomerServerCountAndSpeedChanged", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.CUSTOMER.CustomerServerCountAndSpeedChanged", |payload| {
if let Some(method) = payload.get("method") {
println!("[CUSTOMER] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.CUSTOMER.CustomerServerCountAndSpeedChanged", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[CUSTOMER] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.CUSTOMER.CustomerServerCountAndSpeedChanged", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.CUSTOMER.CustomerServerCountAndSpeedChanged", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[CUSTOMER] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.CUSTOMER.CustomerServerCountAndSpeedChanged` as the canonical routing key end-to-end.
docs/02_development/hooks-library/customer/greg-customer-dataloaded.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.CUSTOMER.DataLoaded
sidebar_label: greg.CUSTOMER.DataLoaded
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CustomerBase.LoadData"
---
# `greg.CUSTOMER.DataLoaded`
## Description
- Auto-generated from Il2Cpp unpack: CustomerBase.LoadData
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CustomerBase::LoadData(CustomerBaseSaveData)` | Postfix | Auto-generated from Il2Cpp unpack: CustomerBase.LoadData |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.CUSTOMER.DataLoaded`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.CUSTOMER.DataLoaded", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.CUSTOMER.DataLoaded`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.CUSTOMER.DataLoaded", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.CUSTOMER.DataLoaded", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.CUSTOMER.DataLoaded", |payload| {
if let Some(method) = payload.get("method") {
println!("[CUSTOMER] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.CUSTOMER.DataLoaded", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[CUSTOMER] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.CUSTOMER.DataLoaded", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.CUSTOMER.DataLoaded", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[CUSTOMER] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.CUSTOMER.DataLoaded` as the canonical routing key end-to-end.
docs/02_development/hooks-library/customer/greg-customer-getappidforip.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.CUSTOMER.GetAppIDForIP
sidebar_label: greg.CUSTOMER.GetAppIDForIP
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CustomerBase.GetAppIDForIP"
---
# `greg.CUSTOMER.GetAppIDForIP`
## Description
- Auto-generated from Il2Cpp unpack: CustomerBase.GetAppIDForIP
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CustomerBase::GetAppIDForIP(string)` | Postfix | Auto-generated from Il2Cpp unpack: CustomerBase.GetAppIDForIP |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.CUSTOMER.GetAppIDForIP`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.CUSTOMER.GetAppIDForIP", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.CUSTOMER.GetAppIDForIP`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.CUSTOMER.GetAppIDForIP", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.CUSTOMER.GetAppIDForIP", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.CUSTOMER.GetAppIDForIP", |payload| {
if let Some(method) = payload.get("method") {
println!("[CUSTOMER] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.CUSTOMER.GetAppIDForIP", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[CUSTOMER] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.CUSTOMER.GetAppIDForIP", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.CUSTOMER.GetAppIDForIP", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[CUSTOMER] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.CUSTOMER.GetAppIDForIP` as the canonical routing key end-to-end.
docs/02_development/hooks-library/customer/greg-customer-getservertypeforip.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.CUSTOMER.GetServerTypeForIP
sidebar_label: greg.CUSTOMER.GetServerTypeForIP
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CustomerBase.GetServerTypeForIP"
---
# `greg.CUSTOMER.GetServerTypeForIP`
## Description
- Auto-generated from Il2Cpp unpack: CustomerBase.GetServerTypeForIP
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CustomerBase::GetServerTypeForIP(string)` | Postfix | Auto-generated from Il2Cpp unpack: CustomerBase.GetServerTypeForIP |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.CUSTOMER.GetServerTypeForIP`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.CUSTOMER.GetServerTypeForIP", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.CUSTOMER.GetServerTypeForIP`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.CUSTOMER.GetServerTypeForIP", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.CUSTOMER.GetServerTypeForIP", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.CUSTOMER.GetServerTypeForIP", |payload| {
if let Some(method) = payload.get("method") {
println!("[CUSTOMER] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.CUSTOMER.GetServerTypeForIP", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[CUSTOMER] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.CUSTOMER.GetServerTypeForIP", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.CUSTOMER.GetServerTypeForIP", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[CUSTOMER] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.CUSTOMER.GetServerTypeForIP` as the canonical routing key end-to-end.
docs/02_development/hooks-library/customer/greg-customer-getsubnetsperapp.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.CUSTOMER.GetSubnetsPerApp
sidebar_label: greg.CUSTOMER.GetSubnetsPerApp
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CustomerBase.GetSubnetsPerApp"
---
# `greg.CUSTOMER.GetSubnetsPerApp`
## Description
- Auto-generated from Il2Cpp unpack: CustomerBase.GetSubnetsPerApp
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CustomerBase::GetSubnetsPerApp()` | Postfix | Auto-generated from Il2Cpp unpack: CustomerBase.GetSubnetsPerApp |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.CUSTOMER.GetSubnetsPerApp`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.CUSTOMER.GetSubnetsPerApp", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.CUSTOMER.GetSubnetsPerApp`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.CUSTOMER.GetSubnetsPerApp", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.CUSTOMER.GetSubnetsPerApp", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.CUSTOMER.GetSubnetsPerApp", |payload| {
if let Some(method) = payload.get("method") {
println!("[CUSTOMER] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.CUSTOMER.GetSubnetsPerApp", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[CUSTOMER] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.CUSTOMER.GetSubnetsPerApp", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.CUSTOMER.GetSubnetsPerApp", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[CUSTOMER] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.CUSTOMER.GetSubnetsPerApp` as the canonical routing key end-to-end.
docs/02_development/hooks-library/customer/greg-customer-gettotalappspeed.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.CUSTOMER.GetTotalAppSpeed
sidebar_label: greg.CUSTOMER.GetTotalAppSpeed
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CustomerBase.GetTotalAppSpeed"
---
# `greg.CUSTOMER.GetTotalAppSpeed`
## Description
- Auto-generated from Il2Cpp unpack: CustomerBase.GetTotalAppSpeed
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CustomerBase::GetTotalAppSpeed()` | Postfix | Auto-generated from Il2Cpp unpack: CustomerBase.GetTotalAppSpeed |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.CUSTOMER.GetTotalAppSpeed`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.CUSTOMER.GetTotalAppSpeed", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.CUSTOMER.GetTotalAppSpeed`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.CUSTOMER.GetTotalAppSpeed", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.CUSTOMER.GetTotalAppSpeed", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.CUSTOMER.GetTotalAppSpeed", |payload| {
if let Some(method) = payload.get("method") {
println!("[CUSTOMER] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.CUSTOMER.GetTotalAppSpeed", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[CUSTOMER] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.CUSTOMER.GetTotalAppSpeed", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.CUSTOMER.GetTotalAppSpeed", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[CUSTOMER] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.CUSTOMER.GetTotalAppSpeed` as the canonical routing key end-to-end.
docs/02_development/hooks-library/customer/greg-customer-isippresent.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.CUSTOMER.IsIPPresent
sidebar_label: greg.CUSTOMER.IsIPPresent
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CustomerBase.IsIPPresent"
---
# `greg.CUSTOMER.IsIPPresent`
## Description
- Auto-generated from Il2Cpp unpack: CustomerBase.IsIPPresent
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CustomerBase::IsIPPresent(string)` | Postfix | Auto-generated from Il2Cpp unpack: CustomerBase.IsIPPresent |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.CUSTOMER.IsIPPresent`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.CUSTOMER.IsIPPresent", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.CUSTOMER.IsIPPresent`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.CUSTOMER.IsIPPresent", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.CUSTOMER.IsIPPresent", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.CUSTOMER.IsIPPresent", |payload| {
if let Some(method) = payload.get("method") {
println!("[CUSTOMER] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.CUSTOMER.IsIPPresent", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[CUSTOMER] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.CUSTOMER.IsIPPresent", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.CUSTOMER.IsIPPresent", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[CUSTOMER] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.CUSTOMER.IsIPPresent` as the canonical routing key end-to-end.
docs/02_development/hooks-library/customer/greg-customer-resetallappspeeds.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.CUSTOMER.ResetAllAppSpeeds
sidebar_label: greg.CUSTOMER.ResetAllAppSpeeds
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CustomerBase.ResetAllAppSpeeds"
---
# `greg.CUSTOMER.ResetAllAppSpeeds`
## Description
- Auto-generated from Il2Cpp unpack: CustomerBase.ResetAllAppSpeeds
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CustomerBase::ResetAllAppSpeeds()` | Postfix | Auto-generated from Il2Cpp unpack: CustomerBase.ResetAllAppSpeeds |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.CUSTOMER.ResetAllAppSpeeds`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.CUSTOMER.ResetAllAppSpeeds", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.CUSTOMER.ResetAllAppSpeeds`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.CUSTOMER.ResetAllAppSpeeds", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.CUSTOMER.ResetAllAppSpeeds", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.CUSTOMER.ResetAllAppSpeeds", |payload| {
if let Some(method) = payload.get("method") {
println!("[CUSTOMER] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.CUSTOMER.ResetAllAppSpeeds", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[CUSTOMER] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.CUSTOMER.ResetAllAppSpeeds", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.CUSTOMER.ResetAllAppSpeeds", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[CUSTOMER] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.CUSTOMER.ResetAllAppSpeeds` as the canonical routing key end-to-end.
docs/02_development/hooks-library/customer/greg-customer-speedoncustomerbaseappchanged.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.CUSTOMER.SpeedOnCustomerBaseAppChanged
sidebar_label: greg.CUSTOMER.SpeedOnCustomerBaseAppChanged
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CustomerBase.UpdateSpeedOnCustomerBaseApp"
---
# `greg.CUSTOMER.SpeedOnCustomerBaseAppChanged`
## Description
- Auto-generated from Il2Cpp unpack: CustomerBase.UpdateSpeedOnCustomerBaseApp
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CustomerBase::UpdateSpeedOnCustomerBaseApp(int, float)` | Postfix | Auto-generated from Il2Cpp unpack: CustomerBase.UpdateSpeedOnCustomerBaseApp |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.CUSTOMER.SpeedOnCustomerBaseAppChanged`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.CUSTOMER.SpeedOnCustomerBaseAppChanged", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.CUSTOMER.SpeedOnCustomerBaseAppChanged`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.CUSTOMER.SpeedOnCustomerBaseAppChanged", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.CUSTOMER.SpeedOnCustomerBaseAppChanged", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.CUSTOMER.SpeedOnCustomerBaseAppChanged", |payload| {
if let Some(method) = payload.get("method") {
println!("[CUSTOMER] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.CUSTOMER.SpeedOnCustomerBaseAppChanged", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[CUSTOMER] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.CUSTOMER.SpeedOnCustomerBaseAppChanged", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.CUSTOMER.SpeedOnCustomerBaseAppChanged", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[CUSTOMER] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.CUSTOMER.SpeedOnCustomerBaseAppChanged` as the canonical routing key end-to-end.
docs/02_development/hooks-library/customer/greg-customer-upappset.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.CUSTOMER.UpAppSet
sidebar_label: greg.CUSTOMER.UpAppSet
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CustomerBase.SetUpApp"
---
# `greg.CUSTOMER.UpAppSet`
## Description
- Auto-generated from Il2Cpp unpack: CustomerBase.SetUpApp
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CustomerBase::SetUpApp(int, int, CustomerBaseSaveData)` | Postfix | Auto-generated from Il2Cpp unpack: CustomerBase.SetUpApp |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.CUSTOMER.UpAppSet`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.CUSTOMER.UpAppSet", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.CUSTOMER.UpAppSet`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.CUSTOMER.UpAppSet", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.CUSTOMER.UpAppSet", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.CUSTOMER.UpAppSet", |payload| {
if let Some(method) = payload.get("method") {
println!("[CUSTOMER] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.CUSTOMER.UpAppSet", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[CUSTOMER] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.CUSTOMER.UpAppSet", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.CUSTOMER.UpAppSet", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[CUSTOMER] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.CUSTOMER.UpAppSet` as the canonical routing key end-to-end.
docs/02_development/hooks-library/customer/greg-customer-upbaseset.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.CUSTOMER.UpBaseSet
sidebar_label: greg.CUSTOMER.UpBaseSet
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CustomerBase.SetUpBase"
---
# `greg.CUSTOMER.UpBaseSet`
## Description
- Auto-generated from Il2Cpp unpack: CustomerBase.SetUpBase
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CustomerBase::SetUpBase(CustomerItem, CustomerBaseSaveData)` | Postfix | Auto-generated from Il2Cpp unpack: CustomerBase.SetUpBase |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.CUSTOMER.UpBaseSet`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.CUSTOMER.UpBaseSet", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.CUSTOMER.UpBaseSet`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.CUSTOMER.UpBaseSet", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.CUSTOMER.UpBaseSet", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.CUSTOMER.UpBaseSet", |payload| {
if let Some(method) = payload.get("method") {
println!("[CUSTOMER] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.CUSTOMER.UpBaseSet", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[CUSTOMER] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.CUSTOMER.UpBaseSet", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.CUSTOMER.UpBaseSet", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[CUSTOMER] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.CUSTOMER.UpBaseSet` as the canonical routing key end-to-end.
docs/02_development/hooks-library/economy/_category_.json
-4
View File
@@ -1,4 +0,0 @@
{
"label": "Economy",
"position": 10
}
docs/02_development/hooks-library/economy/greg-economy-playercoinupdated.md
-47
View File
@@ -1,47 +0,0 @@
---
title: greg.economy.PlayerCoinUpdated
sidebar_label: greg.economy.PlayerCoinUpdated
description: "gregCore Hook — Player Coin Updated"
---
# `greg.economy.PlayerCoinUpdated`
## Description
- Emitted when the player's coin balance changes.
## Payload Schema
| Field | Type / Note |
|------|----------------|
| `type` | `valueChange` |
| `key` | `money` |
| `oldValue` | `float` |
| `newValue` | `float` |
## How to use this hook
### 1. Object Bus: `GregEventDispatcher` (Rust / FFI / Lua / TS)
This hook is fired from the core via the `gregCore` plugin bridge whenever the underlying IL2CPP method (`Player.UpdateCoin`) executes successfully.
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.economy.PlayerCoinUpdated", payload =>
{
var newValue = GregPayload.Get<float>(payload, "newValue", 0f);
// Logic here
});
```
### 2. Usage in Lua
Use the Lua bridge and register against the canonical hook string:
~~~lua
greg.on("greg.economy.PlayerCoinUpdated", function(payload)
local newVal = payload and payload.newValue or 0
greg.log("[ECONOMY] new money=" .. tostring(newVal))
end)
~~~
docs/02_development/hooks-library/economy/greg-economy-playerreputationupdated.md
-47
View File
@@ -1,47 +0,0 @@
---
title: greg.economy.PlayerReputationUpdated
sidebar_label: greg.economy.PlayerReputationUpdated
description: "gregCore Hook — Player Reputation Updated"
---
# `greg.economy.PlayerReputationUpdated`
## Description
- Emitted when the player's reputation changes.
## Payload Schema
| Field | Type / Note |
|------|----------------|
| `type` | `valueChange` |
| `key` | `reputation` |
| `oldValue` | `float` |
| `newValue` | `float` |
## How to use this hook
### 1. Object Bus: `GregEventDispatcher` (Rust / FFI / Lua / TS)
This hook is fired from the core via the `gregCore` plugin bridge whenever the underlying IL2CPP method (`Player.UpdateReputation`) executes successfully.
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.economy.PlayerReputationUpdated", payload =>
{
var newValue = GregPayload.Get<float>(payload, "newValue", 0f);
// Logic here
});
```
### 2. Usage in Lua
Use the Lua bridge and register against the canonical hook string:
~~~lua
greg.on("greg.economy.PlayerReputationUpdated", function(payload)
local newVal = payload and payload.newValue or 0
greg.log("[ECONOMY] new reputation=" .. tostring(newVal))
end)
~~~
docs/02_development/hooks-library/economy/greg-economy-playerxpupdated.md
-47
View File
@@ -1,47 +0,0 @@
---
title: greg.economy.PlayerXpUpdated
sidebar_label: greg.economy.PlayerXpUpdated
description: "gregCore Hook — Player XP Updated"
---
# `greg.economy.PlayerXpUpdated`
## Description
- Emitted when the player's XP changes.
## Payload Schema
| Field | Type / Note |
|------|----------------|
| `type` | `valueChange` |
| `key` | `xp` |
| `oldValue` | `float` |
| `newValue` | `float` |
## How to use this hook
### 1. Object Bus: `GregEventDispatcher` (Rust / FFI / Lua / TS)
This hook is fired from the core via the `gregCore` plugin bridge whenever the underlying IL2CPP method (`Player.UpdateXP`) executes successfully.
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.economy.PlayerXpUpdated", payload =>
{
var newValue = GregPayload.Get<float>(payload, "newValue", 0f);
// Logic here
});
```
### 2. Usage in Lua
Use the Lua bridge and register against the canonical hook string:
~~~lua
greg.on("greg.economy.PlayerXpUpdated", function(payload)
local newVal = payload and payload.newValue or 0
greg.log("[ECONOMY] new xp=" .. tostring(newVal))
end)
~~~
docs/02_development/hooks-library/employee/_category_.json
-7
View File
@@ -1,7 +0,0 @@
{
"label": "EMPLOYEE hooks",
"position": 1,
"collapsible": true,
"collapsed": true
}
docs/02_development/hooks-library/employee/greg-employee-assignjob.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.EMPLOYEE.AssignJob
sidebar_label: greg.EMPLOYEE.AssignJob
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Technician.AssignJob"
---
# `greg.EMPLOYEE.AssignJob`
## Description
- Auto-generated from Il2Cpp unpack: Technician.AssignJob
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Technician::AssignJob(TechnicianManager.RepairJob)` | Postfix | Auto-generated from Il2Cpp unpack: Technician.AssignJob |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.AssignJob`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.AssignJob", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.AssignJob`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.AssignJob", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.AssignJob", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.AssignJob", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.AssignJob", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.AssignJob", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.AssignJob", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.AssignJob` as the canonical routing key end-to-end.
docs/02_development/hooks-library/employee/greg-employee-buttonfireemployee.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.EMPLOYEE.ButtonFireEmployee
sidebar_label: greg.EMPLOYEE.ButtonFireEmployee
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: HRSystem.ButtonFireEmployee"
---
# `greg.EMPLOYEE.ButtonFireEmployee`
## Description
- Auto-generated from Il2Cpp unpack: HRSystem.ButtonFireEmployee
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.HRSystem::ButtonFireEmployee(int)` | Postfix | Auto-generated from Il2Cpp unpack: HRSystem.ButtonFireEmployee |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.ButtonFireEmployee`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.ButtonFireEmployee", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.ButtonFireEmployee`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.ButtonFireEmployee", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.ButtonFireEmployee", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.ButtonFireEmployee", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.ButtonFireEmployee", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.ButtonFireEmployee", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.ButtonFireEmployee", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.ButtonFireEmployee` as the canonical routing key end-to-end.
docs/02_development/hooks-library/employee/greg-employee-buttonhireemployee.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.EMPLOYEE.ButtonHireEmployee
sidebar_label: greg.EMPLOYEE.ButtonHireEmployee
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: HRSystem.ButtonHireEmployee"
---
# `greg.EMPLOYEE.ButtonHireEmployee`
## Description
- Auto-generated from Il2Cpp unpack: HRSystem.ButtonHireEmployee
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.HRSystem::ButtonHireEmployee(int)` | Postfix | Auto-generated from Il2Cpp unpack: HRSystem.ButtonHireEmployee |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.ButtonHireEmployee`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.ButtonHireEmployee", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.ButtonHireEmployee`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.ButtonHireEmployee", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.ButtonHireEmployee", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.ButtonHireEmployee", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.ButtonHireEmployee", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.ButtonHireEmployee", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.ButtonHireEmployee", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.ButtonHireEmployee` as the canonical routing key end-to-end.
docs/02_development/hooks-library/employee/greg-employee-componentinitialized.md
-125
View File
@@ -1,125 +0,0 @@
---
title: greg.EMPLOYEE.ComponentInitialized
sidebar_label: greg.EMPLOYEE.ComponentInitialized
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Technician.Awake"
---
# `greg.EMPLOYEE.ComponentInitialized`
## Description
- Auto-generated from Il2Cpp unpack: Technician.Awake
- Auto-generated from Il2Cpp unpack: Technician.Start
- Auto-generated from Il2Cpp unpack: TechnicianManager.Awake
## Patch Targets (Il2Cpp)
This hook name can be mapped to **3** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Technician::Awake()` | Postfix | Auto-generated from Il2Cpp unpack: Technician.Awake |
| `Il2Cpp.Technician::Start()` | Postfix | Auto-generated from Il2Cpp unpack: Technician.Start |
| `Il2Cpp.TechnicianManager::Awake()` | Postfix | Auto-generated from Il2Cpp unpack: TechnicianManager.Awake |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.ComponentInitialized`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.ComponentInitialized", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.ComponentInitialized`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.ComponentInitialized", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.ComponentInitialized", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.ComponentInitialized", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.ComponentInitialized", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.ComponentInitialized", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.ComponentInitialized", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.ComponentInitialized` as the canonical routing key end-to-end.
docs/02_development/hooks-library/employee/greg-employee-devicerepaired.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.EMPLOYEE.DeviceRepaired
sidebar_label: greg.EMPLOYEE.DeviceRepaired
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Technician.RepairDevice"
---
# `greg.EMPLOYEE.DeviceRepaired`
## Description
- Auto-generated from Il2Cpp unpack: Technician.RepairDevice
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Technician::RepairDevice()` | Postfix | Auto-generated from Il2Cpp unpack: Technician.RepairDevice |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.DeviceRepaired`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.DeviceRepaired", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.DeviceRepaired`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.DeviceRepaired", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.DeviceRepaired", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.DeviceRepaired", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.DeviceRepaired", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.DeviceRepaired", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.DeviceRepaired", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.DeviceRepaired` as the canonical routing key end-to-end.
docs/02_development/hooks-library/employee/greg-employee-dispatched.md
-122
View File
@@ -1,122 +0,0 @@
---
title: greg.EMPLOYEE.Dispatched
sidebar_label: greg.EMPLOYEE.Dispatched
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: TechnicianManager.SendTechnician"
---
# `greg.EMPLOYEE.Dispatched`
## Description
- Auto-generated from Il2Cpp unpack: TechnicianManager.SendTechnician
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.TechnicianManager::SendTechnician(NetworkSwitch, Server)` | Postfix | Auto-generated from Il2Cpp unpack: TechnicianManager.SendTechnician |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `networkSwitch` | `NetworkSwitch` |
| `server` | `Server` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.Dispatched`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.Dispatched", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.Dispatched`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.Dispatched", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.Dispatched", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.Dispatched", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.Dispatched", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.Dispatched", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.Dispatched", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.Dispatched` as the canonical routing key end-to-end.
docs/02_development/hooks-library/employee/greg-employee-fired.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.EMPLOYEE.Fired
sidebar_label: greg.EMPLOYEE.Fired
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: TechnicianManager.FireTechnician"
---
# `greg.EMPLOYEE.Fired`
## Description
- Auto-generated from Il2Cpp unpack: TechnicianManager.FireTechnician
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.TechnicianManager::FireTechnician(int)` | Postfix | Auto-generated from Il2Cpp unpack: TechnicianManager.FireTechnician |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `technicianID` | `int` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.Fired`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.Fired", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.Fired`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.Fired", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.Fired", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.Fired", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.Fired", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.Fired", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.Fired", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.Fired` as the canonical routing key end-to-end.
docs/02_development/hooks-library/employee/greg-employee-getcorrectdeviceprefab.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.EMPLOYEE.GetCorrectDevicePrefab
sidebar_label: greg.EMPLOYEE.GetCorrectDevicePrefab
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Technician.GetCorrectDevicePrefab"
---
# `greg.EMPLOYEE.GetCorrectDevicePrefab`
## Description
- Auto-generated from Il2Cpp unpack: Technician.GetCorrectDevicePrefab
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Technician::GetCorrectDevicePrefab()` | Postfix | Auto-generated from Il2Cpp unpack: Technician.GetCorrectDevicePrefab |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.GetCorrectDevicePrefab`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.GetCorrectDevicePrefab", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.GetCorrectDevicePrefab`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.GetCorrectDevicePrefab", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.GetCorrectDevicePrefab", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.GetCorrectDevicePrefab", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.GetCorrectDevicePrefab", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.GetCorrectDevicePrefab", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.GetCorrectDevicePrefab", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.GetCorrectDevicePrefab` as the canonical routing key end-to-end.
docs/02_development/hooks-library/employee/greg-employee-hired.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.EMPLOYEE.Hired
sidebar_label: greg.EMPLOYEE.Hired
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: TechnicianManager.AddTechnician"
---
# `greg.EMPLOYEE.Hired`
## Description
- Auto-generated from Il2Cpp unpack: TechnicianManager.AddTechnician
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.TechnicianManager::AddTechnician(Technician)` | Postfix | Auto-generated from Il2Cpp unpack: TechnicianManager.AddTechnician |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `technician` | `Technician` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.Hired`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.Hired", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.Hired`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.Hired", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.Hired", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.Hired", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.Hired", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.Hired", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.Hired", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.Hired` as the canonical routing key end-to-end.
docs/02_development/hooks-library/employee/greg-employee-isdevicealreadyassigned.md
-123
View File
@@ -1,123 +0,0 @@
---
title: greg.EMPLOYEE.IsDeviceAlreadyAssigned
sidebar_label: greg.EMPLOYEE.IsDeviceAlreadyAssigned
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: TechnicianManager.IsDeviceAlreadyAssigned"
---
# `greg.EMPLOYEE.IsDeviceAlreadyAssigned`
## Description
- Auto-generated from Il2Cpp unpack: TechnicianManager.IsDeviceAlreadyAssigned
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.TechnicianManager::IsDeviceAlreadyAssigned(NetworkSwitch, Server)` | Postfix | Auto-generated from Il2Cpp unpack: TechnicianManager.IsDeviceAlreadyAssigned |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `networkSwitch` | `NetworkSwitch` |
| `server` | `Server` |
| `assigned` | `bool` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.IsDeviceAlreadyAssigned`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.IsDeviceAlreadyAssigned", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.IsDeviceAlreadyAssigned`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.IsDeviceAlreadyAssigned", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.IsDeviceAlreadyAssigned", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.IsDeviceAlreadyAssigned", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.IsDeviceAlreadyAssigned", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.IsDeviceAlreadyAssigned", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.IsDeviceAlreadyAssigned", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.IsDeviceAlreadyAssigned` as the canonical routing key end-to-end.
docs/02_development/hooks-library/employee/greg-employee-jobqueued.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.EMPLOYEE.JobQueued
sidebar_label: greg.EMPLOYEE.JobQueued
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: TechnicianManager.EnqueueDispatch"
---
# `greg.EMPLOYEE.JobQueued`
## Description
- Auto-generated from Il2Cpp unpack: TechnicianManager.EnqueueDispatch
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.TechnicianManager::EnqueueDispatch(TechnicianManager.RepairJob)` | Postfix | Auto-generated from Il2Cpp unpack: TechnicianManager.EnqueueDispatch |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `job` | `TechnicianManager.RepairJob` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.JobQueued`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.JobQueued", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.JobQueued`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.JobQueued", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.JobQueued", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.JobQueued", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.JobQueued", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.JobQueued", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.JobQueued", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.JobQueued` as the canonical routing key end-to-end.
docs/02_development/hooks-library/employee/greg-employee-jobqueueloaded.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.EMPLOYEE.JobQueueLoaded
sidebar_label: greg.EMPLOYEE.JobQueueLoaded
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: TechnicianManager.RestoreJobQueue"
---
# `greg.EMPLOYEE.JobQueueLoaded`
## Description
- Auto-generated from Il2Cpp unpack: TechnicianManager.RestoreJobQueue
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.TechnicianManager::RestoreJobQueue(List<RepairJobSaveData>)` | Postfix | Auto-generated from Il2Cpp unpack: TechnicianManager.RestoreJobQueue |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `savedJobs` | `List<RepairJobSaveData>` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.JobQueueLoaded`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.JobQueueLoaded", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.JobQueueLoaded`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.JobQueueLoaded", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.JobQueueLoaded", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.JobQueueLoaded", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.JobQueueLoaded", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.JobQueueLoaded", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.JobQueueLoaded", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.JobQueueLoaded` as the canonical routing key end-to-end.
docs/02_development/hooks-library/employee/greg-employee-nextjobrequested.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.EMPLOYEE.NextJobRequested
sidebar_label: greg.EMPLOYEE.NextJobRequested
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: TechnicianManager.RequestNextJob"
---
# `greg.EMPLOYEE.NextJobRequested`
## Description
- Auto-generated from Il2Cpp unpack: TechnicianManager.RequestNextJob
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.TechnicianManager::RequestNextJob(Technician)` | Postfix | Auto-generated from Il2Cpp unpack: TechnicianManager.RequestNextJob |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `technician` | `Technician` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.NextJobRequested`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.NextJobRequested", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.NextJobRequested`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.NextJobRequested", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.NextJobRequested", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.NextJobRequested", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.NextJobRequested", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.NextJobRequested", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.NextJobRequested", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.NextJobRequested` as the canonical routing key end-to-end.
docs/02_development/hooks-library/employee/greg-employee-ondestroy.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.EMPLOYEE.OnDestroy
sidebar_label: greg.EMPLOYEE.OnDestroy
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Technician.OnDestroy"
---
# `greg.EMPLOYEE.OnDestroy`
## Description
- Auto-generated from Il2Cpp unpack: Technician.OnDestroy
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Technician::OnDestroy()` | Postfix | Auto-generated from Il2Cpp unpack: Technician.OnDestroy |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.OnDestroy`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.OnDestroy", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.OnDestroy`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.OnDestroy", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.OnDestroy", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.OnDestroy", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.OnDestroy", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.OnDestroy", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.OnDestroy", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.OnDestroy` as the canonical routing key end-to-end.
docs/02_development/hooks-library/employee/greg-employee-onloadingstarted.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.EMPLOYEE.OnLoadingStarted
sidebar_label: greg.EMPLOYEE.OnLoadingStarted
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Technician.OnLoadingStarted"
---
# `greg.EMPLOYEE.OnLoadingStarted`
## Description
- Auto-generated from Il2Cpp unpack: Technician.OnLoadingStarted
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Technician::OnLoadingStarted()` | Postfix | Auto-generated from Il2Cpp unpack: Technician.OnLoadingStarted |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.OnLoadingStarted`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.OnLoadingStarted", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.OnLoadingStarted`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.OnLoadingStarted", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.OnLoadingStarted", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.OnLoadingStarted", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.OnLoadingStarted", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.OnLoadingStarted", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.OnLoadingStarted", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.OnLoadingStarted` as the canonical routing key end-to-end.
docs/02_development/hooks-library/employee/greg-employee-positionhandtargetsondevice.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.EMPLOYEE.PositionHandTargetsOnDevice
sidebar_label: greg.EMPLOYEE.PositionHandTargetsOnDevice
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Technician.PositionHandTargetsOnDevice"
---
# `greg.EMPLOYEE.PositionHandTargetsOnDevice`
## Description
- Auto-generated from Il2Cpp unpack: Technician.PositionHandTargetsOnDevice
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Technician::PositionHandTargetsOnDevice(GameObject)` | Postfix | Auto-generated from Il2Cpp unpack: Technician.PositionHandTargetsOnDevice |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.PositionHandTargetsOnDevice`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.PositionHandTargetsOnDevice", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.PositionHandTargetsOnDevice`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.PositionHandTargetsOnDevice", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.PositionHandTargetsOnDevice", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.PositionHandTargetsOnDevice", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.PositionHandTargetsOnDevice", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.PositionHandTargetsOnDevice", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.PositionHandTargetsOnDevice", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.PositionHandTargetsOnDevice` as the canonical routing key end-to-end.
docs/02_development/hooks-library/employee/greg-employee-rotatetowardsgoal.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.EMPLOYEE.RotateTowardsGoal
sidebar_label: greg.EMPLOYEE.RotateTowardsGoal
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Technician.RotateTowardsGoal"
---
# `greg.EMPLOYEE.RotateTowardsGoal`
## Description
- Auto-generated from Il2Cpp unpack: Technician.RotateTowardsGoal
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Technician::RotateTowardsGoal(Vector3)` | Postfix | Auto-generated from Il2Cpp unpack: Technician.RotateTowardsGoal |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.EMPLOYEE.RotateTowardsGoal`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.EMPLOYEE.RotateTowardsGoal", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.EMPLOYEE.RotateTowardsGoal`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.EMPLOYEE.RotateTowardsGoal", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.EMPLOYEE.RotateTowardsGoal", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.EMPLOYEE.RotateTowardsGoal", |payload| {
if let Some(method) = payload.get("method") {
println!("[EMPLOYEE] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.EMPLOYEE.RotateTowardsGoal", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[EMPLOYEE] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.EMPLOYEE.RotateTowardsGoal", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.EMPLOYEE.RotateTowardsGoal", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[EMPLOYEE] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.EMPLOYEE.RotateTowardsGoal` as the canonical routing key end-to-end.
docs/02_development/hooks-library/gameplay/_category_.json
-7
View File
@@ -1,7 +0,0 @@
{
"label": "GAMEPLAY hooks",
"position": 1,
"collapsible": true,
"collapsed": true
}
docs/02_development/hooks-library/gameplay/greg-gameplay-clearobjectives.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.GAMEPLAY.ClearObjectives
sidebar_label: greg.GAMEPLAY.ClearObjectives
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Objectives.ClearObjectives"
---
# `greg.GAMEPLAY.ClearObjectives`
## Description
- Auto-generated from Il2Cpp unpack: Objectives.ClearObjectives
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Objectives::ClearObjectives()` | Postfix | Auto-generated from Il2Cpp unpack: Objectives.ClearObjectives |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.GAMEPLAY.ClearObjectives`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.GAMEPLAY.ClearObjectives", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.GAMEPLAY.ClearObjectives`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.GAMEPLAY.ClearObjectives", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.GAMEPLAY.ClearObjectives", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.GAMEPLAY.ClearObjectives", |payload| {
if let Some(method) = payload.get("method") {
println!("[GAMEPLAY] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.GAMEPLAY.ClearObjectives", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[GAMEPLAY] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.GAMEPLAY.ClearObjectives", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.GAMEPLAY.ClearObjectives", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[GAMEPLAY] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.GAMEPLAY.ClearObjectives` as the canonical routing key end-to-end.
docs/02_development/hooks-library/gameplay/greg-gameplay-componentinitialized.md
-123
View File
@@ -1,123 +0,0 @@
---
title: greg.GAMEPLAY.ComponentInitialized
sidebar_label: greg.GAMEPLAY.ComponentInitialized
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Objectives.Awake"
---
# `greg.GAMEPLAY.ComponentInitialized`
## Description
- Auto-generated from Il2Cpp unpack: Objectives.Awake
- Auto-generated from Il2Cpp unpack: Objectives.Start
## Patch Targets (Il2Cpp)
This hook name can be mapped to **2** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Objectives::Awake()` | Postfix | Auto-generated from Il2Cpp unpack: Objectives.Awake |
| `Il2Cpp.Objectives::Start()` | Postfix | Auto-generated from Il2Cpp unpack: Objectives.Start |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.GAMEPLAY.ComponentInitialized`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.GAMEPLAY.ComponentInitialized", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.GAMEPLAY.ComponentInitialized`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.GAMEPLAY.ComponentInitialized", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.GAMEPLAY.ComponentInitialized", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.GAMEPLAY.ComponentInitialized", |payload| {
if let Some(method) = payload.get("method") {
println!("[GAMEPLAY] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.GAMEPLAY.ComponentInitialized", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[GAMEPLAY] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.GAMEPLAY.ComponentInitialized", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.GAMEPLAY.ComponentInitialized", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[GAMEPLAY] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.GAMEPLAY.ComponentInitialized` as the canonical routing key end-to-end.
docs/02_development/hooks-library/gameplay/greg-gameplay-createappobjective.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.GAMEPLAY.CreateAppObjective
sidebar_label: greg.GAMEPLAY.CreateAppObjective
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Objectives.CreateAppObjective"
---
# `greg.GAMEPLAY.CreateAppObjective`
## Description
- Auto-generated from Il2Cpp unpack: Objectives.CreateAppObjective
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Objectives::CreateAppObjective(int, int, int, int)` | Postfix | Auto-generated from Il2Cpp unpack: Objectives.CreateAppObjective |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.GAMEPLAY.CreateAppObjective`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.GAMEPLAY.CreateAppObjective", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.GAMEPLAY.CreateAppObjective`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.GAMEPLAY.CreateAppObjective", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.GAMEPLAY.CreateAppObjective", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.GAMEPLAY.CreateAppObjective", |payload| {
if let Some(method) = payload.get("method") {
println!("[GAMEPLAY] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.GAMEPLAY.CreateAppObjective", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[GAMEPLAY] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.GAMEPLAY.CreateAppObjective", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.GAMEPLAY.CreateAppObjective", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[GAMEPLAY] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.GAMEPLAY.CreateAppObjective` as the canonical routing key end-to-end.
docs/02_development/hooks-library/gameplay/greg-gameplay-createnewobjective.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.GAMEPLAY.CreateNewObjective
sidebar_label: greg.GAMEPLAY.CreateNewObjective
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Objectives.CreateNewObjective"
---
# `greg.GAMEPLAY.CreateNewObjective`
## Description
- Auto-generated from Il2Cpp unpack: Objectives.CreateNewObjective
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Objectives::CreateNewObjective(int, int, Vector3, int, int, bool)` | Postfix | Auto-generated from Il2Cpp unpack: Objectives.CreateNewObjective |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.GAMEPLAY.CreateNewObjective`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.GAMEPLAY.CreateNewObjective", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.GAMEPLAY.CreateNewObjective`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.GAMEPLAY.CreateNewObjective", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.GAMEPLAY.CreateNewObjective", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.GAMEPLAY.CreateNewObjective", |payload| {
if let Some(method) = payload.get("method") {
println!("[GAMEPLAY] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.GAMEPLAY.CreateNewObjective", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[GAMEPLAY] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.GAMEPLAY.CreateNewObjective", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.GAMEPLAY.CreateNewObjective", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[GAMEPLAY] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.GAMEPLAY.CreateNewObjective` as the canonical routing key end-to-end.
docs/02_development/hooks-library/gameplay/greg-gameplay-destroyobjective.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.GAMEPLAY.DestroyObjective
sidebar_label: greg.GAMEPLAY.DestroyObjective
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Objectives.DestroyObjective"
---
# `greg.GAMEPLAY.DestroyObjective`
## Description
- Auto-generated from Il2Cpp unpack: Objectives.DestroyObjective
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Objectives::DestroyObjective(int)` | Postfix | Auto-generated from Il2Cpp unpack: Objectives.DestroyObjective |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.GAMEPLAY.DestroyObjective`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.GAMEPLAY.DestroyObjective", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.GAMEPLAY.DestroyObjective`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.GAMEPLAY.DestroyObjective", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.GAMEPLAY.DestroyObjective", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.GAMEPLAY.DestroyObjective", |payload| {
if let Some(method) = payload.get("method") {
println!("[GAMEPLAY] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.GAMEPLAY.DestroyObjective", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[GAMEPLAY] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.GAMEPLAY.DestroyObjective", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.GAMEPLAY.DestroyObjective", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[GAMEPLAY] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.GAMEPLAY.DestroyObjective` as the canonical routing key end-to-end.
docs/02_development/hooks-library/gameplay/greg-gameplay-gettimedobjective.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.GAMEPLAY.GetTimedObjective
sidebar_label: greg.GAMEPLAY.GetTimedObjective
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Objectives.GetTimedObjective"
---
# `greg.GAMEPLAY.GetTimedObjective`
## Description
- Auto-generated from Il2Cpp unpack: Objectives.GetTimedObjective
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Objectives::GetTimedObjective(int)` | Postfix | Auto-generated from Il2Cpp unpack: Objectives.GetTimedObjective |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.GAMEPLAY.GetTimedObjective`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.GAMEPLAY.GetTimedObjective", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.GAMEPLAY.GetTimedObjective`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.GAMEPLAY.GetTimedObjective", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.GAMEPLAY.GetTimedObjective", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.GAMEPLAY.GetTimedObjective", |payload| {
if let Some(method) = payload.get("method") {
println!("[GAMEPLAY] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.GAMEPLAY.GetTimedObjective", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[GAMEPLAY] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.GAMEPLAY.GetTimedObjective", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.GAMEPLAY.GetTimedObjective", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[GAMEPLAY] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.GAMEPLAY.GetTimedObjective` as the canonical routing key end-to-end.
docs/02_development/hooks-library/gameplay/greg-gameplay-instantiateobjectivesign.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.GAMEPLAY.InstantiateObjectiveSign
sidebar_label: greg.GAMEPLAY.InstantiateObjectiveSign
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Objectives.InstantiateObjectiveSign"
---
# `greg.GAMEPLAY.InstantiateObjectiveSign`
## Description
- Auto-generated from Il2Cpp unpack: Objectives.InstantiateObjectiveSign
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Objectives::InstantiateObjectiveSign(int, Vector3)` | Postfix | Auto-generated from Il2Cpp unpack: Objectives.InstantiateObjectiveSign |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.GAMEPLAY.InstantiateObjectiveSign`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.GAMEPLAY.InstantiateObjectiveSign", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.GAMEPLAY.InstantiateObjectiveSign`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.GAMEPLAY.InstantiateObjectiveSign", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.GAMEPLAY.InstantiateObjectiveSign", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.GAMEPLAY.InstantiateObjectiveSign", |payload| {
if let Some(method) = payload.get("method") {
println!("[GAMEPLAY] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.GAMEPLAY.InstantiateObjectiveSign", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[GAMEPLAY] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.GAMEPLAY.InstantiateObjectiveSign", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.GAMEPLAY.InstantiateObjectiveSign", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[GAMEPLAY] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.GAMEPLAY.InstantiateObjectiveSign` as the canonical routing key end-to-end.
docs/02_development/hooks-library/gameplay/greg-gameplay-istutorialinprogress.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.GAMEPLAY.IsTutorialInProgress
sidebar_label: greg.GAMEPLAY.IsTutorialInProgress
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Objectives.IsTutorialInProgress"
---
# `greg.GAMEPLAY.IsTutorialInProgress`
## Description
- Auto-generated from Il2Cpp unpack: Objectives.IsTutorialInProgress
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Objectives::IsTutorialInProgress()` | Postfix | Auto-generated from Il2Cpp unpack: Objectives.IsTutorialInProgress |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.GAMEPLAY.IsTutorialInProgress`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.GAMEPLAY.IsTutorialInProgress", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.GAMEPLAY.IsTutorialInProgress`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.GAMEPLAY.IsTutorialInProgress", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.GAMEPLAY.IsTutorialInProgress", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.GAMEPLAY.IsTutorialInProgress", |payload| {
if let Some(method) = payload.get("method") {
println!("[GAMEPLAY] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.GAMEPLAY.IsTutorialInProgress", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[GAMEPLAY] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.GAMEPLAY.IsTutorialInProgress", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.GAMEPLAY.IsTutorialInProgress", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[GAMEPLAY] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.GAMEPLAY.IsTutorialInProgress` as the canonical routing key end-to-end.
docs/02_development/hooks-library/gameplay/greg-gameplay-objectivesignremoved.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.GAMEPLAY.ObjectiveSignRemoved
sidebar_label: greg.GAMEPLAY.ObjectiveSignRemoved
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Objectives.RemoveObjectiveSign"
---
# `greg.GAMEPLAY.ObjectiveSignRemoved`
## Description
- Auto-generated from Il2Cpp unpack: Objectives.RemoveObjectiveSign
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Objectives::RemoveObjectiveSign(int)` | Postfix | Auto-generated from Il2Cpp unpack: Objectives.RemoveObjectiveSign |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.GAMEPLAY.ObjectiveSignRemoved`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.GAMEPLAY.ObjectiveSignRemoved", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.GAMEPLAY.ObjectiveSignRemoved`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.GAMEPLAY.ObjectiveSignRemoved", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.GAMEPLAY.ObjectiveSignRemoved", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.GAMEPLAY.ObjectiveSignRemoved", |payload| {
if let Some(method) = payload.get("method") {
println!("[GAMEPLAY] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.GAMEPLAY.ObjectiveSignRemoved", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[GAMEPLAY] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.GAMEPLAY.ObjectiveSignRemoved", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.GAMEPLAY.ObjectiveSignRemoved", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[GAMEPLAY] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.GAMEPLAY.ObjectiveSignRemoved` as the canonical routing key end-to-end.
docs/02_development/hooks-library/gameplay/greg-gameplay-objectivetimedtext.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.GAMEPLAY.ObjectiveTimedText
sidebar_label: greg.GAMEPLAY.ObjectiveTimedText
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Objectives.ObjectiveTimedText"
---
# `greg.GAMEPLAY.ObjectiveTimedText`
## Description
- Auto-generated from Il2Cpp unpack: Objectives.ObjectiveTimedText
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Objectives::ObjectiveTimedText()` | Postfix | Auto-generated from Il2Cpp unpack: Objectives.ObjectiveTimedText |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.GAMEPLAY.ObjectiveTimedText`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.GAMEPLAY.ObjectiveTimedText", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.GAMEPLAY.ObjectiveTimedText`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.GAMEPLAY.ObjectiveTimedText", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.GAMEPLAY.ObjectiveTimedText", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.GAMEPLAY.ObjectiveTimedText", |payload| {
if let Some(method) = payload.get("method") {
println!("[GAMEPLAY] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.GAMEPLAY.ObjectiveTimedText", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[GAMEPLAY] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.GAMEPLAY.ObjectiveTimedText", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.GAMEPLAY.ObjectiveTimedText", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[GAMEPLAY] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.GAMEPLAY.ObjectiveTimedText` as the canonical routing key end-to-end.
docs/02_development/hooks-library/gameplay/greg-gameplay-ondestroy.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.GAMEPLAY.OnDestroy
sidebar_label: greg.GAMEPLAY.OnDestroy
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Objectives.OnDestroy"
---
# `greg.GAMEPLAY.OnDestroy`
## Description
- Auto-generated from Il2Cpp unpack: Objectives.OnDestroy
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Objectives::OnDestroy()` | Postfix | Auto-generated from Il2Cpp unpack: Objectives.OnDestroy |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.GAMEPLAY.OnDestroy`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.GAMEPLAY.OnDestroy", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.GAMEPLAY.OnDestroy`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.GAMEPLAY.OnDestroy", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.GAMEPLAY.OnDestroy", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.GAMEPLAY.OnDestroy", |payload| {
if let Some(method) = payload.get("method") {
println!("[GAMEPLAY] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.GAMEPLAY.OnDestroy", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[GAMEPLAY] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.GAMEPLAY.OnDestroy", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.GAMEPLAY.OnDestroy", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[GAMEPLAY] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.GAMEPLAY.OnDestroy` as the canonical routing key end-to-end.
docs/02_development/hooks-library/gameplay/greg-gameplay-onload.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.GAMEPLAY.OnLoad
sidebar_label: greg.GAMEPLAY.OnLoad
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Objectives.OnLoad"
---
# `greg.GAMEPLAY.OnLoad`
## Description
- Auto-generated from Il2Cpp unpack: Objectives.OnLoad
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Objectives::OnLoad()` | Postfix | Auto-generated from Il2Cpp unpack: Objectives.OnLoad |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.GAMEPLAY.OnLoad`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.GAMEPLAY.OnLoad", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.GAMEPLAY.OnLoad`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.GAMEPLAY.OnLoad", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.GAMEPLAY.OnLoad", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.GAMEPLAY.OnLoad", |payload| {
if let Some(method) = payload.get("method") {
println!("[GAMEPLAY] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.GAMEPLAY.OnLoad", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[GAMEPLAY] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.GAMEPLAY.OnLoad", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.GAMEPLAY.OnLoad", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[GAMEPLAY] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.GAMEPLAY.OnLoad` as the canonical routing key end-to-end.
docs/02_development/hooks-library/gameplay/greg-gameplay-startobjective.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.GAMEPLAY.StartObjective
sidebar_label: greg.GAMEPLAY.StartObjective
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: Objectives.StartObjective"
---
# `greg.GAMEPLAY.StartObjective`
## Description
- Auto-generated from Il2Cpp unpack: Objectives.StartObjective
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.Objectives::StartObjective(int, Vector3, bool)` | Postfix | Auto-generated from Il2Cpp unpack: Objectives.StartObjective |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.GAMEPLAY.StartObjective`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.GAMEPLAY.StartObjective", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.GAMEPLAY.StartObjective`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.GAMEPLAY.StartObjective", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.GAMEPLAY.StartObjective", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.GAMEPLAY.StartObjective", |payload| {
if let Some(method) = payload.get("method") {
println!("[GAMEPLAY] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.GAMEPLAY.StartObjective", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[GAMEPLAY] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.GAMEPLAY.StartObjective", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.GAMEPLAY.StartObjective", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[GAMEPLAY] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.GAMEPLAY.StartObjective` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/_category_.json
-7
View File
@@ -1,7 +0,0 @@
{
"label": "NETWORK hooks",
"position": 1,
"collapsible": true,
"collapsed": true
}
docs/02_development/hooks-library/network/greg-network-assignnewposition.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.AssignNewPosition
sidebar_label: greg.NETWORK.AssignNewPosition
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CablePositions.AssignNewPosition"
---
# `greg.NETWORK.AssignNewPosition`
## Description
- Auto-generated from Il2Cpp unpack: CablePositions.AssignNewPosition
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CablePositions::AssignNewPosition(int, Transform, bool, bool, CableLink.TypeOfLink, string)` | Postfix | Auto-generated from Il2Cpp unpack: CablePositions.AssignNewPosition |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.AssignNewPosition`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.AssignNewPosition", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.AssignNewPosition`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.AssignNewPosition", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.AssignNewPosition", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.AssignNewPosition", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.AssignNewPosition", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.AssignNewPosition", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.AssignNewPosition", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.AssignNewPosition` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-brokenserveradded.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.BrokenServerAdded
sidebar_label: greg.NETWORK.BrokenServerAdded
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkMap.AddBrokenServer"
---
# `greg.NETWORK.BrokenServerAdded`
## Description
- Auto-generated from Il2Cpp unpack: NetworkMap.AddBrokenServer
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkMap::AddBrokenServer(Server)` | Postfix | Auto-generated from Il2Cpp unpack: NetworkMap.AddBrokenServer |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.BrokenServerAdded`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.BrokenServerAdded", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.BrokenServerAdded`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.BrokenServerAdded", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.BrokenServerAdded", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.BrokenServerAdded", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.BrokenServerAdded", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.BrokenServerAdded", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.BrokenServerAdded", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.BrokenServerAdded` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-brokenserverremoved.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.BrokenServerRemoved
sidebar_label: greg.NETWORK.BrokenServerRemoved
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkMap.RemoveBrokenServer"
---
# `greg.NETWORK.BrokenServerRemoved`
## Description
- Auto-generated from Il2Cpp unpack: NetworkMap.RemoveBrokenServer
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkMap::RemoveBrokenServer(string)` | Postfix | Auto-generated from Il2Cpp unpack: NetworkMap.RemoveBrokenServer |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.BrokenServerRemoved`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.BrokenServerRemoved", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.BrokenServerRemoved`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.BrokenServerRemoved", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.BrokenServerRemoved", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.BrokenServerRemoved", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.BrokenServerRemoved", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.BrokenServerRemoved", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.BrokenServerRemoved", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.BrokenServerRemoved` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-buttonshownetworkswitchconfig.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.ButtonShowNetworkSwitchConfig
sidebar_label: greg.NETWORK.ButtonShowNetworkSwitchConfig
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkSwitch.ButtonShowNetworkSwitchConfig"
---
# `greg.NETWORK.ButtonShowNetworkSwitchConfig`
## Description
- Auto-generated from Il2Cpp unpack: NetworkSwitch.ButtonShowNetworkSwitchConfig
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkSwitch::ButtonShowNetworkSwitchConfig()` | Postfix | Auto-generated from Il2Cpp unpack: NetworkSwitch.ButtonShowNetworkSwitchConfig |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.ButtonShowNetworkSwitchConfig`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.ButtonShowNetworkSwitchConfig", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.ButtonShowNetworkSwitchConfig`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.ButtonShowNetworkSwitchConfig", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.ButtonShowNetworkSwitchConfig", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.ButtonShowNetworkSwitchConfig", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.ButtonShowNetworkSwitchConfig", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.ButtonShowNetworkSwitchConfig", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.ButtonShowNetworkSwitchConfig", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.ButtonShowNetworkSwitchConfig` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-cableconnectionremoved.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.CableConnectionRemoved
sidebar_label: greg.NETWORK.CableConnectionRemoved
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkMap.RemoveCableConnection"
---
# `greg.NETWORK.CableConnectionRemoved`
## Description
- Auto-generated from Il2Cpp unpack: NetworkMap.RemoveCableConnection
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkMap::RemoveCableConnection(int)` | Postfix | Auto-generated from Il2Cpp unpack: NetworkMap.RemoveCableConnection |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.CableConnectionRemoved`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.CableConnectionRemoved", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.CableConnectionRemoved`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.CableConnectionRemoved", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.CableConnectionRemoved", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.CableConnectionRemoved", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.CableConnectionRemoved", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.CableConnectionRemoved", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.CableConnectionRemoved", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.CableConnectionRemoved` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-cablefromlacpgroupsremoved.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.CableFromLACPGroupsRemoved
sidebar_label: greg.NETWORK.CableFromLACPGroupsRemoved
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkMap.RemoveCableFromLACPGroups"
---
# `greg.NETWORK.CableFromLACPGroupsRemoved`
## Description
- Auto-generated from Il2Cpp unpack: NetworkMap.RemoveCableFromLACPGroups
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkMap::RemoveCableFromLACPGroups(int)` | Postfix | Auto-generated from Il2Cpp unpack: NetworkMap.RemoveCableFromLACPGroups |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.CableFromLACPGroupsRemoved`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.CableFromLACPGroupsRemoved", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.CableFromLACPGroupsRemoved`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.CableFromLACPGroupsRemoved", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.CableFromLACPGroupsRemoved", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.CableFromLACPGroupsRemoved", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.CableFromLACPGroupsRemoved", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.CableFromLACPGroupsRemoved", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.CableFromLACPGroupsRemoved", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.CableFromLACPGroupsRemoved` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-cableloaded.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.CableLoaded
sidebar_label: greg.NETWORK.CableLoaded
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CablePositions.LoadCable"
---
# `greg.NETWORK.CableLoaded`
## Description
- Auto-generated from Il2Cpp unpack: CablePositions.LoadCable
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CablePositions::LoadCable(CableSaveData)` | Postfix | Auto-generated from Il2Cpp unpack: CablePositions.LoadCable |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.CableLoaded`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.CableLoaded", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.CableLoaded`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.CableLoaded", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.CableLoaded", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.CableLoaded", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.CableLoaded", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.CableLoaded", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.CableLoaded", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.CableLoaded` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-canacceptsfp.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.CanAcceptSFP
sidebar_label: greg.NETWORK.CanAcceptSFP
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: SFPBox.CanAcceptSFP"
---
# `greg.NETWORK.CanAcceptSFP`
## Description
- Auto-generated from Il2Cpp unpack: SFPBox.CanAcceptSFP
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.SFPBox::CanAcceptSFP(int)` | Postfix | Auto-generated from Il2Cpp unpack: SFPBox.CanAcceptSFP |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.CanAcceptSFP`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.CanAcceptSFP", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.CanAcceptSFP`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.CanAcceptSFP", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.CanAcceptSFP", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.CanAcceptSFP", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.CanAcceptSFP", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.CanAcceptSFP", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.CanAcceptSFP", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.CanAcceptSFP` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-clearerrorsign.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.ClearErrorSign
sidebar_label: greg.NETWORK.ClearErrorSign
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkSwitch.ClearErrorSign"
---
# `greg.NETWORK.ClearErrorSign`
## Description
- Auto-generated from Il2Cpp unpack: NetworkSwitch.ClearErrorSign
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkSwitch::ClearErrorSign()` | Postfix | Auto-generated from Il2Cpp unpack: NetworkSwitch.ClearErrorSign |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.ClearErrorSign`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.ClearErrorSign", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.ClearErrorSign`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.ClearErrorSign", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.ClearErrorSign", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.ClearErrorSign", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.ClearErrorSign", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.ClearErrorSign", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.ClearErrorSign", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.ClearErrorSign` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-clearmap.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.ClearMap
sidebar_label: greg.NETWORK.ClearMap
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkMap.ClearMap"
---
# `greg.NETWORK.ClearMap`
## Description
- Auto-generated from Il2Cpp unpack: NetworkMap.ClearMap
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkMap::ClearMap()` | Postfix | Auto-generated from Il2Cpp unpack: NetworkMap.ClearMap |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.ClearMap`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.ClearMap", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.ClearMap`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.ClearMap", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.ClearMap", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.ClearMap", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.ClearMap", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.ClearMap", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.ClearMap", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.ClearMap` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-clearwarningsign.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.ClearWarningSign
sidebar_label: greg.NETWORK.ClearWarningSign
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkSwitch.ClearWarningSign"
---
# `greg.NETWORK.ClearWarningSign`
## Description
- Auto-generated from Il2Cpp unpack: NetworkSwitch.ClearWarningSign
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkSwitch::ClearWarningSign(bool)` | Postfix | Auto-generated from Il2Cpp unpack: NetworkSwitch.ClearWarningSign |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.ClearWarningSign`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.ClearWarningSign", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.ClearWarningSign`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.ClearWarningSign", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.ClearWarningSign", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.ClearWarningSign", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.ClearWarningSign", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.ClearWarningSign", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.ClearWarningSign", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.ClearWarningSign` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-componentinitialized.md
-135
View File
@@ -1,135 +0,0 @@
---
title: greg.NETWORK.ComponentInitialized
sidebar_label: greg.NETWORK.ComponentInitialized
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CableLink.Start"
---
# `greg.NETWORK.ComponentInitialized`
## Description
- Auto-generated from Il2Cpp unpack: CableLink.Start
- Auto-generated from Il2Cpp unpack: CablePositions.Awake
- Auto-generated from Il2Cpp unpack: CablePositions.Start
- Auto-generated from Il2Cpp unpack: NetworkMap.Awake
- Auto-generated from Il2Cpp unpack: NetworkSwitch.Awake
- Auto-generated from Il2Cpp unpack: NetworkSwitch.Start
- Auto-generated from Il2Cpp unpack: SFPBox.Awake
- Auto-generated from Il2Cpp unpack: SFPModule.Awake
## Patch Targets (Il2Cpp)
This hook name can be mapped to **8** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CableLink::Start()` | Postfix | Auto-generated from Il2Cpp unpack: CableLink.Start |
| `Il2Cpp.CablePositions::Awake()` | Postfix | Auto-generated from Il2Cpp unpack: CablePositions.Awake |
| `Il2Cpp.CablePositions::Start()` | Postfix | Auto-generated from Il2Cpp unpack: CablePositions.Start |
| `Il2Cpp.NetworkMap::Awake()` | Postfix | Auto-generated from Il2Cpp unpack: NetworkMap.Awake |
| `Il2Cpp.NetworkSwitch::Awake()` | Postfix | Auto-generated from Il2Cpp unpack: NetworkSwitch.Awake |
| `Il2Cpp.NetworkSwitch::Start()` | Postfix | Auto-generated from Il2Cpp unpack: NetworkSwitch.Start |
| `Il2Cpp.SFPBox::Awake()` | Postfix | Auto-generated from Il2Cpp unpack: SFPBox.Awake |
| `Il2Cpp.SFPModule::Awake()` | Postfix | Auto-generated from Il2Cpp unpack: SFPModule.Awake |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.ComponentInitialized`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.ComponentInitialized", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.ComponentInitialized`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.ComponentInitialized", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.ComponentInitialized", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.ComponentInitialized", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.ComponentInitialized", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.ComponentInitialized", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.ComponentInitialized", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.ComponentInitialized` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-connect.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.Connect
sidebar_label: greg.NETWORK.Connect
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkMap.Connect"
---
# `greg.NETWORK.Connect`
## Description
- Auto-generated from Il2Cpp unpack: NetworkMap.Connect
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkMap::Connect(string, string)` | Postfix | Auto-generated from Il2Cpp unpack: NetworkMap.Connect |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.Connect`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.Connect", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.Connect`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.Connect", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.Connect", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.Connect", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.Connect", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.Connect", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.Connect", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.Connect` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-createlacpgroup.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.CreateLACPGroup
sidebar_label: greg.NETWORK.CreateLACPGroup
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkMap.CreateLACPGroup"
---
# `greg.NETWORK.CreateLACPGroup`
## Description
- Auto-generated from Il2Cpp unpack: NetworkMap.CreateLACPGroup
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkMap::CreateLACPGroup(string, string, List<int>)` | Postfix | Auto-generated from Il2Cpp unpack: NetworkMap.CreateLACPGroup |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.CreateLACPGroup`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.CreateLACPGroup", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.CreateLACPGroup`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.CreateLACPGroup", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.CreateLACPGroup", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.CreateLACPGroup", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.CreateLACPGroup", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.CreateLACPGroup", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.CreateLACPGroup", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.CreateLACPGroup` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-createnewreversecable.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.CreateNewReverseCable
sidebar_label: greg.NETWORK.CreateNewReverseCable
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CablePositions.CreateNewReverseCable"
---
# `greg.NETWORK.CreateNewReverseCable`
## Description
- Auto-generated from Il2Cpp unpack: CablePositions.CreateNewReverseCable
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CablePositions::CreateNewReverseCable()` | Postfix | Auto-generated from Il2Cpp unpack: CablePositions.CreateNewReverseCable |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.CreateNewReverseCable`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.CreateNewReverseCable", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.CreateNewReverseCable`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.CreateNewReverseCable", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.CreateNewReverseCable", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.CreateNewReverseCable", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.CreateNewReverseCable", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.CreateNewReverseCable", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.CreateNewReverseCable", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.CreateNewReverseCable` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-createropeattachpoint.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.CreateRopeAttachPoint
sidebar_label: greg.NETWORK.CreateRopeAttachPoint
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CableLink.CreateRopeAttachPoint"
---
# `greg.NETWORK.CreateRopeAttachPoint`
## Description
- Auto-generated from Il2Cpp unpack: CableLink.CreateRopeAttachPoint
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CableLink::CreateRopeAttachPoint()` | Postfix | Auto-generated from Il2Cpp unpack: CableLink.CreateRopeAttachPoint |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.CreateRopeAttachPoint`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.CreateRopeAttachPoint", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.CreateRopeAttachPoint`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.CreateRopeAttachPoint", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.CreateRopeAttachPoint", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.CreateRopeAttachPoint", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.CreateRopeAttachPoint", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.CreateRopeAttachPoint", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.CreateRopeAttachPoint", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.CreateRopeAttachPoint` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-createtubemesh.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.CreateTubeMesh
sidebar_label: greg.NETWORK.CreateTubeMesh
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CablePositions.CreateTubeMesh"
---
# `greg.NETWORK.CreateTubeMesh`
## Description
- Auto-generated from Il2Cpp unpack: CablePositions.CreateTubeMesh
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CablePositions::CreateTubeMesh(List<Vector3>)` | Postfix | Auto-generated from Il2Cpp unpack: CablePositions.CreateTubeMesh |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.CreateTubeMesh`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.CreateTubeMesh", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.CreateTubeMesh`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.CreateTubeMesh", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.CreateTubeMesh", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.CreateTubeMesh", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.CreateTubeMesh", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.CreateTubeMesh", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.CreateTubeMesh", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.CreateTubeMesh` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-customerservercountandspeedchanged.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.CustomerServerCountAndSpeedChanged
sidebar_label: greg.NETWORK.CustomerServerCountAndSpeedChanged
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkMap.UpdateCustomerServerCountAndSpeed"
---
# `greg.NETWORK.CustomerServerCountAndSpeedChanged`
## Description
- Auto-generated from Il2Cpp unpack: NetworkMap.UpdateCustomerServerCountAndSpeed
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkMap::UpdateCustomerServerCountAndSpeed(int, int, float)` | Postfix | Auto-generated from Il2Cpp unpack: NetworkMap.UpdateCustomerServerCountAndSpeed |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.CustomerServerCountAndSpeedChanged`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.CustomerServerCountAndSpeedChanged", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.CustomerServerCountAndSpeedChanged`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.CustomerServerCountAndSpeedChanged", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.CustomerServerCountAndSpeedChanged", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.CustomerServerCountAndSpeedChanged", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.CustomerServerCountAndSpeedChanged", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.CustomerServerCountAndSpeedChanged", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.CustomerServerCountAndSpeedChanged", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.CustomerServerCountAndSpeedChanged` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-deviceadded.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.DeviceAdded
sidebar_label: greg.NETWORK.DeviceAdded
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkMap.AddDevice"
---
# `greg.NETWORK.DeviceAdded`
## Description
- Auto-generated from Il2Cpp unpack: NetworkMap.AddDevice
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkMap::AddDevice(string, CableLink.TypeOfLink, int)` | Postfix | Auto-generated from Il2Cpp unpack: NetworkMap.AddDevice |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.DeviceAdded`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.DeviceAdded", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.DeviceAdded`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.DeviceAdded", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.DeviceAdded", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.DeviceAdded", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.DeviceAdded", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.DeviceAdded", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.DeviceAdded", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.DeviceAdded` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-devicecustomeridchanged.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.DeviceCustomerIDChanged
sidebar_label: greg.NETWORK.DeviceCustomerIDChanged
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkMap.UpdateDeviceCustomerID"
---
# `greg.NETWORK.DeviceCustomerIDChanged`
## Description
- Auto-generated from Il2Cpp unpack: NetworkMap.UpdateDeviceCustomerID
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkMap::UpdateDeviceCustomerID(string, int)` | Postfix | Auto-generated from Il2Cpp unpack: NetworkMap.UpdateDeviceCustomerID |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.DeviceCustomerIDChanged`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.DeviceCustomerIDChanged", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.DeviceCustomerIDChanged`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.DeviceCustomerIDChanged", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.DeviceCustomerIDChanged", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.DeviceCustomerIDChanged", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.DeviceCustomerIDChanged", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.DeviceCustomerIDChanged", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.DeviceCustomerIDChanged", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.DeviceCustomerIDChanged` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-deviceremoved.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.DeviceRemoved
sidebar_label: greg.NETWORK.DeviceRemoved
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkMap.RemoveDevice"
---
# `greg.NETWORK.DeviceRemoved`
## Description
- Auto-generated from Il2Cpp unpack: NetworkMap.RemoveDevice
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkMap::RemoveDevice(string)` | Postfix | Auto-generated from Il2Cpp unpack: NetworkMap.RemoveDevice |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.DeviceRemoved`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.DeviceRemoved", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.DeviceRemoved`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.DeviceRemoved", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.DeviceRemoved", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.DeviceRemoved", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.DeviceRemoved", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.DeviceRemoved", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.DeviceRemoved", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.DeviceRemoved` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-devicerepaired.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.DeviceRepaired
sidebar_label: greg.NETWORK.DeviceRepaired
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkSwitch.RepairDevice"
---
# `greg.NETWORK.DeviceRepaired`
## Description
- Auto-generated from Il2Cpp unpack: NetworkSwitch.RepairDevice
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkSwitch::RepairDevice()` | Postfix | Auto-generated from Il2Cpp unpack: NetworkSwitch.RepairDevice |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.DeviceRepaired`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.DeviceRepaired", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.DeviceRepaired`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.DeviceRepaired", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.DeviceRepaired", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.DeviceRepaired", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.DeviceRepaired", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.DeviceRepaired", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.DeviceRepaired", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.DeviceRepaired` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-disconnect.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.Disconnect
sidebar_label: greg.NETWORK.Disconnect
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkMap.Disconnect"
---
# `greg.NETWORK.Disconnect`
## Description
- Auto-generated from Il2Cpp unpack: NetworkMap.Disconnect
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkMap::Disconnect(string, string)` | Postfix | Auto-generated from Il2Cpp unpack: NetworkMap.Disconnect |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.Disconnect`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.Disconnect", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.Disconnect`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.Disconnect", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.Disconnect", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.Disconnect", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.Disconnect", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.Disconnect", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.Disconnect", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.Disconnect` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-disconnectcables.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.DisconnectCables
sidebar_label: greg.NETWORK.DisconnectCables
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkSwitch.DisconnectCables"
---
# `greg.NETWORK.DisconnectCables`
## Description
- Auto-generated from Il2Cpp unpack: NetworkSwitch.DisconnectCables
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkSwitch::DisconnectCables()` | Postfix | Auto-generated from Il2Cpp unpack: NetworkSwitch.DisconnectCables |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.DisconnectCables`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.DisconnectCables", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.DisconnectCables`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.DisconnectCables", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.DisconnectCables", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.DisconnectCables", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.DisconnectCables", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.DisconnectCables", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.DisconnectCables", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.DisconnectCables` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-disconnectcableswhenswitchisoff.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.DisconnectCablesWhenSwitchIsOff
sidebar_label: greg.NETWORK.DisconnectCablesWhenSwitchIsOff
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkSwitch.DisconnectCablesWhenSwitchIsOff"
---
# `greg.NETWORK.DisconnectCablesWhenSwitchIsOff`
## Description
- Auto-generated from Il2Cpp unpack: NetworkSwitch.DisconnectCablesWhenSwitchIsOff
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkSwitch::DisconnectCablesWhenSwitchIsOff()` | Postfix | Auto-generated from Il2Cpp unpack: NetworkSwitch.DisconnectCablesWhenSwitchIsOff |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.DisconnectCablesWhenSwitchIsOff`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.DisconnectCablesWhenSwitchIsOff", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.DisconnectCablesWhenSwitchIsOff`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.DisconnectCablesWhenSwitchIsOff", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.DisconnectCablesWhenSwitchIsOff", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.DisconnectCablesWhenSwitchIsOff", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.DisconnectCablesWhenSwitchIsOff", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.DisconnectCablesWhenSwitchIsOff", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.DisconnectCablesWhenSwitchIsOff", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.DisconnectCablesWhenSwitchIsOff` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-findallroutes.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.FindAllRoutes
sidebar_label: greg.NETWORK.FindAllRoutes
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkMap.FindAllRoutes"
---
# `greg.NETWORK.FindAllRoutes`
## Description
- Auto-generated from Il2Cpp unpack: NetworkMap.FindAllRoutes
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkMap::FindAllRoutes(string, string)` | Postfix | Auto-generated from Il2Cpp unpack: NetworkMap.FindAllRoutes |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.FindAllRoutes`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.FindAllRoutes", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.FindAllRoutes`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.FindAllRoutes", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.FindAllRoutes", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.FindAllRoutes", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.FindAllRoutes", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.FindAllRoutes", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.FindAllRoutes", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.FindAllRoutes` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-findphysicalpath.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.FindPhysicalPath
sidebar_label: greg.NETWORK.FindPhysicalPath
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkMap.FindPhysicalPath"
---
# `greg.NETWORK.FindPhysicalPath`
## Description
- Auto-generated from Il2Cpp unpack: NetworkMap.FindPhysicalPath
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkMap::FindPhysicalPath(string, string)` | Postfix | Auto-generated from Il2Cpp unpack: NetworkMap.FindPhysicalPath |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.FindPhysicalPath`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.FindPhysicalPath", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.FindPhysicalPath`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.FindPhysicalPath", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.FindPhysicalPath", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.FindPhysicalPath", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.FindPhysicalPath", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.FindPhysicalPath", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.FindPhysicalPath", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.FindPhysicalPath` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-fromportremoved.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.FromPortRemoved
sidebar_label: greg.NETWORK.FromPortRemoved
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: SFPModule.RemoveFromPort"
---
# `greg.NETWORK.FromPortRemoved`
## Description
- Auto-generated from Il2Cpp unpack: SFPModule.RemoveFromPort
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.SFPModule::RemoveFromPort()` | Postfix | Auto-generated from Il2Cpp unpack: SFPModule.RemoveFromPort |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.FromPortRemoved`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.FromPortRemoved", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.FromPortRemoved`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.FromPortRemoved", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.FromPortRemoved", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.FromPortRemoved", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.FromPortRemoved", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.FromPortRemoved", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.FromPortRemoved", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.FromPortRemoved` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-generatebentsegment.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.GenerateBentSegment
sidebar_label: greg.NETWORK.GenerateBentSegment
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CablePositions.GenerateBentSegment"
---
# `greg.NETWORK.GenerateBentSegment`
## Description
- Auto-generated from Il2Cpp unpack: CablePositions.GenerateBentSegment
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CablePositions::GenerateBentSegment(Vector3, Vector3, Transform, bool)` | Postfix | Auto-generated from Il2Cpp unpack: CablePositions.GenerateBentSegment |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.GenerateBentSegment`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.GenerateBentSegment", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.GenerateBentSegment`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.GenerateBentSegment", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.GenerateBentSegment", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.GenerateBentSegment", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.GenerateBentSegment", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.GenerateBentSegment", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.GenerateBentSegment", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.GenerateBentSegment` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-generatecornerbend.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.GenerateCornerBend
sidebar_label: greg.NETWORK.GenerateCornerBend
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: CablePositions.GenerateCornerBend"
---
# `greg.NETWORK.GenerateCornerBend`
## Description
- Auto-generated from Il2Cpp unpack: CablePositions.GenerateCornerBend
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.CablePositions::GenerateCornerBend(Vector3, Vector3, Vector3, Transform)` | Postfix | Auto-generated from Il2Cpp unpack: CablePositions.GenerateCornerBend |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.GenerateCornerBend`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.GenerateCornerBend", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.GenerateCornerBend`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.GenerateCornerBend", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.GenerateCornerBend", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.GenerateCornerBend", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.GenerateCornerBend", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.GenerateCornerBend", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.GenerateCornerBend", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.GenerateCornerBend` as the canonical routing key end-to-end.
docs/02_development/hooks-library/network/greg-network-generatedevicename.md
-121
View File
@@ -1,121 +0,0 @@
---
title: greg.NETWORK.GenerateDeviceName
sidebar_label: greg.NETWORK.GenerateDeviceName
description: "gregCore Hook — Auto-generated from Il2Cpp unpack: NetworkMap.GenerateDeviceName"
---
# `greg.NETWORK.GenerateDeviceName`
## Description
- Auto-generated from Il2Cpp unpack: NetworkMap.GenerateDeviceName
## Patch Targets (Il2Cpp)
This hook name can be mapped to **1** Harmony target(s):
| Patch Target | Strategy | Description |
|------------|-----------|--------------|
| `Il2Cpp.NetworkMap::GenerateDeviceName(CableLink.TypeOfLink, Vector3)` | Postfix | Auto-generated from Il2Cpp unpack: NetworkMap.GenerateDeviceName |
**Strategy:** Postfix — The catalog says **Postfix** → typically use `HookBinder.OnAfter(...)`.
## Payload Schema (from Registry)
| Field | Type / Note |
|------|----------------|
| `method` | `string` |
## How to use this hook
### 1. Harmony Pipeline: `HookBinder` (Main path for `greg_hooks.json`)
The framework code patches Il2Cpp methods and calls `HookBinder.DispatchBefore` / `DispatchAfter`. You register handlers with the **exact** string `greg.NETWORK.GenerateDeviceName`:
```csharp
using GregFramework.Hooks;
// For Postfix strategy (common):
HookBinder.OnAfter("greg.NETWORK.GenerateDeviceName", ctx =>
{
// ctx.HookName, ctx.Method, ctx.Instance, ctx.Arguments, ctx.ReturnValue
});
```
Prerequisites:
- A hook **catalog** / alias file has been loaded (e.g., `HookBinder.LoadAliases(path)` or `Hooker.InstallFromCatalog(...)`), so the Il2Cpp signature is mapped to the canonical string `greg.NETWORK.GenerateDeviceName`.
- Namespace `GregFramework.Hooks`, type `HookContext` (includes `Arguments`, `Instance`, `ReturnValue`, etc.).
### 2. Object Bus: `GregEventDispatcher` (Rust / FFI / manual emits)
Some names in the form ``greg.<Domain>.<Action>`` are additionally fired from the core via `GregHookIntegration` / `GregEventDispatcher.Emit` (numeric `EventIds` → String). If your hook is only defined in `greg_hooks.json` as an Il2Cpp patch, **HookBinder** is the correct entry point; use `GregEventDispatcher` if you want to explicitly listen to the payload bus:
```csharp
using gregFramework.Core;
GregEventDispatcher.On("greg.NETWORK.GenerateDeviceName", payload =>
{
// depending on the payload type; helpers: GregPayload.Get<T>(payload, "field", fallback)
});
```
Unregister: `GregEventDispatcher.Off("greg.NETWORK.GenerateDeviceName", handler)` (same delegate reference as for `On`).
## See also
- [Overview of all greg hooks](/wiki/_internal/README)
- Source: `gregCore/gregFramework/greg_hooks.json`
## Usage in Rust
If your Rust bridge exposes the event bus, subscribe to the exact hook name:
~~~rust
use greg_framework::events::EventBus;
fn register_hooks(bus: &mut EventBus) {
bus.on("greg.NETWORK.GenerateDeviceName", |payload| {
if let Some(method) = payload.get("method") {
println!("[NETWORK] method={}", method);
}
});
}
~~~
> If your current Rust runtime only exposes numeric EventIds, map those IDs to canonical `greg.*` names in your bridge layer before dispatching to mod code.
## Usage in Lua
Use the Lua bridge and register against the same canonical hook string:
~~~lua
greg.on("greg.NETWORK.GenerateDeviceName", function(payload)
local method = payload and payload.method or "unknown"
greg.log("[NETWORK] method=" .. tostring(method))
end)
~~~
For Harmony-level interception use:
~~~lua
greg.hook.after("greg.NETWORK.GenerateDeviceName", function(ctx)
greg.log("after hook: " .. tostring(ctx.method_name))
end)
~~~
## Usage in TypeScript
In a TS/JS bridge, subscribe via your event client using the same hook key:
~~~ts
import { gregBus } from './gregBus';
gregBus.on("greg.NETWORK.GenerateDeviceName", (payload) => {
const method = payload?.method ?? 'unknown';
console.log("[NETWORK] method=" + method);
});
~~~
When using RPC/WebSocket transport, keep `greg.NETWORK.GenerateDeviceName` as the canonical routing key end-to-end.

Some files were not shown because too many files have changed in this diff Show More