Vestiaires techniques

Noms et administration

La migration 0014_named_changing_rooms ajoute le nom persistant. Les routes internes PUT et DELETE /internal/v1/changing-rooms/{id}, ainsi que les routes web /admin/changing-rooms, exigent ADMIN_ALLOW_EDIT_CHGROOM. Toute mutation provoque une resynchronisation des props.

La NUI sépare la saisie du nom du placement. Les contrôles de molette 14/15 sont désactivés puis lus avec IsDisabledControlJustPressed. Les contrôles 172/173 appliquent un décalage vertical borné après la pose au sol du prop.

La migration 0017_selected_chgroom_props ajoute spawn_prop et prop_model_hash. Une salle avec spawn_prop=false référence un objet existant au lieu de créer un prop. Le client effectue un raycast limité aux objets, commute SetEntityDrawOutline uniquement lors d'un changement de cible, puis persiste le hash, la position et l'orientation. Comme les objets de mapping sont streamés, un worker borné à 80 mètres résout GetClosestObjectOfType et enregistre l'interaction à l'arrivée du joueur. La disparition de l'entité retire proprement l'interaction jusqu'au prochain streaming. Une mutation de position conserve spawn_prop : elle relance la sélection pour une référence existante et le placement partagé pour un prop généré.

Le manifest exige au minimum le game build 3258, qui contient mp2024_01; le déploiement force actuellement le build 3570. Avant IsModelInCdimage et RequestModel, le client demande les IPL de requiredIpls (par défaut m24_1_bailoffice_davis) et attend brièvement leur activation afin d'enregistrer les archétypes de l'intérieur DLC. Le build effectif, les IPL demandés et le résultat de validation de chaque modèle restent visibles dans F8. prop_coathook_01 a été retiré à la fois de la configuration et des fallbacks codés.

Après la saisie du nom, medusa-changing-rooms délègue la prévisualisation du prop et les contrôles à medusa-entity-placement, puis persiste uniquement le résultat renvoyé par son callback.

La migration 0015_cleanup_changing_rooms supprime les lignes sans nom, avec un nom vide, ou portant la valeur transitoire Vestiaire attribuée par 0014 aux anciennes lignes. Cette suppression est volontairement irréversible, car les lignes supprimées ne peuvent pas être reconstruites fidèlement lors d'un downgrade.

Persistance et API

La migration 0013_changing_rooms crée changing_rooms avec position, orientation, état et timestamps. PostgreSQL reste la source de vérité. Le resource medusa-changing-rooms synchronise GET /internal/v1/changing-rooms toutes les deux secondes et ne rediffuse l'inventaire que lorsque son empreinte change. POST /internal/v1/changing-rooms exige la clé interne et réautorise les rôles Discord avec ADMIN_ALLOW_PLACE_CHGROOM.

Les routes GET /internal/v1/changing-rooms/outfits/{character_id} et POST /internal/v1/changing-rooms/outfits/apply listent et appliquent les entrées saved_outfits. L'application vérifie que la tenue appartient au personnage demandé avant d'écrire characters.clothing. Le serveur FiveM résout toujours le personnage depuis la source connectée ; le client ne choisit jamais un autre identifiant de personnage.

Resource FiveM

Chaque client parcourt propModels, vérifie IsModelInCdimage et IsModelValid, puis attend le chargement du premier candidat utilisable. La priorité commence par m24_1_int_01_m241_coatrack_02, puis utilise prop_coathook_01, v_res_tre_wardrobe ou prop_cs_clothes_box. Chaque refus et le modèle finalement retenu sont journalisés dans F8. Le client crée ensuite le prop statique et l'inscrit comme entité dans medusa-interactions. Le contour, la détection de proximité, le verrou d'interaction et le popup sont donc mutualisés. Le resource détruit props et inscriptions lors d'une resynchronisation ou de son arrêt.

À l'ouverture, le client capture composants et accessoires, immobilise le ped et active une caméra plein corps. La sélection applique uniquement un aperçu local avec les exports de medusa-character-customization. La confirmation transmet l'UUID de la tenue au serveur ; seule la réponse API réussie ferme le vestiaire sans restauration. Annulation, arrêt de resource ou erreur de chargement libèrent le verrou d'interaction et restaurent le snapshot si nécessaire.

Le placement /placechangingroom est autorisé côté serveur avant l'ouverture du mode visuel puis réautorisé avant la mutation API. La création est inscrite dans l'audit sous changing_room.place avec position et orientation.

Le serveur vérifie la proximité d'un vestiaire actif avant de charger les tenues et avant la confirmation. Il crée une session de cinq minutes contenant uniquement les UUID renvoyés pour le personnage actif. Un événement client forgé ne peut donc appliquer ni une tenue non présentée, ni une tenue depuis une autre position.