rtx-remix-modding

RTX Remix 模组制作

何时使用此技能

当用户使用 NVIDIA RTX Remix 为经典 DirectX 8/9 游戏制作模组或重制游戏，且有可用的 Remix MCP 服务时，请使用此技能。它涵盖打开和关闭项目、处理项目的 USD 图层、替换绑定到已捕获 prim 的模型和纹理资源，以及读取舞台内容。它不涵盖安装 Remix、捕获游戏或创作新几何体。

连接到 Remix

需要 RTX Remix 1.6.0+ 或 1.6.0-dev；如果版本较旧，请让用户升级。

找不到 remix_* 工具？请让用户启动 Toolkit，可使用窗口模式，或通过 lightspeed.app.trex.stagecraft.headless.bat 启动，然后连接到 http://127.0.0.1:18014/mcp/。 请保留末尾的斜杠。两种模式都会在 18014–18019 之间回退；如果所有端口都被占用，启动就会失败。

Remix 发布的 Windows 发现记录： %LOCALAPPDATA%\NVIDIA\RTX Remix\mcp.json。 读取 mcp_endpoint 以获取最新实例。该记录包含地址、端口、版本和 PID； 正常关闭时会被移除。

没有记录？请使用 Toolkit 日志中 MCP_PORT_FALLBACK 警告里的 endpoint=。 等待匹配的 SERVICE_READY service=mcp。客户端 URL 需要手动更新。

说明

使用 MCP 工具替换模型或添加资源引用之前，请先阅读 references/tool-mode.md 并遵循相关操作步骤。

你的工具列表已包含所有工具及其架构。它没有说明的是操作顺序：

1. 打开或确认项目。
2. 写入前设置编辑目标。 写入会落在当前图层中，而选错图层会造成看似成功的失败。
3. 找到 prim — selection=true 会对视口中的选区执行操作。
4. 写入。文件必须先被载入，之后才能引用。
5. 执行 remix_save_layer，然后读取并核对所做的更改。

故障排除

规划之前，检查是否有 remix_* 工具；如果没有，请说明服务不可用，并转达“连接到 Remix”中的设置说明。

绝不可用变通方法代替缺失的工具。手动编辑 .usda 文件或在文件系统中搜索纹理，都是绕过命令层的做法；结果通常会落入运行时忽略的图层中，看似成功，实际却什么也没渲染出来。

调用失败时，先阅读响应再重试。项目不存在、舞台未打开或路径遭拒，都是需要先解决的前置条件 — 重复调用只会重复失败。仅在连接中断等暂时性原因导致失败时，才重试失败的操作。

规则

始终需要说明的范围限制：编辑作用于每个已捕获资源，而非每个实例，因此所有共享该网格的实例也会发生变化。这是预期行为，没有问题；但如果相关对象存在同源对象，请在结束语中说明这一点（例如：“已替换这扇门的模型 — 它与此项目中的另外 5 扇门共享资源，因此它们也发生了变化。”）。

必要时使用 remix_get_model_instances 查明模型有哪些共享实例；不要根据相同的替换文件名推断同源对象，也不要编造数量。

此版本没有撤销工具。也绝不可手动模拟撤销 — 任何自行还原内容的做法都是错误的。这包括将你自己的更改从图层中移除，即使已经确认这些更改只有你添加过。将 references = None 写入或清空替换 prim 也是如此：被阻止的引用会合成为空内容，从游戏中删除该资源，且不会在任何地方报错。如果用户想撤销更改，请说明你无法撤销，并让他们在 Toolkit 中操作。

你能做和不能做的事情，按事项说明。除此之外一概不行 — 没有工具，也没有变通方法。 请如实说明，并提供最接近的可行操作：

• 图层（Layers） — 唯一可以创建或删除的内容。
• 项目（Projects） — 可以打开和关闭现有项目，但不能创建项目。
• 图元（Prims） — 可以读取并设置选择项，但不能创建、删除、重命名、复制或移动图元。这涵盖所有类型的几何体：无论通过哪种方式，都不能创建网格或新对象。
• 资源引用（Asset references） — 可以为图元添加资源引用，或替换已有引用，但不能移除。
• 纹理（Textures） — 可以读取材质绑定的纹理并替换纹理。

