Se2 Dev Game Code

SE2 Game Code Search Skill

Allows reading the decompiled C# code of Space Engineers 2.

⚠️ CRITICAL: Commands run in a UNIX shell. Use bash syntax! On Windows this is BusyBox (busybox.exe <cmd>); on Linux use the native shell directly.

Examples:

• ✅ test -f file.txt && echo exists
• ✅ ls -la | head -10
• ❌ if exist file.txt (echo exists) - This will NOT work

Actions:

• prepare: Run the one-time preparation (Prepare.bat on Windows, prepare.sh on Linux)
• bash: Run UNIX shell commands (BusyBox on Windows, native shell on Linux)
• search: Run code searches using search_game_code.py
• test: Test this skill (test_search_game_code.bat on Windows, test_search_game_code.sh on Linux)

Routing Decision

Check these patterns in order - first match wins:

Requirements

The host system must have the following on PATH:

• Python 3.13 or newer
• git command line client (used to version each decompiled game build)
• dotnet SDK (for installing ilspycmd)

Getting Started

⚠️ CRITICAL: Before running ANY commands, read CommandExecution.md to avoid common mistakes that cause command failures.

If the Prepare.DONE file is missing in this folder, you MUST run the one-time preparation steps first. See the prepare action.

Folder Layout

After preparation the skill folder contains a Data junction (Windows) or symlink (Linux). The actual data lives outside the skill folder so that it is preserved across Clean.bat/Prepare.bat (Windows) or clean.sh/prepare.sh (Linux) cycles.

