Traitez le dossier de ressource comme un livrable, pas un espace de travail. Il doit contenir les fichiers prêts pour le jeu et un manifeste clair. Sauvegardes Blender, projets d’éditeur et exports d’échange non convertis doivent rester ailleurs.
Commencez avec un dossier propre
Pour un petit intérieur personnalisé, utilisez une structure de ce type :
cw_workshop/
fxmanifest.lua
stream/
cw_workshop.ymap
cw_workshop.ytyp
cw_workshop_shell.ydr
cw_workshop_col.ybn
C’est un exemple d’inventaire, pas une liste exhaustive pour chaque projet. Ajoutez les textures et autres dépendances réelles de vos exports. Les noms doivent correspondre à vos assets et références, pas seulement ressembler à l’exemple.
Rédigez le manifeste de ressource
Pour l’unique YTYP de l’exemple :
fx_version 'cerulean'
game 'gta5'
this_is_a_map 'yes'
files {
'stream/cw_workshop.ytyp'
}
data_file 'DLC_ITYP_REQUEST' 'stream/cw_workshop.ytyp'
Cfx.re documente les directives de ressource dans sa référence des manifestes et le type d’enregistrement YTYP dans sa référence des fichiers de données.
Pour plusieurs YTYP personnalisés, énumérez fichiers et enregistrements de façon cohérente ou utilisez volontairement les motifs glob documentés. N’enregistrez pas de fichiers non livrés. Une carte plaçant seulement des archétypes existants peut avoir un manifeste réduit, comme dans le tutoriel du premier YMAP.
Le outil de manifeste génère ce petit exemple dans le navigateur. Il n’inspecte pas vos assets et ne valide pas un MLO entier.
Ne confondez pas les manifestes
Un manifeste de carte du jeu généré par CodeWalker n’est pas fxmanifest.lua. De même, un fichier .cwproj n’est pas une carte du jeu et ne peut pas être diffusé à la place de ses exports.
Utilisez les sorties natives produites par votre chaîne d’outils. Changer une extension n’est pas convertir. Gardez le dossier d’échange hors du dossier de publication pour repérer les copies accidentelles.
Démarrez sur un serveur de développement
Placez la ressource dans le dossier des ressources du serveur. Les dossiers de catégorie tels que [maps] organisent les projets ; le nom dans la commande doit toujours correspondre au vrai dossier de la ressource.
Depuis la console serveur :
refresh
ensure cw_workshop
Enregistrez la ligne appropriée ensure dans la configuration du serveur pour les prochains démarrages. Vérifiez la sortie du serveur plutôt que de considérer la saisie de commande comme une preuve de chargement. La documentation des commandes serveur fait référence pour le comportement des commandes.
Visitez les coordonnées de test notées. Une ressource peut démarrer sans placer son contenu où prévu ; vérifiez donc le placement indépendamment du démarrage.
Testez le paquet livré, pas votre espace de travail
Copiez uniquement le dossier candidat dans un emplacement de test propre. Comparez sa liste de fichiers aux exports prévus. Si la carte exige une autre ressource expérimentale, identifiez cette dépendance au lieu de la laisser implicite.
Testez la reconnexion, l’approche depuis l’extérieur de la zone et le démarrage du serveur avec la ressource configurée dès le départ. Pour un MLO, répétez aussi les parcours de pièces, portails et collisions des leçons concernées.
Séparez les sorties Legacy et Enhanced. La note sur les éditions explique pourquoi un ancien test Legacy réussi ne prouve pas la compatibilité Enhanced.
Rendez les mises à jour réversibles
Versionnez le dossier ou l’archive de publication et conservez le paquet fonctionnel précédent. Notez les changements précis et le parcours testé. Sur un serveur partagé, suivez la maintenance de l’exploitant au lieu d’expérimenter sur les joueurs connectés.
Après un déploiement échoué, restaurez ensemble tous les fichiers d’une version fonctionnelle. Mélanger un ancien YMAP avec un YTYP ou une collision récente complique le retour arrière. Une publication reproductible s’identifie, se reproduit et se remplace comme un ensemble.
Installez un YMAP utilisant uniquement les objets du jeu
Utilisez un nouveau dossier de ressource, par exemple cw_three_props, avec fxmanifest.lua à sa racine et le natif YMAP dans stream/. Gardez le JSON du projet et le XML d’échange hors du dossier stream livré. Pour l’exemple simple, le manifeste peut être :
fx_version 'cerulean'
game 'gta5'
this_is_a_map 'yes'
Cela suppose tous les archétypes déjà fournis par le jeu et les DLC cibles. Un modèle personnalisé peut nécessiter sa définition et ses dépendances même avec un seul placement YMAP. Utilisez le générateur avec l’option personnalisée désactivée uniquement si cette hypothèse est vraie.
Enregistrez un YTYP personnalisé sous son vrai nom de fichier
Si vous fournissez stream/cw_workshop_types.ytyp, la ressource doit déclarer ce fichier précis. Le nom du dossier de ressource n’impose pas le même nom de base au YTYP :
files {
'stream/cw_workshop_types.ytyp'
}
data_file 'DLC_ITYP_REQUEST' 'stream/cw_workshop_types.ytyp'
Ajoutez ceci au manifeste de carte, pas au XML YMAP. La référence des fichiers de données Cfx.re identifie ce type d’enregistrement. Plusieurs définitions exigent des déclarations correspondantes ; les assets entre ressources nécessitent aussi un plan de dépendances et de démarrage documenté. Le générateur traite un YTYP facultatif, pas tout un graphe de dépendances.
Isolez les échecs de démarrage de ressource
Exécutez refresh après avoir ajouté un dossier de ressource, puis ensure cw_three_props avec le vrai nom du dossier. Vérifiez la console avant la carte. Une ressource inconnue exige de vérifier l’imbrication des dossiers et le nom du manifeste ; une erreur d’analyse Lua exige de vérifier la syntaxe. Enregistrez les fichiers sans suffixe caché .txt .
Le message « ensure succeeded » prouve le démarrage, pas la validité des assets. Reconnectez-vous, visitez les coordonnées exactes et vérifiez les placements. Pour du contenu invisible ou un scintillement lié aux portes, poursuivez avec le diagnostic guidé par les symptômes. Gardez les exemples sources hors production tant que leurs étapes natives et en jeu distinctes n’ont pas été effectuées.