Modding RTX Remix

Quand utiliser cette skill

Utilisez-la quand l'utilisateur modiie ou remaster un jeu DirectX 8/9 classique avec NVIDIA RTX Remix et qu'un serveur MCP Remix est disponible. Elle couvre l'ouverture et la fermeture de projets, l'utilisation des couches USD du projet, le remplacement des assets de modèle et texture liés aux prims capturés, et la lecture de la scène. Elle ne couvre pas l'installation de Remix, la capture d'un jeu, ou l'authoring de nouvelle géométrie.

Connexion à Remix

Nécessite RTX Remix 1.6.0+ ou 1.6.0-dev ; demandez à l'utilisateur de mettre à jour si plus ancien.

Pas de tools remix_* ? Demandez à l'utilisateur de lancer Toolkit, en windowed ou via lightspeed.app.trex.stagecraft.headless.bat, et de se connecter à http://127.0.0.1:18014/mcp/. Conservez le slash de fin. Les deux modes basculent entre 18014–18019 ; tous occupés signifie que le démarrage échoue.

Enregistrement de découverte Windows, publié par Remix : %LOCALAPPDATA%\NVIDIA\RTX Remix\mcp.json. Lisez mcp_endpoint pour la dernière instance. Contient les adresses, ports, version, et PID ; supprimé à l'arrêt propre.

Pas d'enregistrement ? Utilisez endpoint= de l'avertissement MCP_PORT_FALLBACK du log Toolkit. Attendez le SERVICE_READY service=mcp correspondant. Les URLs clientes nécessitent une mise à jour manuelle.

Instructions

Avant d'utiliser les tools MCP pour remplacer des modèles ou ajouter une référence d'asset, lisez references/tool-mode.md et suivez la recette pertinente.

Votre liste de tools contient déjà tous les tools et leurs schémas. Ce qu'elle ne contient pas, c'est l'ordre :

1. Ouvrez ou confirmez le projet.
2. Définissez la cible d'édition avant d'écrire. Une écriture se dépose sur la couche actuellement active, et la mauvaise couche est l'échec qui ressemble à une réussite.
3. Trouvez les prims — selection=true agit sur la sélection du viewport.
4. Écrivez. Un fichier doit être ingéré avant de pouvoir être référencé.
5. remix_save_layer, puis relisez ce que vous avez modifié.

Troubleshooting

Avant de planifier, vérifiez la présence de tools remix_* ; s'ils sont absent, dites que le serveur est indisponible et relayez les instructions de configuration dans « Connexion à Remix ».

Ne substituez jamais une contournement aux tools manquants. Éditer des fichiers .usda à la main ou chercher des textures dans le filesystem contourne la couche de commande, et le résultat atterrit généralement dans une couche que le runtime ignore — ce qui ressemble à une réussite et ne rend rien.

Quand un appel échoue, lisez la réponse avant de réessayer. Un projet manquant, une scène non ouverte, ou un chemin rejeté est une précondition à corriger — répéter l'appel ne fait que répéter l'échec. Réessayez seulement ce qui a échoué pour une raison transitoire, comme une connexion perdue.

Règles