skills/se2-dev-game-code/
├── Data/                 (junction/symlink → per-user persistent game-code data)
│   ├── .git/             local Git repository tracking decompiled sources and content
│   ├── .gitignore        ignores CodeIndex/, graphify-out/, __pycache__, *.py[cod], *.bak, *.log
│   ├── game_version.txt  recorded SE2 version label
│   ├── game_files.json   SHA256 of every original game file (committed - diffable)
│   ├── Decompiled/       decompiled C# sources only, organised per assembly (committed)
│   ├── Content/          textual game content (committed - definition changes reviewable)
│   ├── CodeIndex/        CSV indexes (NOT committed - regenerated)
│   └── graphify-out/     Graphify graph of Decompiled/ (NOT committed - regenerated)
├── Game2/                (junction/symlink → game's Game2, removed after preparation)
└── ...                   skill scripts and documentation

The Data folder points at the per-user persistent data directory:

• Windows: junction to %USERPROFILE%\.se2-dev\game-code\ (%USERPROFILE% is used rather than %LOCALAPPDATA% so the data sits outside any per-app UWP filesystem virtualization).
• Linux: symlink to ~/.se2-dev/game-code/.

Treat Data/Decompiled, Data/Content and Data/CodeIndex the same way on every platform.

Local Versioning of Decompiled Sources

The Data folder is a local Git repository. Every successful preparation creates a commit of the decompiled C# sources and the copied content files whose message is the game's version label. Only the indexable text content is copied (definitions, translations, blueprints, shaders), never the binary assets, so definition changes stay reviewable and diffable across game versions.

This means:

• All previously decompiled game versions are preserved in the local Git history. You can git checkout any past commit inside Data/ to inspect or diff against an older build, and git diff two version commits to see what a game update changed in both the code and the content definitions.
• Game updates are detected automatically by comparing the binaries' embedded version with Data/game_version.txt. If they differ (or the file is missing), Decompiled/, Content/, CodeIndex/, graphify-out/ and game_files.json are wiped and a fresh decompilation runs.
• This makes it easy to update plugins for compatibility with new game releases: diff the relevant source between two commits inside Data/ to see exactly what changed.

The repository uses an internal author/email (se2-dev-skills@localhost) so commits work even on machines without a configured global Git identity.

Original Game File Hashes

Preparation also records the SHA256 of every file in the game install into Data/game_files.json (path relative to the SpaceEngineers2 folder → lower-case hex digest, alphabetically sorted, one pair per line) and commits it under the version label. Diffing it between two version commits shows exactly which binaries a game update changed — including assets that are neither assemblies nor text, so they appear in neither Data/Decompiled nor Data/Content.

Verify an install against the recorded digests with ./verify_game_files.sh (Linux) or .\VerifyGameFiles.bat (Windows). Read GameFileHashes.md for the file format, the diffing recipe and the verification output.

Graphify Graph (optional)

Preparation can build a separate Graphify graph for the decompiled game code under Data/Decompiled (or SE2_DEV_GAME_CODE_GRAPH_ROOT). The graph is written beside the graphed tree, to Data/graphify-out (or SE2_DEV_GAME_CODE_GRAPH_OUT), so Data/Decompiled holds nothing but decompiled C# code and the graph never reaches the repository. It is a navigable map of call/inherit/reference edges plus clustered communities that answers structural questions the CSV code index cannot. Prepare installs Graphify on Python 3.12 with the fast native Rust Leiden clustering backend and, when that backend is available (needs uv), builds the graph automatically in 1-2 minutes. Where the fast backend cannot be provisioned it falls back to slow single-core clustering (10-30 minutes) and stays opt-in with SE2_DEV_GRAPHIFY=1 (ask the user first); SE2_DEV_GRAPHIFY=0 disables it. The Graphify tooling is shared by all se2-dev-* skills and lives in the se2-dev skill. Read these on demand — skip them for normal search work:

• Build / health-check / rebuild: GraphifyPrepare.md
• Query an existing graph: GraphifyUsage.md

Health check and query test (only meaningful once a graph is built):

bash ../se2-dev/graphify_check.sh Data --deep   # is the graph usable?
./test_graphify_game_code.sh                   # run a few graph queries

Essential Documentation

• CommandExecution.md - ⚠️ READ THIS FIRST - How to run commands correctly on Windows and Linux

Code Search Documentation

• QuickStart.md - More examples and quick reference
• CodeSearch.md - Complete guide to searching classes, methods, fields, etc.
• HierarchySearch.md - Finding class/interface inheritance and implementations
• Advanced.md - Power user techniques for complex searches
• Troubleshooting.md - What to do when searches return NO-MATCHES or too many results
• GameFileHashes.md - SHA256 digests of the original game files: format, diffing across game versions, verifying an install
• Implementation.md - Technical details for skill contributors (optional)

Quick Search Examples

# Find class declarations
uv run search_game_code.py class declaration CubeGridComponent

# Find method signatures
uv run search_game_code.py method signature OnAddedToScene

# Find class hierarchy
uv run search_game_code.py class children GameComponent

# Count results before viewing (useful for large result sets)
uv run search_game_code.py class usage CubeGridComponent --count

# Limit number of results
uv run search_game_code.py class usage CubeGridComponent --limit 10

# Paginate through results
uv run search_game_code.py class usage CubeGridComponent --limit 10 --offset 0
uv run search_game_code.py class usage CubeGridComponent --limit 10 --offset 20

Always check the game code when:

• You're unsure about the game's internal APIs and how to interface with them.
• The inner workings of Space Engineers is unclear.

Custom Scripting

For building your own utility scripts to work with the indexes and decompiled code:

• ScriptingGuide.md - How to write Python scripts, use BusyBox, handle Windows paths

Game Content Data

The textual part of the game's Content is copied into the Data/Content folder for free text search:

• Language translations, including the string IDs
• Block and other entity definitions
• Default blueprints and scenarios
• See ContentTypes.md for the full list of content types
• See ContentSelection.md for which files are copied and which are left behind — only text is copied, so models, textures, audio and video are not in Data/Content even when a definition references them

Content Index

Data/CodeIndex/content_index.csv maps every textual content file to the decompiled C# source files that reference it. Columns: rel_path (path relative to Data/Content/) and usage (path of a C# source file in Data/Decompiled/ that references it). Each content file appears once per usage, so you can filter and page by rel_path to see all C# code that loads or references a given content file. Files with no known usages have a single row with an empty usage column.

General Rules

• In the Data/Decompiled folder search only inside the C# source files (.cs) in general. If you work on transpiler or preloader patches, then also search in the IL code (.il) files.
• In the Data/Content folder search the files appropriate for the task. See ContentTypes.md for the list of types and ContentSelection.md for what is not there at all.
• Do not search for decompiled game code outside the Data/Decompiled folder. The decompiled game source tree must be there if the preparation succeeded.
• Do not search for game content data outside the Data/Content folder. The copied game content must be there if the preparation succeeded.

Action References

Follow the detailed instructions in:

• prepare action - One-time preparation
• bash action - Running UNIX shell commands via busybox
• search action - Running code searches
• test action - Testing this skill

Remarks

The original source of this skill: https://github.com/CometWorks/skills2