(Fix) Vider les materiaux surcharges au changement de mesh

Passer du corps A au corps B donnait une silhouette feminine peinte avec la
peau et les abdominaux du modele masculin.

OverrideMaterials appartient au COMPOSANT et pas au mesh : SetSkeletalMeshAsset
remplace l'asset sans y toucher, donc le MID derive de MI_BodyA_a restait colle
a l'element 0. Le symptome trompe, parce que le mesh, lui, avait bien change --
seule sa peau ne suivait pas.

SetPartMesh() vide les overrides avant d'assigner, et rend la main sans rien
faire quand le mesh est deja le bon : un changement de couleur seul continue
ainsi de reutiliser les MID en place au lieu de tout reconstruire.

Vaut pour toutes les pieces, pas seulement le corps -- changer de tete ou de
coiffure donnait le meme symptome.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.claude/CLAUDE.md

@@ -100,6 +100,9 @@ l'oublie, en Standalone seulement : la caméra ne répond qu'au clic droit maint
 **Enhanced Input en pause** : un jeu en pause ne fait qu'un tick d'input réduit, où seules les
 actions cochées **« Trigger When Paused »** sont évaluées. C'est une case sur l'asset `IA_`,
 pas du C++ — et son corollaire est qu'aucune action du pawn ne se déclenche en pause.
+*Le projet ne met plus jamais le jeu en pause (voir le menu de pause plus bas), donc la case sur
+`IA_Pause` ne sert plus à rien. La laisser cochée est sans effet ; la note reste ici parce que le
+piège ressortira au premier `SetPause` réintroduit.*
 
 **Le `namespace` anonyme n'isole rien.** Le build unity concatène les `.cpp` du module : deux
 constantes de même nom dans deux fichiers différents deviennent une redéfinition (C2374). Les
@@ -112,6 +115,7 @@ qu'une compilation propre l'est vraiment.
 | Système | Fichiers |
 |---|---|
 | Personnage, caméra, game feel | `FpsPlayer.h/.cpp` |
+| Balancement de tête procédural | `HeadBobComponent` (profils par état, additionné dans `ApplyCameraTransform`) |
 | HUD, input d'interface, fondus, respawn | `FpsPlayerController.h/.cpp` |
 | Interaction (trace + interface) | `Interactable.h`, `InteractionComponent`, `InteractionPromptWidget` |
 | Objets | `ItemDataAsset`, `PickupItem` |
@@ -124,7 +128,364 @@ qu'une compilation propre l'est vraiment.
 | Écran à onglets (inventaire / craft) | `InventoryScreenWidget` |
 | Menu de pause | `PauseMenuWidget` + la partie pause de `FpsPlayerController` |
 | Réglages | `SurvivalUserSettings`, `SettingsMenuWidget`, `SettingsTabWidget`, `SettingsGameplayWidget`, `SettingRowWidget` |
+| Musique | `MusicDirector`, `MusicSubsystem`, `MusicPlaylistDataAsset` |
+| Audio (volumes) | `SurvivalAudioSettings`, `SettingsAudioWidget` + `USurvivalUserSettings::ApplyAudioSettings` |
 | Fondus, boîtes de dialogue | `ScreenFadeComponent`, `ConfirmDialogWidget` |