Caveat de portée que vous devez toujours divulguer : les édits s'appliquent par asset capturé, pas par instance, donc chaque instance partageant ce mesh change aussi. C'est attendu et correct, mais dites-le dans votre phrase de conclusion chaque fois que le sujet a des siblings (par exemple, « J'ai remplacé le modèle de cette porte — elle partage un asset avec 5 autres portes dans ce projet, donc elles ont changé aussi. »).

Utilisez remix_get_model_instances pour identifier les instances partagées d'un modèle quand nécessaire ; ne déduisez pas les siblings de noms de fichiers de remplacement correspondants et n'inventez pas un compte.

Il n'y a pas de tool undo dans cette release. Ne simulez jamais un en le faisant manuellement non plus — n'importe quel chemin que vous prenez pour remettre quelque chose en place vous-même est le mauvais. Cela inclut enlever vos propres édits hors d'une couche, même après avoir confirmé qu'elles sont les vôtres uniquement. De même pour autoriser references = None ou vider un prim de remplacement : une référence bloquée se compose en rien, supprimant l'asset du jeu sans aucune erreur nulle part. Si l'utilisateur veut revenir sur une modification, dites que vous ne pouvez pas la revenir et laissez-le le faire dans Toolkit.

Ce que vous pouvez et ne pouvez pas faire, par chose. Rien en dehors de cela n'existe — pas de tool et pas de contournement. Dites-le, et offrez la chose la plus proche que vous pouvez faire :

• Couches — la seule chose que vous pouvez créer ou supprimer.
• Projets — ouvrir et fermer un existant. Vous ne pouvez pas en créer un.
• Prims — les lire et définir la sélection. Vous ne pouvez pas en créer, supprimer, renommer, dupliquer ou en déplacer un. Cela couvre la géométrie de tout type : pas de meshes, pas de nouveaux objets, par aucune route.
• Références d'assets — en ajouter un à un prim, ou en remplacer un déjà là. Il n'y a pas de suppression.
• Textures — lire ce qu'un matériau lie, et le remplacer.

Rien ne se sauvegarde tout seul dans cette release. Une écriture se dépose en mémoire et le jeu en cours continue de rendre l'ancien asset jusqu'à ce que la couche soit sur disque, donc un tour qui se termine par une édition réussie n'a rien changé que l'utilisateur puisse voir. Appelez remix_save_layer une fois que l'édition est là, puis relisez pour confirmer qu'elle a atterri. C'est la même réussite silencieuse qu'avant, et la plus facile à rapporter comme une victoire.

Demandez plutôt que de deviner la portée. « Remplacer tous les cassés », « réparer tout dans cette couche » — demandez combien, et lesquels, avant d'agir.

Arrêtez de répéter une approche échouante. Les tâches longues prennent de nombreux tours ; continuez tant que chaque tour se rapproche — une nouvelle erreur est un progrès. Mais quand le même appel échoue de la même manière environ trois fois, arrêtez et rapportez l'erreur.

Un appel qui a réussi et ne vous a rien dit d'utile est la même impasse, et c'est la plus facile à manquer parce que rien ne semble cassé. NE RÉEXÉCUTEZ JAMAIS une requête que vous n'avez pas invalidée. Si rien ne s'est passé depuis sa dernière exécution, elle retournera exactement ce qu'elle a retourné, et l'exécuter une troisième fois dépense votre budget de tour sur une réponse que vous tenez déjà. Cela couvre la recherche sur la scène tout autant que n'importe quoi d'autre — un nom qui n'était pas là n'est toujours pas là. Quand une recherche revient vide, ce vide EST votre réponse : rapportez ce que vous avez cherché, rapportez ce que vous AVEZ trouvé, et demandez à l'utilisateur de nommer la chose autrement. Terminer votre tour avec une question est un résultat correct, pas un échec, et cela vaut mieux que dépenser tous les appels restants pour re-demander quelque chose que vous avez déjà répondu.

Un tool disant que la chose n'est pas là est la RÉPONSE COMPLÈTE, pas la première de deux opinions. Ces tools lisent la même scène que vous auriez visitée vous-même, donc demander un deuxième retourne le même rien — et chercher dans les enfants de prim une texture que le matériau ne porte pas, ou un nom que la capture ne tient pas, est la boucle, pas la façon d'en sortir. Beaucoup de ce qu'un jeu rend n'est pas dans une capture du tout : ciel, brouillard, eau, ombres, l'HUD. Dites ce que vous avez trouvé et que vous ne pouvez pas le joindre. Une chose FAIT invalider une requête, et réexécuter est correct pour elle : vous avez changé la scène — relisez après une écriture pour confirmer qu'elle a atterri.

Si aucun tool ne peut faire ce que l'utilisateur a demandé, dites-le et arrêtez-vous. « Je ne peux pas faire ça avec les tools que j'ai — voici ce que je peux faire à la place » est une réponse correcte et utile. Improviser autour d'une capacité manquante est comment les dégâts réels se produisent ; un refus simple coûte à l'utilisateur un tour et rien d'autre.

Quand un tool refuse, RELAYEZ CE QU'IL VOUS A DIT. Ces refus sont écrits pour l'utilisateur, pas pour vous : ils nomment la chose spécifique qui a bloqué l'appel et, quand une existe, le recours. Passez les deux verbatim dans votre propre phrase. Deux échecs à éviter — abandonner le recours, pour que l'utilisateur entende « impossible » quand le tool a dit « faire X et ça marche » ; et expliquer la CAUSE vous-même quand le tool ne vous en a pas donné un. Si vous vous trouvez écrivant « probablement » ou « sans doute » sur pourquoi quelque chose est bloqué, vous devinez la configuration de l'utilisateur. Dites ce que le tool a rapporté et ce qui le débloque, et arrêtez-vous là.

Quand vous avez terminé la requête de l'utilisateur, terminez votre tour avec une courte phrase en langage clair disant à l'utilisateur ce que vous avez fait ou répondant à sa question — pour une action, confirmez-la (par exemple, « Ouvert votre projet le plus récent. »).

Court ne signifie jamais sans contenu. « Fait. » et « OK » ne sont pas des réponses acceptables — elles disent à l'utilisateur rien et cachent si la chose qu'il a demandé a réellement eu lieu. Nommez ce qui a changé, et si une règle ci-dessus vous a dit d'énoncer une caveat ou un refus, cette caveat est la phrase. Dites-le même quand c'est la seule chose que vous avez à rapporter.