Rtx Remix Modding

RTX Remix Modding

When to Use This Skill

Use this when the user is modding or remastering a classic DirectX 8/9 game with NVIDIA RTX Remix and a Remix MCP server is available. It covers opening and closing projects, working with the project's USD layers, swapping the model and texture assets bound to captured prims, and reading the stage. It does not cover installing Remix, capturing a game, or authoring new geometry.

Connecting to Remix

Requires RTX Remix 1.6.0+ or 1.6.0-dev; ask the user to upgrade if older.

Missing remix_* tools? Ask the user to start Toolkit, windowed or via lightspeed.app.trex.stagecraft.headless.bat, and connect to http://127.0.0.1:18014/mcp/. Keep the trailing slash. Both modes fall back within 18014–18019; all busy means startup fails.

Windows discovery record, published by Remix: %LOCALAPPDATA%\NVIDIA\RTX Remix\mcp.json. Read mcp_endpoint for the latest instance. Contains addresses, ports, version, and PID; removed on clean shutdown.

No record? Use endpoint= from the Toolkit log's MCP_PORT_FALLBACK warning. Wait for matching SERVICE_READY service=mcp. Client URLs need manual updating.

Instructions

Before using the MCP tools to replace models or add an asset reference, read references/tool-mode.md and follow the relevant recipe.

Your tool list already carries every tool and its schema. What it does not carry is the order:

1. Open or confirm the project.
2. Set the edit target before writing. A write lands in whichever layer is current, and the wrong layer is the failure that looks like success.
3. Find the prims — selection=true acts on the viewport selection.
4. Write. A file has to be ingested before it can be referenced.
5. remix_save_layer, then read back what you changed.

Troubleshooting

Before planning, check for remix_* tools; if absent, say the server is unavailable and relay the setup instructions in "Connecting to Remix".

Never substitute a workaround for the missing tools. Editing .usda files by hand or searching the filesystem for textures goes around the command layer, and the result usually lands in a layer the runtime ignores — which looks like success and renders nothing.

When a call fails, read the response before trying again. A missing project, an unopened stage, or a rejected path is a precondition to fix — repeating the call only repeats the failure. Retry only what failed for a transient reason, such as a dropped connection.

Rules

Scope caveat you must always disclose: edits apply per captured asset, not per instance, so every instance sharing that mesh changes too. This is expected and fine, but say it in your closing sentence whenever the subject has siblings (e.g. "Swapped that door's model — it shares an asset with 5 other doors in this project, so they changed too.").

Use remix_get_model_instances to identify a model's shared instances when needed; do not infer siblings from matching replacement filenames or invent a count.

There is no undo tool in this release. Never simulate one by hand either — any route you take to put something back yourself is the wrong one. That includes stripping your own edits back out of a layer, even after confirming they are only yours. So does authoring references = None or emptying a replacement prim: a blocked reference composes to nothing, deleting the asset from the game with no error anywhere. If the user wants a change reverted, say that you cannot revert it and let them do it in the Toolkit.

What you can and cannot do, by thing. Nothing outside this exists — no tool and no workaround. Say so, and offer the nearest thing you can do:

• Layers — the only thing you can create or delete.
• Projects — open and close an existing one. You cannot create one.
• Prims — read them and set the selection. You cannot create, delete, rename, duplicate or move one. That covers geometry of every kind: no meshes, no new objects, by any route.
• Asset references — add one to a prim, or replace one already there. There is no removal.
• Textures — read what a material binds, and replace it.

Nothing saves itself in this release. A write lands in memory and the running game keeps rendering the old asset until the layer is on disk, so a turn that ends on a successful edit has changed nothing the user can see. Call remix_save_layer once the edit is in, then read back to confirm it landed. This is the same silent success as above, and the easier one to report as a win.

Ask instead of guessing scope. "Swap all the broken ones", "fix everything in this layer" — ask how many, and which, before acting.

Stop repeating a failing approach. Long tasks take many rounds; keep going while each round gets closer — a new error is progress. But when the same call fails the same way about three times, stop and report the error.