+| Coop Steam (sessions) | `SessionSubsystem`, `SurvivalGameMode`, `SurvivalGameState`, `SurvivalPlayerState` |
+| Pseudo au-dessus des joueurs | `PlayerNameplateComponent`, `PlayerNameplateWidget` |
+| Corps 3e personne | `PlayerBodyAnimInstance` + `ABP_PlayerBody_A`, le `Mesh` de `BP_FpsPlayer` |
+
+### Le corps vu par les autres — pièges du personnage modulaire
+
+Le pack **Stylized Characters** (+ *CustomizationPack01*, tous deux dans `Content/External/`)
+livre un personnage **en morceaux** : `SKM_BodyA` s'arrête au cou, la tête, les sourcils, les
+cheveux, la barbe et la moustache sont des meshes séparés.
+
+- **Un seul mesh porte l'animation, les autres recopient sa pose.** C'est le
+  **Leader Pose Component** : le corps est le leader avec son AnimBP, tous les autres sont des
+  `USkeletalMeshComponent` enfants **sans animation à eux**. La correspondance se fait **par nom
+  d'os**, donc elle marche même entre squelettes distincts — les têtes du pack de customisation
+  sont sur `SK_BodyA_empty` et se posent sans problème sur un corps `SK_BodyA`.
+- **`LeaderPoseComponent` est `BlueprintReadOnly`, PAS `EditAnywhere`.** Elle n'apparaît donc
+  **jamais** dans le Details panel, et on la cherche longtemps : la section « Leader Pose
+  Component » qu'on y voit ne contient que des cases de bornes et de LOD. Elle ne s'assigne que
+  par `SetLeaderPoseComponent()` — Construction Script en Blueprint, ou C++.
+- **La physique de cheveux est perdue en leader pose.** Coiffures, barbes et moustaches ont leur
+  propre squelette et leur physics asset, mais l'AnimBP post-process d'un *follower* ne tourne
+  pas. La démo du pack accepte déjà ce compromis.
+- **Le squelette est celui du Mannequin UE5** (`ik_foot_root`, `ik_hand_gun`, `spine_01..05`,
+  `index_metacarpal_l` — les métacarpiens n'existaient pas sur le squelette UE4). Conséquence
+  précieuse : **toute animation vendue « UE5 Mannequin compatible » se branche sans retarget.**
+  C'est par là qu'arriveront l'accroupissement et les gestes d'outil, absents du pack.
+- **`Approx Size` d'un Skeletal Mesh n'est pas sa hauteur visible** : les bounds incluent une
+  marge et celles du Physics Asset. `SKM_BodyA` affiche 184 alors que le personnage entier,
+  tête comprise, mesure à peu près autant. Pour juger une taille, passer le viewport en vue
+  **Front** et se servir de la ligne verte (`Z = 0`, centre de la capsule) : le bas est à
+  `-HalfHeight`, le haut à `+HalfHeight`. Le personnage fait ~184 cm pour une capsule de 176,
+  et on **ne scale pas** — la capsule porte la collision et le game feel déjà calibré.
+
+**Côté animation**, `UPlayerBodyAnimInstance` suit le partage des rôles de
+`UFpsArmsAnimInstance` : le C++ lit l'état du pawn et le republie, le Blueprint choisit
+l'animation. Deux points valent d'être retenus :
+
+- **Rien n'y est répliqué, et c'est voulu.** Le corps est vu par tout le monde, mais chaque
+  variable **dérive** d'un état déjà synchronisé : `Velocity` par le CharacterMovement,
+  `bIsCrouched` par `ACharacter`, `bIsSprinting` par `AFpsPlayer`, et le tangage du regard par
+  `RemoteViewPitch` que `APawn` réplique tout seul — d'où `GetBaseAimRotation()` et surtout pas
+  `GetControlRotation()`, qui n'existe que sur la machine propriétaire.
+- **`bIsFalling` ne distingue pas un saut d'une chute** : le moteur appelle « falling » tout ce
+  qui n'est pas au sol. C'est le **signe de `VerticalSpeed`** qui tranche, sans quoi sortir d'un
+  rebord jouerait l'animation de détente. Et la condition `Ground → Jump` a besoin du `AND` avec
+  `bIsFalling` : gravir une pente donne aussi une vitesse verticale positive.
+- **Le `Cast` du pawn est relancé à chaque frame tant qu'il est nul.** Chez un client le mesh
+  arrive par réplication et peut s'animer **avant** le pawn : un `Cast` fait une seule fois dans
+  `NativeInitializeAnimation` laisserait le corps de l'ami figé en pose de référence pour toute
+  la partie. Invisible en solo comme chez l'hôte.
+
+Enfin, le BlendSpace du pack posait `Walk_InPlace` à la vitesse 0 — un personnage qui piétine
+sur place à l'arrêt. On y a mis l'idle à la place, plutôt qu'un état `Idle` séparé : un état,
+c'est un **seuil** qui claque au démarrage et au freinage, là où le BlendSpace interpole en
+continu. Ses points restent calés sur les **vitesses réelles mesurées des animations**
+(225.6 et 500), ce qui est précisément ce qui évite le glissement de pieds — on ne les déplace
+pas. Il s'arrête en revanche à 500 alors que le sprint est à 650 : un second échantillon de
+course posé à 650 avec un **Rate Scale** de 1.3 le couvrirait.
+
+### Coop Steam — décisions figées
+
+- **Cible : 4 joueurs, serveur d'écoute, P2P par le relais Valve.** Plugins `OnlineSubsystemSteam`
+  et `SteamSockets`, AppID **4282850** (Emberwild). Le C++ ne parle **jamais** de Steam : tout passe
+  par `IOnlineSubsystem`, dont l'implémentation est choisie dans `DefaultEngine.ini`. Corollaire
+  précieux : sans Steam le moteur retombe sur `OnlineSubsystemNULL` et tout le code bascule en LAN
+  (`USessionSubsystem::IsLanMode`), ce qui rend le test à deux instances possible sur une machine.
+- **L'OSS Steam est désactivé de force dans l'éditeur** (`IsEnabled()` teste `IsRunningGame()`).
+  Steam ne s'initialise donc **jamais en PIE** — c'est voulu par Epic, pas un bug de config. Pour
+  le tester : **Play > Standalone Game**, ou un build packagé.
+- **Toute partie est une partie en ligne.** Un seul bouton *Jouer*, qui crée la session puis ouvre
+  la map en `?listen`. Pas de « Héberger » vs « Rejoindre » : le joueur devrait choisir avant de
+  savoir si un ami le rejoindra, et devrait relancer sa partie pour changer d'avis.
+- **On rejoint UNIQUEMENT par invitation Steam**, depuis le bouton *Inviter* du menu de pause.
+  L'acceptation est écoutée par `USessionSubsystem` dès son `Initialize` et jamais coupée : une
+  invitation tombe à n'importe quel instant, y compris en pleine partie, et le sous-système est le
+  seul objet dont on soit certain qu'il vive à ce moment-là. La commande console **`EmberJoin`**
+  existe pour tester à deux instances, sans aucun bouton pour y mener.
+- **Un échec de session ne bloque pas le lancement** : la map s'ouvre quand même en serveur
+  d'écoute, seul *Inviter* est grisé. Un joueur qui clique Jouer veut jouer ; le renvoyer à son
+  menu pour une panne de Steam serait une punition qui n'est pas la sienne.
+- **`bUseLobbiesIfAvailable = true` est LE drapeau à ne pas oublier** : Steam ne route le P2P que
+  par un lobby. Sans lui la session se crée, apparaît même dans une recherche, mais aucune
+  connexion n'aboutit hors du LAN.
+- **`AGameMode` n'existe que sur le serveur.** `GetGameMode()` rend `nullptr` sur un client,
+  toujours. Tout appel écrit côté client doit devenir un RPC serveur ou une lecture du GameState —
+  c'est notamment le cas du respawn dans `AFpsPlayerController`, **encore à faire**.
+- **Autorité : le serveur, pour tout ce qui touche au monde.** Pickups, coffres, feux, établis et
+  inventaires sont modifiés **uniquement** côté serveur ; les clients demandent par RPC et
+  reçoivent le résultat par réplication. Coop entre amis, donc aucune anti-triche : les
+  validations serveur sont des garde-fous contre la désynchronisation, pas contre le joueur.
+- **`Slots` de `UInventoryComponent` est répliqué à TOUT LE MONDE**, pas au seul propriétaire.
+  Ce n'est pas un raccourci : les conditions de `GetLifetimeReplicatedProps` sont mises en cache
+  **par classe**, pas par instance. Un `COND_OwnerOnly` frapperait donc aussi le composant d'un
+  coffre — or un coffre n'appartient à aucune connexion, et sa grille n'arriverait chez personne.
+  Le même composant sert le sac et le contenant, et les coffres sont à accès simultané. Coût réel :
+  4 × 30 slots de trois champs, envoyés seulement quand ils changent.
+- **Coffres : accès simultané**, pas de verrou. `TransferSlot` diffuse déjà `OnInventoryChanged`
+  des deux côtés, l'ossature est là.
+
+### Tester la coop — ça ne se teste QUE en build Steam
+
+**PIE ne teste pas la coop de ce projet.** L'OSS Steam y est désactivé de force par Epic
+(`IsEnabled()` teste `IsRunningGame()`), donc pas de session, pas d'invitation, pas de relais.
+PIE en *Play As Listen Server* reste utile pour la réplication pure (voir l'autre joueur bouger,
+un pickup disparaître), mais **tout ce qui touche à la session se teste en build packagé**,
+distribué par le dépôt Steam. C'est la procédure de référence.
+
+**1. Packager** — éditeur fermé :
+
+```powershell
+& "C:\Program Files\Epic Games\UE_5.8\Engine\Build\BatchFiles\RunUAT.bat" BuildCookRun `
+  -project="D:\Projet\Perso\Unreal\Survival_projet\Survival_projet.uproject" `
+  -noP4 -platform=Win64 -clientconfig=Development `
+  -build -cook -stage -pak -compressed -prereqs `
+  -archive -archivedirectory="D:\Projet\Perso\Unreal\Survival_projet\Build\Package" `
+  -utf8output -nocompileeditor
+```
+
+`Development` et pas `Shipping` : on garde la console (`~`), les logs dans `Saved/Logs` et la
+commande `EmberJoin`. Sans eux, un échec chez le testeur ne dit rien. Premier cook ≈ 18 min,
+les suivants sont bien plus courts (DDC chaud).
+
+**2. Copier dans le dépôt** — le contenu de `Build\Package\Windows\` va **à la racine** de
+`C:\sdk\tools\ContentBuilder\content\`, en excluant `steam_appid.txt` : Steam fournit lui-même
+l'AppID au lancement, et le fichier l'écraserait.
+
+**3. Uploader** — `C:\sdk\tools\ContentBuilder\upload_emberwild.bat` (App **4282850**, dépôt
+**4282851**). Le `.vdf` n'a **pas** de `SetLive`, donc le build monte sans devenir live.
+
+**4. Publier sur la branche `develop`**, jamais sur `default`. Et vérifier que *Launch Options*
+pointe sur `Survival_projet.exe` — puis **publier les changements**, sinon rien n'est visible
+côté client.
+
+**5. Tester à deux** : les deux lancent le jeu **depuis Steam**, l'hôte clique *Jouer*, puis
+Échap → *Inviter des amis*. Les logs à lire sont dans `Survival_projet/Saved/Logs/` de chaque
+côté — `ShowInviteUI` chez l'hôte, `invitation acceptee` puis `voyage vers [...]` chez l'invité.
+
+**Deux réglages qui cassent tout si on les oublie** : la *List of Maps to Include* dans les
+Packaging Settings doit contenir `MenuScene` **et** `GameScene` — cette dernière n'est référencée
+que par un `TSoftObjectPtr`, et une référence soft n'est pas suivie par le cooker ; sans elle le
+build démarre sur le menu et *Jouer* ne charge rien. Et sans liste du tout, le cook embarque les
+~25 maps de démo SoStylized.
+
+**Se tester seul** reste possible malgré l'invitation obligatoire : deux instances lancées avec
+`-nosteam` retombent sur `OnlineSubsystemNULL`, donc en LAN, et la commande console `EmberJoin`
+fait recherche + connexion sur la seconde.
+
+### Réplication — la règle, et où on en est
+
+**La règle : rien de ce qui touche au monde ne s'exécute sur un client.** Un client trace, vise,
+affiche, glisse — mais dès qu'il faut *changer* quelque chose, il envoie un RPC serveur et attend
+la réplication. Le symptôme quand on l'oublie est toujours le même et il est fourbe : ça marche
+parfaitement en solo et chez l'hôte, et l'objet réapparaît chez le client à la réplication suivante.
+
+**Le point de passage unique : `IInteractable::Execute_Interact`.** Les quatre acteurs du monde
+(`PickupItem`, `CookingStation`, `CraftingStation`, `StorageContainer`) passent tous par là.
+`UInteractionComponent::TryInteract()` route donc vers `Server_Interact` quand on n'a pas
+l'autorité — une seule RPC rend les quatre autoritaires. Ne jamais appeler `Execute_Interact`
+ailleurs sans se poser la question de qui exécute.
+
+**`SetIsReplicatedByDefault(true)` est obligatoire sur un composant qui porte un RPC serveur**,
+même s'il ne réplique aucune propriété : sans lui le moteur **jette silencieusement** l'appel.
+
+**`OnConstruction` s'exécute avant l'arrivée des propriétés répliquées.** Un acteur dont le
+visuel dépend d'une `UPROPERTY` répliquée doit la déclarer `ReplicatedUsing` et reposer son
+visuel dans l'`OnRep` — sinon l'objet est correct chez l'hôte et nu chez les clients. C'est
+exactement le cas d'`APickupItem::OnRep_ItemData`.
+
+**L'UI se recâble toute seule.** Tous les widgets sont abonnés à `OnInventoryChanged` et aucun
+ne fait de Tick : il suffit qu'`OnRep_Slots()` rediffuse ce délégué. C'est le dividende de la
+règle « les widgets s'abonnent à des délégués », et il faut la tenir pour les systèmes à venir.
+
+**Un client arrive en SPECTATEUR, et la caméra y reste un instant.** C'est la cause du « on voit
+sous la carte » à la connexion, et elle est contre-intuitive : le pawn est bien créé **et bien
+placé**, mais `GetViewTarget()` vaut encore `SpectatorPawn_0` — né au centre du monde, donc sous
+le terrain. Mesuré sur une vraie connexion :
+
+```
+FadeIn démarre        ViewTarget=SpectatorPawn_0   PawnLoc=(11319, -16530, 1805)
+AcknowledgePossession Pawn=BP_FpsPlayer_C_0        ViewTarget=SpectatorPawn_0
+```
+
+La caméra bascule sur le corps **après** l'acquittement de la possession. La bonne condition pour
+éclaircir n'est donc pas « ai-je un pawn » mais **`GetViewTarget() == GetPawn()`** — d'où la
+boucle de réessai de `TryStartupFadeIn()`, avec `CompleteStartupFadeIn()` comme filet au bout de
+`StartupFadeTimeout` (un écran noir définitif se lit comme un plantage).
+
+**Et rien ne doit être rendu avant.** Entre le chargement de la map et ce moment-là, aucun acteur
+n'existe à qui accrocher un voile — le composant de fondu vit justement sur le contrôleur absent.
+`USurvivalGameInstance` coupe donc `bDisableWorldRendering` sur le viewport, seul objet qui survive
+au changement de map sans appartenir à personne, et c'est le contrôleur qui le rend une fois son
+voile noir en place.
+
+**`PreLoadMap` et surtout PAS `PostLoadMapWithWorld`** pour cette coupure. Le second est diffusé
+**après** le `BeginPlay` des acteurs : sur une map chargée localement — le menu, ou la partie chez
+l'hôte — le contrôleur rendait la main au rendu, et on la lui reprenait juste après. Écran noir
+définitif jusqu'au filet de sécurité. Chez un client ça passait *par accident*, son contrôleur
+arrivant plus tard — donc invisible si l'on ne teste que ce cas-là.
+
+*Note : `ReceivedPlayer()` arrive AVANT `BeginPlay()` chez un client, et `IsLocalController()` y est
+déjà vrai — ce n'est donc pas là qu'est le problème, contrairement à ce qu'on pourrait croire.*
+
+**`IsLocalController()` est indispensable sur tout ce qui touche à l'écran.** Sur la machine de
+l'hôte, chaque joueur distant a AUSSI un `AFpsPlayerController` côté serveur. Sans cette garde, le
+contrôleur d'un ami qui se connecte va poser un fondu et rallumer le rendu **du viewport de
+l'hôte**, à un instant totalement arbitraire.
+
+### Étiquettes de pseudo
+
+- **Le serveur ne peut PAS deviner le pseudo Steam d'un client** : l'API d'identité ne connaît que
+  l'utilisateur local de chaque machine. C'est donc le client qui l'annonce
+  (`Server_SetPlayerNickname`), et le serveur l'écrit sur le `PlayerState`, déjà répliqué par le
+  moteur. Sans ça on lit « Player » au-dessus des quatre joueurs — c'est le nom par défaut que le
+  moteur met dans l'URL de voyage.
+- **Espace ÉCRAN, pas Monde** : l'étiquette fait face à la caméra *par construction*, sans calcul
+  d'orientation, et n'est jamais occultée par le décor. Mais `SWorldWidgetScreenLayer::Tick`
+  n'applique **aucune échelle de distance** — le pseudo garderait une taille en pixels constante
+  pendant que le personnage rétrécit, ce que l'œil lit comme une étiquette qui *grossit* en
+  s'éloignant. D'où l'échelle calculée à la main en 1/d, et l'opacité en fondu sur la dernière
+  bande avant `MaxDrawDistance`.
+- Le composant ne réplique **rien** : le pseudo vit déjà sur le `PlayerState`.
+
+### Le pop-in au chargement — deux causes, deux remèdes
+
+**Les requêtes** — textures et LOD de meshes. `IStreamingManager::StreamAllResources()` les traite
+toutes (`UpdateResourceStreaming(0, true)` n'a pas besoin de point de vue, ce qui tombe bien : le
+rendu est encore coupé) puis bloque jusqu'à ce qu'elles aboutissent. Appelé dans
+`ResumeWorldRendering()`, donc **écran noir** : c'est du temps de chargement, pas une saccade.
+Mesuré : ~80 ms, 0 requête restante.
+
+**Ce qui converge par IMAGE** — Nanite, ombres virtuelles, Lumen. Aucun flush ne peut les forcer :
+il leur faut des images rendues. D'où `BeginSceneWarmup()`, qui laisse le monde rendre derrière le
+voile encore noir avant de l'éclaircir.
+
+**Il compte des IMAGES, pas des secondes**, et c'est tout l'intérêt : une durée fixe donnerait
+quarante images sur une machine rapide et cinq sur une machine lente — c'est-à-dire le moins de
+chauffe à celle qui en a le plus besoin. `SetTimerForNextTick` = un tick, une image.
+`SceneWarmupMaxSeconds` n'est qu'un **plafond**, pas la mesure ; le log dit « plafond atteint »
+quand il s'applique, pour savoir lequel des deux réglages ajuster.
+
+Ordre non négociable dans le menu : `SetViewTarget` **puis** `ResumeWorldRendering()`. L'inverse
+ferait chauffer le décor vu depuis l'angle par défaut, c'est-à-dire pas celui qu'on va montrer.
+
+**`OnPossess` n'existe QUE sur le serveur.** Chez un client, le pawn arrive par réplication et
+`OnPossess` n'est jamais appelée — son pendant est **`AcknowledgePossession`**. Tout ce qui doit
+se produire à la prise de contrôle (création du HUD, rebranchement des widgets, abonnement à
+`OnDied`) passe donc par `SetupForPossessedPawn()`, appelée des deux côtés et **idempotente** :
+chez l'hôte, qui est serveur *et* client local, les deux chemins l'exécutent. D'où
+`AddUniqueDynamic` sur `OnDied`, sinon la mort déclencherait deux fondus et deux respawns.
+Symptôme quand on l'oublie : un joueur qui rejoint n'a aucune interface, alors que l'hôte a la
+sienne — donc invisible en solo comme en test chez soi.
+
+**Une connexion qui tombe ne ramène personne nulle part.** Le moteur coupe le lien et s'arrête là.
+`USurvivalGameInstance` s'abonne donc à `GEngine->OnNetworkFailure()` et `OnTravelFailure()` pour
+détruire la session et rouvrir le menu. C'est sur le GameInstance et pas sur le PlayerController
+parce que celui-ci est justement détruit par l'échec.
+
+**Quand l'hôte quitte, tout le monde quitte — et on le dit explicitement.** Le moteur ne prévient
+personne : sans RPC, les clients restent dans un monde mort, avec le **pawn fantôme de l'hôte**
+encore planté devant eux, jusqu'à un timeout qui peut ne jamais venir. `HandleQuitToMenuConfirmed`
+appelle donc `KickRemoteClientsToMainMenu()` **avant** de lancer son propre fondu, pour que les
+quatre fondus tournent ensemble. Le filet `OnNetworkFailure` reste pour ce qui n'est pas annoncé —
+hôte qui plante, câble arraché — et se tait pendant un départ voulu grâce à
+`BeginReturnToMainMenu()`, sinon il chargerait le menu en plein milieu du fondu.
+
+| Système | État |
+|---|---|
+| Déplacement, crouch | ✅ gratuit via `ACharacter` / `CharacterMovement` |
+| Sprint (`bIsSprinting` + RPC vitesse) | ✅ fait |
+| Interaction (RPC serveur + validation de distance) | ✅ fait |
+| `PickupItem` (ramassage, visuel, quantité) | ✅ fait |
+| `InventoryComponent` — lecture (`Slots` répliqué) | ✅ fait |
+| `InventoryComponent` — écriture (transferts, consommation) | ✅ fait |
+| Jeter au sol (`DropFromInventory`, `DropAllItems`) | ✅ fait |
+| `SurvivalStatsComponent` (simulation serveur, mort par `OnRep_Dead`) | ✅ fait |
+| Respawn (`Server_RequestRespawn`) | ✅ fait |
+| `StorageContainer` (contenu, couvercle) | ✅ fait |
+| `CraftingComponent` (`Server_Craft`) | ✅ fait |
+| `CookingStation` (grill, bûches, flamme) | ✅ fait |
+| Corps 3e personne animé (rien à répliquer, tout dérivé) | ✅ fait |
+
+**Un acteur du monde qui ouvre une interface doit RENVOYER l'ordre au client.**
+`Interact_Implementation` s'exécute sur le serveur : `PlayerController->OpenStorage(...)` y créerait
+un widget dans le vide et l'écran du joueur ne s'ouvrirait jamais. D'où `Client_OpenStorage` et
+`Client_OpenCraftingAtStation`. C'est le piège le plus contre-intuitif du portage, parce que le
+code *semble* correct et fonctionne parfaitement chez l'hôte.
+
+**L'établi n'a rien à répliquer.** `ACraftingStation` est un meuble : un mesh, un prompt, aucun
+état. Ce qui devait changer, c'est le sens de l'appel (ci-dessus) et `Craft()`, qui touche
+l'inventaire autoritaire. Le poste accessible est tenu **des deux côtés** — le client en a besoin
+pour filtrer sa grille de recettes, le serveur pour valider `Server_Craft`. N'en tenir qu'un
+donnerait soit un onglet vide devant un établi, soit un établi utilisable depuis la forêt.
+
+**La cuisson ne se compte que sur le serveur.** Les `FTimerHandle` ne sont pas des `UPROPERTY` et
+ne partent jamais sur le réseau : les clients ne reçoivent que le *résultat* — l'objet devenu
+cuit, la bûche disparue, la flamme allumée. Quatre clients qui compteraient chacun leur cuisson
+divergeraient, et le steak serait brûlé chez l'un et cru chez l'autre.
+
+**Le sprint est le piège qui ne se voit pas chez l'hôte.** `MaxWalkSpeed` posé en local
+seulement laisse le serveur croire le client à `WalkSpeed` : il corrige alors sa position à
+chaque pas, et c'est le rubber-banding. D'où `Server_SetSprinting`, appelée **après** avoir
+appliqué en local — l'inverse donnerait un sprint qui démarre en retard.
+
+**Pas de prédiction sur l'inventaire.** Le client envoie sa RPC et attend `OnRep_Slots`.
+Quelques dizaines de millisecondes sur un relais Steam, invisibles pour un glisser-déposer,
+alors qu'une prédiction fausse donnerait une pile qui saute.
+
+**`FindNetProxy` est le passage obligé des transferts vers un coffre.** Un `UInventoryComponent`
+de conteneur n'appartient à aucune connexion : une RPC émise depuis lui est **silencieusement
+jetée**. On route donc toujours par l'inventaire du pawn local, et la source comme la destination
+sont passées en paramètres — jamais déduites du récepteur, sinon « Tout prendre » viderait le sac
+du joueur dans lui-même.
+
+### Audio — le mixage passe par les SoundClass, et par rien d'autre
+
+- **Une hiérarchie de `SoundClass`, un `SoundMix`, quatre curseurs.** `SC_Master` est la
+  racine ; `SC_Music`, `SC_SFX` et `SC_UI` en descendent. Le moteur multiplie déjà le volume
+  du parent dans celui de l'enfant, donc le volume général est gratuit — pas de produit à
+  calculer en C++.
+- **`SM_Settings` est déclaré comme *Default Base Sound Mix*** dans Project Settings > Audio,
+  et le C++ le relit à cet endroit au lieu d'en garder une référence à lui. Deux raisons : un
+  mix de base est **rejoué à plein régime en permanence** (un mix poussé à la main s'éteindrait
+  au bout de sa durée), et le moteur le **repose à chaque chargement de map** — donc les
+  volumes traversent les transitions sans une ligne de code. Une seconde référence côté projet
+  n'apporterait qu'un risque de divergence.
+- **`bApplyToChildren = true` sur le maître, `false` sur les trois autres.** C'est le piège de
+  ce système : le moteur propage les propriétés parent → enfant (`ParseSoundClasses`) **avant**
+  d'appliquer les ajusteurs du mix (`ApplyClassAdjusters`). Un ajusteur posé sur `SC_Master`
+  arrive donc trop tard pour redescendre tout seul. Sans ce drapeau, le volume général n'agit
+  que sur les sons rangés *directement* dans `SC_Master` — c'est-à-dire quasiment rien, et le
+  symptôme se lit comme « le curseur maître ne fait rien ».
+- **Aucun fondu sur `SetSoundMixClassOverride` — `FadeInTime` vaut 0.** Ce n'est pas une
+  simplification : toute durée non nulle rend le curseur inutilisable. Reposer un override
+  avant la fin du précédent relance l'interpolation (`FDynamicParameter::Set` remet
+  `CurrTimeSec` à zéro) **sans** appeler `Update(DeltaTime)` la même frame. Un curseur qu'on
+  glisse repose l'override à chaque image, donc la rampe repart indéfiniment de zéro et le
+  volume ne rattrape son retard qu'une fois le geste **arrêté**. Le mixeur lisse déjà le gain
+  de chaque source dans son buffer de rendu : à zéro il n'y a pas de clic pour autant.
+- **`SC_SFX` est la *Default Sound Class* du projet.** Un son qui n'annonce pas sa classe
+  atterrit donc dans les effets plutôt que nulle part : oublier de taguer un bruitage le laisse
+  quand même sous le curseur Effets. Seuls les sons d'interface se taguent à la main.
+- **La musique impose sa classe depuis le code** (`SoundClassOverride` posé par
+  `UMusicSubsystem`), pas depuis les assets : ajouter une piste à une playlist ne doit pas
+  demander de penser à la taguer. Corollaire, `UMusicSubsystem::SetMusicVolume` **n'est pas** le
+  réglage du joueur — deux chemins vers le même volume finiraient par se multiplier.
+- **Les volumes sont des pourcentages, élevés au carré avant d'être envoyés.** L'oreille répond
+  au logarithme de l'amplitude : un curseur envoyé tel quel donne un réglage où tout se joue
+  dans les vingt derniers pourcents. À 50 %, l'amplitude vaut 0,25, soit environ la moitié du
+  volume *perçu*.
+- **`ApplyAudioSettings()` est séparée d'`ApplySurvivalSettings()`** : cinq commandes vers le
+  thread audio à chaque cran du champ de vision seraient du bruit pur. `ApplyNonResolutionSettings`
+  appelle les deux, donc le démarrage n'en oublie aucune.
+- **Le jeu est muet en arrière-plan par défaut, et c'est le moteur qui le décide**
+  (`FApp::UnfocusedVolumeMultiplier`, dont la valeur d'usine est 0). Le réglage ne fait que
+  l'exposer ; il ne passe pas par le mix, puisqu'il baisse l'application entière bien en amont.
 
 ### Décisions de gameplay figées
 
@@ -148,9 +509,14 @@ qu'une compilation propre l'est vraiment.
   **relit** à son `BeginPlay` et s'abonne à `OnSurvivalSettingsApplied`.
 - **Échap** a une priorité explicite dans `HandlePauseInput()` : boîte de confirmation →
   réglages → inventaire → pause. Sans cet ordre, deux écrans se retrouvent ouverts en même temps.
-- **Menu de pause** : `SetPause(true)` fige le monde, mais **pas Slate** — les animations UMG et
-  `ScreenFadeComponent` continuent (d'où son `bTickEvenWhenPaused`). Pas de bouton « Quitter le
-  jeu » : la sortie se fait depuis le menu principal.
+- **Menu de pause : il ne met plus rien en pause.** `SetPause()` a disparu du projet. En coop la
+  pause est impossible par nature — côté client l'appel est ignoré (elle appartient à l'autorité),
+  côté hôte elle figerait le monde des quatre joueurs parce qu'un seul a ouvert son menu. Le monde
+  continue donc de tourner, comme dans Valheim et Raft : ouvrir son menu ne met pas à l'abri.
+  Corollaire **non négociable** : c'est la pause qui coupait gratuitement l'input du pawn, il faut
+  donc passer par `SetUiInputMode(true)` — le même que l'inventaire et le coffre. L'oublier laisse
+  la caméra tourner derrière le menu. Pas de bouton « Quitter le jeu » : la sortie se fait depuis
+  le menu principal.
 - **Réglages** : `USurvivalUserSettings` fait autorité, jamais le CDO du pawn. Application
   immédiate, aucun bouton « Appliquer » ; la sauvegarde a lieu à la fermeture de l'écran.
   L'écran ignore qui l'ouvre (`OnCloseRequested`), d'où un seul `WBP_Settings` pour le menu
@@ -295,26 +661,128 @@ Le détail du système de craft — API, câblage éditeur, dépannage — est d
 
 ## État actuel et suite
 
-Boucle complète : récolter → **fabriquer** → **cuire** → ranger → consommer → survivre →
-mourir → réapparaître. Autour : menu principal, menu de pause, et un écran de réglages dont **seul
-l'onglet « Jeu & Contrôles » est rempli**.
+Boucle complète **en coop jusqu'à 4 joueurs** : récolter → fabriquer → cuire → ranger →
+consommer → survivre → mourir → réapparaître. Autour : menu principal, menu de pause, écran de
+réglages, étiquettes de pseudo Steam.
 
-Le craft est en place de bout en bout : `DA_RecipeBook`, onglets Inventaire / Fabrication,
-grille de recettes filtrée par poste accessible, panneau de détail avec compteurs colorés.
-Restent à faire quand le besoin viendra : l'**acteur établi** qui appellera
-`AddAvailableStation(Workbench)`, les **boutons de filtre** par poste (`SetStationFilter` existe
-déjà et `ECraftingStation::Count` sert de sentinelle « tout »), et les vraies recettes — celles
-en place sont deux `DA_Craft_Test_*` bâties sur `DA_Branch` et `DA_Rocher`.
+Le portage réseau est terminé pour tout le gameplay existant — voir *Réplication* plus haut pour
+le détail et les pièges. Les transitions de map sont propres de bout en bout : plus de flash, plus
+de pop-in, départ groupé quand l'hôte quitte.
 
-Suite immédiate sur les réglages, dans l'ordre : onglet **Affichage** (le moteur fait tout,
-prévoir la confirmation à rebours de 10 s sur la résolution), onglet **Graphismes** (les dix
-curseurs de `UGameUserSettings` ; végétation et distance d'affichage comptent double avec
-SoStylized), onglet **Audio** quand des `SoundClass` existeront, et enfin le **remappage des
-touches** via `UEnhancedInputUserSettings` — le seul morceau réellement coûteux.
+Les vraies recettes restent à écrire : celles en place sont deux `DA_Craft_Test_*` bâties sur
+`DA_Branch` et `DA_Rocher`. Les **boutons de filtre** par poste ne sont pas faits non plus
+(`SetStationFilter` existe déjà, `ECraftingStation::Count` sert de sentinelle « tout »).
+
+### Chantier en cours : customisation de personnage
+
+Découpé en quatre lots. **Le lot 1 est fait** : le pawn a enfin un corps visible et animé (voir
+*Le corps vu par les autres* plus haut) — sans lui il n'y avait rien à customiser, et les autres
+joueurs voyaient un pseudo flotter au-dessus du vide.
+
+**Le lot 2 est fait aussi** : `FCharacterAppearance` (11 octets d'index), `UCharacterPartsDataAsset`
+(le catalogue) et `UCharacterAppearanceComponent` (monte les pièces en leader pose, pose les
+couleurs sur des MID). `DA_CharacterParts` couvre Body A ; **Body B reste à remplir**, avec son
+`ABP_PlayerBody_B` et sans barbes ni moustaches — le pack n'en livre pas, et une liste vide se
+comporte déjà comme `NoPart`.
+
+**Le lot 3 est fait** : l'apparence vit sur `ASurvivalPlayerState` en `ReplicatedUsing` et se
+persiste dans `USurvivalUserSettings`. Elle survit donc au respawn — le pawn est un nouvel acteur,
+le PlayerState non — et au relancement du jeu.
+
+- **`SubmitCharacterAppearance()` sur `AFpsPlayerController` est le point d'entrée UNIQUE.** Il
+  persiste *et* annonce au serveur, jamais l'un sans l'autre : persister sans annoncer laisserait
+  le joueur seul à se voir changé, annoncer sans persister le ferait repartir au visage par défaut
+  au lancement suivant. C'est par là que passent les commandes console, et par là que passera
+  l'écran du lot 4.
+- **La course pawn / PlayerState se résout des deux côtés.** Chez un client ils arrivent par deux
+  chemins de réplication indépendants et rien ne dit lequel gagne : `OnRep_CharacterAppearance`
+  monte le personnage si le pawn est déjà là, `AFpsPlayer::OnRep_PlayerState` va chercher
+  l'apparence si c'est le pawn qui est arrivé le premier. Les deux appellent la même fonction
+  idempotente. Chez l'hôte, aucun `OnRep` ne se déclenche — c'est le `BeginPlay` du pawn qui monte,
+  et `SetCharacterAppearance` qui applique en local juste après avoir écrit la propriété.
+- **Rien n'est validé côté PlayerState, et c'est délibéré** : borner un index demande le catalogue,
+  que seul `UCharacterAppearanceComponent` connaît — or il passe déjà tout ce qu'il monte par
+  `Catalog->Sanitize()`, sur chaque machine. Dupliquer la validation demanderait de donner le
+  catalogue au PlayerState pour un résultat identique.
+- Piège de test : **en PIE à deux joueurs, les deux fenêtres lisent le même `.ini`**, donc les deux
+  personnages démarrent identiques. Il faut changer l'un des deux à la console pour vérifier que la
+  réplication marche.
+
+Reste le **lot 4** — l'écran : `ACharacterPreviewActor` dans `MenuScene`, caméra à cadrages
+interpolés, UI à gauche. Et le remplissage de **Body B** dans `DA_CharacterParts`.
+
+#### Trois pièges du lot 2, aucun visible depuis le code
+
+- **Les `UFUNCTION(Exec)` d'un `UActorComponent` ne sont JAMAIS appelées.** La chaîne de routage
+  (`UPlayer::Exec`, dans `Player.cpp`) interroge le monde, le `PlayerInput`, le contrôleur, le
+  **pawn**, le HUD, le GameMode, le `CheatManager`, le GameState et le camera manager — jamais les
+  composants, `AActor` ne surchargeant pas `ProcessConsoleExec` pour les parcourir. Et rien ne
+  proteste : la commande est simplement introuvable. D'où `EmberPart` / `EmberColor` /
+  `EmberAppearanceDump` posées sur `AFpsPlayer`, qui délègue au composant. *(`EmberJoin` marche
+  parce que `UGameInstance`, lui, route vers ses subsystems.)*
+- **L'ordre des slots de matériau varie d'un mesh à l'autre.** Sur `SKM_HeadA_01`, l'Element 0
+  est celui des **yeux** et l'Element 1 celui de la peau — l'inverse de l'intuition. Les six têtes
+  viennent de deux packs différents, rien ne garantit qu'elles s'accordent. On cherche donc le slot
+  **par son nom** (`EyeMaterialSlotHint`, « Eye »), et si rien ne correspond on ne pose rien et on
+  le dit dans le log : écraser le slot de la peau repeint le visage entier de la couleur des yeux,
+  symptôme qu'on met bien plus longtemps à diagnostiquer qu'une ligne de log.
+- **Un nom de paramètre matériau se lit dans l'éditeur du Material INSTANCE, jamais dans les
+  chaînes du master.** Le binaire de `M_Head_Base` contient « Skin Base color », mais le paramètre
+  réellement exposé s'appelle **`Skin`** — le chercher sous l'autre nom dans `MI_HeadA_01_a` ne
+  rend aucun résultat. Corollaire : les noms de paramètres sont des `UPROPERTY` du catalogue et
+  pas des constantes C++, pour qu'une erreur se corrige sans recompiler.
+
+Le montage lui-même n'a rien de surprenant : le composant crée un `USkeletalMeshComponent` par
+catégorie, le met en leader pose du `Mesh` du Character, et recopie sur chacun le `bOwnerNoSee` et
+le `bCastHiddenShadow` du porteur — c'est ce qui fera que le mannequin du menu, lui, sera visible
+sans une ligne de plus. Les couleurs sont posées sur **tous** les éléments de chaque mesh sans
+chercher lequel les porte : un `SetVectorParameterValue` dont le paramètre n'existe pas est
+ignoré, ce qui évite une table d'index de slots qui casserait au premier mesh mal rangé.
+
+**Décisions figées** :
+
+- **Couleurs = palette pure, un bouton par couleur.** Une `TArray<FLinearColor>` par catégorie
+  dans le catalogue, un index d'un octet dans l'apparence. Cliquer une pastille pose la couleur,
+  sans réglage intermédiaire. Le curseur de nuance envisagé au départ a été retiré : l'auteur veut
+  des boutons.
+- **Pas de `DisplayName` sur les entrées du catalogue** — la vignette (`Icon`, un `UTexture2D`
+  comme celle d'`UItemDataAsset`) identifie l'option à elle seule.
+- **Écran imposé sur le chemin *Jouer*.** Corollaire assumé : l'arrivée par invitation Steam ne
+  passe pas par là, l'invité garde donc son apparence persistée du dernier passage.
+- **Étendue : silhouette + couleurs.** Tatouages et maquillage reportés — ce ne sont que des
+  paramètres texture de plus (`M_Head_Base` et `M_Body_Base` les exposent déjà), aucune refonte.
+- **Les index et jamais les chemins d'assets** dans la struct répliquée : quelques octets au lieu
+  d'une chaîne, et un index se valide contre le catalogue.
+- **Le corps se monte depuis une LISTE de meshes, jamais un pointeur unique**, même quand la liste
+  n'a qu'une case. C'est ce qui permettra aux armures de cacher des segments (`SKM_BodyA_torso`,
+  `_arms`, `_legs_01/02/03`…) sans refonte — le pack les fournit exprès. Contrainte qui en
+  découle : **tout futur pack d'armure devra être skinné sur `SK_BodyA` / `SK_BodyB`**, à vérifier
+  avant achat. Le jour venu, `SKM_BodyA_empty` deviendra le porteur d'animation invisible — il
+  faudra lui réassigner `SK_BodyA`, son squelette d'origine étant `SK_BodyA_empty`.
+- Limite acceptée : **les bras vus en 1re personne ne sont pas customisés.** Leur squelette
+  (`BasePose_Skeleton`) n'a rien à voir avec `SK_BodyA` ; les rendre customisables imposerait de
+  retargeter toutes les animations FPS. Raft assume le même compromis.
+
+**Les matériaux du pack sont pilotables par MID**, ce qui rend les variantes `_a` / `_b` / `_c`
+inutiles — ce ne sont que des presets de couleur figés. Une seule instance par pièce suffit :
+
+| Master | Paramètres utiles |
+|---|---|
+| `M_Body_Base` | `Skin color`, `Underware color`, `Tattoo 01..05 color` + masques |
+| `M_Head_Base` | `Skin Base color`, `Skin roughness`, `Blush` / `Lipstick` / `Eyeliner` / `Eyeshadow` / `Eyelashes` / `Tattoo` (couleur + masque chacun) |
+| `M_Hairstyle_Base` | `Color` — parent des **cheveux, barbes, moustaches ET sourcils** |
+| `M_Eyes_Base` | `Eye color`, groupes Iris / Pupil / Sclera |
+
+### Après la customisation
 
 Prochaine étape gameplay recommandée : **spawner de ressources avec repousse**
 (`AResourceSpawner`, liste pondérée de DataAssets, rayon, densité, délai). Sans lui la carte se
-vide en dix minutes.
+vide en dix minutes. À écrire **serveur-autoritaire d'emblée** — c'est un acteur du monde.
 
-Ensuite, par ordre de valeur : objet visible en main, établi, coffres, sauvegarde,
-cycle jour/nuit.
+Ensuite, par ordre de valeur : objet visible en main, sauvegarde, cycle jour/nuit.
+
+> **Systèmes présents dans `Source/` mais pas encore décrits ici** :
+> `SettingsDisplayWidget`, `SettingsGraphicsWidget`,
+> `SettingsControlsWidget`, `SettingKeyRowWidget`, `KeyCaptureWidget`. Ils sont arrivés en dehors
+> des sessions qui ont produit ce document — à documenter quand on y touchera, plutôt que de
+> décrire de mémoire un code qu'on n'a pas lu.

Config/DefaultEngine.ini

@@ -92,6 +92,46 @@ FontDPI=72
 ; n'existent tout simplement pas au runtime.
 GameUserSettingsClassName=/Script/Survival_projet.SurvivalUserSettings
 
+; ==================================================================
+; Coop Steam (4 joueurs, listen server, P2P par le relais Valve)
+; ==================================================================
+
+; Le NetDriver par defaut ouvre un socket UDP et attend une IP : inutilisable
+; derriere un NAT. SteamSocketsNetDriver fait transiter la connexion par le
+; relais de Valve -- aucun port a ouvrir, aucune IP echangee entre joueurs.
+; Le ClearArray est obligatoire : sans lui on empile une seconde definition
+; "GameNetDriver" et c'est celle du moteur qui gagne.
+; Le Fallback sert au PIE et aux tests hors Steam : sans client Steam lance,
+; le moteur retombe sur l'IpNetDriver classique au lieu de refuser de demarrer.
+[/Script/Engine.GameEngine]
+!NetDriverDefinitions=ClearArray
++NetDriverDefinitions=(DefName="GameNetDriver",DriverClassName="/Script/SteamSockets.SteamSocketsNetDriver",DriverClassNameFallback="/Script/OnlineSubsystemUtils.IpNetDriver")
+
+[/Script/SteamSockets.SteamSocketsNetDriver]
+NetConnectionClassName="/Script/SteamSockets.SteamSocketsNetConnection"
+
+[OnlineSubsystem]
+DefaultPlatformService=Steam
+
+; SteamDevAppId = notre AppID reel (Emberwild). Le classique 480 (Spacewar)
+; ne sert que si des testeurs ne possedent pas encore le jeu sur leur compte.
+;
+; PAS de bInitServerOnClient : il force l'initialisation de l'API GameServer
+; de Steam en plus de l'API client, dans le meme process. C'est fait pour
+; tester du code de serveur dedie sur une machine de dev. Un listen server
+; n'en a pas besoin -- il cree un LOBBY Steam via l'API client. Pire, si
+; l'init serveur echoue alors que le client a reussi, OnlineSubsystemSteam
+; detruit TOUT (voir le Shutdown() de son Init) : on ajouterait un mode
+; d'echec sans rien gagner.
+;
+; Rappel qui fait perdre du temps : dans l'EDITEUR, IsEnabled() rend toujours
+; faux (IsRunningGame() est faux), donc Steam ne s'initialise jamais en PIE et
+; le moteur retombe sur OnlineSubsystemNULL. C'est voulu par Epic. Pour tester
+; Steam il faut Play > Standalone Game, ou un build package.
+[OnlineSubsystemSteam]
+bEnabled=true
+SteamDevAppId=4282850
+
 [/Script/AndroidFileServerEditor.AndroidFileServerRuntimeSettings]
 bEnablePlugin=True
 bAllowNetworkConnection=True
@@ -106,3 +146,7 @@ ConnectionType=USBOnly
 bUseManualIPAddress=False
 ManualIPAddress=
 
+[/Script/Engine.AudioSettings]
+DefaultSoundClassName=/Game/Game/Sounds/Mix/SC_SFX.SC_SFX
+DefaultBaseSoundMix=/Game/Game/Sounds/Mix/SM_Settings.SM_Settings
+

Config/DefaultGame.ini

@@ -13,3 +13,54 @@ ProjectID=4774BE68499C24D0A70C6E87B49DA419
 [/Script/DiscordRichPresence.DiscordRichPresenceSettings]
 ClientId=1432045921620725933
 
+; Sans cette liste le cooker embarque TOUTES les maps du dossier Content, donc
+; les ~25 maps de demonstration de SoStylized : build enorme et cook interminable.
+;
+; MenuScene doit y figurer meme si c'est deja la GameDefaultMap, et GameScene
+; SURTOUT : elle n'est referencee que par un TSoftObjectPtr (GameLevel sur
+; BP_MainMenuPlayerController). Une reference soft n'est pas suivie par le
+; cooker comme une reference dure -- sans cette ligne le build demarre sur le
+; menu, on clique Jouer, et rien ne se charge.
+[/Script/UnrealEd.ProjectPackagingSettings]
++MapsToCook=(FilePath="/Game/Game/Maps/MenuScene")
++MapsToCook=(FilePath="/Game/Game/Maps/GameScene")
+; Dev_Scene y figure parce que GameLevel peut pointer sur elle le temps d'un
+; test : la map visee se choisit dans BP_MainMenuPlayerController, et toute map
+; susceptible d'y atterrir doit etre listee ici. Les garder toutes les trois
+; coute un peu de cook mais permet de basculer sans retoucher cette liste --
+; l'oubli, lui, ne se voit qu'une fois le build chez le testeur.
++MapsToCook=(FilePath="/Game/Game/Maps/Dev/Dev_Scene")
+
+; ==================================================================
+; Videos de demarrage (logo moteur puis logo studio)
+; ==================================================================
+;
+; Les entrees sont des noms de fichiers SANS extension, cherches dans
+; Content/Movies/. Ce ne sont PAS des assets : le cooker ne les importe pas,
+; il copie le dossier tel quel au staging (automatique, aucun reglage de
+; packaging a ajouter -- sauf a cocher "Skip Movies", qui les supprimerait).
+;
+; L'ordre de cette liste EST l'ordre de lecture.
+;
+; bWaitForMoviesToComplete : sans lui, la video est coupee net des que la
+; premiere map est prete. MenuScene se charge vite, donc le logo du studio
+; serait ampute -- ou jamais vu.
+;
+; bMoviesAreSkippable : le passage se fait au CLIC SOURIS, pas au clavier
+; (voir le commentaire d'UMoviePlayerSettings). Inutile de chercher pourquoi
+; Echap ne fait rien.
+;
+; Piege qui coute une soiree : ces videos ne jouent JAMAIS en PIE. Il faut
+; Play > Standalone Game, ou un build packagee -- meme logique que Steam.
+[/Script/MoviePlayer.MoviePlayerSettings]
+bWaitForMoviesToComplete=True
+bMoviesAreSkippable=True
++StartupMovies=UnrealLogo
++StartupMovies=StudioLogo
+
+[/Script/Survival_projet.SurvivalAudioSettings]
+MasterSoundClass=/Game/Game/Sounds/Mix/SC_Master.SC_Master
+MusicSoundClass=/Game/Game/Sounds/Mix/SC_Music.SC_Music
+EffectsSoundClass=/Game/Game/Sounds/Mix/SC_SFX.SC_SFX
+UiSoundClass=/Game/Game/Sounds/Mix/SC_UI.SC_UI
+