Le dernier export n’est pas automatiquement la publication. Une publication est un paquet identifiable avec une cible connue et des contrôles consignés. Gardez la décision assez claire pour qu’une autre personne la reproduise sans dépendre de votre mémoire.
Cette liste est un plan éditorial de test pour votre projet, pas une certification de plateforme ni une affirmation de tests des assets du tutoriel dans GTA V.
Créez le candidat à partir de sorties propres
Exportez dans un nouveau dossier ou videz volontairement votre seul dossier de préparation. Copiez les assets prévus et comparez les noms à l’inventaire. Les anciens exports ne doivent pas subsister simplement parce que le dernier ne les a pas écrasés.
Gardez ensemble YMAP, YTYP, drawables, collisions et textures correspondants. Si les sources sont versionnées, notez la révision ; sinon, archivez au moins un état daté et une note de chaîne d’outils.
N’incluez jamais une archive GTA entière ou des assets tiers sans rapport pour masquer une dépendance manquante. Identifiez-la et vérifiez le droit de l’inclure.
Précisez exactement la cible prise en charge
Notez édition GTA, version cible, outils et conditions du serveur de test. « Compatible FiveM » est moins utile qu’une description précise de ce qui a été vérifié.
Pour des sorties Legacy et Enhanced, gardez des comptes rendus de compilation et de non-régression distincts. Utilisez la note de planification des éditions comme point de départ de cette organisation.
Testez quatre types de comportement
Arrivée : approchez depuis plusieurs directions et distances réalistes. Incluez une nouvelle connexion, pas seulement un redémarrage de ressource près de l’entrée.
Transitions intérieures : franchissez chaque connexion dans les deux sens. Arrêtez-vous aux seuils et tournez la caméra. Utilisez le même parcours que la leçon sur les portails.
Interaction physique : testez sols, marches, entrées et limites réellement présents. Séparez résultats de collision et résultats visuels.
Coexistence : exécutez la carte avec les ressources voisines prévues en production. Identifiez remplacements superposés et dépendances partagées avant distribution.
Choisissez les tests supplémentaires selon les fonctions livrées. Des portes mobiles exigent leurs propres tests ; un atelier ouvert simple ne gagne rien à cocher une fonction inexistante.
Rendez le compte rendu de test utile
Pour chaque problème, conservez lieu, reproduction, résultats attendu et réel et version candidate. Une capture complète ces champs sans les remplacer.
Faites suivre l’installation par une autre personne sans votre dossier de travail. S’il manque un fichier, enregistrement ou ressource requis, corrigez le paquet ou les instructions au lieu de lui demander de deviner.
Préparez un déploiement réversible
Conservez la dernière ressource fonctionnelle comme paquet cohérent. Définissez les conditions de retour arrière, comme une entrée bloquée reproductible ou un conflit grave dans la configuration prévue.
Prévoyez une maintenance sur les serveurs partagés. Ne validez pas des collisions inachevées près des joueurs actifs. Après déploiement, refaites un test rapide avec le dossier publié lui-même.
Incluez une transmission claire
Livrez un README avec installation, nom, conditions cibles, dépendances, limites et version. Créditez outils et assets selon leurs conditions. Fournissez les liens originaux des sources et du téléchargement CodeWalker sans laisser entendre que vous avez créé l’outil.
Une bonne note de version peut être courte : changements, lieu de test et étape différente éventuelle pour une installation existante. La valeur est la reproductibilité, pas une longue liste d’affirmations.