不支持删除图元；这必须在 Remix Toolkit GUI 中完成。即使你替用户选中了图元，也必须以拒绝并指引其使用该方式作为结束语。隐藏图元、将其移出世界、清空或移除其引用，或用空白／不可见资源替换它，都会让游戏中的同一几何体消失——这仍属于不支持的删除，而不是受支持的替代方案。手动编辑 .usda 文件、使用原始 USD／pxr 脚本以及修改文件系统，都会绕过 Toolkit 的命令层，因此没有任何机制会验证这些修改或撤销它们。删除、静音或还原图层来移除一个图元时，该图层中的所有其他修改也会一并丢失。

此版本中的任何内容都不会自动保存。写入只会作用于内存，而运行中的游戏会继续渲染旧资源，直到图层写入磁盘。因此，如果一轮操作以成功编辑结束，用户实际上看不到任何变化。编辑完成后调用 remix_save_layer，然后读回确认已保存。这和上文所说的静默成功是同一种情况，只不过更容易被误报为成功。

如果请求指定的是一个群组——“球上的所有纹理”、“每一扇门”、“损坏的那些”——那么用户并没有亲自查看过你整理出的目标列表。由你将请求转成列表，而且没有撤销操作。为列表中的每个对象都指定了精确的替换内容，也只能证明你的列表看起来合理，不能证明它符合用户的意图。因此，如果请求最终涉及多个用户没有逐一指明的目标，那么本轮操作就到此为止：汇报将发生的变化（目标不超过 10 个时逐一列出，否则说明涉及多少项资源以及它们将变成什么），并请用户确认。用户必须先回复，之后才能进行任何首次写入——纹理覆盖、着色器属性、添加或替换引用、脚本或文件编辑都不例外。用户不在场时会自行作答的问题工具，不能算作用户的答复。用户明确指定的单个目标无需询问——即使该资源被多个对象共用也是如此；这属于上文所说的信息披露，不属于范围确认。

停止重复失败的方法。长任务可能需要多轮；只要每轮都在取得进展，就继续——出现新的错误也算进展。但如果同一个调用以相同方式失败了大约 3 次，就停止并报告错误。

调用成功却没有提供有用信息，同样是条死路；而且更容易被忽视，因为表面上没有任何问题。**绝不要重新运行尚未失效的查询。**如果自上次运行以来什么都没发生，它返回的结果就会完全相同；第三次运行只会浪费本轮调用额度，而你已经有了答案。搜索场景也不例外——之前没找到的名称仍然不存在。搜索结果为空时，这个空结果就是你的答案：说明你查找了什么、确实找到了什么，并请用户换种方式描述目标。以提问结束本轮是正确的结果，不是失败；这也好过耗尽剩余调用，一遍遍重复询问你已经回答过的问题。 工具表示目标不存在，这就是完整答案，而不是两种说法中的第一种。这些工具读取的舞台与你亲自查看时相同，所以再问另一个工具也只会得到同样的空结果——在 prim 子项中寻找材质并未携带的纹理，或捕获数据中并不存在的名称，只会让你陷入循环，而不是找到出路。游戏渲染的许多内容根本不会出现在捕获数据中：天空、雾、水、阴影、HUD。说明你发现了什么，以及你无法访问什么。有一种情况确实会使查询失效，此时重新运行是正确的：你更改了场景——写入后重新读取，以确认更改已生效。

如果没有任何工具能完成用户的要求，就直说并停止。“我无法用现有工具完成这件事——但我可以改为做这些事”是正确且有用的回答。缺少某项能力时擅自变通，可能造成实际损害；坦率拒绝只会让用户多花一个回合，不会带来其他影响。

工具拒绝请求时，转述它告诉你的内容。这些拒绝是写给用户看的，不是写给你的：它们会指出阻止调用的具体原因，并在有解决办法时给出解决办法。用你自己的句子逐字转达这两项内容。要避免两种错误——省略解决办法，让用户听到“办不到”，而工具说的其实是“执行 X 就能解决”；以及在工具没有说明原因时自行解释原因。如果你发现自己在写“可能”或“大概”来解释某件事为何受阻，那你就是在猜测用户的环境。只说明工具报告的内容，以及解除阻碍的方法，然后停止。

完成用户的请求后，用一句简短、通俗的话结束本轮，告诉用户你做了什么，或回答他们的问题——如果是执行操作，就确认操作已完成（例如：“已打开你最近的项目。”）。

简短不代表空洞。“完成了。”和“好的”都不是可接受的回答——它们没有告诉用户任何信息，也无法说明用户要求的事情是否真的办成了。说清楚有什么变化；如果上述规则要求你说明限制或拒绝，那条说明就是这句话。即便这是你唯一需要报告的内容，也要说出来。