Updated GregCore to PreRelease 40
gregCore CI / build (push) Has been cancelled

This commit is contained in:
Marvin
2026-04-24 21:52:53 +02:00
parent 3595b3e40b
commit 5282adecfb
34 changed files with 55 additions and 2561 deletions
-27
View File
@@ -1,27 +0,0 @@
---
name: Bug report
about: Create a report to help us improve
title: ''
labels: bug
assignees: ''
---
**Describe the bug**
A clear and concise description of what the bug is.
**To Reproduce**
Steps to reproduce the behavior.
**Expected behavior**
A clear and concise description of what you expected to happen.
**Screenshots**
If applicable, add screenshots to help explain your problem.
**Desktop:**
- OS: [e.g. Windows 11]
- Game Version: [e.g. 1.0.45]
- gregCore Version: [e.g. 1.0.0.30-pre]
**Additional context**
Add any other context about the problem here.
-15
View File
@@ -1,15 +0,0 @@
## Description
<!-- Describe your changes in detail -->
## Motivation and Context
<!-- Why is this change required? What problem does it solve? -->
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
## Checklist:
- [ ] My code follows the code style of this project.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
-22
View File
@@ -1,22 +0,0 @@
# Copilot Instructions
## Core Runtime Guardrails
- Keep all gameplay/runtime-facing components compatible with `.NET 6.x`.
- Do not retarget runtime projects beyond `net6.0` unless explicitly requested and validated for Unity IL2CPP + MelonLoader.
## Mandatory System Architecture Prompt
- Apply `.github/instructions/gregframework_system_architecture.instructions.md` to all implementation and design decisions.
- If constraints conflict, prioritize runtime stability, clean layered boundaries, and `.NET 6` compatibility.
## SonarQube MCP Rules
- Apply `.github/instructions/sonarqube_mcp.instructions.md` whenever SonarQube MCP tooling is used.
## Collaboration Defaults
- Respond in technical German unless a file or repository policy explicitly requires English-only artifacts.
- Summarize intent before code changes.
- Keep refactors minimal and architecture-safe.
## Wiki Currency Check (Mandatory)
- At the end of every change request, verify whether relevant wiki pages are up to date.
- If updates are required, list the pages and include them in follow-up recommendations.
@@ -1,238 +0,0 @@
---
applyTo: "**/*"
---
# GregFramework Technischer Systemarchitektur-Prompt
## Identität & Rolle
Du bist ein hochspezialisierter technischer Architekt und Senior-Entwickler für folgendes Gesamtsystem:
**GregFramework** Ein modulares, user-erweiterbares All-in-One Modding-SDK für Unity/IL2CPP-Spiele, das als zentrale Bridge zwischen dem Spiel und externen Mods dient, und über eine .NET MAUI-Anwendung (ModManager) verwaltet wird.
Du hast gleichzeitig tiefes Fachwissen in:
- Unity (IL2CPP und Mono), MelonLoader und Harmony
- .NET 6 / C# (Reflection, AppDomain, Assembly-Loading, Code-Generierung)
- .NET MAUI (Deployment, Installer, Debugging, Release-Build-Fixes)
- Model Context Protocol (MCP) für AI-Integration
- Mehrsprachige Runtime-Bridges (C#, Lua, Python, TypeScript/JS, Rust, Go, extensible)
- Modularer Plugin-Architektur (MEF, AssemblyLoadContext, Extension Points)
- Harmony/HarmonyX Patching (Prefix, Postfix, Transpiler, dynamische TargetMethod)
- IL2CPP-Metadaten-Analyse (Il2CppDumper, Il2CppInspector, Cpp2IL, Reflection zur Laufzeit)
---
## Zielarchitektur (Pflicht: immer im Kopf behalten)
Die Systemhierarchie ist unveränderlich wie folgt:
```
[MAUI ModManager]
[GregFramework Core SDK]
├──▶ [Plugin Layer] ← Interne Erweiterungen des Frameworks
│ │
│ ▼
│ [Language Bridges] ← C#, Lua, Python, TS/JS, Rust, Go, extensible
[Mod Layer] ← User-Mods (geschrieben in beliebiger Sprache)
[Unity Spiel / IL2CPP Assembly] ← via Harmony Hooks als Event-Proxy
```
Jede deiner Antworten muss explizit benennen, in welcher Schicht eine Komponente lebt.
---
## greg.* Das kanonische API-Schema
**JEDE Funktion im Framework folgt diesem Namensschema in ALLEN Sprachen identisch:**
```
greg.<Domain>.<Action>.<Variant>.<Timing>
Beispiele:
greg.Economy.SetMoney.plus.now
greg.Economy.SetMoney.minus.timed(30)
greg.Economy.SetMoney.plus.repeating(5)
greg.Player.SetHealth.plus.now
greg.Inventory.AddItem.byId.now
greg.World.SetTime.to.timed(10)
```
Aufbau:
- greg → Namespace-Root (global, unveränderlich)
- Domain → Fachbereich (Economy, Player, Inventory, World, UI, ...)
- Action → Was gemacht wird (SetMoney, AddItem, SpawnEnemy, ...)
- Variant → Wie es gemacht wird (plus, minus, to, byId, byName, ...)
- Timing → Wann es gemacht wird: now | timed(seconds) | repeating(seconds)
(Timing ist optional, Default ist "now")
Dieses Schema ist SPRACHUNABHÄNGIG. Lua, Python, Rust, TS alle verwenden
identische Namen. Die Sprache ist nur der Host, nicht das API.
---
## Technische Kernkomponenten (Pflicht: du kennst alle Details)
### 1. MelonLoader MCP Plugin (Assembly Scanner + MCP Server)
**Zweck:** Läuft im Spielprozess, scannt zur Laufzeit alle geladenen Assemblies
und hostet einen MCP-kompatiblen HTTP-Server auf localhost:8081, den AI-Tools
(Claude, Cursor, GitHub Copilot) direkt abfragen können.
**Tools die der MCP-Server exposed:**
- `list_assemblies` → Alle geladenen Assemblies mit Typenanzahl
- `search_types(query)` → Typen nach Name/Namespace suchen
- `search_methods(query)` → Methoden nach Name suchen (mit Signaturen)
- `get_type_detail(fullname)` → Alle Members eines Typs (Methoden, Fields, Props, Events)
- `suggest_greg_api(method)` → Vorschlag für greg.* Mapping einer Methode
- `export_full_scan()` → Vollständiger JSON-Export aller Assemblies
- `get_hook_candidates()` → Methoden die sinnvoll hookbar sind (heuristisch)
**Technischer Stack:**
- MelonLoader Mod (erbt von MelonMod)
- HttpListener auf localhost:8081 (kein externen Dep nötig)
- JSON via System.Text.Json
- Reflection (BindingFlags.Public | NonPublic | Instance | Static)
- AppDomain.CurrentDomain.GetAssemblies()
- IL2CPP-kompatibel durch MelonLoader-Interop
**Fehlerbehandlung:** Jeder Typ/Methoden-Scan in try/catch, fehlerhafte Typen
werden geloggt aber übersprungen. Server läuft in Task.Run() um Gameloop nicht
zu blockieren.
### 2. Assembly-Analyse Pipeline (Offline AI-Workflow)
**Zweck:** Aus dem MCP-Export einen vollständigen greg.*-API-Tree erstellen.
**Pipeline:**
```
MCP Export (JSON)
AI Klassifikation
→ Gruppierung in Domains (Economy, Player, ...)
→ Mapping: Spielmethode → greg.* Name
→ Risiko-Bewertung (safe/risky/unsafe)
→ Dokumentations-Generierung
greg-manifest.json ← Das kanonische API-Manifest des Frameworks
Code-Generierung
→ C# Harmony-Patches (auto-generiert)
→ Wiki-Seiten (Markdown)
→ Language Bridge Stubs
```
### 3. GregFramework Core SDK
**Zweck:** Runtime-Schicht im Spielprozess. Lädt greg-manifest.json,
initialisiert Harmony, registriert alle Hooks als Event-Proxy.
**Namespaces:**
```
GregFramework.Core → Bootstrap, Lifecycle, EventBus
GregFramework.Hooks → Harmony-Patches (auto-generiert oder manuell)
GregFramework.API → Öffentliches API für Mods (greg.* Aufrufe)
GregFramework.Loader → Mod-Loading, Hotload, Abhängigkeiten
GregFramework.Bridges → Language Bridge Interfaces
GregFramework.Extensions → Plugin/Extension-System
```
### 4. Language Bridges
**Prinzip:** Jede Bridge implementiert `IGregLanguageBridge` und hostet eine
Runtime (Lua-VM, Python.NET, JS-Engine, Rust-FFI, etc.) die gegen
`IGregContext` arbeitet. Die Bridge ist ein Plugin im Plugin-Layer.
**Neue Sprachen per Extension:**
- User erstellt Plugin-DLL die `IGregLanguageBridge` implementiert
- Wird automatisch im Extensions-Ordner entdeckt (MEF oder DirectoryWatcher)
- Keine Änderung am Core nötig
### 5. MAUI ModManager
**Zweck:** Desktop-Anwendung für Mod-Verwaltung. Kommuniziert mit
GregFramework über MCP oder Named Pipes (localhost).
**Deployment-Anforderungen:**
- Windows Installer (MSIX oder Inno Setup)
- Kein Crash nach Installation (Release-Build stabil)
- Globaler Exception-Handler mit File-Logging für Release-Crashes
- Visual Studio Attach-to-Process Support für Release-Debugging
---
## Deine Verhaltenspflichten
### Bei Code-Anfragen:
1. Benenne immer die Schicht (MCP Plugin / Core SDK / Bridge / ModManager)
2. Kompatibilität mit IL2CPP und MelonLoader prüfen
3. Fehlerbehandlung ist nicht optional jede kritische Stelle bekommt try/catch + Logging
4. IDisposable korrekt implementieren, Event-Handler deregistrieren
5. Async-Code: ConfigureAwait(false) wo kein UI-Thread nötig, keine Blocking-Calls in UI
### Bei Refactoring:
1. Erst: Was soll der Code tun? (Intent-Summary)
2. Dann: Was ist falsch / fragil / riskant?
3. Dann: Konkreter Verbesserungsvorschlag mit Begründung
4. Optional: Umgeschriebener Code
### Bei Architekturentscheidungen:
1. Immer prüfen: Welche Schicht ist zuständig?
2. Kein Direct-Access von Mods auf Unity-Typen (immer über greg.* API)
3. Language Bridges sind isoliert ein Crash in Lua killt nicht den C#-Stack
4. Neue Features: erst Manifest anpassen, dann Hook generieren, dann Bridge updaten
### Bei MAUI-Problemen:
1. Unterschied Debug/Release benennen (Trimming, AOT, Linking)
2. Global Exception Handler in App.xaml.cs und MauiProgram.cs
3. Logging in %AppData%\GregModManager\logs\ für Release-Diagnose
4. Installer-Probleme: Permissions, PATH, missing Runtimes prüfen
### Bei KI/MCP-Integration:
1. MCP-Server ist im MelonLoader-Mod, nicht im Framework selbst
2. greg-manifest.json ist das einzige "Wahrheits-Dokument" des Frameworks
3. Code-Generierung aus manifest.json ist deterministisch und reproduzierbar
---
## Fokus-Prioritäten (in dieser Reihenfolge)
1. **Stabilität & Fehlertoleranz** Ein kaputter Mod darf das System nicht killen
2. **Saubere Architektur** Schichten respektieren, keine Querverlinkungen
3. **Developer Experience** greg.* API muss intuitiv sein, gute Fehlermeldungen
4. **Sprachunabhängigkeit** Naming ist in allen Bridges identisch
5. **Performance** Kein unnötiger Overhead, Hooks gezielt und sparsam
6. **Erweiterbarkeit** Neue Sprachen/Plugins per Drop-in, kein Core-Edit nötig
---
## Kontext zur Spielumgebung
- Spiel: Data Center (Unity, IL2CPP)
- Pfad: C:\Program Files (x86)\Steam\steamapps\common\Data Center
- MelonLoader: im MelonLoader-Ordner des Spiels
- MCP Plugin Port: localhost:8081
- Framework Config: im Spielordner unter GregFramework\config\
- Mod-Ordner: im Spielordner unter GregFramework\mods\
- Extension-Ordner: im Spielordner unter GregFramework\extensions\
---
## Gesprächsregeln
- Antworte auf Deutsch, technisch präzise
- Fass vor jedem Codevorschlag kurz zusammen, was du verstanden hast
- Wenn Kontext fehlt (Unity-Version, MelonLoader-Version, etc.), frage gezielt aber nur eine Sache auf einmal
- Erkläre Entscheidungen kurz (warum dieser Ansatz, nicht nur was)
- Code in C# Blöcken, kompilierbar oder klar mit Platzhaltern markiert
- Verweise immer auf die relevante Schicht im Architektur-Tree
-62
View File
@@ -1,62 +0,0 @@
# gregCore - Agent Guide
Welcome to the `gregCore` repository. This document outlines the project architecture, commands, conventions, and constraints to help AI agents work effectively in this codebase.
## 1. Project Overview
`gregCore` is a modding framework for the game "Data Center". It acts as a bridge between the game (running on Unity IL2CPP with MelonLoader) and various modding languages (C#, Lua, JS, Rust, Go).
**Critical Constraint:** All runtime/gameplay-facing components MUST remain compatible with **.NET 6.0**. Do not upgrade the target framework beyond `net6.0`, as it will break Unity IL2CPP + MelonLoader compatibility.
## 2. Essential Commands & Scripts
The project uses PowerShell scripts for most build and deployment tasks. You can find them in the `scripts/` directory.
- **Build Release:** `pwsh scripts/Build-Release.ps1`
- This builds `src/gregCore.csproj` in Release configuration and packages it into `publish/gregCore-vX.Y.Z.zip`.
- **Manual Build:** `dotnet build src/gregCore.csproj -c Release`
- **Hooks Generation:** `pwsh scripts/Generate-GregHooksFromIl2CppDump.ps1`
- **Workshop Deployment:** `pwsh scripts/Deploy-Release-ToWorkshop.ps1`
When `CI=true` is set, the project uses stub DLLs from `ci-stubs/` instead of actual MelonLoader references.
## 3. Architecture & Layers
The framework is strictly layered (as detailed in `modding_core_architecture_summary.md`):
1. **Unity Game Layer:** Game types/methods patched via Harmony (`src/GameLayer/Patches/`).
2. **Core Layer (gregCore):**
- `src/GameLayer/Bootstrap/gregCoreLoader.cs` (MelonMod entry point)
- FFI Bridge (`Win32FfiBridge.cs`) and API Table (`GameApiTable.cs`)
- Event Dispatching (`GregEventBus`, `NativeEventHooks.cs`)
3. **Plugin Layer:** Plugin registry and dependency resolver (`src/Infrastructure/Plugins/`).
4. **Language Bridges:** Hosts for script isolation (`src/Infrastructure/Scripting/Lua`, `Js`).
5. **Mod Layer:** User-created mods (C#, native DLLs, or scripts).
### Event / Hooking Pipeline
1. `HarmonyPatches` intercept Unity methods (Prefix/Postfix).
2. Data is extracted into primitive/struct DTOs.
3. Dispatched via `GregEventBus` using canonical hook names: `greg.<Domain>.<Event>`.
4. Mappings are defined in `assets/greg_hooks.json` and loaded dynamically via `GregHookRegistry` (`IGregHookRegistry`), providing stable hashed Event-IDs for the FFI.
## 4. Conventions and Rules
- **Language:** Respond in **technical German** when summarizing intent before code changes, unless a file or repository policy explicitly requires English.
- **ABI & FFI Boundaries:**
- Struct order/types are ABI-critical. Always use `[StructLayout(LayoutKind.Sequential)]`.
- Pass stable primitive types (`int`, `uint`, `float`, `byte[]`, `IntPtr`) across the bridge.
- No implicit Unity/IL2CPP object references in public Bridge DTOs.
- **Error Handling:** Every boundary (FFI, JSON parse, network) must be wrapped in `try/catch` + logging. Failure in a mod must remain isolated and not crash the core loop.
- **`MISSING.md` Rule:** If a required API abstraction is missing during extension work, you MUST create a `MISSING.md` file in the relevant module folder. It must include a `.gitignore` header (`!MISSING.md`). (See `docs/MODDING_MelonLoader_gregCore.md` for the template).
- **Wiki Currency Check:** At the end of every change request, you MUST verify whether relevant wiki pages in `docs/` are up to date and list them if updates are required.
## 5. Directory Structure
- `src/Core/`: Core interfaces, exceptions, and models.
- `src/GameLayer/`: Harmony patches and bootstrap/entry point logic.
- `src/PublicApi/`: Public SDK used by C# mods (Attributes, Mod base classes).
- `src/Infrastructure/`: Implementations for Networking (MCP, Sync), FFI, UI, Config, Scripting (MoonSharp Lua, JS), Automation, and Performance Governors.
- `scripts/`: PowerShell automation for builds, packaging, and hook generation.
- `assets/`: Contains `greg_hooks.json`.
- `docs/`: Extensive project documentation (Tutorials, Hooks Catalog, Architecture).
- `lib/`: Third-party dependencies and references (e.g., MoonSharp, MelonLoader stubs).
-125
View File
@@ -1,125 +0,0 @@
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [1.0.0.35-pre] - 2026-04-21
### Fixed
- **Unity 6 Compatibility**: Fixed `UpdateCoin` Harmony patch parameter name mismatch (`_amount` -> `_coinChhangeAmount`).
- **Stability**: Switched `GregDevConsole` and UI windows to `GUI.Window` to avoid `LayoutedWindow` constructor errors in Unity 6.
- **HexViewer**: Major refactor to use stable IMGUI and current SDK namespaces.
## [0.1.0] - 2026-04-18
### Added
- NuGet packaging baseline for `gregCore` with symbol package output (`.snupkg`).
- Local + GitHub Packages feed configuration and package source mapping.
- Downstream `build/gregCore.props` integration for reference-only package usage.
## [v1.0.0.7] - 2026-04-12
### Added
- **gregUI**: Complete UI manipulation layer for UGUI (`src/UI/`).
- **GregUIManager**: Central canvas registry and lifecycle management.
- **GregUITheme**: Design system tokens (The Luminescent Architect).
- **GregUIBuilder**: Fluent builder API for mod developers.
- **UI Components**: `GregPanel`, `GregButton`, `GregLabel`, `GregToggle`, `GregSlider`, `GregBadge`, `GregSeparator`.
- **HexViewer Integration**: UI Tree Inspector (F1), Hook Monitor (F2), Element Inspector (F3).
- **UI Hooks**: New hook category `greg.UI.*` for monitoring game UI events (MainMenu, PauseMenu, HUD, Tooltips).
### Changed
- `gregCoreLoader.OnInitializeMelon`: Now registers `GregUIManager`.
- `gregUiExtensionBridge.OnSceneLoaded`: Now notifies `GregUIManager`.
## [v1.0.0.6] - 2026-04-12
### Added
- **Game Compatibility Update**: Verified compatibility with *Data Center* patch `v1.0.45.5`.
- **VLAN Management**: Added `SetVlanAllowed`, `SetVlanDisallowed`, and `IsVlanAllowed` to `gregGameHooks` and `gregGameApi` (v9).
- **Route Evaluation**: Documented hooks for improved routing system.
- **gregReferences Synchronization**: Updated reference documentation for the new game version.
## [v1.0.0.0] - 2026-04-11
### Added
- **Phase 5 Implementation**: Initial SDK bridges for Economy and Data.
- **GregBalanceService**: Access to financial data, salaries, and income simulation.
- **GregLocalisationService**: Direct access to the game's internal translation system.
- **Roadmap Expansion**: Added Phase 8 (Unity Scripting API) and refactored all documentation to English with Material Symbols.
## [v1.0.0.0] - 2026-04-11
### Added
- **Game System Bridges**: 9 new SDK services for direct control of game systems via IL2CPP abstraction.
- **Hardware Bridges**: Direct interaction with physical server and rack objects.
### Added
- **Unity Signal Normalization**: 30+ canonical hooks in `GregNativeEventHooks` based on IL2CPP snapshots.
- **Full Category Registries**: Offizielle SDK-Registries für Server, Switches, Kunden, Mitarbeiter, SFP, Kabel, Möbel und Items.
- **Advanced Model Overrides**: Priority-based conflict resolution, author metadata, and diagnostics.
- **Language Bridge APIs**: Dynamic event registration for Lua (`on_update`, `on_gui`) and C# bridge surface for TS/JS.
- **Native Header**: Added `greg_api.h` for Rust/C mod developers to consume the v8 API table.
- **Validation & Migration**: `IContentValidator` and `IContentMigration` interfaces for mod data integrity.
- **Functional Services**: Basic implementation for `GregIPAllocationService` and `GregRackService`.
### Fixed
- Fixed build issues with nullable reference types in `gregSdk`.
- Corrected test project references and added comprehensive integration tests.
## [v1.0.0.0] - 2026-04-11
### Fixed
- **Definitive UI Removal**: Fixed incorrect file exclusions in `.csproj` and disabled bootstrap registration in `gregCore.cs` to ensure the native UI is used.
- **Debug Overlay**: Added **F5** toggle to show/hide the debug info panel.
## [v1.0.0.0] - 2026-04-11
### Fixed
- Standardized all Lua modules to camelCase (`gregUnityLuaModule`, etc.).
- Fixed static/instance member access conflicts in `gregModSettingsMenuBridge`.
- Corrected over-aggressive renaming of Unity engine components (e.g. `Camera.main`).
- Normalized `gregSdk` namespace usage across the framework.
### Changed
- Separated `gregAddons` into its own logical structure (Node.js tools and optional plugins).
- Built-in reference DLLs for out-of-the-box CI support.
## [v1.0.0.0] - 2026-04-11
### Added
- Missing SDK APIs for all 4 languages (C#, Rust, Lua, TS/JS).
- HUD and Targeting bridge modules for Lua.
- Advanced event subscription model.
- Windows x64 and .NET 6 as primary targets.
### Changed
- **Major Refactor**: Renamed all directories and files to follow the `greg[Name]` camelCase convention.
- Global namespace update from `DataCenterModLoader` to `gregModLoader`.
- Global namespace update from `AssetExporter` to `gregAssetExporter`.
- Standardized author name to `MLeeM97`.
## [v0.7.0.0] - 2026-04-10
### Fixed
- Project references and solution structure for correct DLL paths.
- README path updates.
## [v0.6.0.0] - 2026-04-09
### Added
- Language bridge architecture with Lua and TypeScript/JavaScript support.
- MoonSharp integration for Lua scripting.
## [v0.5.0.0] - 2026-04-08
### Added
- `UiExtensionBridge` for UI feature integration and modernization.
- Custom Main Menu replacement capabilities.
## [v0.4.0.0] - 2026-04-07
### Added
- Scripts for generating and parsing greg hooks from IL2CPP dumps.
## [v0.3.0.0] - 2026-04-06
### Changed
- Flat `gregFramework` workspace layout.
- Documentation alignment with the new repository structure.
## [v0.2.0.0] - 2026-04-05
### Added
- RustBridge integration for native mod support via FFI.
## [v0.1.0.0] - 2026-04-04
### Added
- Initial standalone repository setup.
- Basic MelonLoader mod structure.
-640
View File
@@ -1,640 +0,0 @@
## 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 // 03
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)
-14
View File
@@ -1,14 +0,0 @@
# 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.
-89
View File
@@ -1,89 +0,0 @@
# gregCore - Framework Core
> The heart of the gregFramework modding ecosystem for Data Center.
**Author:** MLeeM97 (teamGreg) | **License:** MIT | **Framework:** [gregCore](https://git.datacentermods.com/teamGreg/gregCore)
---
## Features
- **GregSaveService** - Persistent mod data storage
- **GregUIBuilder** - FixedTableUI, Panel System, Canvas Management
- **GregPersistenceService** - Centralized `UserData/gregCore/Data/` storage
- **GregMCPServer** - Embedded HTTP MCP server (Port 10420) for external tooling
- **GregMultiplayerService** - WebSocket relay-based multiplayer
- **Harmony Patches** - MainMenu, MODS Button injection
- **IL2CPP Compatibility** - InputSystem, Coroutines, Il2CppTMPro
- **MoonSharp Lua** - Embedded scripting engine
- **Integrated DataCenter Compatibility Layer** - RustBridge/LangCompat runtime is embedded in-core under `src/Compatibility/DataCenterModLoader`
## Installation
1. Install **MelonLoader** (v0.6+)
2. Place `gregCore.dll` + `gregCore.dll` into `Game/Mods/`
3. Start the game and press **Framework auto-initializes on game start**
## Dependencies
- Built-in only (this IS the core)
- Legacy `RustBridge` and `LangCompatBridge` are integrated into `gregCore` and are no longer shipped as standalone external plugin/mod dependencies
## Architecture Update
- Legacy external trees `plugins/DataCenter-RustBridge` and `mods/greg.Plugin.LangCompatBridge` were retired from `gregCore`
- Runtime compatibility lifecycle is now wired directly from `GregCoreMod` to `DataCenterModLoader.Core`
- Compatibility sources are maintained in-core at `src/Compatibility/DataCenterModLoader`
## Building from Source
```bash
cd gregFramework/gregCore
dotnet build -c Release
# Output: bin/Release/net6.0/gregCore.dll
```
Or build everything at once:
```bash
cd gregFramework/deploy
./build-all.ps1
# Output: gregFramework/BuiltModsForGame/
```
## Links
- **Primary:** [git.datacentermods.com/teamGreg](https://git.datacentermods.com/teamGreg)
- **Discord:** [discord.gg/greg](https://discord.gg/greg)
---
## Contributors & Thanks
### Discord Community
**Thanks to:**
- **Noootry**
- **TheSlickers**
- **Jarvis**
- **Kirei**
- **TeamWaseku** (ModernSamurai, GamerFrankstar, Ultra, Zyn)
*...for keeping the community alive!*
### Code & Testing
**Special thanks:**
- **Joniii** & **mochimus** - Code + Tests
- **Baker**, **Sharpy1o1**, **MachineFreak** - Testing + Modeling
### Sponsors
- **@tobiasreichel** - Haupt-Sponsor
- **SQ8** - Infrastructure Hosting
---
*gregFramework - Powered by the Community!*
## Contributors
- @mleem97
- @Joniii11
-36
View File
@@ -1,36 +0,0 @@
:rotating_light: **Major Update: gregCore v1.0.0.7 is LIVE! (gregUI Framework & HexViewer Integration)**
Hey everyone,
We've just reached another massive milestone! Today we are dropping **gregCore v1.0.0.7**, which introduces the brand-new **gregUI Framework** and deep integration with the **HexViewer** for advanced developer tooling.
---
:wrench: **What's new in v1.0.0.7?**
This update focuses on UI extensibility and modularity.
:paintbrush: **gregUI Framework** — A complete UI manipulation layer for UGUI.
* **GregUIBuilder**: Fluent API for modders to create panels and components with 5 lines of code.
* **Luminescent Architect Design System**: Standardized tokens for colors, spacing, and glow effects.
* **Live UI Replacements**: Users can now override any game UI element (position, scale, color) via `ui_overrides.json`.
:joystick: **Advanced Hooking** — New `greg.UI.*` hook category. Subscribe to MainMenu, PauseMenu, and HUD events.
:mag: **Developer Tooling** — HexViewer integration with F1 (UI Tree), F2 (Hook Monitor), and F3 (Element Inspector).
---
:package: **Installation**
1. **Requirement**: Ensure you have [MelonLoader v0.6.1](https://github.com/LavaGang/MelonLoader/releases) installed for *Data Center*.
2. **Files**:
* Copy `gregCore.dll` to your game's `Mods/` folder.
* Copy `Jint.dll` and `Esprima.dll` to your game's `MelonLoader/Libs/` folder.
* Copy `greg_hooks.json` to your game's root directory (next to the `.exe`).
3. **Launch**: Start the game. You should see "gregCore v1.0.0.7 initialized" in the console.
---
:point_right: **[Download gregCore v1.0.0.7 on GitHub](https://github.com/mleem97/gregCore/releases/tag/v1.0.0.7)**
Thank you for being part of this journey! — Your **teamGreg**
-27
View File
@@ -1,27 +0,0 @@
:rotating_light: **Update: All Changes since Pre-Release 4!** :rotating_light:
Hi everyone! Here is a compact overview of all the new features, fixes, and bridges that have landed in **gregCore** since `pre4`. We have reached some huge milestones!
:joystick: **Game Compatibility & Networking**
- **Data Center Patch v1.0.45.5**: Compatibility with the latest game version has been verified!
- **VLAN Management**: Added `SetVlanAllowed`, `SetVlanDisallowed`, and `IsVlanAllowed` to `gregGameHooks` and the API (v9).
- **Route Evaluation**: New hooks for the improved in-game routing system have been added and documented.
:rocket: **New SDK Features & Bridges (Pre-Release 5 & 6)**
- **TS/JS Engine Integration:** Full integration of the TypeScript/JavaScript engine, including associated API documentation.
- **IL2CPP Game System Bridges:** 9 completely new SDK services for direct control of in-game systems.
- **Hardware Bridges:** Direct interaction possibilities with physical server and rack objects in the game.
- **Phase 5 (Economy & Data):**
- `GregBalanceService`: Access to financial data, salaries, and income simulation.
- `GregLocalisationService`: Direct access to the game's internal translation system (mod-specific translations are now possible).
:blue_book: **Documentation & Roadmap**
- All framework documentation has been translated into English and enhanced with Material Symbols.
- Reference documentation (`gregReferences`) has been synchronized for the new game version.
- The Master Roadmap has been updated (including preparations for Phase 8: Unity Scripting API).
:bug: **Bugfixes & Polish (up to v1.0.0.17)**
- **UI & Config:** Resolved an issue with UI transparency and improved the accessibility of mod configurations in the menu.
Grab the latest build on GitHub and happy modding! If you notice any bugs, feel free to report them. :fire:
-72
View File
@@ -1,72 +0,0 @@
# 📋 gregCore Roadmap to 100% Coverage
Dieses Dokument ist der zentrale Masterplan für das Greg Framework. Es wird laufend aktualisiert, um mit der Entwicklung von *Data Center* Schritt zu halten.
---
## ✅ Phase 0: Baseline (Abgeschlossen)
- [x] ~~Initiales Standalone-Repository Setup~~
- [x] ~~Namespace-Migration zu `gregModLoader`~~
- [x] ~~Basis-Struktur für MelonLoader Mods~~
## ✅ Phase 1: Framework Foundation (Abgeschlossen)
- [x] ~~Typsicheres Registrierungssystem (`GregContentRegistry`)~~
- [x] ~~Basis-Definitionen für Hardware (Server, Switches)~~
- [x] ~~Zentraler Event-Bus (`gregEventDispatcher`)~~
## ✅ Phase 2: Runtime Integration (Abgeschlossen)
- [x] ~~Implementierung der `gregSdk` Services~~
- [x] ~~Kunden- und Mitarbeiter-Registries~~
- [x] ~~Netzwerk-Kompatibilitäts-Prüfung (`GregNetworkCompatibilityService`)~~
## ✅ Phase 3: Visual Layer & Overrides (Abgeschlossen)
- [x] ~~Offizieller Modell-Ersetzungs-Dienst (`GregModelOverrideService`)~~
- [x] ~~Prioritätsbasiertes Konflikt-Management für Mods~~
- [x] ~~JADE-Style HUD Referenz-Implementierung~~
## ✅ Phase 4: Quality & API Expansion (Abgeschlossen)
- [x] ~~30+ Normalisierte Unity-Signale (`GregNativeEventHooks`)~~
- [x] ~~Automatisierte Unit-Tests in `gregCore.Tests`~~
- [x] ~~9 System-Bridges (Shop, Time, Player etc.)~~
- [x] ~~Pre-Release v1.0.0 veröffentlicht~~
## ✅ Phase 4.5: gregUI Framework & Release v1.0.0.30-pre (Abgeschlossen)
- [x] ~~gregUI Framework mit vollständiger UGUI-Manipulation~~
- [x] ~~GregUIBuilder Fluent API~~
- [x] ~~Luminescent Architect Design System~~
- [x] ~~HexViewer Integration (F1, F2, F3 Developer Tools)~~
- [x] ~~UI Hooks Kategorie (`greg.UI.*`)~~
- [x] ~~v1.0.0.30-pre Release mit allen Dependencies~~
- [x] ~~GitHub Release mit DLL-Downloads~~
## 🚧 Phase 5: Economy & Data (In Arbeit)
- [ ] **SaveSystem & SaveData**: Abstraktion des Speichervorgangs. Ermöglicht Custom-Save-Daten für Mods.
- [ ] **BalanceSheet & Finanzen**: Zugriff auf Einnahmen, Ausgaben und historische Daten.
- [ ] **Localisation**: Bridge zum internen Übersetzungssystem für mehrsprachige Mods.
## 📅 Phase 6: Deep Hardware & UI (Geplant)
- [ ] **CableLink & SFPModule**: Detailsteuerung für Kabeltypen und SFP-Zustände (Hitze, Verschleiß).
- [ ] **PatchPanel**: Interaktion mit passiver Netzwerk-Hardware.
- [ ] **Tooltip & UI_Section**: Erweiterte UI-Manipulation über das HUD hinaus.
- [ ] **AudioManager**: Steuerung von Soundeffekten und Umgebungsmusik.
- [ ] **Network Crawler (`GregTopologyService`)**: Implementierung eines performanten Graphen-Crawlers für automatisiertes Routing.
- [ ] **Power Simulation (`GregPowerService`)**: Rekursive Berechnung des Rack- und Raum-Stromverbrauchs.
## 📅 Phase 7: Environment & Simulation (Geplant)
- [ ] **HRSystem**: Tiefere Integration in das Mitarbeiter-Management (Boni, Level-Up).
- [ ] **SteamManager & Lobbies**: API-Queue für Steam-Lobby-Callbacks (FFI `gregGameApi`).
- [ ] **Objectives**: Manipulation von Tutorial- und Haupt-Zielen.
## 🔄 Phase 8: Unity Scripting API Integration (Laufend)
- [ ] **Unity API Abgleich**: Systematischer Abgleich mit der offiziellen Unity Scripting API.
- [ ] **Standard Module**: Integration von Physics, SceneManagement und NavMesh-Bridges.
---
> 💡 **Hinweis zur Roadmap:** Diese Roadmap ist ein **lebendes Dokument**. Da sich *Data Center* ständig weiterentwickelt, werden neue Systeme laufend in Phase 8 aufgenommen und bei Bedarf neue Phasen definiert.
## Technischer Status
- **Aktuelle Coverage**: ~65% der IL2CPP-Kernlogik bridged.
- **Letzter Snapshot-Abgleich**: 11. April 2026
- **Aktuelle Release**: v1.0.0.30-pre (15. April 2026)
- **GitHub**: https://github.com/mleem97/gregCore/releases/tag/v1.0.0.30-pre
Binary file not shown.
-64
View File
@@ -1,64 +0,0 @@
---
title: gregCore Framework Dependencies
description: Vollständige Übersicht über Laufzeit- und Sprachabhängigkeiten sowie On-Demand-Aktivierung.
slug: /framework-dependencies
---
## Dependency-Tabelle
| Abhängigkeit | Version | Typ | Wann aktiv? | Quelle |
|---|---|---|---|---|
| MelonLoader | aktuell | Runtime | immer | GameDir |
| Il2CppInterop | aktuell | Runtime | immer | GameDir |
| 0Harmony | aktuell | Runtime | immer | GameDir |
| MoonSharp | 2.0.0 | NuGet/embedded | nur bei `*.lua` | `gregCore.dll` |
| Rust-Bridge DLL | aktuell | FFI/ABI | nur bei `*.rs`/`*.rmod` | `gregCore.dll` |
| Python-Host | aktuell | Binding | nur bei `*.py` | `gregCore.dll` |
| JS-Runtime | aktuell | Binding | nur bei `*.js`/`*.ts` | `gregCore.dll` |
## Immer vorhanden, aber on-demand aktiviert
`gregCore` enthält die Framework-Bausteine, instanziiert Hosts aber nur bei Bedarf:
- Keine passende Script-Datei → Host wird nicht erstellt.
- Script-Datei vorhanden + Dependency fehlt → Warnung, Host bleibt deaktiviert.
## `gregCore.csproj` (Auszug)
```xml
<ItemGroup>
<PackageReference Include="Jint" Version="4.1.0" />
<PackageReference Include="Mono.Cecil" Version="0.11.6" />
<PackageReference Include="MoonSharp" Version="2.0.0" />
<PackageReference Include="pythonnet" Version="3.0.3" />
</ItemGroup>
```
## Registry-API
```csharp
// Signatur
public static bool IsActive(Language lang)
```
```csharp
// Signatur
public static IGregLanguageHost GetHost(Language lang)
```
```csharp
// Signatur
public static void ScanAndActivate(string modsScriptsDir)
```
## MISSING.md-Workflow
Wenn eine Sprach-Bridge noch nicht vollständig ist:
1. Stub mit `IGregLanguageHost` implementieren.
2. Lokales `MISSING.md` mit Pflicht-Header pflegen.
3. `MISSING.md` nie committen (`.gitignore`: `MISSING.md`, `**/MISSING.md`).
## Konfliktmarkierung
- ⚠️ WIKI↔CODE CONFLICT: Historische Pfade in älteren Dokumenten können `Plugins/<Lang>` nennen. Der aktuelle Standard ist `Mods/Scripts` für Script-Erkennung.
-87
View File
@@ -1,87 +0,0 @@
---
title: Getting Started (Modding)
description: Einstieg in gregCore mit klarer Trennung zwischen MelonLoader-Plugins und Script-Mods.
slug: /getting-started
---
## Voraussetzungen
- Visual Studio 2022
- .NET 6 SDK
- MelonLoader
- `gregCore.dll`
- Steam-Spiel **Data Center**
## Grundregel: Plugin vs Script
- **Plugin**: MelonLoader-Assembly (`*.dll`) im Mods-Plugin-Kontext.
- **Script**: Datei in `Mods/Scripts` (`*.lua`, `*.py`, `*.rs`, `*.rmod`, `*.js`, `*.ts`, `*.cs`).
## Erstes C#-Plugin (kompilierbar)
```csharp
using MelonLoader;
[assembly: MelonInfo(typeof(HelloPlugin), "HelloPlugin", "1.0.0", "TeamGreg")]
[assembly: MelonGame("", "Data Center")]
public sealed class HelloPlugin : MelonMod
{
public override void OnInitializeMelon()
{
MelonLogger.Msg("[HelloPlugin] loaded");
}
}
```
## Erstes Lua-Script (funktional)
```lua
-- Datei: Mods/Scripts/hello.lua
greg.log_info("Hello from lua script")
greg.show_notification("Lua script is running")
```
## Framework-Guard-Pattern (REGEL 10)
```csharp
public static class Guard
{
public static bool Ensure(bool condition, string message)
{
if (!condition)
{
MelonLoader.MelonLogger.Warning($"[gregCore] Guard failed: {message}");
return false;
}
return true;
}
}
```
## Deployment-Matrix
| Typ | Datei | Zielpfad |
|---|---|---|
| Plugin | `MyMod.dll` | `Data Center/Mods` |
| Lua Script | `*.lua` | `Data Center/Mods/Scripts` |
| Python Script | `*.py` | `Data Center/Mods/Scripts` |
| Rust Script/Mod Trigger | `*.rs`, `*.rmod` | `Data Center/Mods/Scripts` |
| JS/TS Script | `*.js`, `*.ts` | `Data Center/Mods/Scripts` |
| C# Script | `*.cs` | `Data Center/Mods/Scripts` |
## Häufige Fehler (Top 5)
1. `Python.Runtime` fehlt → Python-Host wird übersprungen.
2. Script liegt im falschen Ordner (`Plugins` statt `Mods/Scripts`).
3. TypeScript ohne Transpiler abgelegt.
4. C# Script ohne Roslyn-Runtime.
5. Lua-Fehler im Script stoppt das jeweilige Script (Framework bleibt aktiv).
## Nächste Schritte
- [Scripting Language Support](./scripting-language-support.md)
- [MoonSharp Lua Integration](./moonsharp-lua-integration.md)
- [Framework Dependencies](./framework-dependencies.md)
-34
View File
@@ -1,34 +0,0 @@
---
title: "F8 Settings Hub"
description: "How to use and extend the F8 Settings Hub"
---
# F8 Settings Hub
## Was ist das F8 Settings Hub?
Der F8 Hub ist das zentrale Mod-Konfigurationsmenü für alle gregCore-Mods. Es basiert auf dem `GregUIBuilder` (OnGUI) und nutzt das Luminescent Architect Design System. Kein Mod sollte mehr ein eigenes, abgetrenntes Fenster für Einstellungen bauen.
## Standard-Tabs
- **[Framework]**: Zeigt Core-Infos und Debug-Toggles.
- **[Grid]**: Einstellungen für das `greg.GridPlacement`.
- **[SaveEngine]**: Einstellungen für `greg.SaveEngine`.
- **[Languages]**: Status der registrierten Skriptsprachen.
- **[Debug]**: Diagnose.
## Modder: Eigenen Tab registrieren
```csharp
// 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");
```
## Vanilla-Save-Banner
Wird ein Vanilla-Save geladen, erscheint im F8-Menü ein Warnbanner `Vanilla Save detected — Grid Placement disabled`. Dies signalisiert dem User, dass Game-Breaking-Features deaktiviert wurden, um den Vanilla-Save nicht zu korrumpieren.
-54
View File
@@ -1,54 +0,0 @@
---
title: "Grid Placement Guide"
description: "How to use greg.GridPlacement and integrate it with your mods"
---
# Grid Placement Guide
## Was ist greg.GridPlacement?
greg.GridPlacement ersetzt das Vanilla-Rack-Placement durch ein dynamisches Grid-Placement-System, das ohne vorgefertigte RackHolder-Plates auskommt (ähnlich zu Bausimulationen wie Die Sims).
## Vanilla RackHolder vs. Grid-System
| Feature | Vanilla RackHolder | greg.GridPlacement |
| --- | --- | --- |
| Basis | Vorab platzierte Plates | Endloses virtuelles Raster |
| Flexibilität | Gering | Hoch |
| Sub-Routing | Nein | Ja (2x2 Sub-Grid für Kabel etc.) |
## Grid-Terminologie
- **Cell**: Eine Grid-Einheit, entspricht dem Footprint eines Racks.
- **SubCell**: Eine Cell ist in 4 SubCells (2x2) unterteilt.
- **Snap**: Einrasten auf die Grid-Koordinaten.
- **Origin**: Der 0,0,0 Punkt des virtuellen Grids.
## Wie Racks platziert werden
1. Modus aktivieren via F8 (oder B-Taste).
2. Raster erscheint.
3. Hover zeigt Preview.
4. Klick platziert Rack direkt im World-Space und aktualisiert den GridManager.
## Vanilla-Save-Verhalten
Wenn ein Vanilla-Save geladen wird, deaktiviert sich das Grid-Placement automatisch (`GridPlacement disabled`).
Vanilla speichert Racks in ihrem echten Positionen und Plates. Unser System speichert sie via `greg.SaveEngine`. Beides mischen zerstört Spielstände.
## Modder-API
```csharp
// 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);
```
## Bekannte Einschränkungen
⚠️ Siehe `MISSING.md` im `greg.GridPlacement`-Verzeichnis: Vanilla-Unterdrückung (`RackPlacementPatch.cs`) benötigt ein Update, da die exakte `RackHolder`-Klasse in `Assembly-CSharp` noch verifiziert wird. Standalone-Modus (via Controller) wird derzeit genutzt.
-56
View File
@@ -1,56 +0,0 @@
# Modding Migration Guide: gregCore v1.0.0.35
## The Unity 6 IL2CPP Problem
In Unity 6 (Data Center version), the **IMGUI** system (`GUI.Window`, `GUILayout`) is heavily stripped during the IL2CPP build process. Using managed delegates (like `Action<int>`) for UI windows often fails with:
`[Il2CppInterop] Exception in IL2CPP-to-Managed trampoline: System.NotSupportedException: Method unstripping failed`.
This causes infinite log spam and crashes the rendering bridge.
## The Solution: GregUI (UGUI Framework)
Starting with version 1.0.0.35, `gregCore` provides a safe, native UGUI backend that bypasses the broken IMGUI trampolines.
### 1. Legacy Fixes (Automatic)
- **`greg.Sdk.gregEventDispatcher`**: Restored for compatibility with older mods.
- **`gregNativeEventHooks`**: Stabilized signatures for better IL2CPP linking.
### 2. Migrating to GregUI (Manual Action Required)
Mods using `OnGUI()` or `GUI.Window()` should migrate to the **GregUI Builder API**.
#### Old Code (Prone to Crashes):
```csharp
void OnGUI() {
GUI.Window(id, rect, DrawWindow, "Title");
}
void DrawWindow(int id) {
if (GUILayout.Button("Click Me")) { /* logic */ }
}
```
#### New Safe Code (v1.0.0.35+):
```csharp
using gregCore.PublicApi;
public void BuildUI() {
greg.UI.CreateBuilder("Economy Hud")
.SetSize(400, 300)
.AddLabel("Current Funds: $1500")
.AddButton("Add Money", () => {
// Your logic here - safely wrapped for IL2CPP
})
.AddButton("Close", () => {
gregCore.UI.GregUIManager.SetPanelActive("Economy Hud", false);
})
.Build();
}
// Toggle visibility via hotkey
if (Input.GetKeyDown(KeyCode.F9)) {
gregCore.UI.GregUIManager.TogglePanel("Economy Hud");
}
```
## Important: Clear Cache
After updating `gregCore.dll`, you **MUST** delete the following folder to force metadata regeneration:
`[GamePath]/MelonLoader/Il2CppAssemblies/`
Failure to do so will cause `TypeLoadExceptions` even if the code is correct.
-45
View File
@@ -1,45 +0,0 @@
---
title: "Save Engine Guide"
description: "Documentation for the LiteDB-based greg.SaveEngine"
---
# Save Engine Guide
## Was ist greg.SaveEngine?
Eine hochperformante, embedded BSON-Datenbank (LiteDB 5.x) zum Speichern von Spielständen. Sie ersetzt den schwerfälligen Vanilla-IL2CPP-Binary-Save durch flexible, schemalose Document-Collections.
## Vanilla-Save vs. greg.SaveEngine
| Feature | Vanilla Save | greg.SaveEngine |
| --- | --- | --- |
| Format | Binary IL2CPP | LiteDB (BSON) |
| Mod-Kompatibilität | Schlecht (Runtime-only states) | Perfekt (Collections) |
| Erweiterbarkeit | Keine | Beliebig viele eigene Collections |
## LiteDB & ILRepack
LiteDB ist via ILRepack vollständig in die `gregCore.dll` eingebettet. Es gibt keine externe `LiteDB.dll` und keine Abhängigkeit in UserLibs.
## Vanilla-Kompatibilität
**NOT COMPATIBLE by design.**
Wenn ein Vanilla-Save geladen wird, deaktiviert sich `greg.SaveEngine.Write`.
## Modder-API
```csharp
// 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();
};
```
@@ -1,33 +0,0 @@
---
title: "Vanilla Save Compatibility"
description: "How gregCore handles vanilla save files"
---
# Vanilla Save Compatibility
## Was ist ein "Vanilla Save"?
Ein "Vanilla Save" ist ein Spielstand, der vom nativen Speichersystem des Spiels "Data Center" angelegt wurde (IL2CPP Binary Save). Er enthält keine `greg_meta`-Dokumente.
## Wie greg.SaveEngine es erkennt
Beim Aufruf von `LoadGame` überprüft `GregVanillaDetector`, ob die zu ladende Datei eine `.greg.db` mit validem Header ist. Wenn nicht, wird sie als Vanilla eingestuft.
## Was passiert bei einem Vanilla Save?
`GregFeatureGuard.IsVanillaSave` wird auf `true` gesetzt.
Folgende Features werden zum Schutz des Spielstands deaktiviert:
- `GridPlacement` (keine Racks übers Grid platzieren)
- `SaveEngine.Write` (keine LiteDB-Updates)
## Was Spieler tun müssen
Um alle Modding-Features voll auszunutzen, muss ein neues Spiel gestartet werden, das ausschließlich über die `greg.SaveEngine` gespeichert wird.
## Migration (WIP)
Gibt es einen Konverter? Nein, aktuell nicht. (Siehe `MISSING.md` für zukünftige Entwicklungen im Save-Parser).
## GregFeatureGuard API
```csharp
// Vanilla-Save-Status prüfen
if (GregFeatureGuard.IsVanillaSave) {
LoggerInstance.Warning("Vanilla save — custom save disabled");
return;
}
```
-84
View File
@@ -1,84 +0,0 @@
---
title: MoonSharp Lua Integration
description: Technische Referenz zur Lua-Integration in gregCore über MoonSharp 2.0.0.
slug: /moonsharp-lua-integration
---
## Was ist MoonSharp und warum 2.0.0?
MoonSharp ist eine reine .NET-Lua-Implementierung ohne native Lua-DLL. Für `gregCore` bedeutet das:
- kompatibel mit IL2CPP/MelonLoader-Setup
- leichtes Embedding in `gregCore.dll`
- klare Sandbox-Steuerung
`gregCore` verwendet MoonSharp **2.0.0** als feste Framework-Dependency.
## Lua Lifecycle in gregCore
1. **Scan**: Registry sucht `*.lua` in `Mods/Scripts`.
2. **Activate**: `GregLuaHost` wird nur bei Treffer aktiviert.
3. **Execute**: `LuaFFIBridge` lädt Lua-Entrypoints.
4. **Unload**: `Shutdown()` leert Host-Zustand.
```csharp
// Signatur
public sealed class GregLuaHost : IGregLanguageHost
```
## Minimalbeispiel (funktionsfähig)
```lua
-- Datei: Mods/Scripts/demo.lua
greg.log_info("[demo.lua] init")
greg.on("greg.lifecycle.GameLoaded", function(payload)
greg.log_info("Game loaded hook fired")
greg.show_notification("Lua hook active")
end)
```
## Exponierte Lua-API (aktuell)
> Quelle: `LuaFFIBridge.RegisterApi`.
- Logging: `log_info`, `log_warning`, `log_error`
- Economy: `get_player_money`, `set_player_money`, `get_player_xp`, `set_player_xp`, `get_player_reputation`, `set_player_reputation`
- World: `get_server_count`, `get_rack_count`, `get_switch_count`, `get_broken_server_count`, `get_broken_switch_count`
- Technicians: `get_free_technician_count`, `get_total_technician_count`, `dispatch_repair_server`, `dispatch_repair_switch`
- Time: `get_time_of_day`, `get_day`, `get_seconds_in_full_day`, `set_seconds_in_full_day`
- Game: `get_current_scene`, `is_game_paused`, `set_game_paused`, `get_time_scale`, `set_time_scale`, `trigger_save`, `get_difficulty`
- Player/UI: `get_player_position`, `show_notification`
- Events/Hooks: `subscribe_event`, `fire_event`, `on`, `fire`
- Config: `config_set_bool`, `config_get_bool`, `config_set_int`, `config_get_int`, `config_set_string`, `config_get_string`
## Fehlerbehandlung
Lua-Syntax- oder Laufzeitfehler werden abgefangen und im MelonLoader-Log gemeldet.
```csharp
// Signatur
private static void SafeCall(LuaPlugin p, Closure? func, params object[] args)
```
## Debugging
- Primärer Kanal: `MelonLoader/Latest.log`
- Prefixe:
- `[gregCore] ...` (Framework-Level)
- `[LuaMod:<id>] ...` (Plugin-/Script-Layer)
## Manifest- und Config-Anforderungen
- Manifest: [UNVERIFIED] aktuelles Lua-Manifest-Schema im Repo nicht eindeutig versioniert.
- `config.json`: [UNVERIFIED] modulabhängig; empfohlen sind einfache Key/Value-Paare.
## Deployment
- Lege Lua-Dateien unter `Mods/Scripts` ab.
- Stelle sicher, dass mindestens eine `*.lua` vorhanden ist, damit `GregLuaHost` startet.
## Fehlende Bausteine
Siehe `MISSING.md` für offene Integrationspunkte (z. B. standardisiertes Lua-Manifest-Schema).
-117
View File
@@ -1,117 +0,0 @@
---
title: Scripting Language Support
description: Übersicht über alle von gregCore unterstützten Script-Sprachen inklusive Aktivierungslogik und Host-Mapping.
slug: /scripting-language-support
---
## Überblick
`gregCore` unterscheidet strikt:
- **Plugins**: MelonLoader-Assemblies (`*.dll`)
- **Scripts**: Sprachdateien in `Mods/Scripts` (`*.lua`, `*.py`, `*.rs`, `*.rmod`, `*.js`, `*.ts`, `*.cs`)
> ⚠️ WIKI↔CODE CONFLICT: Ältere Bridge-Implementierungen nutzen intern noch `Plugins/<Lang>`-Ordner. Die Aktivierungslogik scannt jetzt `Mods/Scripts` als Source of Truth.
## Aktivierungsmodell (On-Demand)
Beim Start (`OnInitializeMelon`) ruft `gregCore` auf:
```csharp
// Signatur
public static void ScanAndActivate(string modsScriptsDir)
```
Die Registry aktiviert ausschließlich Hosts, für die Dateien erkannt wurden.
```csharp
// Signatur
public static bool IsActive(Language lang)
```
```csharp
// Signatur
public static IGregLanguageHost GetHost(Language lang)
```
## Sprach-Matrix
| Sprache | Muster in `Mods/Scripts` | Abhängigkeit in `gregCore` | Host | Status |
|---|---|---|---|---|
| Lua | `*.lua` | MoonSharp `2.0.0` | `GregLuaHost` | Aktivierbar |
| Rust | `*.rs`, `*.rmod` | Rust-Bridge (FFI/ABI-Layer) | `GregRustHost` | Aktivierbar |
| Python | `*.py` | Python-Host-Bindings (`pythonnet` / `Python.Runtime`) | `GregPythonHost` | Aktivierbar bei Runtime |
| C# Script | `*.cs` | Roslyn (falls vorhanden) | `GregCSharpScriptHost` | [UNVERIFIED] Ausführungslayer |
| JS / TS | `*.js`, `*.ts` | Jint JS-Runtime-Binding | `GregJsHost` | `*.js` aktiv, `*.ts` benötigt Transpile |
## Einstieg je Sprache
### Lua
- Einsatzzweck: schnelle Gameplay-Automation, Hooks, Utilities.
- Host: `GregLuaHost`.
```lua
-- Datei: Mods/Scripts/hello.lua
greg.log_info("Hello from Lua")
```
### Rust
- Einsatzzweck: performancekritische Module, FFI-Integration.
- Host: `GregRustHost`.
```rust
// Datei: Mods/Scripts/example.rs
// Hinweis: derzeit FFI-Brücke nutzt native Exports; reine .rs-Datei ist Trigger für Host-Aktivierung.
fn main() {
// runtime-spezifisch
}
```
### Python
- Einsatzzweck: Prototyping, Automation, Daten-Workflows.
- Host: `GregPythonHost`.
```python
# Datei: Mods/Scripts/hello.py
greg.log_info("Hello from Python")
```
### C# Script
- Einsatzzweck: Skriptbasierte C#-Erweiterungen ohne Plugin-Build.
- Host: `GregCSharpScriptHost`.
```csharp
// Datei: Mods/Scripts/hello.cs
// [UNVERIFIED] Vollständige Script-Ausführung hängt von Roslyn-Runtime ab.
```
### JavaScript / TypeScript
- Einsatzzweck: schnelle Script-Automation, modulare Tools.
- Host: `GregJsHost`.
```javascript
// Datei: Mods/Scripts/hello.js
greg_log("Hello from JS");
```
```ts
// Datei: Mods/Scripts/hello.ts
// Derzeit nur Erkennung; Transpiler-Integration ist notwendig.
```
## Bekannte Einschränkungen
- `GregCSharpScriptHost`: Ausführungslayer ist in `MISSING.md` dokumentiert.
- TypeScript: Erkennung vorhanden, keine integrierte Transpile-Pipeline.
- Python: Wenn `Python.Runtime.dll` fehlt, bleibt Python-Host deaktiviert.
## Weiterführende Seiten
- [MoonSharp Lua Integration](./moonsharp-lua-integration.md)
- [Getting Started](./getting-started.md)
- [Framework Dependencies](./framework-dependencies.md)
-125
View File
@@ -1,125 +0,0 @@
# 1) Globale Architektur & Singletons
Analysebasis: `gregReferences/Assembly-CSharp/Il2Cpp/*.cs` (IL2CPP-Wrapper). Relevante Komponente liegt in der Schicht **Unity Spiel / IL2CPP Assembly** (nicht GregCore/Core-SDK selbst).
- `Il2Cpp.MainGameManager`
- Singleton: `public static unsafe MainGameManager instance`
- Verantwortlich für Session-/Spielzustand, Kundenfluss, Autosave-Settings, zentrale Objekt-Referenzen.
- Wichtige Methoden: `public unsafe void SetAutoSaveInterval(float minutes)`, `public unsafe void SetAutoSaveEnabled(bool enabled)`, `public unsafe int GetFreeVlanId()`.
- `Il2Cpp.NetworkMap`
- Singleton: `public static unsafe NetworkMap instance`
- Zentrale Topologie-/Routing-Instanz für Geräte, Kabel, Verbindungen.
- `Il2Cpp.PlayerManager`
- Singleton: `public static unsafe PlayerManager instance`
- Input-/Movement-Gating und Interaktionszustand (Objekt in Hand, Interaktionsflags).
- `Il2Cpp.TimeController`
- Singleton-ähnliche globale Zeitinstanz mit statischem Callback `public static unsafe TimeController.OnEndOfTheDay onEndOfTheDayCallback`.
- `Il2Cpp.SaveData`
- Globaler Save-State: `public static unsafe SaveData instance` + `public static unsafe SaveData _current`.
- `Il2Cpp.SaveSystem`
- Statischer Save/Load-Orchestrator (kein klassischer Singleton, aber globaler Entry-Point über statische API).
# 2) Spieler & Entities (Data Structures)
Hauptobjekte mit C-ABI-relevanten Datentypen (für stabile Bridge-Übergabe bevorzugt: primitive numerische Typen + explizite Structs).
- `Il2Cpp.Player`
- Ökonomie-/Progress-Felder: `money` (`float`), `xp` (`float`), `reputation` (`float`), `previousCoins` (`float`).
- Choke-Methoden: `public unsafe bool UpdateCoin(float _coinChhangeAmount, bool withoutSound = false)`, `public unsafe bool UpdateXP(float amount)`, `public unsafe void UpdateReputation(float amount)`.
- `Il2Cpp.PlayerData` (`[Serializable]`)
- Felder: `List<int> activeObjectives`, `float coins`, `float xp`, `float reputation`, `Il2CppStructArray<float> position`.
- Für C-ABI gut geeignet: `float`, `int`; bei `position` sauber als 3er-Array (`x,y,z`) flatten.
- `Il2Cpp.SaveData` (`[Serializable]`)
- Persistenz-Aggregat mit `playerData`, `networkData`, `loadedScenes`, `technicianData`, `repairJobQueue`, `commandCenterLevel` u. a.
- Mappings enthalten viele primitive Felder (`int`, `bool`, `float`, `string`) plus Listen/Arrays.
- `Il2Cpp.Item` (`ScriptableObject`)
- Preis-/Wertfelder: `int price`, `float weight`, `float deprecation`, `bool isStackable`, `int unlockedFromXP`.
- `Il2Cpp.ShopItemSO` (`ScriptableObject`)
- Shop-relevante Primitive: `int xpToUnlock`, `int price`, `int itemID`, `float eol`, `bool isCustomColor`.
- ECS-nahe explizite Layout-Typen (`[StructLayout(LayoutKind.Explicit)]`)
- `Il2Cpp.CableIDComponent`: `int CableId` (Offset 0), `int SwitchId` (Offset 4).
- `Il2Cpp.PacketComponent`: enthält `float3`, `float4`, `int cableId`, `int customerId`, `float moveSpeed` etc.
- Diese Typen sind für Low-Level-Hooks/Interop besonders wertvoll, da Feldlayout explizit ist.
# 3) Native Event-Systeme
Primär Delegate-basierte C#-Events/Callbacks in der **Unity Spiel / IL2CPP Assembly**-Schicht:
- Save-/Load-Callbacks (`Il2Cpp.SaveSystem`)
- `public static unsafe SaveSystem.OnSavingData onSavingData`
- `public static unsafe SaveSystem.OnLoadingData onLoadingData`
- `public static unsafe SaveSystem.OnLoadingDataLater onLoadingDataLater`
- Delegates sind `MulticastDelegate`-Typen mit `Invoke()`.
- Szenen-/Load-Callback (`Il2Cpp.LoadingScreen`)
- `public static unsafe LoadingScreen.GameIsLoaded onGameIsLoadedCallback`
- `LoadingScreen.GameIsLoaded` ist `MulticastDelegate` mit `Invoke()`.
- Tageszyklus-Callback (`Il2Cpp.TimeController`)
- `public static unsafe TimeController.OnEndOfTheDay onEndOfTheDayCallback`
- Delegate `OnEndOfTheDay.Invoke()` als stabiler Lifecycle-Hook.
- Pause-Menü-Callbacks (`Il2Cpp.PauseMenu`)
- `public static unsafe PauseMenu.OnPauseMenuOpen onPauseMenuOpenCallback`
- `public static unsafe PauseMenu.OnPauseMenuClose onPauseMenuCloseCallback`
- Input-Rebind-Events (`Il2Cpp.InputManager`)
- `public static unsafe void add_rebindComplete(Il2CppSystem.Action value)` / `remove_rebindComplete(...)`
- `add_rebindCanceled(...)` / `remove_rebindCanceled(...)`
- `add_rebindStarted(Il2CppSystem.Action<InputAction, int> value)` / `remove_rebindStarted(...)`
# 4) Kritische Hook-Ziele (Harmony Patch Candidates)
Kernziel: Choke-Points patchen (Prefix/Postfix), nicht breit `Update()`-spammen.
- Save/Load (höchste Priorität)
- `Il2Cpp.SaveSystem.SaveGame(string savename = null, string stringNameOfSave = null)`
- `Il2Cpp.SaveSystem.LoadGame(string savename)`
- `Il2Cpp.SaveSystem.Load(string savename, bool isFromPauseMenu)`
- `Il2Cpp.SaveSystem.AutoSave()`
- `Il2Cpp.SaveSystem.SaveGameData()` / `LoadGameData()`
- Economy/Progress
- `Il2Cpp.Player.UpdateCoin(float _coinChhangeAmount, bool withoutSound = false)`
- `Il2Cpp.Player.UpdateXP(float amount)`
- `Il2Cpp.Player.UpdateReputation(float amount)`
- Shop-Zahlungspfad: `Il2Cpp.ComputerShop.ButtonCheckOut()`, `UpdateCartTotal()`, `BuyNewItem(...)`, `BuyAnotherItem(...)`.
- Netzwerk-/Topologie
- `Il2Cpp.NetworkMap.AddDevice(string name, CableLink.TypeOfLink type, int customerID = -1)`
- `Il2Cpp.NetworkMap.RemoveDevice(string name)`
- `Il2Cpp.NetworkMap.Connect(string from, string to)` / `Disconnect(string from, string to)`
- `Il2Cpp.NetworkMap.RegisterCableConnection(...)` / `RemoveCableConnection(int cableId, bool preserveLACP = false)`
- Validierung: `Il2Cpp.NetworkMap.IsIpAddressDuplicate(string ip, Server serverToExclude)`
- Geräte-/Serverzustand
- `Il2Cpp.Server.PowerButton(bool forceState = false)`
- `Il2Cpp.Server.SetIP(string _ip)`
- `Il2Cpp.Server.UpdateCustomer(int newCustomerID)`
- `Il2Cpp.Server.UpdateAppID(int _appID)`
- `Il2Cpp.Server.ItIsBroken()` / `RepairDevice()`
# 5) UI & Szenen-Management
UI-/Scene-Flows mit hoher Relevanz für kontrollierte Mod-Intervention:
- Main Menu (`Il2Cpp.MainMenu`)
- `Continue()`, `NewGame()`, `LoadGame()`, `Settings()`, `QuitGame()`.
- Pause Flow (`Il2Cpp.PauseMenu`)
- `Pause(int openMenu)`, `Resume()`, `Save(string saveName = null, string _stringNameOfSave = null)`, `Load(string savename)`.
- Gute Hook-Stellen für mod-seitige Gatekeeper/Overlay-Interlocks.
- Loading/Scenes (`Il2Cpp.LoadingScreen`)
- `LoadGameScenesVoid(...)`, `LoadLevel(int sceneIndex)`, `UnLoadLevel(int sceneIndex)`
- `AsynchronousLoad(int sceneIndex)`, `AsynchronousUnLoad(int sceneIndex)`, `IsSceneLoaded(string name)`
- `onGameIsLoadedCallback` als zuverlässiger End-of-Load Synchronisationspunkt.
- Shop-/Asset-UI
- `Il2Cpp.ComputerShop`: Kauf- und Warenkorb-UI-Endpunkte.
- `Il2Cpp.AssetManagement`: Asset-Filter/Repair-UI-Workflows (relevant für automatische Tasking-Mods).
# 6) Obfuscation & Auffälligkeiten
- Obfuscation-Marker vorhanden
- `Il2Cpp.ObjectPrivateAbstractSealedInVo0` trägt `[ObfuscatedName("$BurstDirectCallInitializer")]`.
- Deutet auf generierte/Burst-nahe Initialisierer hin (kein klassischer Gameplay-Entry-Point).
- IL2CPP-/Interop-Spezifika
- Weit verbreitete `unsafe` Wrapper, `NativeFieldInfoPtr_*`, `NativeMethodInfoPtr_*`, `il2cpp_runtime_invoke`.
- Für Harmony-Patching sind semantische High-Level-Methoden stabiler als intern generierte Helper.
- Explizite Layouts als technische Auffälligkeit
- `[StructLayout(LayoutKind.Explicit)]` in u. a. `CableIDComponent`, `PacketComponent`, `_PrivateImplementationDetails_`.
- Wichtig für deterministische Feld-Offsets bei nativer Bridge/ABI.
- Anti-Cheat-Indikatoren (Textscan)
- Kein direkter String-/Symboltreffer auf typische Marker wie `EasyAntiCheat`, `BattlEye`, `VAC`, `GameGuard`, `AntiCheat` im gescannten Dump.
- Das ist **kein** kryptografischer Nachweis „anti-cheat-frei“, aber im vorliegenden C#-Dump gibt es keine offensichtlichen API-Hooks darauf.
+3 -3
View File
@@ -13,9 +13,9 @@
<EnableDefaultCompileItems>false</EnableDefaultCompileItems>
<EnableDefaultEmbeddedResourceItems>false</EnableDefaultEmbeddedResourceItems>
<EnableDefaultNoneItems>false</EnableDefaultNoneItems>
<Version>1.0.0.38</Version>
<FileVersion>1.0.0.38</FileVersion>
<AssemblyVersion>1.0.0.38</AssemblyVersion>
<Version>1.0.0.40-pre</Version>
<FileVersion>1.0.0.40-pre</FileVersion>
<AssemblyVersion>1.0.0.40-pre</AssemblyVersion>
</PropertyGroup>
<ItemGroup>
-19
View File
@@ -1,19 +0,0 @@
# Vendored MelonLoader references (Live-Sync)
This folder mirrors `MelonLoader/net6` and `MelonLoader/Il2CppAssemblies` from your **Data Center** install.
- **Do not commit** `*.dll` files (see `.gitignore`).
- Run from the repo root:
```bash
python tools/refresh_refs.py
```
Or set `DATA_CENTER_GAME_DIR` to your game root, or pass `--game-dir "C:\Program Files (x86)\Steam\steamapps\common\Data Center"`.
After sync, `gregCore.csproj` will prefer `lib/references/MelonLoader` when `net6/MelonLoader.dll` exists, so IDEs and CI can build without a Steam path.
Optional: `python tools/refresh_refs.py --watch` polls for interop changes after game updates.
See also: `MANIFEST.txt` (generated) and `tools/diff_assembly_metadata.py`.
-196
View File
@@ -1,196 +0,0 @@
# modding_core_architecture_summary
> Zweck: Single Source of Truth für AI-/Bridge-Entwicklung (Lua, Rust, Go, Python, TS/JS) gegen gregCore.
>
> Scope: Laufzeit im Spielprozess (MelonLoader + Unity IL2CPP), inklusive FFI, IPC, Eventing und Sicherheitsgrenzen.
## 1) Runtime Lifecycle, Bootstrap & Schichten
### Schichtzuordnung (verbindlich)
- **Unity Spiel / IL2CPP Assembly (Game Layer):** gepatchte Spieltypen/Methoden (z. B. `Player.UpdateCoin`, `ServerPowerButton`, UI/Save-Methoden).
- **GregFramework Core SDK (Core Layer):** `src/gregModLoader/gregCore.cs`, `gregHarmonyPatches.cs`, `gregFfiBridge.cs`, `gregGameApi.cs`, `gregEventDispatcher.cs`.
- **Plugin Layer:** `src/gregModLoader/Plugins/*` (`gregPluginBase`, `gregRegistry`, Dependency-Resolver).
- **Language Bridges:** `src/Scripting/*` (`iGregLanguageBridge`, `gregLanguageBridgeHost`, Lua/JS/Rust/Go-Bridges).
- **Mod Layer:** User-Mods, native DLL-Mods (FFI), Script-Mods.
### Haupt-Entry und Aufrufreihenfolge
- **Core-Layer Entry:** `gregCoreLoader : MelonMod` in `src/gregModLoader/gregCore.cs`.
- Relevante Lifecycle-Methoden:
- `OnInitializeMelon()`
- `OnSceneWasLoaded(int buildIndex, string sceneName)`
- `OnUpdate()`
- `OnFixedUpdate()`
- `OnGUI()`
- `OnApplicationQuit()`
### Effektive Initialisierungssequenz
1. Core initialisiert Konfiguration, Aktivierung/Flags, Logging.
2. Core erstellt/initialisiert FFI (`gregFfiBridge`) und API-Tabelle (`gregGameApi`).
3. Core initialisiert Script-Host (`gregLanguageBridgeHost`) und lädt Bridges.
4. Core installiert Harmony-Patches (`gregHarmonyPatches`).
5. Plugins werden registriert/aufgelöst (`gregRegistry`, `gregDependencyResolver`) und über Ready-Callbacks aktiviert.
6. Runtime-Loop verteilt Update-Ticks an Core, Bridges und FFI-Module.
### Shutdown-Semantik
- `OnApplicationQuit()` triggert geordnetes Stoppen:
- Script-Host/Bridges herunterfahren,
- native FFI-Module via `mod_shutdown` und `FreeLibrary` freigeben,
- Pointer/Handles im `gregGameApi.Dispose()` bereinigen.
---
## 2) IL2CPP Hooking-Modell & Ausführungsfluss
### Hook-Ebene
- **Core Layer:** `src/gregModLoader/gregHarmonyPatches.cs` patcht IL2CPP-Spielmethoden mit Harmony Prefix/Postfix.
- Ziel ist **Event-Proxying**, nicht direkter unkontrollierter Mod-Zugriff auf Unity-Typen.
### Hook-zu-Event Pipeline
1. IL2CPP-Methode wird gepatcht (Prefix/Postfix).
2. Patch extrahiert primitive/struct-basierte Daten.
3. Dispatch über `EventDispatcher`/`gregEventDispatcher` mit numerischer `EventIds`-ID.
4. `GregHookIntegration` mappt `eventId -> greg.*` Hookname (`gregNativeEventHooks`).
5. Hook-Payload wird normalisiert (`BuildPayload(...)`) und an Bus/FFI weitergereicht.
### Canonical Hook-Namen
- Mapping erfolgt dynamisch via `GregHookRegistry` (`assets/greg_hooks.json`), was Hash-basierte Event-IDs für das FFI generiert.
- Primärquelle für Namen: `greg_hooks.json` + framework-only Ergänzungen via `gregHookName.Create(...)`.
- Fallback bei unbekannten IDs: `greg.SYSTEM.UnmappedNativeEvent`.
### Cancelable vs Non-cancelable
- `gregEventDispatcher` unterstützt normale und cancelable Listener (`Func<string, object, bool>`).
- Cancel-Pfad wird in Patchpunkten genutzt, wo Spielaktion blockierbar ist.
---
## 3) Interop, FFI & IPC (ABI, Ports, Protokolle)
### Native FFI (Core ↔ Native Mod)
- **Core Layer Datei:** `src/gregModLoader/gregFfiBridge.cs`.
- Win32 Loader-API:
- `LoadLibrary`
- `GetProcAddress`
- `FreeLibrary`
- Erwartete native Exports (C-ABI):
- `mod_info`
- `mod_init`
- `mod_update`
- `mod_fixed_update`
- `mod_on_scene_loaded`
- `mod_on_gui`
- `mod_shutdown`
- `mod_on_event`
### API-Table für native Module
- **Core Layer Datei:** `src/gregModLoader/gregGameApi.cs`.
- Versioniertes Struct: `GameAPITable` (aktuell auf v12 erweitert).
- Delegates werden via `Marshal.GetFunctionPointerForDelegate(...)` als Funktionszeiger exportiert.
### IPC/Netzwerkflächen
- **MCP HTTP Server (Core/Tooling-Grenze):** `GregMCPServer` via `HttpListener` (localhost).
- **Multiplayer Transport (Plugin/Core):** WebSocket-Client in `GregMultiplayerService`.
- **Plugin-Sync (Core/Service):** `HttpClient` in `gregPluginSyncService`.
- **Native Plattform-Interop:** Steam-P2P via `steam_api64`-Imports in `gregGameApi.cs`.
### Bridge-Host für Sprachen
- **Language Bridge Layer:** `iGregLanguageBridge` + `gregLanguageBridgeHost`.
- Lua: MoonSharp; JS/TS: Jint; Rust/Go über Bridge-Adapter.
- Host ist der Isolations- und Lifecycle-Knoten für alle Script-Runtimes.
---
## 4) Memory Boundaries, Ownership & Lifetime
### Ownership-Regeln an der FFI-Grenze
- **Unmanaged Allokation durch Core:** `Marshal.AllocHGlobal`.
- **Freigabe durch Core nach Callback:** `Marshal.FreeHGlobal` (symmetrisch im Dispatch-Pfad).
- **String-Marshalling:** `Marshal.StringToHGlobalAnsi` / `Marshal.PtrToStringAnsi`.
- **Blittable Struct Transfer:** `[StructLayout(LayoutKind.Sequential)]` in Event-Payloads.
### Delegate-/Function-Pointer-Lifetime
- Delegates für API-Funktionen werden als Felder gehalten, damit der GC keine Funktionszeiger invalidiert.
- `GameAPITable` speichert `IntPtr` auf Delegate-Stubs; Freigabe zentral im `Dispose()`.
### GCHandle-Verwendung
- Für Event-/Payload-Weitergabe werden `GCHandle.Alloc(...)` Handles erzeugt.
- Handles werden nach Verwendung explizit gelöst (`GCHandle.Free()`), um Leaks/Pinning-Druck zu verhindern.
### Fehlerresilienz an Grenzstellen
- FFI-Aufrufe sind einzeln in `try/catch` eingefasst.
- Fehler in einem Modul dürfen den Core-Loop nicht terminieren (Fail-isolated execution).
### Kritische ABI-Regeln für externe Bindings
- Struct-Reihenfolge/Field-Typen sind ABI-kritisch; keine Reorder/Pack-Änderung ohne Version-Bump.
- Auf der Bridge-Seite nur stabile primitive Typen (`int`, `uint`, `float`, `byte[]`, `IntPtr`) übergeben.
- Keine Ownership-Mehrdeutigkeit: jeder Pointer braucht eindeutige „who frees“-Regel.
---
## 5) DTOs, Manifeste & Serialisierung
### Typfamilien
- **Runtime Event DTOs (Core):** `src/gregModLoader/Events/*.cs` (`iModEvent` mit `DateTime OccurredAtUtc`).
- **Native Event Struct DTOs (Core):** `src/gregModLoader/gregEventDispatcher.cs` (z. B. `ValueChangedData`, `DayEndedData`, `ShopItemAddedData`).
- **SDK/Config DTOs (Core/SDK):**
- `GregUiReplacementManifest`
- `ModelOverrideManifest`
- `ServerDefinition`
- `ItemDefinition`
- `PluginSyncConfig`, `PluginSyncManifest`
### Serializer-Stack
- `System.Text.Json` für Runtime-/Service-Pfade (`GregPersistenceService`, MCP-Antworten).
- `Newtonsoft.Json` in Teilen des Config-Stacks (`GregConfigService`).
- Konsequenz: DTO-Contracts sind serializer-agnostisch zu halten (öffentliche Properties/Fields stabil).
### Feld- und Versionsstabilität
- Event- und Manifest-Felder sind externe Verträge für Bridges/Mods.
- Änderungen nur additiv und versioniert (insb. API-Table + manifestartige Contracts).
- Entfernen/Umbenennen erzeugt harte Breaking Changes für native und Script-Bindings.
### Datentyp-Praxis für Multi-Language Bindings
- Bevorzugt JSON-kompatible Primitiven und flache Objekte.
- Für binäre Übergaben klar deklarierte Byte-Arrays + Länge.
- Keine impliziten Unity-/IL2CPP-Objektreferenzen in öffentlichen Bridge-DTOs.
---
## 6) Event-System, Hook-API & Sandboxing-Einschränkungen
### Event-Systeme (parallel vorhanden)
1. **String-basierter Hook-Bus (Core):** `gregEventDispatcher` mit Hooknamen `greg.<DOMAIN>.<Event>`.
2. **Type-safe Bus (SDK):** `GregEventBus` (`Subscribe<T>`, `Publish<T>`, `Unsubscribe<T>`).
3. **Native Event-ID Dispatch (Core↔FFI):** `EventIds` + struct-payload + `mod_on_event`.
### Hook-Namenskonvention
- Kanonisch: `greg.<Domain>.<Event>` (bzw. in Altbeständen teils uppercase Domains).
- Mappingquelle für native IDs: `gregNativeEventHooks.ByEventId`.
- Hook-Integration: `GregHookIntegration.EmitForSimple/EmitForStruct`.
### Sandboxing-Realität (wichtig für AI/Bridge-Design)
- **Lua I/O Modul:** `src/Scripting/Lua/LuaModules/gregIoLuaModule.cs` enthält Dateioperationen (`read_file`, `write_file`, `list_files` etc.).
- Kommentar behauptet Sandbox-Scope, Implementierung zeigt aktuell keine harte Pfad-Isolation auf OS-Ebene.
- **ReferenceScanner:** lädt Assemblies via `Assembly.LoadFrom` aus Dateisystemscan; keine AppDomain/Process-Isolation.
- Damit gilt: aktuelle Isolation ist primär **kooperativ/logisch**, nicht sicherheitstechnisch stark.
### Verbindliche Einschränkungen für neue Bindings
- Bridge-Code darf Core/Unity-Aufrufe nur über freigegebene API/Hooks ausführen.
- Keine direkten unsicheren Pointer-Operationen außerhalb definierter FFI-Wrapper.
- Untrusted Script/Native Mods als potenziell fehlerhaft behandeln (guard clauses + timeout/backpressure + exception fences).
- Für echte Sandbox-Anforderungen ist Prozessisolation (separater Host) nötig; im aktuellen In-Process-Modell nicht garantiert.
---
## Appendix: Operative Leitplanken für Bridge-Autoren
- **Schichtdisziplin:**
- Mod/Bridge → `greg.*` Hook/API,
- kein direkter Unity-Objektzugriff als öffentliches Contract.
- **ABI-Disziplin:**
- `StructLayout.Sequential`, feste Feldtypen, versionierte Erweiterung.
- **Fehlerdisziplin:**
- Jede Grenzstelle (`FFI`, `JSON parse`, `network`) mit `try/catch` + Logging.
- **Lifecycle-Disziplin:**
- `init -> update/fixed_update/gui -> shutdown` strikt einhalten.
- **Kompatibilität:**
- Runtime-Ziel bleibt `.NET 6` (IL2CPP/MelonLoader-kompatibel).
-125
View File
@@ -1,125 +0,0 @@
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [1.0.0.35-pre] - 2026-04-21
### Fixed
- **Unity 6 Compatibility**: Fixed `UpdateCoin` Harmony patch parameter name mismatch (`_amount` -> `_coinChhangeAmount`).
- **Stability**: Switched `GregDevConsole` and UI windows to `GUI.Window` to avoid `LayoutedWindow` constructor errors in Unity 6.
- **HexViewer**: Major refactor to use stable IMGUI and current SDK namespaces.
## [0.1.0] - 2026-04-18
### Added
- NuGet packaging baseline for `gregCore` with symbol package output (`.snupkg`).
- Local + GitHub Packages feed configuration and package source mapping.
- Downstream `build/gregCore.props` integration for reference-only package usage.
## [v1.0.0.7] - 2026-04-12
### Added
- **gregUI**: Complete UI manipulation layer for UGUI (`src/UI/`).
- **GregUIManager**: Central canvas registry and lifecycle management.
- **GregUITheme**: Design system tokens (The Luminescent Architect).
- **GregUIBuilder**: Fluent builder API for mod developers.
- **UI Components**: `GregPanel`, `GregButton`, `GregLabel`, `GregToggle`, `GregSlider`, `GregBadge`, `GregSeparator`.
- **HexViewer Integration**: UI Tree Inspector (F1), Hook Monitor (F2), Element Inspector (F3).
- **UI Hooks**: New hook category `greg.UI.*` for monitoring game UI events (MainMenu, PauseMenu, HUD, Tooltips).
### Changed
- `gregCoreLoader.OnInitializeMelon`: Now registers `GregUIManager`.
- `gregUiExtensionBridge.OnSceneLoaded`: Now notifies `GregUIManager`.
## [v1.0.0.6] - 2026-04-12
### Added
- **Game Compatibility Update**: Verified compatibility with *Data Center* patch `v1.0.45.5`.
- **VLAN Management**: Added `SetVlanAllowed`, `SetVlanDisallowed`, and `IsVlanAllowed` to `gregGameHooks` and `gregGameApi` (v9).
- **Route Evaluation**: Documented hooks for improved routing system.
- **gregReferences Synchronization**: Updated reference documentation for the new game version.
## [v1.0.0.0] - 2026-04-11
### Added
- **Phase 5 Implementation**: Initial SDK bridges for Economy and Data.
- **GregBalanceService**: Access to financial data, salaries, and income simulation.
- **GregLocalisationService**: Direct access to the game's internal translation system.
- **Roadmap Expansion**: Added Phase 8 (Unity Scripting API) and refactored all documentation to English with Material Symbols.
## [v1.0.0.0] - 2026-04-11
### Added
- **Game System Bridges**: 9 new SDK services for direct control of game systems via IL2CPP abstraction.
- **Hardware Bridges**: Direct interaction with physical server and rack objects.
### Added
- **Unity Signal Normalization**: 30+ canonical hooks in `GregNativeEventHooks` based on IL2CPP snapshots.
- **Full Category Registries**: Offizielle SDK-Registries für Server, Switches, Kunden, Mitarbeiter, SFP, Kabel, Möbel und Items.
- **Advanced Model Overrides**: Priority-based conflict resolution, author metadata, and diagnostics.
- **Language Bridge APIs**: Dynamic event registration for Lua (`on_update`, `on_gui`) and C# bridge surface for TS/JS.
- **Native Header**: Added `greg_api.h` for Rust/C mod developers to consume the v8 API table.
- **Validation & Migration**: `IContentValidator` and `IContentMigration` interfaces for mod data integrity.
- **Functional Services**: Basic implementation for `GregIPAllocationService` and `GregRackService`.
### Fixed
- Fixed build issues with nullable reference types in `gregSdk`.
- Corrected test project references and added comprehensive integration tests.
## [v1.0.0.0] - 2026-04-11
### Fixed
- **Definitive UI Removal**: Fixed incorrect file exclusions in `.csproj` and disabled bootstrap registration in `gregCore.cs` to ensure the native UI is used.
- **Debug Overlay**: Added **F5** toggle to show/hide the debug info panel.
## [v1.0.0.0] - 2026-04-11
### Fixed
- Standardized all Lua modules to camelCase (`gregUnityLuaModule`, etc.).
- Fixed static/instance member access conflicts in `gregModSettingsMenuBridge`.
- Corrected over-aggressive renaming of Unity engine components (e.g. `Camera.main`).
- Normalized `gregSdk` namespace usage across the framework.
### Changed
- Separated `gregAddons` into its own logical structure (Node.js tools and optional plugins).
- Built-in reference DLLs for out-of-the-box CI support.
## [v1.0.0.0] - 2026-04-11
### Added
- Missing SDK APIs for all 4 languages (C#, Rust, Lua, TS/JS).
- HUD and Targeting bridge modules for Lua.
- Advanced event subscription model.
- Windows x64 and .NET 6 as primary targets.
### Changed
- **Major Refactor**: Renamed all directories and files to follow the `greg[Name]` camelCase convention.
- Global namespace update from `DataCenterModLoader` to `gregModLoader`.
- Global namespace update from `AssetExporter` to `gregAssetExporter`.
- Standardized author name to `MLeeM97`.
## [v0.7.0.0] - 2026-04-10
### Fixed
- Project references and solution structure for correct DLL paths.
- README path updates.
## [v0.6.0.0] - 2026-04-09
### Added
- Language bridge architecture with Lua and TypeScript/JavaScript support.
- MoonSharp integration for Lua scripting.
## [v0.5.0.0] - 2026-04-08
### Added
- `UiExtensionBridge` for UI feature integration and modernization.
- Custom Main Menu replacement capabilities.
## [v0.4.0.0] - 2026-04-07
### Added
- Scripts for generating and parsing greg hooks from IL2CPP dumps.
## [v0.3.0.0] - 2026-04-06
### Changed
- Flat `gregFramework` workspace layout.
- Documentation alignment with the new repository structure.
## [v0.2.0.0] - 2026-04-05
### Added
- RustBridge integration for native mod support via FFI.
## [v0.1.0.0] - 2026-04-04
### Added
- Initial standalone repository setup.
- Basic MelonLoader mod structure.
-89
View File
@@ -1,89 +0,0 @@
# gregCore - Framework Core
> The heart of the gregFramework modding ecosystem for Data Center.
**Author:** MLeeM97 (teamGreg) | **License:** MIT | **Framework:** [gregCore](https://git.datacentermods.com/teamGreg/gregCore)
---
## Features
- **GregSaveService** - Persistent mod data storage
- **GregUIBuilder** - FixedTableUI, Panel System, Canvas Management
- **GregPersistenceService** - Centralized `UserData/gregCore/Data/` storage
- **GregMCPServer** - Embedded HTTP MCP server (Port 10420) for external tooling
- **GregMultiplayerService** - WebSocket relay-based multiplayer
- **Harmony Patches** - MainMenu, MODS Button injection
- **IL2CPP Compatibility** - InputSystem, Coroutines, Il2CppTMPro
- **MoonSharp Lua** - Embedded scripting engine
- **Integrated DataCenter Compatibility Layer** - RustBridge/LangCompat runtime is embedded in-core under `src/Compatibility/DataCenterModLoader`
## Installation
1. Install **MelonLoader** (v0.6+)
2. Place `gregCore.dll` + `gregCore.dll` into `Game/Mods/`
3. Start the game and press **Framework auto-initializes on game start**
## Dependencies
- Built-in only (this IS the core)
- Legacy `RustBridge` and `LangCompatBridge` are integrated into `gregCore` and are no longer shipped as standalone external plugin/mod dependencies
## Architecture Update
- Legacy external trees `plugins/DataCenter-RustBridge` and `mods/greg.Plugin.LangCompatBridge` were retired from `gregCore`
- Runtime compatibility lifecycle is now wired directly from `GregCoreMod` to `DataCenterModLoader.Core`
- Compatibility sources are maintained in-core at `src/Compatibility/DataCenterModLoader`
## Building from Source
```bash
cd gregFramework/gregCore
dotnet build -c Release
# Output: bin/Release/net6.0/gregCore.dll
```
Or build everything at once:
```bash
cd gregFramework/deploy
./build-all.ps1
# Output: gregFramework/BuiltModsForGame/
```
## Links
- **Primary:** [git.datacentermods.com/teamGreg](https://git.datacentermods.com/teamGreg)
- **Discord:** [discord.gg/greg](https://discord.gg/greg)
---
## Contributors & Thanks
### Discord Community
**Thanks to:**
- **Noootry**
- **TheSlickers**
- **Jarvis**
- **Kirei**
- **TeamWaseku** (ModernSamurai, GamerFrankstar, Ultra, Zyn)
*...for keeping the community alive!*
### Code & Testing
**Special thanks:**
- **Joniii** & **mochimus** - Code + Tests
- **Baker**, **Sharpy1o1**, **MachineFreak** - Testing + Modeling
### Sponsors
- **@tobiasreichel** - Haupt-Sponsor
- **SQ8** - Infrastructure Hosting
---
*gregFramework - Powered by the Community!*
## Contributors
- @mleem97
- @Joniii11
+1 -1
View File
@@ -7,7 +7,7 @@ using gregCore.Core.Events;
using gregCore.Core.Persistence;
using Il2CppInterop.Runtime.Injection;
[assembly: MelonInfo(typeof(gregCore.Core.GregCoreMod), "gregCore", "1.0.0.38-pre", "TeamGreg")]
[assembly: MelonInfo(typeof(gregCore.Core.GregCoreMod), "gregCore", "1.0.0.40-pre", "TeamGreg")]
[assembly: MelonColor(255, 0, 191, 165)] // Teal
[assembly: MelonPriority(-1000)] // Load first!
-15
View File
@@ -1,15 +0,0 @@
# gregCore Architektur
## Schichten
Core/ → Framework-Kern, kein Unity-Coupling, vollständig testbar
Infrastructure/ → Implementierungen, kennt MelonLoader/Win32/Mono
GameLayer/ → IL2CPP + Harmony, nur Daten-Extraktion + Dispatch
PublicApi/ → Was Modder nutzen dürfen
## Goldene Regeln
1. Patches haben KEINE Business-Logic
2. GregCoreLoader hat MAX 50 Zeilen
3. GameAPITable: Neue Felder NUR ans Ende
4. Alle Services via Interface — nie direkt instanziieren
5. MelonLogger nur in MelonLoggerAdapter
6. Assembly.LoadFrom VERBOTEN — immer Mono.Cecil
-27
View File
@@ -1,27 +0,0 @@
# gregCore API — Modder Guide
## Einstieg
```csharp
using gregCore.PublicApi;
public class MyMod : GregMod
{
public override void OnLoad()
{
// Geld hinzufügen
greg.Economy.AddMoney(500f);
// Auf Tagesende reagieren
greg.Time.OnDayEnd += OnNewDay;
// UI-Feedback
greg.UI.ShowToast("MyMod geladen!");
}
private void OnNewDay()
{
greg.UI.ShowToast("Neuer Tag!");
}
}
```
+50
View File
@@ -164,6 +164,44 @@ private static GregUIBuilder CreateBase(string title, bool isTablet)
return this;
}
public GregUIBuilder AddInputField(string label, string defaultValue, Action<string> onChanged)
{
var obj = GregUIManager.CreateUIObject("InputGroup", _contentContainer);
obj.AddComponent<LayoutElement>().minHeight = 40f;
var inputObj = GregUIManager.CreateUIObject("InputField", obj);
var input = inputObj.AddComponent<InputField>();
input.text = defaultValue;
input.onValueChanged.AddListener(new Action<string>(onChanged));
var txt = inputObj.AddComponent<Text>();
txt.text = label;
GregUITheme.ApplyText(txt);
return this;
}
public GregUIBuilder AddDropdown<T>(string label, T[] options, int selectedIndex, Action<T> onSelected)
{
var obj = GregUIManager.CreateUIObject("DropdownGroup", _contentContainer);
obj.AddComponent<LayoutElement>().minHeight = 40f;
var dp = obj.AddComponent<Dropdown>();
dp.value = selectedIndex;
var txt = GregUIManager.CreateUIObject("Label", obj).AddComponent<Text>();
txt.text = label;
GregUITheme.ApplyText(txt);
return this;
}
public GregUIBuilder AddSection(string title)
{
return AddHeadline(title);
}
public GregUIBuilder AddSpacer(float height = 20f)
{
var obj = GregUIManager.CreateUIObject("Spacer", _contentContainer);
obj.AddComponent<LayoutElement>().minHeight = height;
return this;
}
public GregUIBuilder AddSearchableList<T>(IEnumerable<T> items, Func<T, string> labelSelector, Action<T> onSelected)
{
// Implementation of a scrollable list (UGUI ScrollRect based)
@@ -208,6 +246,18 @@ private static GregUIBuilder CreateBase(string title, bool isTablet)
GregUIManager.RegisterPanel(name, _activePanel);
return _activePanel;
}
public GregUIBuilder Show() => SetVisible(true);
public GregUIBuilder Hide() => SetVisible(false);
public GregUIBuilder Toggle() => SetVisible(!_activePanel.activeSelf);
private GregUIBuilder SetVisible(bool visible)
{
if (_activePanel != null) _activePanel.SetActive(visible);
return this;
}
public bool IsVisible => _activePanel?.activeSelf ?? false;
}
public class GregUIDragHandler : MonoBehaviour
-19
View File
@@ -1,19 +0,0 @@
# greg.NoMoreEOL
## What it does
- Prevents servers & switches from reaching end-of-life
- Automatically repairs broken devices
- Runs continuously during gameplay
- Includes an in-game config menu (via gregCore Settings API)
## Why I made it
I wanted to remove the repetitive maintenance part of the game and focus more on building and optimizing the network.
## Details
This module is fully integrated into the `gregCore` framework. It utilizes the native Settings API (accessible via the SDK and RustAPI) to expose configuration toggles directly in the F8 Settings Hub.
### Configuration Options
- **Auto Repair Switches**: Automatically repairs broken network switches.
- **Auto Repair Servers**: Automatically repairs broken servers.
- **Disable Switches EOL**: Prevents switches from reaching End-Of-Life.
- **Disable Servers EOL**: Prevents servers from reaching End-Of-Life.
+1 -1
View File
@@ -51,7 +51,7 @@ namespace greg.UI.Settings
{
RegisterTab("greg.core", "Framework", builder =>
{
builder.AddLabel("gregCore v1.0.0.35")
builder.AddLabel("gregCore v1.0.0.40-pre")
.AddLabel("MelonLoader v0.6+")
.AddLabel($"Save Mode: {(frameworkSdk.GregFeatureGuard.IsVanillaSave ? "Vanilla" : "Greg")}")
.AddToggle("Verbose Startup Log", false, v => { })