Stricter name validation, and better disambiguation of graph actions
This commit is contained in:
46
AGENTS.md
46
AGENTS.md
@@ -13,8 +13,8 @@ The luprex DLL never calls into the Unreal driver. Output goes through polled bu
|
||||
|
||||
- Use `build.py` for all builds. Do NOT follow Epic's standard build instructions.
|
||||
- `build.py all` — full rebuild (engine, game, intellisense, project files)
|
||||
- `build.py c++` — lightweight rebuild (only if you've only edited C++ files in this repo)
|
||||
- Lua and Blueprint edits don't require a rebuild.
|
||||
- `build.py c++` — lightweight rebuild (use if you've only edited c++ files)
|
||||
- Lua and Blueprint edits don't require any kind of build.
|
||||
|
||||
## Directory Structure
|
||||
|
||||
@@ -24,6 +24,8 @@ The luprex DLL never calls into the Unreal driver. Output goes through polled bu
|
||||
- `Docs/` — Documentation. When trying to understand this system, start with the markdown files in the Docs directory.
|
||||
- `Config/` — Unreal config files
|
||||
- `EnginePatches/` — Custom engine modifications
|
||||
- `Plugins/UEWingman/' - An MCP that gives you control over the unreal editor.
|
||||
- `../integration.UE/` - the unreal engine source tree
|
||||
|
||||
## Architecture: World Models and Predictive Reexecution
|
||||
|
||||
@@ -46,11 +48,6 @@ See `Docs/Predictive-Reexecution.md` for the full explanation.
|
||||
|
||||
Lua scripts have no access to the Unreal API whatsoever. The scripter works with plain Lua tables, animation queues of key-value tuples, and coroutines. There are no "unreal bindings." The Luprex DLL is engine-agnostic — Unreal (or any other front end) interprets the animation queues and renders accordingly.
|
||||
|
||||
Small concessions to reality exist in animation step tuples:
|
||||
- `bp` — names which Tangible Actor blueprint to use for rendering
|
||||
- `mat_color` — a persistent value that hints at material color
|
||||
These are still just key-value data; the script never touches the Unreal API directly.
|
||||
|
||||
## Architecture: Tangibles
|
||||
|
||||
Tangibles are game objects. Each has:
|
||||
@@ -70,10 +67,6 @@ On the Unreal side, **Tangible Actor blueprints** (TangibleStaticMesh, TangibleS
|
||||
- **LuaDefine macro** — declares Lua-callable C++ functions and auto-registers them in a global registry for automatic insertion into the Lua environment.
|
||||
- **eng::malloc heap** — custom deterministic memory allocator for the driven portion, ensuring reproducible addresses during replay.
|
||||
|
||||
## Architecture: Determinism
|
||||
|
||||
The driven portion must be fully deterministic so that synchronous models stay in lockstep and event replay works. Rules: no true random numbers, no iterating unordered maps, no real-time clocks, no threads (with carefully sandboxed exceptions). See `Docs/The-Event-Driven-Structure-of-the-Engine.md`.
|
||||
|
||||
## Architecture: GUI System
|
||||
|
||||
Blueprints call into Lua via two mechanisms:
|
||||
@@ -82,39 +75,22 @@ Blueprints call into Lua via two mechanisms:
|
||||
|
||||
Look-at widgets, hotkeys, and menus are built on top of this. The menu system is implemented entirely in "user space" Lua and blueprint code. See `Docs/Displaying-Widget-Blueprints.md`.
|
||||
|
||||
## Blueprint Text Export
|
||||
|
||||
Blueprints are automatically exported to readable text files in `Saved/BlueprintExports/` whenever they are saved in the editor. This lets Claude Code read blueprint logic. See `Docs/Blueprint Text Export.md` for format details. Source: `Source/Integration/BlueprintExporter.h/.cpp` and `Source/Integration/Integration.cpp`.
|
||||
|
||||
## Key Documentation
|
||||
|
||||
Look in the Docs directory for important documentation.
|
||||
|
||||
## Git
|
||||
|
||||
Do not use git to make changes (commit, push, branch, etc.). Read-only git commands (status, log, diff, etc.) are fine.
|
||||
|
||||
## Workflow
|
||||
|
||||
- When the user gives a direct command, execute it. But when proposing changes on your own initiative, describe the plan and get approval before editing files.
|
||||
- Do not use git to make changes (commit, push, branch, etc.). Read-only git commands (status, log, diff, etc.) are fine.
|
||||
- Work at the user's pace. Do not start coding until the user says it is time.
|
||||
- If an instruction ends with an ellipsis (`...`), the user has more to say. Wait for the next message before acting.
|
||||
- Do not output multiple paragraphs. Doing so is very rude. You are having a conversation, give the other person a
|
||||
chance to speak. For most questions, 3-4 sentences is the maximum, unless you've been asked to give a
|
||||
detailed explanation.
|
||||
|
||||
## Coding Conventions
|
||||
|
||||
- Prefer early returns and `continue` to reduce nesting (never-nester style).
|
||||
- Do not use static functions in Unreal code. Use class methods or namespace-scoped functions instead.
|
||||
- Use `LogLuprexIntegration` for log messages, not `LogTemp`.
|
||||
- When writing UFUNCTIONs that take an `AActor*`, `UObject*`, or similar "self" parameter, add `DefaultToSelf` meta to that pin. Most functions should have this on the obvious pin so the user doesn't have to manually wire it in blueprints.
|
||||
- Do not use static functions in Unreal code. Use class methods instead.
|
||||
- Use `LogLuprexIntegration` for log messages inside Source/. Use LogTemp inside Plugins/.
|
||||
|
||||
## Session Startup
|
||||
|
||||
At the beginning of every session, do a directory listing of these three directories so you know what files are available:
|
||||
- `Docs/` — documentation
|
||||
- `Source/Integration/` — Unreal-side C++ code
|
||||
- `luprex/cpp/core/` — Luprex DLL core C++ code
|
||||
|
||||
These two code directories contain 99% of the code we'll be working on together.
|
||||
|
||||
## Current Status
|
||||
|
||||
(Use this section to track what we're working on across sessions.)
|
||||
|
||||
Reference in New Issue
Block a user