# 🏗️ Architecture du Projet — ProjectF

> **Ce document est la référence d'architecture du projet, destinée en priorité aux modèles d'IA (Claude, etc.) qui vont lire, modifier ou créer du contenu dans ce projet Unreal Engine.**
> Il doit permettre de comprendre **où se trouve chaque système, quel fichier est responsable de quoi, et où ajouter du nouveau contenu** — sans avoir à explorer tout le projet à chaque session.
>
> ⚠️ **Ce document doit rester à jour.** Voir la section [10. Maintenir ce document à jour](#10-maintenir-ce-document-à-jour) et le skill `maintain-architecture-doc`.

---

## 1. Vue d'ensemble du projet

### 1.1 Nature du projet

- **Moteur** : Unreal Engine **5.8**.
- **Aucun code C++** : il n'y a pas de dossier `Source/`. Tout le gameplay est écrit en **Blueprint visuel**, dans `Content/`.
- **Genre** : jeu de survie / extraction en vue 3e personne avec un **inventaire en grille façon "Escape from Tarkov"** (armure, sac à dos, armes, munitions, craft sur feu de camp/fonderie, générateurs, lecteurs de carte magnétique, coffres, PNJ pillables, véhicules).
- **Multijoueur** : le système d'inventaire est répliqué (RPC client/serveur visibles partout dans `Inventory_Player`, ex. `Request Switch Weapon SERVER`, `Disarm Request SERVER`). Le projet doit donc être pensé serveur-autoritaire pour tout ce qui touche à l'inventaire, aux stats et au combat.

### 1.2 Les grandes couches du projet

Le projet est construit par empilement de **trois grands blocs** de contenu, plus une couche d'outillage IA :

1. **Framework de personnage / locomotion ("Sandbox Character")** — `Content/Systems/Blueprints/`
   Basé sur le sample officiel Epic "Motion Matching" (plugins `Mover`, `MotionWarping`, `MotionTrajectory`, `Chooser`, `AnimationLocomotionLibrary`, `AnimationWarping`). Gère le mouvement, la caméra, le Motion Matching, le traversal (vault/mantle/climb), les modes de mouvement personnalisés. **Ce framework est en grande partie template/tiers** : n'y toucher qu'en connaissance de cause.

2. **Système d'inventaire AGIS** ("Advanced Grid Inventory System", asset marketplace) — `Content/Core/Coreinventory/`, `Content/Systems/Inventory/`, `Content/UI/Inventory_UI/`, `Content/Data/Inventory_Data/`.
   C'est le **cœur du gameplay** : inventaire en grille, équipement, craft, loot, sauvegarde. La quasi-totalité des systèmes de jeu ajoutés par l'équipe (stats, mort, sélection rapide d'équipement, interactables) se branchent sur ce système.

3. **Systèmes de jeu spécifiques au projet**, ajoutés par-dessus AGIS — `Content/Systems/Stats/`, `Content/Systems/Scent/`, `Content/Systems/Movable_Object/`, `Content/Systems/Door/`, `Content/PCG/`, `Content/Items/`, `Content/UI/Widgets/` (HUD, pause menu). C'est ici que la majorité des évolutions de gameplay futures doivent être ajoutées.

4. **Outillage IA** — plugins `VibeUE`, `EditorToolset`, `ModelContextProtocol`, `Terminal` (déclarés dans `ProjectFv1.uproject`) + `.mcp.json` à la racine. Ils exposent l'éditeur Unreal (Blueprints, Widgets, Input, PCG, Landscape, Niagara, etc.) à un serveur MCP local (`http://127.0.0.1:8000/mcp`) piloté par des agents Claude. **C'est le mécanisme par lequel un modèle d'IA lit/modifie ce projet** — voir la section [9. Notes pour les IA](#9-notes-pour-les-ia-pièges-connus-de-loutillage) pour les pièges connus.

En plus de cela, deux couches d'assets tiers volumineuses sont présentes mais **ne contiennent pas de logique de gameplay propre au projet** : le pack météo **UltraDynamicSky** (`Content/Systems/Weather/UltraDynamicSky/`) et diverses bibliothèques d'assets 3D Fab/Megascans/Quixel (`Content/Fab/`, `Content/Megaplant_Library/`, une bonne partie de `Content/Animations/` et `Content/Characters/`).

### 1.3 Dépendances principales entre systèmes

```
Character (Pawn, géré par le framework "Sandbox Character")
 │
 ├─ Composant Inventory_Player          (Content/Core/Coreinventory/Inventory_Player)
 │   └─ hérite de Inventory_Equipper    (équipement d'armes/objets)
 │       └─ hérite de Inventory__Main   (cœur générique AGIS : slots, containers, réseau)
 │
 │   ⚠️ Pour un item (`_BP_ItemBase` et enfants) qui a besoin de chercher/consommer un item dans
 │   l'inventaire de son porteur (ex. l'arc qui cherche des flèches), utiliser sa propriété héritée
 │   `Owner Inventory` (fonction `Variables|Runtime|GetOwnerInventory`, self implicite) plutôt que de
 │   reconstruire `GetOwnerCharacter → Cast SandboxCharacter_CMC → GetInventoryPlayer → GetListeningInventory` :
 │   cette dernière chaîne se résout à `None` tant que le joueur n'a pas ouvert son écran d'inventaire au
 │   moins une fois (`Listening Inventory` est un état d'UI, pas l'inventaire persistant). `Owner Inventory`
 │   est typée `Inventory_Equipper` mais accepte directement les pins `Inventory__Main` (ex. `BOTH|FindItem`)
 │   grâce à cette hiérarchie d'héritage — aucun cast nécessaire. Découvert et corrigé dans
 │   `BP_Item_Bow::CountArrows/ConsumeArrow` (voir §7).
 │
 │   Inventory_Player pilote/possède :
 │   ├─ WB_InventoryScreen (UI d'inventaire complète, créée à la demande)
 │   │   └─ WB_InventoryPart1 / WB_InventoryPart2
 │   │       └─ WB_EquipSlot → WB_Container → WB_InventorySlot → WB_Item
 │   ├─ WB_QuickSelect (roue de sélection rapide d'équipement, 4 slots)
 │   └─ Les Input Actions IA_*AGIS via l'IMC_AGIS_Character / IMC_AGIS_InventoryTab
 │
 ├─ Composant AC_Stats                  (Content/Systems/Stats/AC_Stats)
 │   └─ Vie, mort (OnDeath), Revive → déclenche WB_YouDied et le respawn du Character.
 │       TakeDamage(BodyPart, DMGValue) est le point d'entrée UNIQUE de toute cause de mort :
 │       utilisé à la fois par la mort par chute et par la touche de debug K (SandboxCharacter_CMC/EventGraph).
 │
 ├─ Armes (Content/Systems/Weapons/, voir §4.3)
 │   └─ AC_Weapon, ActorComponent ajouté à chaque Blueprint d'arme (BP_Item_Bow, BP_Item_AdvancedRifle) :
 │       s'auto-abonne (EventBeginPlay, cast Owner → BP_Item_HoldableBase) au dispatcher
 │       `BP_Item_HoldableBase::OnHeldStateChanged(bIsHeld)` — PAS à `_BP_ItemBase::OnOwnerChanged`
 │       (2026-09 : bug corrigé — OnOwnerChanged se déclenche pour TOUT changement de propriétaire,
 │       y compris le simple ramassage/rangement dans un slot d'inventaire non tenu en main, ce qui
 │       causait "2 armes équipées en même temps" dès que 2 armes étaient présentes dans l'inventaire.
 │       OnHeldStateChanged ne se déclenche que sur le VRAI changement d'état main/pas-en-main, via
 │       `BPI_HoldableItem::On Item Attached(ShouldHold)` déjà implémenté par BP_Item_HoldableBase).
 │       HandleHeldStateChanged(bIsHeld) → Equip(Owner)/Unequip() selon bIsHeld, qui pilotent `bIsEquipped`.
 │       Expose CanUse()/TryUsePrimary()/StopPrimary() (cooldown générique) que chaque item interroge dans ses
 │       overrides `Custom|PrimaryUse`/`StopPrimaryUsing` existants (voir §7). BFL_WeaponDamage::ApplyPointDamage
 │       route les dégâts d'un projectile vers `AC_Stats::TakeDamage` (mapping nom d'os → E_BodyPart).
 │       **Sélection d'animation (2026-09-06)** : `Equip`/`Unequip` pilotent aussi `SandboxCharacter_CMC::Weapon`
 │       (enum `Weapon_Equip` : None/Bow/OneArmPistol/TwoArmPistol/Riffle/Bat — lu par la Pose Search Database
 │       `CHT_PoseSearchDatabases_Dense` pour sélectionner le pool d'animations armées/désarmées de Motion
 │       Matching) et `isArmed` (bool) — ces deux variables existaient déjà sur le personnage mais n'étaient
 │       JAMAIS renseignées avant ce fix (dette du template de base), donc la locomotion restait toujours
 │       "à mains nues" quelle que soit l'arme tenue. `AC_Weapon` porte une variable `WeaponTypeByte` (byte,
 │       PAS l'enum directement — UserDefinedEnum non utilisable comme type de variable membre via les outils,
 │       voir §9) configurée par arme sur le composant (1=Bow sur `BP_Item_Bow`, 4=Riffle sur
 │       `BP_Item_AdvancedRifle`), convertie via `Utilities|Enum|BytetoEnumWeapon_Equip` avant d'être assignée.
 │       **Bras armé qui reste bloqué en pose par défaut à l'équipement (2026-09-06, CORRIGÉ)** : deux causes
 │       distinctes cumulées, toutes deux dans `SandboxCharacter_CMC_ABP` :
 │       (1) `Get_MMInterruptMode` (utilisée par `Update_MotionMatching` pour choisir le `PoseSearchInterruptMode`
 │       passé à `MotionMatchingAnimNodeLibrary.SetDatabasesToSearch`) ne testait QUE MovementMode/MovementState/
 │       Gait — jamais `Weapon_Equip` (variable ABP, distincte de `SandboxCharacter_CMC::Weapon`, alimentée depuis
 │       celle-ci via PropertyAccess dans `Update_States`, qui a bien SON PROPRE tracker `Weapon_Equip Last Frame`
 │       déjà présent mais jamais branché). Résultat : passer armé/désarmé EN RESTANT IMMOBILE ne changeait ni
 │       MovementMode/State/Gait, donc `Get_MMInterruptMode` retournait toujours `DoNotInterrupt` et Motion
 │       Matching continuait indéfiniment l'ancienne pose (`bIsContinuingPoseSearch=True`) sans jamais essayer
 │       la nouvelle base de données pourtant correctement sélectionnée dans `ValidDatabases`/`DatabasesToSearch`.
 │       Fix : condition supplémentaire `Weapon_Equip != Weapon_Equip Last Frame` ajoutée au `OR` racine de
 │       `Get_MMInterruptMode` (3ᵉ pin ajoutée au nœud `ORBoolean` existant via `add_node_pin`, PAS une réécriture
 │       DSL complète — voir §9 pour le piège du wildcard enum). (2) Une fois l'interruption forcée, la recherche
 │       échouait quand même : `PSD_Dense_Stand_Bow_Idles`/`_Bow_Aim_Idles`/`PSD_Walk_Bow`/`PSD_Crouch_Bow`
 │       (toutes sous `/Game/Animations/humain/Armed_mov/Bow/`) avaient leur `PoseSearchMode` sur `PCAKD_TREE`
 │       et leur build d'index échouait dès le chargement (`LogPoseSearch: Error: ... BuildIndex Failed because
 │       of 'No Convergence' while calculating PCA data`) — passées en `BRUTE_FORCE` (pas besoin de PCA, dataset
 │       de toute façon minuscule), ce qui a débloqué la recherche. (3) **Lignes armées manquantes dans le
 │       chooser (CORRIGÉ 2026-09-06)** : la colonne `Is Armed` de `CHT_PoseSearchDatabases_Dense` (seule des 4
 │       tables LOD à en avoir une) n'avait que DEUX lignes `MatchTrue` — "Stand Idles Bow" (ligne 1) et "Stand
 │       Walks Armed" (ligne 3). Toutes les autres (courses 4-5, sprint 6, InAir 7, accroupi 8-9, prone 10-11,
 │       nage 12-17) exigeaient `MatchFalse`, donc AUCUNE ligne ne correspondait dès qu'on courait/sautait/
 │       s'accroupissait armé → chooser vide → Motion Matching gardait la dernière pose (symptôme : "même
 │       animation en marchant, courant et accroupi"). Fix : ces lignes passées de `MatchFalse` à `MatchAny`
 │       (repli propre sur l'animation non-armée au lieu du gel ; les lignes 0 et 2 DOIVENT rester `MatchFalse`
 │       sinon elles masqueraient les lignes arc 1 et 3, l'évaluation étant descendante premier-match-gagne).
 │       Aucun sous-chooser concerné n'a de colonne d'arme, le repli est donc sans effet de bord.
 │       ⚠️ **RÉGRESSION 2026-09-13 (voir §8.2)** : `CHT_PoseSearchDatabases_Dense` a été ÉCRASÉ par la migration depuis
 │       `Project_F` — les lignes armées Bow (`PSD_Dense_Stand_Bow_Idles`, `_Bow_Aim_Idles`, `PSD_Walk_Bow`) et le passage
 │       `MatchFalse`→`MatchAny` décrits ci-dessus avaient disparu. **RESTAURÉ le 2026-09-14** : la version du commit `d29748b`
 │       a été remise (lignes Bow, Prone, nage, cover accroupi et Push revenues, contexte `Systems/Blueprints/SandboxCharacter_CMC_ABP`)
 │       puis le fix MatchAny a été refait par script : colonne `Is Armed` : lignes 0 et 2 en `MatchFalse`, 1 et 3 en `MatchTrue`, lignes 4 à 17 passées de `MatchFalse` à `MatchAny` (la ligne 18 l'était déjà), vérifié après rechargement.
 │       **Reste un problème de contenu NON corrigé** (voir §9) : `PSD_Dense_Stand_Bow_Idles` — et ELLE SEULE
 │       (`_Bow_Aim_Idles`/`PSD_Walk_Bow`/`PSD_Crouch_Bow` sont sains) — a ses 4 entrées
 │       `DatabaseAnimationAssets[i].SamplingRange` réglées sur `(longueur_du_clip, longueur_du_clip)`, une
 │       fenêtre de largeur nulle placée à la toute FIN du clip. Or Pose Search ne traite un asset comme
 │       bouclable que si sa plage vaut `(0,0)` (= « tout le clip ») : d'où `bLoopAnimation=False` + fenêtre de
 │       lecture nulle = une seule frame figée, alors même que les AnimSequences sources sont bien `Loop=True`.
 │       Correction = remettre chaque `Sampling Range` à `0 / 0` dans l'éditeur Pose Search Database — à faire à
 │       la main : la propriété n'est exposée par AUCUNE API (absente de `ObjectTools.list_properties`, refusée
 │       par `get/set_editor_property` ET `ObjectTools`, et le `SET` console ne cible qu'une classe entière donc
 │       toutes les databases chargées). C'est aussi ce dataset dégénéré (4 poses uniques) qui faisait échouer
 │       le PCA du point (2).
 │       `PSD_Crouch_Bow` existe mais n'est référencée par AUCUN chooser (contenu orphelin) : une fois les
 │       SamplingRange corrigées, on pourra lui dédier une vraie ligne armée accroupie plutôt que le repli.
 │
 ├─ Composants de mouvement            (Content/Systems/Movement/, Systems/Blueprints/MovementModes/)
 │   └─ AC_ClimbingComponent, AC_Cover, AC_TraversalLogic, AC_PreCMCTick, AC_VisualOverrideManager…
 │
 ├─ Composant AIPerceptionStimuliSourceComponent (2026-09-05)
 │   └─ Ajouté sur SandboxCharacter_CMC pour que le joueur soit détectable par la vue de l'IA
 │       (AISense_Sight, auto_register_as_source=true). Sans lui, AUCUN AIPerceptionComponent
 │       ne peut jamais détecter le joueur, quels que soient rayon/FOV/LOS configurés côté IA.
 │
 └─ Autres composants gameplay         (BP_ScentPoint, etc. — voir Systems/Scent/ §4.3 et Systems/Wildlife/ §4.4)

Interactables (Content/Systems/Inventory/Interactables/*)
 └─ Implémentent BPI_Interactable, exposent un inventaire via un composant
    Inventory_Storage / Inventory_Vendor / Inventory_Crafting (mêmes bases AGIS que le joueur)
    → consultés par Inventory_Player lors d'une interaction (touche IA_InteractAGIS)

Données d'items (Content/Data/Inventory_Data/, Content/Items/)
 └─ DT_Items (DataTable), ItemDefaults / ItemInfo (structs), DD_Item (DataAsset par item)
    alimentent à la fois l'UI d'inventaire ET les Blueprints d'objets sous Content/Items/BP_Item_*

Faune sauvage (Content/Systems/Wildlife/, voir §4.4)
 └─ BP_AnimalBase (Character) réutilise TEL QUEL AC_Stats (vie/dégâts/mort, §1.3 ci-dessus) et
    BP_ScentPoint (Systems/Scent/, §4.3) — aucun système de vie ni d'odeur parallèle n'a été créé.
    BFL_WeaponDamage::ApplyPointDamage fonctionne automatiquement sur un animal (résout AC_Stats
    par GetComponentByClass) : aucune adaptation nécessaire côté système d'armes.
```

### 1.4 Conventions de nommage des assets

| Préfixe | Signification | Exemple |
|---|---|---|
| `BP_` | Blueprint d'acteur | `BP_Campfire`, `BP_Item_Helmet` |
| `WB_` / `WBP_` | Widget Blueprint (UMG) | `WB_InventoryScreen`, `WBP_PauseMenu` |
| `AC_` | ActorComponent | `AC_Stats`, `AC_ClimbingComponent` |
| `IA_` | Input Action (Enhanced Input) | `IA_InteractAGIS`, `IA_QuickSelectAGIS` |
| `IMC_` | Input Mapping Context | `IMC_AGIS_Character` |
| `E_` / `EM_` | Enum | `E_MovementMode`, `EM_Road_Type` |
| `S_` / `ST_` | Struct | `S_TraversalCheckInputs`, `ST_Weather_Zone_forecasts` |
| `M_` | Material | `M_Road`, `M_Campfire` |
| `MI_` | Material Instance | `MI_Black`, `MI_Bottle` |
| `SM_` | Static Mesh | `SM_Campfire`, `SM_RifleAdvanced` |
| `SKM_` | Skeletal Mesh | `SKM_BodyArmor` |
| `PA_` | Physics Asset | `PA_BodyArmor` |
| `T_` | Texture | `T_Helmet` |
| `RT_` | Render Target | `RT_InspectRenderer` |
| `DT_` | Data Table | `DT_Items` |
| `DD_` | Data Definition (DataAsset) | `DD_Item` |
| `ML_` | Macro Library (Blueprint) | `ML_InventoryMacros` |
| `SG_` | SaveGame | `SG_AGIS_UID`, `SG_AGIS_World` |
| `GM_` / `PC_` | GameMode / PlayerController | `GM_Sandbox`, `PC_Sandbox` |
| `CR_` | Control Rig | `CR_ClimbingGraphV2` |
| `ABP_` | Animation Blueprint | `ABP_GenericRetarget` |
| `AM_` | Anim Modifier / Anim Montage | `AM_ReloadHip` |
| `NS_` | Niagara System | `NS_Tornado` |
| `BPI_` | Blueprint Interface | `BPI_Interactable` |

Le suffixe `AGIS` sur beaucoup d'assets (`IA_InteractAGIS`, `WB_...AGIS`, fonctions "Target is Inventory Player") signale qu'ils appartiennent au **socle marketplace AGIS**, par opposition aux ajouts spécifiques au projet.

### 1.5 Conventions importantes à respecter

- **Ne jamais renommer/déplacer** les assets du socle AGIS (`Content/Core/Coreinventory/`, une bonne partie de `Content/Systems/Inventory/`, `Content/UI/Inventory_UI/Widgets/WB_Container|WB_EquipSlot|WB_InventorySlot|WB_Item`) sans nécessité — de nombreuses références internes au plugin marketplace en dépendent.
- **Nouveau système de gameplay** → créer un dossier dédié sous `Content/Systems/<NomDuSysteme>/`, à l'image de `Systems/Stats/`, `Systems/Scent/`, `Systems/Movable_Object/`.
- **Nouvel objet d'inventaire (item)** → suivre le patron existant dans `Content/Items/` : un Blueprint `BP_Item_<Nom>` (héritant de `_BP_ItemBase` ou d'une base spécialisée dans `Items/BaseBlueprints/`), ses assets (mesh/matériau/texture) dans un sous-dossier `Content/Items/<Nom>/` ou `Content/Items/Resources/<Nom>/`, et une entrée dans `DT_Items` / les DataAssets sous `Content/Data/Inventory_Data/DataAssets/`.
- **Nouvel Input Action lié à l'inventaire** → `Content/Systems/Inventory/Other/Inputs/Actions/`, mappé dans `IMC_AGIS_Character` ou `IMC_AGIS_InventoryTab`. **Input Action de déplacement/caméra générique** → `Content/Core/PlayerController/Input/`, mappé dans `IMC_Sandbox`.
- **Nouveau widget d'inventaire** → `Content/UI/Inventory_UI/Widgets/`. **Nouveau widget hors inventaire** (HUD, menus) → `Content/UI/Widgets/`.
- Le clavier cible est **AZERTY** ; privilégier des touches identiques physiquement sur QWERTY/AZERTY pour les nouveaux raccourcis (ex. `V`, `B`).
- Réplication réseau : toute action qui modifie l'état du jeu côté inventaire/stats doit suivre le patron `Request X SERVER` (Custom Event `...SERVER`, `Replicated From Client, Executes On Server`) déjà présent dans `Inventory_Player`.

---

## 2. Vue d'ensemble de l'arborescence racine

```text
ProjectF/
├── .gitattributes              → Règles Git (LFS, line-endings)
├── .gitignore                  → Exclut Binaries/, Intermediate/, Saved/, DerivedDataCache/, .vscode/…
├── .mcp.json                   → Déclare le serveur MCP "unreal-mcp" (http://127.0.0.1:8000/mcp) utilisé par les agents IA
├── ProjectFv1.uproject           → Fichier projet UE5.8 : liste des plugins activés (voir §1.2/§8)
├── README.md                   → Description minimale du projet
├── Architecture_Projet.md      → CE DOCUMENT
│
├── .claude/                    → Skills et configuration Claude Code pour ce projet
│   └── skills/
│       └── maintain-architecture-doc/SKILL.md   → Skill de maintenance de ce document (voir §10)
│
├── .codex/, .cursor/, .gemini/, .vscode/   → Configuration d'IDE / d'agents IA tiers (mcp.json, config.toml…)
│
├── Config/                     → Configuration moteur & jeu (voir détail §7)
├── Content/                    → Tous les assets du jeu (voir détail §3 à §6)
│
├── Binaries/, Intermediate/, Saved/, DerivedDataCache/   → Générés par l'éditeur, exclus de Git, jamais à éditer/documenter
```

### 2.1 ⚠️ Fichiers centraux autrefois isolés à la racine de `Content/` (rangés le 2026-09-13)

Quelques fichiers importants vivent directement sous `Content/`, hors de toute organisation par dossier — à connaître avant de chercher "où est le personnage" ou "où est le GameInstance" :

```text
Content/
├── Core/Character/SandboxCharacter_CMC.uasset   → (déplacé depuis la racine le 2026-09-13) ⭐ Le Blueprint du PERSONNAGE JOUEUR lui-même (Character/Pawn). Référencé par GM_Dev, GM_Sandbox, PC_Sandbox, Gamemode_AGIS, WB_InventoryScreen, WBP_PauseMenu, BP_Moveble_Object, BP_Simply_Door, AC_PreCMCTick, AC_ClimbingComponent et son propre Anim BP (Systems/Blueprints/SandboxCharacter_CMC_ABP). C'est le point d'entrée central de tout le gameplay. Son EventGraph contient aussi : la détection de mort par chute (suivi tick de `IsFalling`/`FallStartZ`, calcul de hauteur à `OnLanded`, dégâts scalés via `AC_Stats.TakeDamage` au-delà de 300 unités, létal au-delà de 800) et une touche de debug K (InputDebugKey) qui force la mort via ce même `TakeDamage` — ajoutés le 2026-09-04.
├── Core/BP_GameInstance.uasset   → (déplacé depuis la racine le 2026-09-13 ; `Config/DefaultEngine.ini` → `GameInstanceClass=/Game/Core/BP_GameInstance.BP_GameInstance_C`) GameInstance réellement utilisé par le projet (à ne pas confondre avec `Core/Coreinventory/GameInstance_AGIS`, la base du plugin — vérifier lequel des deux est configuré comme GameInstance par défaut avant de supposer que c'est l'un ou l'autre).
└── Data/DT_DemoTags.uasset   → (déplacé depuis la racine le 2026-09-13 ; l'export texte `DT_DemoTags.T3D` a été supprimé) ⚠️ **À NE PAS SUPPRIMER** : DataTable de gameplay tags du socle AGIS, déclarée dans `Config/DefaultGameplayTags.ini` (`+GameplayTagTableList=/Game/Data/DT_DemoTags`). Elle définit `General Inventory Slot` (indispensable à l'inventaire), `Human.*`, `Attachment.*` (singulier), `Flashlight.Battery`, `Other.*`, `Vehicle.*`. (Corrigé le 2026-09-13 : l'ancienne mention « aucune référence trouvée » était fausse — la référence passe par la config, invisible pour l'Asset Registry.) Dette connue : `DT_Items`, `Inventory_Player` et `AttachmentData_AdvancedRifle` utilisent `Attachments.*` (pluriel, tags inexistants → avertissements « Invalid GameplayTag »), antérieur au commit du 2026-09-04.
```


---

## 3. `Content/Core/` — Socle inventaire (AGIS) + Player Controller + Tick

Le cœur technique de l'inventaire et des entrées génériques du joueur.

```text
Content/Core/
├── Coreinventory/                        → Cœur du plugin AGIS (composants, données, sauvegarde)
│   ├── Inventory__Main.uasset            → ActorComponent BASE : logique générique de containers/slots, réplication réseau. Racine de la hiérarchie d'inventaire.
│   ├── Inventory_Equipper.uasset         → hérite de Inventory__Main : ajoute la logique d'équipement (armes/objets tenus en main)
│   ├── Inventory_Player.uasset           → hérite de Inventory_Equipper : composant d'inventaire du JOUEUR. Contient toute la logique spécifique projet ajoutée cette session (SelectQuickSlot, ToggleQuickEquip, GetQuickSlotItemInfo, graphe INPUTS avec tous les bindings Enhanced Input du joueur). (2026-09-05) `ToggleQuickEquip`/`GetQuickSlotItemInfo` (touches V/B) étaient des stubs de prototype (PrintString uniquement, aucun appel d'équipement réel, plus un bool `bQuickSlotArmed` inversé) — corrigés pour appeler réellement `Inventory_Equipper::SwitchWeaponByUID`/`EmptyHands` (hérités). `GetQuickSlotItemInfo` retourne désormais aussi le `ContainerUID` du slot (WEAPON/WEAPON2/Speed1/Speed2) via `WBContainer::GetContainerUID`, nécessaire pour cibler `SwitchWeaponByUID`. B équipe/déséquipe donc réellement l'item du slot présélectionné par V (le slot doit déjà contenir un item via le drag&drop du paperdoll — la roue V/B ne fait que choisir PARMI les 4 emplacements déjà équipés, elle ne pioche pas dans l'inventaire général). Nouvelle fonction `CycleQuickSlot()` (Weapon→Weapon2→Speed1→Speed2→Weapon→…) ajoutée pour fiabiliser la sélection : `WB_QuickSelect::EventConstruct` (Content/UI/Inventory_UI/Widgets/Other/WB_QuickSelect.uasset) l'appelle désormais automatiquement à chaque pression de V (donc à chaque création de la roue), sans dépendre du clic sur un bouton de la roue (`BtnWeapon1` etc. — dont le fonctionnement en jeu n'a pas pu être confirmé). Les boutons de la roue restent câblés à `SelectQuickSlot` en plus, au cas où le clic fonctionne réellement.
│   ├── Inventory_Storage.uasset          → Inventaire des containers de stockage (coffres, trunk, etc.)
│   ├── Inventory_Vendor.uasset           → Inventaire des PNJ vendeurs
│   ├── Inventory_Crafting.uasset         → Inventaire des stations de craft (campfire, smelter, générateur)
│   ├── BP_AttachmentHandler.uasset       → ActorComponent gérant les attachements sur les armes (silencieux, lampe, chargeur…)
│   ├── CombatComponent.uasset            → ActorComponent : logique de combat (tir, dégâts) liée aux armes AGIS
│   ├── BP_SM_DroppedMesh.uasset          → Acteur représentant un objet lâché au sol (mesh statique + interaction de ramassage)
│   ├── ItemMesh_STATIC.uasset / ItemMesh_Skeletal.uasset  → Acteurs générant le rendu 3D d'un item tenu/lâché (mesh statique ou squelettal)
│   ├── DD_Item.uasset                    → DataAsset décrivant un item (référencé par ItemDefaults)
│   ├── FL_AGIS.uasset                    → Function Library : fonctions statiques utilitaires du plugin AGIS
│   ├── ML_AGISDefaults.uasset            → Macro Library : macros par défaut du plugin
│   ├── ML_AGIS_UMG.uasset                → Macro Library : macros dédiées à l'UI (UMG)
│   ├── ML_InventoryMacros.uasset         → Macro Library : macros génériques d'inventaire
│   ├── GameInstance_AGIS.uasset          → GameInstance de base du plugin (état persistant entre les maps)
│   ├── Gamemode_AGIS.uasset              → GameMode de base du plugin (indépendant de GM_Sandbox, voir §4)
│   ├── PlayerController_AGIS.uasset      → PlayerController de base du plugin
│   └── SG_AGIS_UID.uasset / SG_AGIS_World.uasset  → SaveGame : compteur d'UID uniques / état persistant du monde (sauvegarde)
│
├── PlayerController/                     → Input générique du joueur (mouvement, caméra), indépendant de l'inventaire
│   ├── IA_InitiateClimb / IA_LeapFromClimb / IA_MovingClimb.uasset   → Input Actions liées à l'escalade
│   └── Input/
│       ├── IMC_Sandbox.uasset            → Input Mapping Context PRINCIPAL, ajouté dans `SetupInput` par `SandboxCharacter_CMC` ET (depuis le 2026-09-15) par `SandboxCharacter_Mover` (mouvement, caméra, saut, + actions AGIS : `IA_ToggleInventory` Tab, `IA_InteractAGIS`, `IA_QuickEquip/Select/GiveAGIS`, `IA_UseItemPrimary/SecondaryAGIS`). Mappings `IA_TriggerRagdoll` (R, X manette) et `IA_Takedown` (clic gauche, RT) ajoutés le 2026-09-15 pour le Mover ragdoll
│       └── IA_Move, IA_Look, IA_Jump, IA_Sprint, IA_Run, IA_Walk, IA_Crouch, IA_Prone, IA_Strafe,
│           IA_Aim, IA_Interact, IA_ESC, IA_NextPawn, IA_Traverse, IA_TeleportToTarget,
│           IA_SwimmingDeep, IA_TwinStick_AimDirection, IA_Move_WorldSpace, IA_Look_Gamepad,
│           IA_NextVisualOverride, IA_Takedown, IA_TriggerRagdoll, IA_rool.uasset   → Input Actions individuelles mappées dans IMC_Sandbox. Aussi écoutées par la chaîne Mover (`SandboxCharacter_Mover`/`_Ragdoll`, `Systems/Mover/PC_Sandbox`, `Systems/Mover/SmartObjects/AC_SmartObjectAnimation`) ; le sprint du Mover écoute `IA_Run` (Started/Completed). `IA_rool` et `IA_Traverse` ne sont écoutés par aucun Blueprint
│
└── Tick/                                 → Système de gestion centralisée du Tick (perf)
    ├── BPI_TickManager.uasset            → Interface implémentée par les acteurs qui veulent être "tickés" par le manager
    ├── BP_TickManager.uasset             → Acteur central qui distribue les ticks (probablement à fréquence configurable)
    └── E_TickFrequency.uasset            → Enum des fréquences de tick disponibles
```

---

## 4. `Content/Systems/` — Systèmes de gameplay

### 4.1 `Systems/Inventory/` — Extension du socle AGIS pour ce projet

```text
Content/Systems/Inventory/
├── BP_Spawner.uasset                     → Acteur de spawn (probablement spawn d'items/loot en début de partie)
├── DT_Items.uasset                       → DataTable listant tous les items du jeu (clé pour créer/reconnaître un item)
│
├── Interactables/                        → Tout ce que le joueur peut "interagir" avec (touche IA_InteractAGIS)
│   ├── BP_EnemyPuppet.uasset             → PNJ/mannequin pillable
│   ├── BP_Vendor.uasset                  → PNJ vendeur (utilise Inventory_Vendor)
│   ├── CraftingInteractables/
│   │   ├── Campfire/BP_Campfire.uasset   → Station de cuisson/craft (feu de camp) + ses assets (mesh, matériaux)
│   │   └── Smelter/BP_Smelter.uasset     → Station de fonte de minerai + ses assets
│   ├── FuelGenerator/BP_Generator.uasset → Générateur électrique (consomme du carburant)
│   ├── KeycardReader/BP_KeycardReader.uasset → Lecteur de carte magnétique (déverrouillage)
│   ├── Other/BP_SimpleDoor.uasset        → Porte interactable simple
│   └── Storages/
│       ├── BP_StorageBox.uasset, BP_Trunk.uasset, BP_SphereStorage.uasset, _BP_StorageBase.uasset  → Coffres/contenants de stockage (héritent de _BP_StorageBase)
│       └── Deadbody/BP_Deadman.uasset    → Cadavre pillable
│
├── Interfaces/                           → Interfaces Blueprint (contrats partagés)
│   ├── BPI_Interactable.uasset           → Contrat pour tout objet interactible (implémenté par tous les Interactables ci-dessus)
│   ├── BPI_SlotWidgets.uasset            → Contrat pour les widgets de slot d'inventaire
│   ├── BPI_HoldableItem.uasset           → Contrat pour un item tenable en main
│   ├── BPI_WeaponAGIS.uasset             → Contrat pour les armes
│   ├── BPI_DamageFeedback.uasset         → Contrat de retour visuel/sonore lors de dégâts
│   └── BPI_GameInstance_AGIS.uasset      → Contrat exposé par le GameInstance côté AGIS
│
├── Other/                                → Assets d'appoint de l'inventaire
│   ├── Animations/                       → Animations liées aux armes/mains nues (Jog, Rifle, TurnInPlace, WALK) — clips Motion Matching (MM_*) et montages (AM_*)
│   ├── Fonts/                            → Polices utilisées par l'UI d'inventaire
│   ├── Inputs/
│   │   ├── Actions/                      → **Toutes** les Input Actions liées à l'inventaire (IA_*AGIS), y compris IA_QuickSelectAGIS et IA_QuickEquipAGIS (sélection rapide, ajoutées pour ce projet)
│   │   ├── IMC_AGIS_Character.uasset     → Mapping Context actif en jeu (personnage) : touches 1/2/3/4, F, V, B, etc.
│   │   └── IMC_AGIS_InventoryTab.uasset  → Mapping Context actif quand l'inventaire plein écran est ouvert
│   ├── InspectCapture/                   → Rendu d'inspection d'objet (RT_InspectRenderer + BP_InspectRenderer + M_Inspect)
│   └── Materials/                        → Matériaux génériques réutilisés par les items (MI_Black, MI_Red, M_Metal, M_Outline…)
│
└── Utilities/                            → Outils d'éditeur (Editor Utility Widgets) pour la création de containers/inventaires
    ├── EUW_ContainersCreator.uasset, EUW_WidgetToInventoryData.uasset
    └── Others/WB_ContainerSpecsUtility.uasset, WB_CreatorContainerUtility.uasset
```

### 4.2 `Systems/Blueprints/` — Framework de personnage / locomotion ("Sandbox Character")

Contenu très largement issu du sample Epic **Motion Matching** (plugins `Mover`, `MotionTrajectory`, `Chooser`, `AnimationLocomotionLibrary`). À traiter comme un framework tiers : préférer l'étendre plutôt que le réécrire.

```text
Content/Systems/Blueprints/
├── BPI_SandboxCharacter_Pawn.uasset      → Interface du Pawn joueur (point d'entrée du framework de locomotion). (2026-09-14) + fonctions du sample GASP pour le Mover : `AddTarget`, `RemoveTarget`, `Set_IsPlayingRootMotion`, `Set_PhysicsProfile`, sorties typées de `Get_MMIResult` / `Get_PropertiesForRagdoll`
├── BPI_SandboxCharacter_ABP.uasset       → Interface de l'Anim Blueprint du personnage. (2026-09-14) + `Get_Trajectory`, `Update_MMIConstraints`
├── AC_TraversalLogic.uasset              → ActorComponent : logique de traversal (vault/mantle/climb contextuel)
├── AC_PreCMCTick.uasset                  → ActorComponent : logique exécutée avant le tick du mouvement (Mover/CMC)
├── AC_VisualOverrideManager.uasset       → ActorComponent : gestion des overrides visuels du personnage
├── GM_Sandbox.uasset / PC_Sandbox.uasset → GameMode / PlayerController du framework de locomotion (indépendants de Gamemode_AGIS/PlayerController_AGIS, voir §3)
│
├── Cameras/                              → Système de caméra (Camera Rigs modulaires)
│   ├── CameraAsset_SandboxCharacter, CameraDirector_SandboxCharacter, CHT_CameraRig
│   ├── E_CameraMode.uasset, E_CameraStyle.uasset
│   └── Rigs/CameraRig_* (Close/Medium/Far × Aim/Freecam/Strafe, CrouchOffset, CollisionOffset, TwinStick…)
│
├── MovementModes/                        → Modes de mouvement personnalisés (plugin Mover)
│   ├── BP_MovementMode_Walking / _Falling / _Slide
│   ├── BP_MovementTransition_ToSlide / _FromSlide
│   └── BP_ClimbingMode.uasset
│
├── ControlRigs/CR_Biped_FootPlacement.uasset   → Control Rig : placement des pieds (foot IK)
├── RetargetedCharacters/ABP_GenericRetarget.uasset  → Anim BP générique pour le retargeting
│
├── AnimModifiers/                        → Anim Modifiers (post-traitement de clips d'animation à l'import)
├── AnimNotifies/                         → Anim Notifies personnalisées (BP_AnimNotify_FoleyEvent*, BP_NotifyState_EarlyTransition/MontageBlendOut) + enums associés
│
├── Data/                                 → Structs/Enums/Curves partagés par tout le framework de locomotion
│   ├── E_Gait, E_Stance, E_MovementMode, E_MovementState, E_MovementDirection(Bias), E_RotationMode,
│   │   E_AnalogStickBehavior, E_ExperimentalStateMachineState, E_TraversalActionType
│   │   (2026-09-14, convergence §8.2) valeurs du sample ajoutées EN FIN d'enum : E_MovementMode += Ragdoll, Flying ;
│   │   E_ExperimentalStateMachineState += Debug Flying Loop. S_CharacterPropertiesForAnimation += BasedMovementDelta,
│   │   Weapon_Type (`Data/Enums/E_WaponType`) ; S_BlendStackInputs += Blend Curve. Ne jamais réordonner ces enums (valeurs stockées par nom interne).
│   ├── S_CharacterPropertiesForAnimation / _ForCamera / _ForTraversal, S_BlendStackInputs,
│   │   S_MoverCustomInputs, S_PlayerInputState, S_TraversalCheckInputs/Result,
│   │   S_TraversalChooserInputs/Outputs (contexte des choosers `CHT_TraversalMontages_CMC/_Mover`), S_ChooserOutputs
│   │   (contexte de `CHT_CMCCharacterAnimations`), S_MovementDirectionThresholds,
│   │   S_RotationOffsetCurveChooser_Inputs, S_DebugGraphLineProperties
│   ├── Curve_RotationOffset_* , Curve_StrafeSpeedMap, CHT_RotationOffsetCurve  → Curve Tables pilotant les offsets d'animation
│   └── BFL_HelpfulFunctions.uasset, BPI_InteractionTransform.uasset
│
├── SmartObjects/                         → Intégration du plugin SmartObject (points d'ancrage d'animation contextuelle)
│   ├── CHPA_SmartObject, AC_SmartObjectAnimation
│   └── SmartObjectAnimationPayload, SmartObjectSelectionInputs/Outputs
│
├── SandboxCharacter_CMC_ABP.uasset       → Anim Blueprint principal du personnage joueur (piloté par `/Game/Core/Character/SandboxCharacter_CMC`). Anciennement égaré dans un dossier `d/` mal nommé — déplacé ici (nettoyage du 2026-09-04).
│
├── (SUPPRIMÉS de ce dossier) SandboxCharacter_Mover / _ABP / _Ragdoll → **Depuis le 2026-09-13 ces trois assets n'existent plus dans `Systems/Blueprints/`** : les versions actives (personnage Mover conservé à la demande de l'utilisateur) sont dans `Content/Systems/Mover/` (voir §4.2.1). `SandboxCharacter_CMC` (`Content/Core/Character/`) reste le personnage RÉEL du jeu. Vérifié le 2026-09-14 : `GM_Dev` (GameMode de `MapDev1`), `Systems/Blueprints/GM_Sandbox` et `Core/Coreinventory/Gamemode_AGIS` ont `DefaultPawnClass = /Game/Core/Character/SandboxCharacter_CMC` ; `GM_Sandbox_Ragdoll` et `GM_MoverTest` (contenu de test du sample) restent à `None` ; `Systems/Mover/GM_Sandbox` spawne `SandboxCharacter_Mover`.
│
├── GM_Sandbox_Ragdoll.uasset              → Variante de `GM_Sandbox` avec `SandboxCharacter_Mover_Ragdoll` comme pawn par défaut (contenu du sample, non utilisée par le jeu réel).
│
├── AI/StateTree/                          → **(2026-09-08)** StateTree + tâches pour l'interaction Smart Object du personnage (`ST_Player_SandboxCharacter_SmartObject`, `STT_CharacterIgnoreCollisionsWithOtherActor`, `STT_FindSlotTransforms`, `S_SmartObjectPayload`). Contenu du sample, AI/SmartObject non branché sur le gameplay AGIS.
│
└── (2026-09-08) Contenu supplémentaire fusionné depuis un import du sample officiel Epic **Game Animation Sample** (voir note globale en fin de §8) : `RetargetedCharacters/` (BP_Echo, BP_Manny, BP_Quinn, BP_Twinblast, BP_UE4_Mannequin — **supprimés le 2026-09-13** avec les personnages de démo ; seul `ABP_GenericRetarget` subsiste), des `Cameras/Rigs/` et `MovementModes/` supplémentaires (`CameraRig_Far_Ragdoll`, `CameraRigPrefab_ThirdPerson`, `BP_MovementMode_Ragdoll`, `B_MovementMode_Flying`), des `Data/` supplémentaires (`S_RagdollProperties`, `S_MoverCustomInputs_Ragdoll`, `E_RagdollInjuryState`, `Ragdoll_Fall_to_Ground_BlendCurve`, variantes `S_CHT_*_IN/OUT` pour les choosers de traversal/interaction/get-up), des `AnimNotifies/` supplémentaires (`BP_NotifyState_MMI_IK`, `_MMI_MotionWarping`, `_OverrideCapsuleCollision`, `_OverrideMovementMode`, enums `E_EarlyTransition_*`/`E_FoleyEventSide`/`E_TraversalBlendOutCondition`), et des `SmartObjects/` supplémentaires (`Bench/`, `DistanceToSmartObject`, `PSS_SmartObject`, `TasksAndConditions/STT_ClaimSlot|ClearHandle|PlayAnimFromBestCost|PlayAnimMontage`).
```

### 4.2.1 `Systems/Mover/` et `Systems/Aiming/` — personnage Mover et framework du sample (isolés le 2026-09-14)

Copie du framework "Sandbox Character" du sample Epic **Game Animation Sample**, arrivée avec la migration `Project_F` (§8.2) et conservée pour le personnage alternatif basé sur le plugin **Mover** et pour le système de visée. Déplacée SANS fusion depuis `Content/Blueprints/` et `Content/Input/`. Beaucoup d'assets ont un homonyme dans `Systems/Blueprints/` (`AC_TraversalLogic`, `BPI_*`, `GM_Sandbox`, `PC_Sandbox`, structs `S_*`, caméras…) : ce sont des doublons DIVERGENTS, à ne pas confondre ni fusionner aveuglément (voir §9, piège `consolidate_assets`). Les enums, eux, sont partagés avec `Systems/Blueprints/Data/` (fusionnés le 2026-09-14).

```text
Content/Systems/Mover/
├── SandboxCharacter_Mover.uasset          → Personnage basé sur le plugin Mover. (Vérifié le 2026-09-15) `GM_Dev` (GameMode de `MapDev1`) a `DefaultPawnClass = SandboxCharacter_Mover` ; en PIE sur `MapDev1` le pion obtenu est `SandboxCharacter_Mover_Ragdoll`. `SetupInput` ajoute `Core/PlayerController/Input/IMC_Sandbox` (même IMC que le CMC, inputs AGIS/inventaire compris) ; il porte aussi `Inventory_Player`, dont la propriété `Input Mapping Context` DOIT valoir ce même `IMC_Sandbox` (corrigé le 2026-09-15, elle valait `IMC_AGIS_Character`) : à la fermeture de l'inventaire, `WB_InventoryScreen.SwitchInput` fait `ClearAllMappings` puis ne ré-ajoute QUE cette variable — une mauvaise valeur coupe tous les contrôles (ZQSD, caméra) après fermeture. Même piège pour tout futur pion équipé d'`Inventory_Player`. Implémente `BPI_Interactable` depuis le 2026-09-17 (`GetTracePoint` = position/forward du composant `Camera`, comme `SandboxCharacter_CMC`) : sans cette interface, le trace d'interaction d'`Inventory_Player` (`Client Trace`, `Verify Trace`) part de (0,0,0) avec une direction nulle et aucun objet ne peut être ramassé. Tout futur pion équipé d'`Inventory_Player` doit aussi implémenter `BPI_Interactable::GetTracePoint`
├── SandboxCharacter_Mover_Ragdoll.uasset  → Variante ragdoll du personnage Mover
├── SandboxCharacter_Mover_ABP.uasset      → Anim Blueprint du Mover (utilise `Systems/Aiming/ABP_AimingMaster`)
├── GM_Sandbox.uasset / PC_Sandbox.uasset  → GameMode (pawn = SandboxCharacter_Mover) et PlayerController du Mover ; création du widget de démo retirée le 2026-09-14
├── AC_TraversalLogic.uasset               → Traversal du personnage Mover (vault/mantle/hurdle/climb). (2026-09-15) La détection de rebords du sample (limitée aux blocs de démo `LevelBlock_Traversable`, retirée le 2026-09-14) est remplacée par celle de `Systems/Blueprints/AC_TraversalLogic` (CMC), portée à l'identique : variables `Min Ledge Width`, `Min Front Ledge Depth`, `Max Ledge Sideways Depth`, `Trace Complex`, `Show Trace`, `Persistent Show Trace`, `RespectPlayersFacingDir`, `Banned Tags` (mêmes valeurs par défaut) et fonctions `ComputeLedgeData`, `TraceAlongHitPlane`, `TraceCorners`, `TraceWidth`, `NudgeTraceTowardsObjectOrigin`, `Set Trace Hit Point`, `Tag Compare`. Dans `TryTraversalAction` : capsule trace sur `TraceTypeQuery1` (Visibility, au lieu du canal `Traversable`), `Hit` → tags acteur+composant → `ComputeLedgeData` → rebords avant/arrière écrits dans `TraversalCheckResult` (équivalent inliné de `TryAndCalculateLedges`, non recopiée car elle prend le struct Systems par référence), puis `Tag Compare` (tags bannis) avant le chooser `CHT_TraversalMontages_Mover`. Le déclenchement (`IA_Jump` → `CanDoTraversal` → `TryTraversalAction`) et l'exécution Mover (`PerformTraversalAction_Mover`, mode `Traversing`) sont inchangés. Les deux composants restent des doublons divergents (structs/BPI `Systems/Mover/` vs `Systems/Blueprints/`).
├── AC_PreCMCTick, AC_PostABPTick, AC_VisualOverrideManager  → Composants du sample (versions GASP, divergentes de celles de `Systems/Blueprints/`)
├── BPI_SandboxCharacter_Pawn / _ABP.uasset → Interfaces GASP implémentées par la chaîne Mover
├── AI/StateTree/                          → `ST_Player_SandboxCharacter_SmartObject` + tâches (copie GASP)
├── AnimModifiers/                         → `AM_BakePhaseCurveFromFootstepNotifies`, `AM_FootSteps_Run` (référencés par quelques anims `UEFN_Mannequin`)
├── Cameras/                               → `CameraAsset_SandboxCharacter`, `CameraDirector_SandboxCharacter`, `CHT_CameraRig`, `CameraShake_Basic`, `Rigs/CameraRig_*` (16)
├── ControlRigs/CR_Biped_FootPlacement.uasset
├── Data/                                  → Structs GASP (`S_CharacterPropertiesFor*`, `S_Traversal*`, `S_CHT_*` des choosers Mover/GetUp/Interaction, `S_Ragdoll*`, `S_MoverCustomInputs*`…), `Curve_RotationOffset_*`, `CHT_RotationOffsetCurve`, `BFL_HelpfulFunctions`, `BPI_InteractionTransform`
├── MovementModes/                         → `BP_MovementMode_Walking/Falling/Slide/Ragdoll`, `B_MovementMode_Flying`, `BP_MovementTransition_To/FromSlide`
└── SmartObjects/                          → `AC_SmartObjectAnimation` (version GASP, aussi utilisée par des STT de `Systems/Blueprints/`), `CHPA_SmartObject`, `PSS_SmartObject`, `Bench/`, `TasksAndConditions/STT_*`

Content/Systems/Aiming/                    → Système de visée développé dans Project_F : `ABP_AimingMaster`, `ABP_AimingMaster_UEFN` (aim offset), choosers `CH_AO`, `CH_Base_AO_Animechooser` (enum `Data/Enums/E_WaponType`)

Content/Blueprints/AnimNotifies/           → SEUL reste de `Content/Blueprints/` : 23 notifies du sample (`BP_AnimNotify_FoleyEvent*`, `BP_NotifyState_EarlyTransition`, `_MontageBlendOut`, `_MMI_*`, `BP_AnimNotify_TriggerRagdoll`, `_OverrideMovementMode`…) liés à 1278 animations de `Characters/UEFN_Mannequin`. Laissés en place volontairement : les déplacer réenregistrerait 1,78 Go d'animations. Pour la plupart doublons de `Systems/Blueprints/AnimNotifies/`.
```

### 4.3 Autres systèmes de gameplay (ajouts spécifiques au projet)

```text
Content/Systems/
├── Stats/
│   └── AC_Stats.uasset                   → ActorComponent ACTIF : gère la vie du personnage (Health), la mort (bIsDead, dispatcher OnDeath), Heal, Revive (voir §1.3). Ajouté cette session pour le système de mort/respawn. (2026-09-05) Extension additive pour la faune : nouveau dispatcher `OnDamaged(BodyPart, DMGValue)`, diffusé au point de convergence partagé de `TakeDamage` (après le switch par bodypart, avant le calcul de mort) — permet à un consommateur (ex. BP_AnimalBase) de réagir à CHAQUE coup reçu, pas seulement à la mort, sans dupliquer la logique de dégâts.
│
├── Weapons/ (2026-09-05)                 → Architecture d'armes générique, réutilisable par toute arme (arc, arme à feu, futur mêlée). Voir §1.3 pour le mécanisme d'équipement.
│   ├── AC_Weapon.uasset                  → ActorComponent commun à TOUTE arme (ajouté à BP_Item_Bow et BP_Item_AdvancedRifle). Ne contient AUCUNE logique spécifique à un type d'arme. Variables : bIsEquipped, bIsBusy, CooldownDuration, LastUseTime, OwnerCharacter. Dispatchers : OnEquipped/OnUnequipped/OnPrimaryUse(Stopped)/OnSecondaryUse(Stopped). Fonctions : CanUse(), Equip/Unequip, TryUsePrimary/StopPrimary, TryUseSecondary/StopSecondary. Son EventGraph s'auto-abonne à `OnOwnerChanged` de son propre acteur (pattern `Default|AssignOnOwnerChanged`) pour appeler Equip/Unequip automatiquement — zéro couplage avec Inventory_Player/Equipper.
│   ├── BFL_WeaponDamage.uasset            → Blueprint Function Library. `ApplyPointDamage(Target, Instigator, HitBoneName, Damage)` : résout le composant `AC_Stats` de la cible (`GetComponentByClass` + cast, no-op silencieux si absent) et route vers `AC_Stats::TakeDamage`, en mappant le nom d'os touché (bones du squelette UEFN_Mannequin : head/neck_*→Head, thigh|calf|foot|ball_L/R→LeftLeg/RightLeg, clavicle|upperarm|lowerarm|hand_L/R→LeftArm/RightArm, tout le reste dont spine_*/pelvis/root→Torso par défaut). Réutilisable par toute arme/projectile/piège futur.
│   ├── BP_Projectile_Base.uasset          → Actor projectile générique : StaticMeshComponent racine `ArrowMesh` (mesh + collision, PAS de mesh par défaut — à fournir par les enfants) + `ProjectileMovement`. `OnComponentHit` : ignore les hits sur son propre `Owner` (évite l'auto-hit au tir), appelle `BFL_WeaponDamage::ApplyPointDamage` puis `HandleImpact(Hit)` — fonction overridable (défaut : `DestroyActor`). Variable `BaseDamage` (instance-editable).
│   └── BP_Projectile_Arrow.uasset         → Hérite de BP_Projectile_Base. Override du mesh `ArrowMesh` (mesh Fab `cc0_wooden_arrow`, collision `BlockAllDynamic`) via override de composant hérité (PAS le template du parent — voir piège §9). Override `HandleImpact` : au lieu de se détruire, se fige (désactive la simulation + la collision) et s'attache (KeepWorld) au composant touché pour rester planté visuellement dans le décor/la cible.
│
├── Wildlife/ (2026-09-05)                → Premiers animaux sauvages (cerf mâle + biche). Architecture générique : toute la logique commune vit dans `BP_AnimalBase` + un unique StateTree partagé ; une espèce (Content/Systems/Wildlife/BP_Deer_Stag, BP_Deer_Doe) ne fait qu'assigner mesh/anims/tunables — ajouter un sanglier ou un loup plus tard consiste à créer UN NOUVEAU Character enfant de `BP_AnimalBase`, sans toucher au StateTree ni aux tâches. Réutilise tel quel `AC_Stats` (vie/dégâts/mort) et `BP_ScentPoint` (odeurs) — voir §1.3. Nécessite le plugin **GameplayStateTree** (ajouté à `ProjectFv1.uproject` cette session, `StateTreeAIComponentSchema`/`StateTreeComponentSchema` indisponibles sans lui — seul le plugin `StateTree` de base était actif auparavant) ; premier usage de StateTree dans ce projet (aucune Behavior Tree/Blackboard/AIController n'existait avant).
│   ├── E_AnimalState.uasset               → Enum (UserDefinedEnum, créé via `unreal.EnumStructService`) : Idle/Wander/Graze/Rest/Alert/Flee/Dead. Sert d'étiquette de debug + de sélecteur d'anim d'arrêt (voir `BP_AnimalBase::ApplyIdleForState`) ; le StateTree stocke en interne l'état courant sous forme de `byte` (les outils Blueprint disponibles ne permettent pas d'ajouter une variable membre ou un paramètre de fonction/dispatcher directement typé sur un enum utilisateur — limitation déjà documentée §9 pour AC_Stats, confirmée à nouveau ici).
│   ├── AC_AnimalSenses.uasset              → ActorComponent générique (vue + odorat), ajouté à `BP_AnimalBase`. Vue : ne fait AUCUNE détection elle-même — se contente de variables (`bCanSeePlayer`, `DistanceToPlayer`, `LastKnownPlayerLocation`) mises à jour par `BP_AnimalAIController` via `ReportPlayerSighted`/`ReportPlayerLostSight`. Odorat : self-contained, `CheckScent` tourne sur un timer (`ScentCheckInterval`, 0.5s par défaut) démarré au `BeginPlay`, interroge `GetAllActorsOfClass(BP_ScentPoint)` et retient le plus proche (`bScentDetected`/`ScentSourceLocation` si distance ≤ `ScentDetectionRadius`, 800 par défaut). `DistanceToPlayer` est recalculée à CHAQUE tick de `CheckScent` (pas seulement quand le joueur est vu) — nécessaire pour que le StateTree puisse détecter le retour au calme (`DistanceToPlayer >= SafeDistance`) même après que l'animal ait fui hors de vue (bug rencontré et corrigé en test PIE, voir §9). (2026-09-14) `CheckScent` réécrit : distance calculée par point d'odeur dans la boucle (l'ancienne version comparait une valeur hors boucle), pawn joueur relu à chaque passe via `GetPlayerPawn(0)` (le cache du `BeginPlay` devenait invalide après mort/respawn → fuite infinie), `LastKnownPlayerLocation` rafraîchie tant que le joueur est vu (la perception ne notifie qu'au gain/perte de vue), et `bCanSeePlayer=false` si aucun pawn.
│   ├── BP_AnimalAIController.uasset        → AIController, `AIPerceptionComponent` natif configuré en Python (`AISenseConfig_Sight`, rayon 2500/3000, FOV 90°). `OnTargetPerceptionUpdated` relaie vers `AC_AnimalSenses` du pion possédé (`ReportPlayerSighted`/`ReportPlayerLostSight` selon `Stimulus.WasSuccessfullySensed()`) — ne fonctionne QUE parce que le joueur porte un `AIPerceptionStimuliSourceComponent` (voir §1.3). (2026-09-14) Filtre ajouté : l'événement ne relaie QUE si `Actor == GetPlayerPawn(0)` — sans lui, les autres animaux (pawns) perçus faisaient passer `bCanSeePlayer` à vrai/faux et déclenchaient alertes/fuites entre cerfs. (2026-09-14) Le template `AIPerception` avait perdu son `AISenseConfig_Sight` (`SensesConfig = [None]` → aucune détection) : recréé par Python (`unreal.new_object(AISenseConfig_Sight, outer=<template AIPerception_GEN_VARIABLE>)` via `SubobjectDataSubsystem`), rayon 2500/3000, angle périphérique 90°, MaxAge 5, toutes affiliations. Le pawn joueur actuel (`SandboxCharacter_Mover`, pawn par défaut de `GM_Dev`) n'a pas de `AIPerceptionStimuliSourceComponent` mais est détecté via `AISense_Sight.bAutoRegisterAllPawnsAsSources` (vrai par défaut) ; en revanche il n'émet PAS d'odeurs (`ScentFunct` n'existe que sur `SandboxCharacter_CMC`).
│   ├── BP_AnimalBase.uasset                → Character générique, base de TOUTE la faune. Composants : `Stats` (AC_Stats), `AnimalSenses` (AC_AnimalSenses), `StateTree` (StateTreeComponent, schema `StateTreeComponentSchema`, contexte = l'acteur lui-même — PAS `StateTreeAIComponentSchema`, pour rester détaché de l'AIController et garder le StateTree simple). `AIControllerClass` = `BP_AnimalAIController`, `AutoPossessAI` = Placed in World or Spawned. Tunables instance-editable : WalkSpeed/RunSpeed, WanderRadius, IdleTime/GrazeTime/RestTime(Min/Max), AlertTime, FleeDistance (400-600 : distance de panique immédiate si vu de près), SafeDistance (doit être largement > FleeDistance : distance à atteindre pour se recalmer), HerdID (Name — animaux partageant le même HerdID se relaient une alerte), DebugEnabled, Anim_Idle/Wander/Graze/Rest/Alert/Flee/Dead/Hit + Anim_RestEnter/Anim_RestExit (AnimSequence, un jeu à fournir par espèce ; RestEnter/Exit optionnelles). Mouvement (2026-09-14) : `bOrientRotationToMovement=true`, `bUseControllerRotationYaw=false`, RotationRate 220, accélération sur les chemins (`NavMovementProperties.bUseAccelerationForPaths`) ; mesh tourné de Yaw −90 (les squelettes DeerStag/DeerDoe regardent +Y). Fonctions clés : `MoveTo`/`StopMovementAnimal` (wrappers autour de l'AIController caché, utilisés par les tâches StateTree), `SetCurrentState` (met à jour l'état, `bIsFleeing` (=Flee), `bInDeadState` (=Dead) et consomme `bHerdAlertReceived` à l'entrée d'Alert/Flee — ne joue plus d'anim), animation (2026-09-14) : toujours **Single Node** (`SkeletalMeshComponent::PlayAnimation`, pas d'AnimBlueprint) mais pilotée par la VITESSE à chaque tick via `DebugTick→UpdateAnimation` : course (`Anim_Flee`, play rate = vitesse/RunSpeed) au-delà de (Walk+Run)/2, marche (`Anim_Wander`, play rate = vitesse/WalkSpeed) au-delà de ~30, sinon `UpdateIdleAnimation` (Rest avec transitions RestEnter/RestExit verrouillées par `AnimLockUntil`, sinon `ApplyIdleForState` : Graze/Alert/Idle). `ApplyAnim(Anim, Loop, Rate)` ne relance l'anim QUE si elle change (`CurrentAnim`) — l'ancienne version relançait l'anim à chaque changement d'état. `PlayStateAnimation` n'est plus appelée (conservée, inutilisée), `GetThreatLocation` (position du joueur si vu, sinon source d'odeur, sinon position du pawn joueur, sinon position de l'animal), `BroadcastAlertToHerd`/`ReceiveHerdAlert` (alerte les autres membres du même HerdID sans jamais lire une variable d'une AUTRE instance directement — le HerdID appelant est passé en paramètre de fonction, voir piège §9), `HandleDeath` (2026-09-14 : plus de ragdoll — `DisableMovement`, arrêt du polling de vie, capsule en `NoCollision`, `Anim_Dead` joué une fois et figé sur sa dernière frame ; lié à `AC_Stats::OnDeath` via un Custom Event `OnAnimalDeathEvt` — PAS un binding direct sur une fonction classique, voir piège §9), `CheckHealthChanged` (polling toutes les 0.2s de `AC_Stats::GetHealth` : une baisse de vie hors mort → `HandleDamaged` : `bWasHitRecently=true`, remis à false par le timer `ClearHitFlag` 6s après le dernier coup (auparavant JAMAIS remis à false → fuite relancée à chaque tick), anim `Anim_Hit` verrouillée 0.4s ; préféré à un binding direct sur le dispatcher `AC_Stats::OnDamaged`, qui provoque une erreur interne du compilateur Blueprint dans ce projet, voir piège §9).
│   ├── ST_AnimalBase.uasset                → StateTree partagé par toute la faune (schema `StateTreeComponentSchema`, contexte = `BP_AnimalBase`). États : `Normal` (groupe) {Idle→Wander→Graze→Rest→Idle, cycle via transitions `OnStateCompleted`/`NextState`}, `Alert` (hésite `AlertTime` secondes puis retourne à Idle si la menace n'est pas confirmée — deny-timeout), `Flee` (fuite), `Dead` (terminal). Transitions clés, TOUTES en conditions liées par binding direct au contexte (`bind_transition_condition_property_to_context`, propriétés imbriquées type `AnimalSenses.bCanSeePlayer` — inclure le préfixe `b` des booléens, voir piège §9), aucune n'exige de Blueprint condition custom : `Normal→Alert` (vue OU odorat OU alerte de horde, combinées en OR via `set_transition_condition_operand`), `Normal→Flee` et `Alert→Flee` (priorité High : vu ET distance ≤ FleeDistance — "trop près, panique immédiate"), `Flee→Normal/Idle` (distance ≥ SafeDistance ET plus vu ET `bWasHitRecently` faux — fuite minimale de 6s après un coup, même tiré de loin), transitions globales posées sur `Root` (s'appliquent depuis N'IMPORTE quel état actif) : `→Flee` (priorité High, `bWasHitRecently` ET pas mort ET `bIsFleeing` faux — sans cette dernière condition, la transition ré-entrait dans Flee à chaque tick) et `→Dead` (priorité Critical, `bIsDead` ET `bInDeadState` faux — même raison que `bIsFleeing` : sans elle, Dead était ré-entré à chaque tick).
│   └── Tasks/                             → StateTree Tasks en Blueprint (parent natif `StateTreeTaskBlueprintBase`), chacune réutilisée par PLUSIEURS états via ses propriétés instance-editable liées au contexte (`bind_task_property_to_context`) :
│       ├── STT_SetAnimalState.uasset       → Appelle `BP_AnimalBase::SetCurrentState(NewState)` et ne se termine JAMAIS (2026-09-14 : l'ancien `FinishTask` immédiat, avec `TasksCompletion=Any`, terminait chaque état dans la frame même de son entrée → Idle→Wander→Graze→Rest bouclaient à chaque frame, animaux immobiles et anims relancées en permanence ; `set_task_considered_for_completion(false)` n'a PAS suffi, voir §9). C'est la tâche Wait/Move de l'état qui le termine. Un exemplaire par état-feuille, seul `NewState` diffère.
│       ├── STT_Wait.uasset                 → Attend une durée aléatoire entre `MinTime`/`MaxTime` (liés au contexte : IdleTimeMin/Max, GrazeTimeMin/Max, RestTimeMin/Max, ou AlertTime/AlertTime pour une durée fixe). Nécessite `should_call_tick_only_on_events = true` sur la classe (sinon `ReceiveLatentTick` n'est jamais appelé — propriété peu intuitive, voir piège §9).
│       ├── STT_MoveToRandomPoint.uasset    → Utilisé par `Wander`. Tire un point via `NavigationSystem::GetRandomReachablePointInRadius` autour de `HomeLocation` (capturée une fois au spawn), appelle `BP_AnimalBase::MoveTo`, termine en arrivant (≤120 en XY), si l'animal est bloqué (vitesse < 5 après 1.5s) ou après 25s ; `ExitState` arrête le mouvement (une alerte interrompt proprement la marche).
│       └── STT_MoveAwayFromThreat.uasset   → Utilisé par `Flee`. À l'entrée : diffuse l'alerte à la horde puis `IssueFleeMove` : point à 1500 dans la direction opposée à `GetThreatLocation` (XY), projeté sur le NavMesh (extent 300/300/1000), sinon point atteignable aléatoire dans 1500 autour de l'animal. Ré-émis tant que l'état Flee est actif dès que l'animal arrive (≤200) ou est bloqué (vitesse < 20 après 1s) — c'est la transition du StateTree qui termine la fuite. `ExitState` arrête le mouvement.
│
│   Espèces (enfants de BP_AnimalBase, aucun nouvel asset graphique créé — réutilisent les meshes/anims
│   déjà présents sous Content/Characters/Animal/DeerStagAndDoe/ et Content/Animations/DeerAndDoe/) :
│   ├── BP_Deer_Stag.uasset                 → SK_DeerStag + jeu d'anims ANIM_DeerStag_* (RestEnter/Exit = GoToRest/RestToGoBackUp), HerdID "DeerHerd_A".
│   └── BP_Deer_Doe.uasset                  → SK_DeerDoe + jeu d'anims ANIM_DeerDoe_* (`Anim_Rest`=IdleRest, manquante avant le 2026-09-14), HerdID "DeerHerd_A" (même horde que le cerf → réactivité croisée via BroadcastAlertToHerd/ReceiveHerdAlert).
│
│   Une instance de chaque a été placée dans `Content/Maps/DevMap/MapDev1` avec un `NavMeshBoundsVolume`
│   (`NavMeshBounds_Wildlife`, RuntimeGeneration = Dynamic — le mode par défaut `Static` ne (re)génère
│   JAMAIS le NavMesh automatiquement, voir piège §9). Étend le NavMesh existant du niveau (aucun n'existait
│   avant cette session).
│
├── Door/
│   ├── Garage_Door/BP_Garage_door.uasset → Porte de garage interactable
│   └── Simply_Door/BP_Simply_Door.uasset → Porte simple interactable
│
├── Movement/
│   ├── Climbing/AC_ClimbingComponent.uasset, CR_ClimbingGraphV2.uasset (Control Rig), CR_Mannequin_BasicFootIK.uasset, ClimbingMaterial.uasset
│   └── Cover/AC_Cover.uasset              → ActorComponent : système de couverture (cover system)
│
├── Scent/BP_ScentPoint.uasset            → Point émetteur d'odeur, spawné par `SandboxCharacter_CMC::ScentFunct` (toutes les 2s pendant que le joueur se déplace) et consommé par `AC_AnimalSenses::CheckScent` (Systems/Wildlife/, §4.4). (2026-09-05) Deux bugs corrigés à la réutilisation par la faune : (a) `ScentFunct` ne créait le point QUE via `SpawnActorFromClass`, sans jamais appeler son événement `Custom|Create(life)` — la durée de vie (`TimeToLife`) restait donc à 0 ; ajout d'un appel explicite `Create(life=20.0)` juste après le spawn. (b) Le décompte de durée de vie (`Custom|CustomEvent(DeltaTime)`) existait déjà mais n'était appelé par PERSONNE (`BeginPlay` enregistrait l'acteur auprès de `BP_TickManager` mais rien n'invoquait réellement l'event) — le point ne s'auto-détruisait donc jamais ; ajout d'un `EventTick` natif qui appelle directement ce Custom Event (évite de toucher au brancher `BP_TickManager` partagé, hors-scope). Comparaison de fin de vie durcie de `== 0` à `<= 0` (float exact-equality fragile). Aucune nouvelle logique d'odeur créée — uniquement réparation du mécanisme existant.
├── Movable_Object/BP_Moveble_Object.uasset → Objet physique déplaçable par le joueur
├── Interact_Interface.uasset             → Interface d'interaction générique (racine de Systems/, à distinguer de BPI_Interactable dans Inventory/Interfaces/)
│
└── Weather/
    ├── Tornado/BP_Tornado.uasset, NS_Tornado.uasset   → Tornade dynamique (acteur + système Niagara), spécifique au projet (`NS_Tornado.uasset`, supprimé du disque avant le 2026-09-13 sans commit, restauré depuis git le 2026-09-14 à la demande de l'utilisateur)
    └── UltraDynamicSky/                  → 🧩 **Asset marketplace tiers complet** (~789 fichiers : Blueprints, matériaux, sons, textures de ciel/météo dynamique). Ne pas modifier directement ; utiliser ses points d'extension documentés par le plugin (Weather_Presets, Climate_Presets, Sky_Modifiers). Structure interne : Blueprints/ (Enum, Functions, Occlusion, Sky_Modifiers, Sound, System, Tools, Utilities, Weather_Effects, Widgets), Materials/, Meshes/, Particles/, Sound/, Textures/, Maps/ (map de démo du plugin). Les systèmes Niagara `Particles/` (Snow, Dust, Wind_Debris, Radial_Storm, Puddle_FluidGrid, DLWE_Interaction_System, VolumetricCloud_LightRays, Actor_Exposure_Test, Standalone/Dripping_*) référençaient encore l'ancien chemin `/Game/UltraDynamicSky/Particles/UDW_Niagara_Parameters` / `UDS_VolumetricClouds_Niagara_Properties` : `[CoreRedirects]` ajouté dans `Config/DefaultEngine.ini` + re-sauvegarde des 10 systèmes (2026-09-14).
        ⚠️ **Exception — code météo PROPRE AU PROJET rangé dans ce dossier tiers** (à ne pas confondre avec le plugin) :
        ├── Blueprints/WB_WeatherControl.uasset → Acteur contrôleur météo (1 par map, porte UDS/UDW en ChildActor). Tick via `BP_TickManager` : fait avancer la saison (`DT_Season`, durée en minutes via `SeasonDurationScale`=60), puis si le joueur est dans une zone (`ActiveZone`) pousse la météo de cette zone vers UDW, sinon `GetNearZone` choisit les 2 zones les plus proches (poids inversement proportionnels à la distance) et `setWeatherbetweenZone` mélange leurs états dans UDW.
        └── Blueprints/WB_WeatherZone.uasset   → Zone météo (Box). `WeatherData` (ST_Weather_ZoneData : temp/humidité/vent/sable) = climat de base. `MakeForcast` génère 16 prévisions (`ST_Weather_Zone_forecasts`, pas de 60–240 s via `ForecastStepMin/Max`) avec `makestate` (nuages `SetNuage`, température `MakeTemp` tirée vers la moyenne de saison, neige/pluie/orage/vent/brouillard/poussière) ; `StepForecast(Delta)` interpole l'état courant et régénère en fin de séquence ; `ApplyToUDW` pousse l'état dans UDW ; `GetInflueZone` liste les zones voisines dans `InfluenceRadius` (15000 uu) non masquées (lissage entre zones via `GetZoneState`). Overlap filtré sur le pawn contrôlé par un joueur. Fonction `Trie zone` restée dans le BP mais plus appelée (2026-09-14).
```

---

## 5. `Content/Data/` — Structures de données globales

```text
Content/Data/
├── DataTable/DT_Season.uasset            → DataTable des saisons (météo)
│
├── Enums/
│   ├── E_CoverD.uasset, E_WeaponType.uasset
│   ├── E_WaponType.uasset                → (2026-09-14, venu de `Characters/UEFN_Mannequin/Animations/Props/`) type d'arme lu par les choosers d'aim offset de `Systems/Aiming/` et par `S_CharacterPropertiesForAnimation.Weapon_Type` ; volontairement NON fusionné avec `E_WeaponType`
│   ├── Enums/E_BodyPart.uasset
│   └── Movement_enum/Weapon_Equip.uasset
│   (⚠️ à ne pas confondre avec Data/Inventory_Data/Enumerations/ ci-dessous — deux emplacements d'enums coexistent)
│
├── Structure/Weather/                    → Structs météo (ST_Season, ST_WeatherZoneState, ST_Weather_Zone_CurentWeather/forecasts/_Data, ST_Zone_Influance)
│
└── Inventory_Data/                       → Données du système d'inventaire AGIS
    ├── DataAssets/
    │   ├── AttachmentData/               → AttachmentData (base) + AttachmentData_AdvancedRifle, AttachmentData_Flashlight : configuration des attachements d'armes
    │   ├── ContainerGroupData/           → Un DataAsset par "groupe de containers" (Backpack BIG/SMALL, Box/Chest Storage, Vest_1/2, ExampleStorage…) : définit la mise en page des slots d'un contenant
    │   └── InventoryData/                → Un DataAsset par inventaire prédéfini (PlayerInventory, PlayerInventoryPart1/2, CardReader_Inventory, Generator_Inventory, Vehicle_Inventory). `PlayerInventory` (2026-09-16) = inventaire du JOUEUR : widget `WB_InventoryPlayer`, containers = les 12 de PlayerInventoryPart1 puis les 3 de PlayerInventoryPart2 (même ordre que `WB_InventoryPlayer::GetAllContainerWidgets`) ; le container 12 (poches) est en 4×3 / 12 slots depuis le 2026-09-17 pour correspondre à `PocketContainer` (il était en 2×2 → seule la 1re ligne était utilisable ; `PlayerInventoryPart2`, utilisé par le pillage, a toujours ce défaut). `PlayerInventoryPart1/2` restent utilisés par les PNJ/cadavres fouillables (`BP_Deadman`, `BP_EnemyPuppet` → `WB_LootingHuman`)
    ├── Enumerations/                     → Enums spécifiques AGIS : EAnimOverlayState, EBallDirections, EFourDirections/ETwoDirections, EInteractionType, EItemActions, ENestingRules, EPrintType, EReloadType, EServerVerificationType, ESlotAppearance, EVendorBuyOption
    └── Structures/                       → Structs spécifiques AGIS
        ├── ItemDefaults.uasset           → Struct CENTRALE décrivant un item (Name, etc.) — lue par WB_Item et par la logique de sélection rapide (Inventory_Player)
        ├── ItemInfo, SlotInfo, SlotAddress, SlotAppearance, SubItemInfo, RandomSubItem
        ├── ContainerInfo, ContainerAppearance
        ├── AttachmentInfo, EquipSlot_KeySettings/_OwnContainersSettings/_TextureSettings/_TitleSettings
        ├── ClientWidgetData, CombinedTexturesInfo, TextureInfo
        ├── CraftingSlotRowInfo, DragSounds, DebugPrint, FindResult, InspectCameraInfo, InteractCosmetics, ItemActorInfo, MenuActions
        └── SaveStructures/SaveData_Player, SaveData_Storages, Savedata_ItemActor   → Structures de sauvegarde (non encore branchées à un vrai système de save, voir §1.3 du système de mort)
```

---

## 6. `Content/UI/` — Interfaces utilisateur

```text
Content/UI/
├── Inventory_UI/                         → TOUTE l'UI de l'inventaire (socle AGIS + ajouts projet)
│   ├── MaterialResources/                → Matériaux/Material Instances de fond des slots (MI_Background_*, M_RuntimeItemMaterial…)
│   └── Widgets/
│       ├── WB_Container.uasset           → Widget représentant un container (grille de slots) — contient SlotWidgets[]. `CreateSlots` construit la grille d'après la `Container Size` DU WIDGET (les SlotInfo du DataAsset doivent avoir la même taille, sinon seules les premières cases sont utilisables). `GetParentEquipSlot` (corrigé le 2026-09-17) ne renvoie l'EquipSlot englobant (Outer.Outer) que si ce container EST son `Container` principal : les sous-containers d'un sac/gilet affichés ailleurs (sous les poches) gardent leur taille et leurs cases de 75 px au lieu d'être réduits à 1×1 en taille d'EquipSlot
│       ├── WB_EquipSlot.uasset           → Widget d'un slot d'équipement (arme/speed) — contient Container. Var `OwnContainersHost` (2026-09-04, typée `WB_InventoryPlayer` depuis 2026-09-16) : si définie, `OnContainerUpdate` ajoute les sous-containers de l'item équipé (ex. grille du sac à dos) dans ce widget via `AddContainerBelowPockets` au lieu de son propre `ContainersCanvas` interne. Câblée uniquement pour `EquipSlotBACKPACK` par `WB_InventoryScreen::InitializeWidgets`.
│       ├── WB_InventorySlot.uasset       → Widget d'un slot individuel dans une grille — expose "ItemWidget On Slot"
│       ├── WB_Item.uasset                → Widget représentant un item posé dans un slot — expose "Item Defaults" (struct ItemDefaults)
│       │
│       ├── InventoryMenu/
│       │   ├── WB_InventoryScreen.uasset → Widget racine de l'inventaire plein écran. Depuis 2026-09-16 contient un seul panneau joueur `Part2Box → OutlinePart2 → BackgroundPart2 → InventoryPlayer` (WB_InventoryPlayer : équipements à gauche, poches + sac à dos défilants à droite ; plus de ScrollBox extérieur depuis 2026-09-17, sinon la colonne de droite n'a pas de hauteur bornée) ; `InitializeWidgets` initialise `InventoryPlayer` et câble `EquipSlotBACKPACK.OwnContainersHost = InventoryPlayer`. `Inventory_Player::GetQuickSlotItemInfo` lit les slots WEAPON/WEAPON2/Speed1/Speed2 via `InventoryScreen.InventoryPlayer`
│       │   ├── WB_InventoryPlayer.uasset → (2026-09-16) Fusion de WB_InventoryPart1 + WB_InventoryPart2 pour l'inventaire du joueur, dans un seul cadre en deux colonnes (2026-09-17) : `EquipsVertical` → `ColumnsBox` (HorizontalBox, Fill) → [`EquipSlotsBox` (SizeBox 760×866) → `SlotsCanvas` avec les 12 EquipSlots] + [`PocketsScroll` (ScrollBox, barre visible) → `VerticalBox_0` (titre Pockets + `PocketContainer`, puis les containers du sac à dos ajoutés dessous par `Add Container Below Pockets`)]. `EquipSlotBACKPACK` et `EquipSlotVEST` ont `Item Containers Settings.ShowInventory = True` et `OwnContainersHost = InventoryPlayer` (câblé dans `WB_InventoryScreen::InitializeWidgets`) (défaut de WB_EquipSlot = False : sans ça, `OnContainerUpdate` ne crée jamais les grilles du sac). `GetAllEquipSlots` = même ordre que Part1 ; `GetAllContainerWidgets` = containers des équipements puis PocketContainer. Données : DataAsset `PlayerInventory`
│       │   ├── WB_InventoryPart1.uasset  → (utilisé seulement par WB_LootingHuman depuis 2026-09-16) Contient les 4 slots d'équipement (EquipSlotWEAPON, EquipSlotWEAPON2, EquipSlotSpeed1, EquipSlotSpeed2) + autres slots d'équipement (casque, gilet, gants, sac à dos…)
│       │   └── WB_InventoryPart2.uasset  → (utilisé seulement par WB_LootingHuman depuis 2026-09-16 ; sa fonction `Add Container Below Pockets` n'est plus appelée, WB_EquipSlot pointe désormais WB_InventoryPlayer) Grille(s) d'inventaire principale(s) (PocketContainer + titre, dans `VerticalBox_0`). Fonction `Add Container Below Pockets(Container)` (2026-09-04) : insère un WB_Container juste après le bloc Pockets (`PocketContainer.GetParent().GetParent()`) — utilisée par `WB_EquipSlot` (sac à dos) pour afficher ses slots supplémentaires sous les slots Pocket plutôt que dans son propre canvas.
│       │
│       ├── ItemActionsMenu/WB_ItemMenu.uasset, WB_GeneralButton.uasset   → Menu contextuel d'actions sur un item
│       │
│       ├── LootWidgets/                  → Fenêtres de pillage, une par type de source (Human, Storage, Vendor, Vehicle, Generator, KeycardReader) héritant de _WB_LootWidgetBASE ; LootingCrafting/ pour les stations de craft
│       │
│       ├── MovableWindows/               → Système de fenêtres déplaçables (_WB_Window_Base) : ItemInspect/ (inspection 3D d'un item), ItemInventory/ (fenêtre d'inventaire flottante), WB_TitleBar_Window (barre de titre commune)
│       │
│       └── Other/
│           ├── WB_QuickSelect.uasset     → 🆕 Roue de sélection rapide (4 slots : Arme1/Arme2/Speed1/Speed2 + "Aucun"). Résout seule son Inventory_Player propriétaire au Construct (GetOwningPlayerPawn → GetComponentByClass). Ouverte/fermée depuis Inventory_Player (touche V maintenue). Le graphe `INPUTS` d'Inventory_Player bascule aussi Input Mode/curseur/Ignore Look Input à l'ouverture/fermeture (même pattern que `ToggleInventory`) — fix du 2026-09-04. **Cause réelle du bug (2026-09-04, deuxième fix)** : IA_QuickSelectAGIS/IA_QuickEquipAGIS (touches V/B) n'étaient mappées QUE dans `IMC_AGIS_Character` (Systems/Inventory/Other/Inputs/), un Input Mapping Context jamais ajouté au joueur nulle part dans le projet (seule une variable `Input Mapping Context` orpheline sur Inventory_Player y faisait référence, sans AddMappingContext associé) — donc l'input V n'atteignait même pas l'Enhanced Input, avant tout problème de widget. Fix : V et B ajoutés directement dans `IMC_Sandbox` (Core/PlayerController/Input/), l'unique IMC réellement ajouté au joueur (via SandboxCharacter_CMC/SetupInput). `IMC_AGIS_Character` reste inutilisée — à nettoyer/fusionner un jour si confirmé obsolète.
│           ├── WB_QuickGive.uasset       → 🆕 (2026-09-05) Menu debug "Quick Give" (touche F9, mappée dans `IMC_Sandbox` via `IA_QuickGiveAGIS`). Champ Item ID + Amount + bouton "Give" générique, plus des boutons raccourcis "Give Bow"/"Give 20 Arrows". Fonction `GiveItem(ItemID, Amount)` : résout l'`Inventory_Player` du joueur possédant (`GetOwningPlayerPawn`+`GetComponentByClass`), construit un item via `FL_AGIS::Create Item Structure`, trouve un slot libre via `Inventory__Main::Find Space For Item`, puis le pose via `Inventory__Main::Set Item On Container` — même chaîne AGIS bas niveau que celle utilisée en interne par `Reload Graph` de `BP_Item_AdvancedRifle`. Toggle (créer/`AddToViewport`+InputMode GameAndUI vs `RemoveFromParent`+InputMode GameOnly) câblé dans `SandboxCharacter_CMC::EventGraph` sur `IA_QuickGiveAGIS` (Started), variable `QuickGiveWidget` sur le Character. Outil de test, pas une fonctionnalité shippable.
│           ├── WB_YouDied.uasset         → Écran "Vous êtes mort" (système de mort/respawn)
│           ├── WB_ActionScreen, WB_InteractScreen, WB_InteractBall, WB_PickupDisplay   → Feedback d'interaction/pickup au sol
│           ├── WB_CombatHUD, WB_DisplayHUD, WB_WeaponAmmoInfo   → HUD de combat/munitions
│           ├── WB_InventoryBackground, WB_ItemInfo, WB_SlotTitle   → Éléments visuels d'appoint
│           └── WidgetTextures/           → Icônes des slots d'équipement (T_EquipSlot_*) et textures d'UI diverses
│
├── TextureUI/M_CharacterUI.uasset, RT_CharacterView.uasset   → Rendu de la vue personnage dans l'UI (ex. écran d'inspection du personnage)
│
└── Widgets/                              → UI HORS inventaire
    ├── HUD/WB_HUD.uasset, WB_New_HUD.uasset, WB_New_InterfacePlayer.uasset
    ├── PauseMenu/WBP_PauseMenu.uasset, WBP_Options.uasset
    └── interaction/WB_Interact.uasset
```

---

## 7. `Content/Items/`, `Content/PCG/`, `Content/Maps/`, `Content/VFX/`, `Content/Prop/`

```text
Content/Items/                            → Objets ramassables/équipables du jeu
├── BaseBlueprints/
│   ├── _BP_ItemBase.uasset               → Blueprint BASE de tout item (racine de hiérarchie). Event `Custom|UpdateCollisionandPhysics` (appelé à l'attache/au drop) bascule aussi la réponse au canal `Visibility` (Ignore quand équipé / Block quand lâché) du mesh principal ET de tous les `WidgetComponent` de l'item (ex. `AmmoUI`) — fix du 2026-09-04 : un item équipé bloquait les BoxTrace (canal Visibility) du système de grimpe/parkour (`AC_ClimbingComponent`), empêchant de grimper une fois une arme en main.
│   ├── BP_Item_HoldableBase.uasset       → Base des items tenables en main. Implémente `BPI_HoldableItem::On Item Attached(ShouldHold)` (seul signal fiable du VRAI état main/pas-en-main) et diffuse ce booléen via son propre dispatcher `OnHeldStateChanged(bIsHeld)` (2026-09) — c'est CE dispatcher (et non `_BP_ItemBase::OnOwnerChanged`, qui se déclenche aussi pour un simple rangement en inventaire) qu'`AC_Weapon` écoute pour piloter Equip/Unequip, voir §4.3.
│   ├── BP_Item_Armor_Base.uasset         → Base des items d'armure/équipement porté
│   └── BP_Item_Skeletal_Base.uasset      → Base des items avec mesh squelettal
│
├── BP_Item_AdvancedRifle / _Backpack_Camper / _Backpack_Sport / _BodyArmor / _Flashlight /
│   _Gloves / _Helmet / _KevlarVest / _LightVest / _Siren / _Bow.uasset     → Blueprints d'items "portés" (racine d'Items/). `BP_Item_Bow` (hérite `BP_Item_HoldableBase`) porte un composant `ItemMesh_STATIC` (mesh Fab `survival_kit_bow_fixed` — voir §8 pour l'incident de corruption/ré-import du 2026-09-05 —, socket `ArrowSocket` ajouté pour l'encoche — position approximative, à ajuster visuellement), équipé sur le socket `weapon_l` (Spine `SpineRifle`, réutilisé faute de socket dédié). `BP_Item_AdvancedRifle` a reçu le même composant `AC_Weapon` (2026-09-05, retrofit de validation) pour l'équipement/déséquipement générique ; sa cadence de tir reste pilotée par sa propre macro interne `Weapon|FiringGate` (non branchée sur `AC_Weapon.CanUse()` — dette technique documentée, voir §9).
│
│   **Gameplay de l'arc** (`BP_Item_Bow`, 2026-09-05/06) — override des hooks existants `Custom|PrimaryUse`/`StopPrimaryUsing` de `_BP_ItemBase`, sans nouveau système d'input : `PrimaryUse` vérifie `AC_Weapon->CanUse()` ET `CountArrows() >= 1` (fonction propre, voir §1.3 pour `Owner Inventory`) avant de démarrer la tension (horodatage `DrawStartTime`, pas de Timeline), puis joue `Draw Montage` (`AM_Bow_Draw`, voir ci-dessous) sur le mesh du personnage. `StopPrimaryUsing` calcule la puissance (`Clamp((Now-DrawStartTime)/MaxDrawTime, MinDrawPower, 1.0)`), joue `Fire Montage` (`AM_Bow_Fire`), appelle `ConsumeArrow()` et, si réussi, spawn `BP_Projectile_Arrow` au socket `ArrowSocket` avec vitesse/dégâts scalés par la puissance, puis appelle `AC_Weapon->TryUsePrimary()`.
│   **`ConsumeArrow()` — fix du 2026-09-06** : retrouve le stack "Arrow" via `BOTH|FindItem`, puis réduit son montant via `Inventory__Main::AddItemAmount(ItemAddress, -1)` — une opération purement sur les DONNÉES de l'inventaire, par adresse, ne nécessitant aucun acteur monde. L'implémentation d'origine appelait `Utilities|GetItemActor` (macro `ML_InventoryMacros::Get Item Actor`) puis `SERVER|ReduceAmount` sur cet acteur — ce qui échoue TOUJOURS silencieusement pour un item empilé passif comme "Arrow" qui, tant qu'il n'est pas équipé/lâché dans le monde, n'a jamais d'acteur spawné (`GetItemActor` retourne systématiquement invalide). Symptôme observé : le tir semblait démarrer (logs "TIR EN COURS") mais aucune flèche ne partait et aucune munition n'était consommée. Voir aussi §9 pour la même leçon appliquée à toute consommation de stock passif (ne jamais utiliser `GetItemActor`+fonction-sur-acteur pour un item qui n'est pas garanti d'être spawné dans le monde — utiliser `Inventory__Main::AddItemAmount` par adresse à la place).
│   **Animations de l'arc** (2026-09-06) — `AM_Bow_Draw`/`AM_Bow_Fire.uasset` (`Content/Items/`) sont des `AnimMontage` à piste unique générés depuis `standingdrawarrow_UE`/`standingaimrecoil_UE` (`Content/Animations/humain/Armed_mov/Bow/`), assignés au **slot `UpperBody`** (voir `SandboxCharacter_CMC_ABP` ci-dessous — PAS `DefaultSlot`). Variables `Draw Montage`/`Fire Montage` sur `BP_Item_Bow`, jouées via un nœud natif `Animation|Montage|PlayMontage` sur le mesh du personnage (`Cast Owner Character → Character → GetMesh`). Appel direct (pas de variante Multicast `...CLIENTS` comme pour `PlayReloadMontageCLIENTS` du fusil) — suffisant en PIE solo ; à revoir si une réplication multijoueur de l'anim est nécessaire plus tard.
│   **Intégration à la locomotion (2026-09-06)** — un montage plein-corps sur `DefaultSlot` remplaçait TOUT le squelette (jambes comprises) par la pose figée de l'animation source, ce qui semblait correct à l'arrêt (la pose "debout" du montage coïncide avec Motion Matching à l'arrêt) mais cassait la marche/course/crouch (jambes figées dans la pose d'arc "debout" enregistrée). Fix : ajout d'un **`Slot 'UpperBody'`** + nœud **`Layered Blend Per Bone`** dans l'`AnimGraph` de `SandboxCharacter_CMC_ABP`, avec un filtre de branche sur l'os `spine_01` (BlendDepth=-1 → toute la branche colonne+bras+tête, jambes/bassin exclus) — voir §9 pour le détail technique (le skeleton `SK_UEFN_Mannequin` avait déjà un Blend Profile "UpperBody" masquant exactement les mêmes os, confirmant que `spine_01` est le bon point de coupure, mais ce Blend Profile n'est pas directement utilisable par ce nœud en 5.8 — filtre de branche manuel utilisé à la place). Le `DefaultSlot` existant (plein corps) n'est pas touché, réutilisable tel quel pour de futures actions plein-corps. Motion Matching, Pose Search, Aim Offset (`Enable_AO`/`Get_AOValue`), Foot/Leg IK et Orientation Warping — tous déjà présents dans cet AnimBP — continuent de piloter le bas du corps et la visée sans changement.
├── Attachments/BP_Item_MagazineBase, BP_Item_RifleFlashlight, BP_Item_Suppressor.uasset  → Attachements d'armes
├── ItemObjects/BPI_MergeableItemObject, ItemObject__BASE, ItemObject_ConsumableBASE, ItemObject_Magazine.uasset  → Objets "monde" associés aux items (empilables, consommables, munitions)
│
├── Ammo/ (Arrow), Weapon/ (Base_Bow, Base_knife), Tool/ (saucepan), Water/ (water_bottle),
│   Food/ (Red_Apple, meat, cooked_Meat, Burnt_Meat), Resource/ (Stick, Stone)
│   → Chaque sous-dossier contient les assets (mesh/matériau/texture/Thumbnail) d'un item ; les Blueprints correspondants sont soit à la racine d'Items/, soit dans Resources/. `Weapon/Base_Bow/Thumbnail` et `Ammo/Arrow/Thumbnail` ne contenaient que des icônes préparées à l'avance (2026-09-04) — item "Bow" et "Arrow" ajoutés dans DT_Items pour les utiliser (voir §5).
│
├── Resources/                            → Assets 3D (mesh/matériau/texture) groupés par équipement porté, + cas particuliers
│   ├── Backpack_Camper/, Backpack_Sport/, BodyArmor/, Gloves/, Helmet/, KevlarVest/, LightVest/, Rifle/
│   ├── _Others/                          → Assets des petits objets (Keycard, Log, Meat, AmmoBox, Battery, Flashlight, FuelCanister, GoldIngot/GoldOre, Headphone, MoneyBag, WaterBottle)
│   └── ABP_SkeletalEquippables.uasset    → Anim Blueprint partagé par les items squelettaux équipés
│
└── ItemTextures/                         → Textures d'icônes/inventaire communes à tous les items (T_*)

Content/PCG/                              → Génération procédurale de contenu (plugin PCG)
├── Road/
│   ├── PCG_Road.uasset                   → Graphe PCG générant la route procédurale (matériaux vieillis/mousse/humidité, potholes via GeometryScript)
│   ├── BP_AbandonedRoad.uasset           → Acteur portant le graphe PCG
│   ├── M_Road.uasset, ST_Road_data.uasset, EM_Road_Type.uasset   → Matériau, struct de données et enum de types de route
├── Vegetation/TreeTest.uasset            → Graphe PCG de placement de végétation (arbres, générés via PVE pour la route)
└── test/NewPCGGraph1.uasset              → Graphe de test/brouillon

Content/Maps/DevMap/
├── MapDev1.umap                          → 🗺️ Map de développement PRINCIPALE (GameDefaultMap / EditorStartupMap, voir Config/DefaultEngine.ini)
├── GM_Dev.uasset                         → GameMode utilisé sur MapDev1 (hérite directement de GameModeBase, indépendant de GM_Sandbox/Gamemode_AGIS)
├── pcg_Test_Dev.umap                     → Map de test PCG
└── PCG_Test_Dev_HLODLayer_*, Untitled_HLOD0_Instancing.uasset   → Assets HLOD générés pour les maps de test

Content/VFX/
├── Firetrail/BP_FireTrail.uasset, Effects/P_BulletTrail.uasset, Materials/M_BulletTrail.uasset   → Traînée de balle
└── MI_MuzzleFlash, M_MuzzleFlash, MuzzleFlash, P_MuzzleFlash   → Effet de tir (bouche de canon)
├── M_Blood.uasset, T_Blood.uasset        → Effet de sang
└── crosshair.uasset, hitmarker.uasset    → Éléments de HUD de tir

Content/Prop/Wooden_Door/                 → Prop de porte en bois (mesh + matériaux), utilisé par les BP de porte interactable
```

---

## 8. Assets tiers / bibliothèques (peu ou pas de logique de gameplay)

Ces dossiers contiennent des assets achetés/importés (Marketplace, Fab/Quixel Megascans, Megaplant, packs d'animation mocap). Ils sont volumineux (des centaines de fichiers) et **ne sont volontairement pas détaillés fichier par fichier** ici — voir §10 pour la règle sur quand les documenter.

```text
Content/Animations/          → Clips de mocap tiers : DeerAndDoe/, Fox/, Wolf/, humain/ (Armed_mov, Avoid, Carrying, Cover,
                                Effect_Animation, INteraction, Prone, Push, SwimmingAnimation…)
Content/Characters/          → Meshes/matériaux/textures des personnages et animaux (Animal/DeerStagAndDoe|Fox|Wolf,
                                UEFN_Mannequin/ avec ses données de Motion Matching : AimOffset, Crouch, Idle, Jump,
                                MotionMatchingData/ [Channels, Databases, Normalization_Sets, Schemas], Poses, Run, Slide,
                                Sprint, Traversal, Walk, Rigs, Materials, Meshes, Textures)
Content/Fab/                 → Assets Fab/Quixel Megascans : MaterialFunctions/, MaterialParameterCollection/, Materials/
                                (Standard/VT), Megascans/Plants/ (Common_Hemp_Nettle, Wild_Grass ×2), Megascans/Surfaces/
                                (Damaged_Asphalt, Dirt_Ground, Forest_Floor), Textures/ (Standard/VT)
                                Survival_Kit_-_Bow/ et CC0_-_Wooden_Arrow/ (StaticMesh + Textures + MI_SurvivalBow/MI_WoodenArrow,
                                utilisés par les items Bow/Arrow, voir §4.4) — ⚠️ ces deux imports glTF avaient leurs slots de
                                matériau pointant vers un `MaterialInstanceDynamic` transitoire (jamais sauvegardable, cause
                                d'échecs d'auto-save « Illegal reference to private object »). Corrigé le 2026-09-04 en créant de
                                vraies `MaterialInstanceConstant` (parent `/InterchangeAssets/gltf/Substrate/M_GLTF`) avec les
                                mêmes textures. Si un futur import Fab/glTF échoue à l'auto-save de la même façon, vérifier le(s)
                                slot(s) de matériau du StaticMesh importé pour ce même symptôme.
                                ⚠️ **2026-09-05** : après une coupure de courant, `survival_kit_bow.uasset` (StaticMesh) s'est retrouvé
                                avec 0 vertex/0 triangle/bounds nuls (asset vidé, probablement une sauvegarde tronquée en cours
                                d'écriture) — l'arc n'avait plus de mesh visible ni de collision en jeu. Diagnostic : toujours
                                vérifier `mesh.get_num_vertices(0)` / `get_bounds()` après une fermeture anormale de l'éditeur sur
                                un asset suspect avant de chercher ailleurs. Fix : ré-import depuis la source Fab d'origine
                                (chemin retrouvé via `mesh.get_editor_property("asset_import_data").extract_filenames()`, cache
                                `%LOCALAPPDATA%/Temp/FabLibrary/<guid>/`) vers un dossier scratch, puis renommage vers
                                `.../StaticMeshes/survival_kit_bow_fixed` (le nom d'origine `survival_kit_bow` n'a pas pu être
                                réutilisé : `delete_asset`/`consolidate_assets` échouaient silencieusement sur l'asset corrompu
                                malgré 0 référenceur restant — laissé orphelin en l'état, sans danger). Toutes les références
                                (`BP_Item_Bow::ItemMesh_STATIC`, `DT_Items` ligne "Bow" → `Spawner Preview Mesh`) repointées vers
                                `survival_kit_bow_fixed`. Le socket `ArrowSocket` a dû être recréé (perdu avec l'ancien asset).
Content/Megaplant_Library/   → Végétation Megaplant : Plant_Bilberry/, Tree_European_Aspen/, Tree_Hornbeam/
                                (chacun avec Instances/, Materials/, Textures/)
Content/Audio/Foley/         → **(2026-09-08)** Système de sons de pas/foley du sample Game Animation Sample :
                                `AC_FoleyEvents` (ActorComponent, ajouté à `SandboxCharacter_Mover`, voir §8.2),
                                `S_FoleyEventParams`, `DefaultFoleyEventAudioBank`. Reste du dossier `Content/Audio/` :
                                sons/bancs audio divers du sample, non branchés sur le gameplay AGIS.
Content/MetaHumans/ et Content/Characters/Echo|Paragon|UE4_Mannequin|UE5_Mannequins/  → **SUPPRIMÉS le 2026-09-13**
                                (nettoyage) : assets MetaHuman et personnages de démonstration du sample Game Animation
                                Sample (~2,6 Go), utilisés uniquement par les BP de démo `RetargetedCharacters/BP_*`
                                (supprimés aussi). Copie de sauvegarde : `E:\projet\ProjectFv1_backup_migration_2026-09-13\nettoyage_etape1_demo\`.
                                `UEFN_Mannequin` reste le seul squelette de personnage humanoïde du projet.
Content/Levels/, Content/Widgets/, Content/dev_map  → **SUPPRIMÉS le 2026-09-14** : démo du sample Game Animation Sample (kit de blockout
                                LevelPrototyping, widgets et map de démo). Seul lien avec le projet : le cast vers
                                `LevelBlock_Traversable` dans `Systems/Mover/AC_TraversalLogic`, retiré (voir §4.2.1).
                                Sauvegarde : commit git `6eb7516`.
Content/Thumbnails/          → Miniatures générées pour la Content Browser
Content/Misc/                → SandboxAnimCurveCompressionSettings.uasset (réglages de compression d'anim)
Content/__ExternalActors__/  → ⚙️ Généré automatiquement par World Partition (données par-acteur des maps, ex. LocomotionAnimPack).
Content/__ExternalObjects__/ → ⚙️ Généré automatiquement par World Partition (objets externes liés aux maps).
                                → Ces deux derniers dossiers ne doivent JAMAIS être édités ou documentés à la main :
                                  leur contenu suit automatiquement les maps et les acteurs qu'elles contiennent.
```

### 8.1 Import du sample Epic "Game Animation Sample" (2026-09-07/08)

L'utilisateur a importé le contenu brut du sample officiel Epic **Game Animation Sample** directement dans `Content/Blueprints/` (structure de dossier d'origine du sample), dans le but de disposer d'une référence complète/fonctionnelle du framework "Sandbox Character" (voir §4.2) pendant que sa migration vers le plugin `Mover` était en cours. Ce sample est la source originelle du framework `Systems/Blueprints/` déjà présent dans ce projet : l'import a donc créé **95 collisions de nom exactes** (mêmes noms : `SandboxCharacter_CMC`, `AC_TraversalLogic`, `BP_MovementMode_Walking`, `E_Gait`, `IMC_Sandbox`, tous les `IA_*` génériques, etc.) entre le contenu fraîchement importé et les versions déjà personnalisées de ce projet.

**Politique appliquée (décision utilisateur explicite)** : garder la version du projet partout, ne conserver du nouvel import que le contenu réellement nouveau (RetargetedCharacters, SmartObjects/AI supplémentaires, Ragdoll, Audio/Foley, MetaHumans, Characters de démo — voir §4.2/§8). Les 95+17 doublons (17 supplémentaires découverts après coup sous `Content/Input/` et `Content/Data/`, dont `IMC_Sandbox` lui-même) ont été fusionnés via `EditorAssetLibrary.consolidate_assets()` (redirecteur automatique + suppression du doublon) quand c'était possible, ou supprimés directement (`delete_asset`) quand rien ne référençait plus la copie importée. Le contenu unique restant a ensuite été déplacé vers son emplacement définitif (`Content/Systems/Blueprints/`, `Content/Core/PlayerController/Input/`) via `AssetToolsHelpers.get_asset_tools().rename_assets()` (déplacement avec réécriture de toutes les références, pas un déplacement de fichier brut).

**Reste à faire / connu (2026-09-08)** :
- `Content/Systems/Mover/SmartObjects/AC_SmartObjectAnimation` (anciennement `Content/Blueprints/SmartObjects/`, déplacé le 2026-09-14) : un doublon n'a **pas** pu être fusionné/supprimé (l'outil `consolidate_assets` fait planter l'éditeur sur cet ActorComponent précis, voir §9) — laissé en l'état intentionnellement, sans impact gameplay (fonctionnalité SmartObject annexe).
- ⚠️ *Obsolète depuis le 2026-09-13 (voir §8.2)* — `Content/Blueprints/` contenait alors de nombreux fichiers `ObjectRedirector` (résidus de `consolidate_assets`) — passer un **"Fixup Redirectors" manuel** (clic droit sur le dossier dans le Content Browser) quand pratique ; aucune API Python trouvée pour cette opération, et forcer une suppression brute des redirecteurs risquerait de casser des références logicielles (soft references) non encore réécrites.

### 8.2 Migration `Project_F` → `ProjectFv1` (2026-09-13) — incident et état après réparation

`E:\projet\Project_F` est un **autre dépôt git** (projet Game Animation Sample nettoyé, où l'utilisateur a développé un système de visée). Le 2026-09-13 (~22:00–22:12), l'éditeur de `Project_F` a migré **3073 packages** directement dans `ProjectFv1/Content` **pendant que l'éditeur de ProjectFv1 était ouvert** (preuve : `Project_F/Saved/Logs/Project_F.log`, lignes `LogSavePackage: Moving ... to E:/projet/ProjectFv1/Content/...`). ⚠️ Ne jamais migrer vers ce projet avec son éditeur ouvert.

Dégâts constatés : 1449 assets suivis par git de `Characters/UEFN_Mannequin/` écrasés (animations + chooser tables, liées désormais aux notifies/enums de `Content/Blueprints/`), 782 fichiers `Systems/Weather/UltraDynamicSky/` écrasés (widgets météo sans leurs structs `ST_Weather*` → 149 erreurs), `Content/Blueprints/` recréé comme copie complète (137 vrais assets) du framework de `Systems/Blueprints/`. Les enums/structs des deux copies DIVERGENT (ex. `E_MovementDirection` : `F/B/LL/LR/RL/RR` vs `Forward/Back/left/…`, `E_Gait` sans Prone/Swimming) : ne JAMAIS les fusionner aveuglément.

Réparation (décisions utilisateur) :
- **Météo** : les 782 fichiers UltraDynamicSky restaurés depuis le commit `d29748b` (LFS). Versions migrées sauvegardées dans `E:\projet\ProjectFv1_backup_migration_2026-09-13\`.
- **Anims/choosers migrés conservés**. Contexte (`ContextData`) des 7 chooser tables CMC/traversal remis aux valeurs du commit : `CHT_PoseSearchDatabases(+_Dense/_Sparse/_ExtremeSparse)` et `CHT_CMCCharacterAnimations` → `Systems/Blueprints/SandboxCharacter_CMC_ABP` (+ `S_ChooserOutputs` Systems) ; `CHT_TraversalMontages_CMC/_Mover` → `Systems/Blueprints/Data/S_TraversalChooserInputs/Outputs`. Lignes Bow du chooser Dense perdues (voir §1.3).
- **Structs strictement identiques fusionnées** (`consolidate_assets`, redirecteurs laissés) : `Content/Blueprints/Data/S_CHT_TraversalMontages_IN/OUT` → `Systems/.../S_TraversalChooserInputs/Outputs`, `Content/Blueprints/Data/S_ChooserOutputs` → `Systems/.../S_ChooserOutputs`. Pins de `Content/Blueprints/AC_TraversalLogic` (traversal du Mover) rebranchées.
- **Doublon GASP du personnage CMC supprimé** : `Content/Blueprints/SandboxCharacter_CMC` + `_ABP`. Références de démo redirigées vers `/Game/SandboxCharacter_CMC` (depuis déplacé dans `/Game/Core/Character/`) / l'ABP Systems (`PC_Sandbox.Characters`, `AC_PreCMCTick`, `GM_Sandbox.PawnClasses_Soft`, `EUW_PawnOverrideButton.Object`, variable locale de `BP_NotifyState_EarlyTransition`). (`Content/Widgets/` a été supprimé le 2026-09-14.)
- `STT_PlayAnimFromBestCost` (Systems) pointe désormais vers `Systems/Blueprints/SmartObjects/AC_SmartObjectAnimation`.
- `Config/DefaultGameplayTags.ini` : ajout des tags du sample `Foley.Event.*` et `SmartObject.ObjectType.Player/Bench` (manquants → avertissements massifs + StateTree SmartObject non liable).

Contenu du framework du sample conservé volontairement (déplacé le 2026-09-14, voir §4.2.1 et « Convergence partielle » ci-dessous) :
- `Systems/Aiming/` (`ABP_AimingMaster`, `ABP_AimingMaster_UEFN`, `CH_AO`, `CH_Base_AO_Animechooser`) → système de visée/aim offset développé dans `Project_F`, utilisé par `SandboxCharacter_Mover_ABP`.
- `Systems/Mover/SandboxCharacter_Mover` / `_ABP` / `_Ragdoll` → personnage alternatif plugin Mover (+ `Systems/Mover/GM_Sandbox`/`PC_Sandbox` ; `dev_map` de démo supprimé le 2026-09-14).
- le reste du framework dupliqué, dans `Systems/Mover/` (AC_TraversalLogic, BPI_*, Data/, Cameras/…) ; ses notifies restent dans `Content/Blueprints/AnimNotifies/` (liés à 1278 animations). Chooser tables toujours liées à ce framework : `CHT_PoseSearchDatabases_Relaxed`, `CHT_MoverCharacterAnimations_PoseMatch`, `CHT_GetUpMontages`, `CHT_CharacterInteractionPSDs`.

**Convergence partielle (2026-09-14)** :
- **Enums fusionnés** : les 17 enums du sample de `Content/Blueprints/Data|Cameras|AnimNotifies/` (`E_Gait`, `E_Stance`, `E_MovementMode`, `E_MovementState`, `E_MovementDirection`, `E_MovementDirectionBias`, `E_RotationMode`, `E_AnalogStickBehavior`, `E_ExperimentalStateMachineState`, `E_RagdollInjuryState`, `E_TraversalActionType`, `E_CameraMode`, `E_CameraStyle`, `E_EarlyTransition_Condition`, `E_EarlyTransition_Destination`, `E_FoleyEventSide`, `E_TraversalBlendOutCondition`) ont été fusionnés dans leurs jumeaux de `Systems/Blueprints/` (17 redirecteurs laissés à l'ancien emplacement). Valeurs propres au sample ajoutées en fin d'enum côté projet (voir §4.2) et pins/switchs de la chaîne Mover remappés dessus. Interfaces et structs Systems enrichies en conséquence (§4.2).
- **Réparations consécutives** (piège décrit en §9) : variables d'enum vidées retypées et liens rebranchés dans `SandboxCharacter_Mover`, `SandboxCharacter_Mover_Ragdoll`, `SandboxCharacter_Mover_ABP` (restauré depuis sauvegarde puis remappé), `BP_AnimNotify_TriggerRagdoll`, `AnimNotifies/BP_NotifyState_EarlyTransition` et `BP_NotifyState_MontageBlendOut` (liens comparés un à un à leurs jumeaux Systems). Chaque asset validé par rechargement de son package.
- **Arrêt de la convergence (décision utilisateur)** : à cause de ce piège, le reste de `Content/Blueprints/` (Mover, Aiming, AC/BPI/structs/notifies/caméras du sample) n'est PAS fusionné. Il a été seulement déplacé, sans fusion, le 2026-09-14 (voir §4.2.1) ; les doublons restants sont une dette connue.

**Restauration Motion Matching (2026-09-14, décision utilisateur)** : un audit des 189 données Motion Matching modifiées depuis `d29748b` (comparaison des références `/Game/...` des blobs git avant/après) a trouvé 7 assets dégradés par la migration, tous restaurés depuis `d29748b` (toutes leurs références existent encore) : `CHT_PoseSearchDatabases_Dense` (19 bases perdues : Bow, Prone, nage, cover accroupi, Push ; colonnes `E_CoverD`/`Weapon_Equip`), `Channels/PSC_Traversal_Head` et `_Pos` (pointaient sur la BPI du sample au lieu de `Systems/Blueprints/BPI_SandboxCharacter_ABP`), `Schemas/PSS_Default` et `PSS_Idle` (table miroir `Rigs/MDT_UEFN_Mannequin` perdue), `Normalization_Sets/PSN_Relaxed_All` (le Mover y perd `PSD_SM_Mover_TraversalTransitions`), `Databases/Dense/PSD_Dense_Stand_Idles` (mesh d'aperçu). Seul autre écart trouvé, conservé : `Traversal/CHT_TraversalMontages_Mover` (montages Climb Relaxed → Neutral, chooser du Mover).

État vérifié en fin de réparation : passe de compilation complète, **435 Blueprints, 0 erreur** (non encore testé en PIE). Dettes connues non liées à la migration : tags `Attachments.*` (§2.1), animations AGIS sans squelette (voir §9 : `Systems/Inventory/Other/Animations/DeathAnim_AGIS` et `Rifle/*` — compatibles à 100 % avec `SK_UEFN_Mannequin`, à assigner à la main dans l'éditeur ; `Jog/`, `WALK/`, `TurnInPlace/`, `AIM_Rifle_Idle_ADS` inutilisées et incompatibles), « Unknown structure » au chargement de `Systems/Blueprints/BPI_SandboxCharacter_Pawn` (antérieur au 2026-09-07).

---

## 9. Notes pour les IA : pièges connus de l'outillage

Ce projet est modifié via le plugin **VibeUE** (service MCP `unreal-mcp`, voir `.mcp.json`), qui expose des services Python (`unreal.BlueprintService`, `unreal.WidgetService`, `unreal.InputService`, `unreal.EnumStructService`, etc.) pour piloter l'éditeur Unreal sans l'ouvrir manuellement. Quelques pièges rencontrés et leurs solutions :

- **`build_graph`** attend un champ **`"ref"`** pour identifier chaque nœud dans la liste `nodes` (pas `"id"`). Un mauvais nom de champ échoue silencieusement (retourne `None` sans erreur explicite).
- Les **variables locales à une fonction** (paramètres, locals créés via `add_object_variable` avec `graph=...`) ne sont pas fiables avec `build_graph`'s `variable_get`/`variable_set` : préférer des **variables membres** du Blueprint.
- Un `K2Node_VariableSet`/`Get` créé via un spawner_key générique (`discover_nodes` + `create_node_by_key`) peut se résoudre sur la **mauvaise classe** si plusieurs Blueprints chargés ont une variable de même nom affiché (ex. "Owner Inventory" existe à la fois sur `WB_Container` et sur un widget créé cette session) — toujours vérifier les pins du nœud créé (`get_node_pins`) avant de câbler, ou utiliser `build_graph` avec `type: "variable_set"` + `params.variable` en contexte "self" qui est fiable.
- Appeler une fonction Blueprint **préexistante** (créée dans une session antérieure/par le plugin marketplace) sur un **autre** Blueprint peut échouer silencieusement selon la méthode utilisée. Privilégier l'accès direct aux propriétés (`member_get`, fiable) plutôt que l'appel de fonction cross-Blueprint quand c'est possible ; sinon tester `add_function_call_on_variable` et vérifier le résultat via `get_node_pins`/`get_nodes_in_graph`.
- Écrire une valeur littérale sur un pin de type `Text`, `Object` ou `Class` via `set_node_pin_value` échoue souvent **silencieusement à l'affichage** (`get_node_pins` renvoie toujours `default_value: ""`) même quand l'assignation a réellement fonctionné — vérifier via une **compilation** (erreurs de compilation manquantes = probablement OK) plutôt que via une relecture du pin.
- **Toujours compiler ET sauvegarder** un Blueprint après modification (`BlueprintEditorLibrary.compile_blueprint` + `EditorAssetLibrary.save_loaded_asset`), puis **tester en PIE** et lire les logs (`EditorToolset.LogsToolset.GetLogEntries`, filtrer sur `"Blueprint Runtime Error"`) pour détecter les erreurs à l'exécution qu'une compilation réussie ne révèle pas (ex. accès à un élément de tableau hors limites).
- Le clavier cible du jeu est **AZERTY** : vérifier les mappings de touches existants (`IMC_Sandbox`, `IMC_AGIS_Character`, `IMC_AGIS_InventoryTab`) avant d'assigner une nouvelle touche, et choisir des touches physiquement identiques entre QWERTY/AZERTY.

**Pièges du toolset `editor_toolset.toolsets.blueprint.BlueprintTools`** (create_node/connect_pins/write_graph_dsl/get_node_infos, utilisé depuis le système d'armes du 2026-09-05) :

- La **DSL `write_graph_dsl`** casse sur un `type_id` contenant une parenthèse fermante suivie d'autres caractères (ex. `BOTH|GetItem(copy)ByUID` échoue avec "does not exist" car le tokenizer coupe au premier `)`) ; un `type_id` se terminant PAR une parenthèse fonctionne (`Utilities|Array|Get(acopy)`). Dans ce cas, construire le nœud à la main (`create_node`/`connect_pins`) plutôt que via la DSL.
- Un `type_id` retourné par `find_node_types` (ex. `Variables|Default|GetACWeapon`) peut différer du `type_id` affiché ensuite par `get_node_infos` pour CE nœud (ex. `|GetAC_Weapon`, avec underscore) : toujours utiliser la chaîne de `find_node_types` pour **créer**/référencer un nœud dans la DSL, jamais celle affichée après coup par `get_node_infos`.
- Éditer une propriété d'un **composant SCS hérité** (ex. changer le mesh d'un `StaticMeshComponent` défini dans une classe parente, depuis le Blueprint enfant) : `SubobjectDataBlueprintFunctionLibrary.get_object`/`get_associated_object` renvoient le **template du PARENT** (le modifier casse le parent pour toutes ses classes filles !). Utiliser `get_object_for_blueprint(data, child_blueprint)` qui crée correctement l'override propre à l'enfant.
- Itérer un `Array[SubobjectDataHandle]` avec `for h in handles:` casse `get_data`/`get_variable_name` (erreur de nativisation) ; indexer explicitement (`for i in range(len(handles)): h = handles[i]`) fonctionne.
- Un Blueprint Function Library (BFL) se crée avec `unreal.BlueprintFunctionLibraryFactory()` (pas le `BlueprintFactory` générique + `parent_class`, qui échoue avec "Cannot create a blueprint based on the class").
- Depuis `execute_python_code`, appeler une fonction Blueprint sur une instance PIE via `actor.call_method(...)` nécessite le nom **d'affichage exact avec ses espaces** (ex. `"Set Item Actor Owner"`, `"Primary Use"`), pas une version condensée/snake_case — sauf pour certains getters de variable auto-générés dont le nom interne réel ne correspond ni à l'un ni à l'autre (à vérifier au cas par cas).
- Créer un `InputAction` en Python : `unreal.InputAction_Factory()` (PAS `unreal.InputActionFactory`, qui n'existe pas) + `AssetToolsHelpers.get_asset_tools().create_asset(...)`. Pour mapper une touche dans un `InputMappingContext` existant, préférer `unreal.InputService.add_key_mapping(imc_path, ia_path, "F9")` (service VibeUE dédié) plutôt que d'éditer la propriété dépréciée `mappings` de l'IMC directement en Python.
- Construire un widget UMG en Python : `unreal.WidgetService.add_component`/`set_property`/`bind_event` fonctionnent bien pour la hiérarchie et les propriétés, mais il n'existe **aucun** `unreal.WidgetBlueprintLibrary.create_widget` exposé pour instancier un widget à la volée. Pour un test rapide en PIE, utiliser `unreal.WidgetService.spawn_widget_in_pie(chemin)` (retourne un handle qu'on repasse à `remove_widget_from_pie`) — mais ce handle n'expose pas d'appel de fonction arbitraire sur l'instance ; il ne sert qu'à l'afficher/la retirer et lire ses propriétés (`get_live_property`).
- `EditorToolset.EditorAppToolset.CaptureAssetImage`/`CaptureViewport` sont le seul moyen fiable de **voir** un résultat (mesh, matériau, scène) : le retour JSON est trop volumineux pour être lu tel quel (limite de tokens) — toujours passer par un script Python (`base64.b64decode` du champ `returnValue.data`, écrit dans le scratchpad) puis `Read` sur le PNG obtenu.
- Un asset `.uasset` peut se retrouver **corrompu à vide** (0 vertex/triangle, bounds nuls) après une fermeture anormale de l'éditeur (coupure de courant, crash) sans que sa taille de fichier ni son chargement ne signalent d'erreur — toujours vérifier `get_num_vertices(0)`/`get_bounds()` (StaticMesh) après un redémarrage suspect avant de chercher un autre bug. `delete_asset`/`consolidate_assets` peuvent échouer silencieusement (retour `False`, sans exception) sur un tel asset corrompu même sans référenceur restant — dans ce cas, renommer le nouvel asset importé sous un autre nom plutôt que de s'acharner à réutiliser le chemin d'origine.
- Toute variable membre **booléenne** (`bXxx`) affiche son nom SANS le préfixe `b` dans les nœuds Get/Set générés par la DSL (`GetCanSeePlayer`, pas `GetbCanSeePlayer`) — mais son **nom de propriété brut**, tel qu'attendu par `get_editor_property`/`set_editor_property` en Python ET par `StateTreeService.bind_*_property_to_context` (chemins de contexte), **conserve le préfixe `b`** (`"bCanSeePlayer"`, `"AnimalSenses.bScentDetected"`). Utiliser le nom sans `b` dans l'un de ces deux contextes échoue silencieusement en DSL (nœud introuvable) ou avec "Malformed target property path" côté StateTree.
- `delete_node` sur un nœud dont une pin est encore référencée par un AUTRE nœud (ex. un nœud `Self`/`GetXxx` pur, réutilisé par plusieurs consommateurs) peut laisser une **connexion fantôme** côté survivant : `get_node_infos` continue de lister une pin connectée vers le node supprimé (qui n'apparaît plus dans `find_nodes`), et la compilation échoue avec l'erreur générique `Internal compiler error inside CreateExecutionSchedule` sans désigner le nœud fautif. Diagnostic : dumper `get_node_infos` de TOUS les nœuds du graphe et chercher une pin connectée vers un node absent de `find_nodes` ; le node fantôme existe encore assez longtemps en mémoire (non garbage-collecté) pour que `break_pins` fonctionne dessus malgré tout — l'appeler explicitement sur cette connexion règle l'erreur.
- Une **UserDefinedEnum** (créée via `unreal.EnumStructService.create_enum`) ne peut PAS servir de type à une variable membre, un paramètre de fonction ou un paramètre de dispatcher via les outils disponibles (`add_variable`/`add_function_param` n'acceptent que bool/int/float/byte/name/string/text/Vector/Rotator/Transform/Vector2D/LinearColor) — limitation déjà notée pour `AC_Stats::OnDamaged`, reconfirmée pour `E_AnimalState`. Contournement : stocker en `byte` et convertir à l'affichage seulement si besoin (`Utilities|String|ToString(Byte)`).
- Une **StateTree Task Blueprint** (`StateTreeTaskBlueprintBase`) ne tique QUE si sa CDO a `should_call_tick_only_on_events = true` — malgré son nom qui suggère l'inverse ("seulement sur événements"), c'est en réalité l'interrupteur général qui active `ReceiveLatentTick`. Aucune property `bShouldCallTick` distincte n'est exposée.
- Chaîner plus de deux concaténations `(+ a b)` de **String** dans une même expression DSL imbriquée casse avec `Could not connect pin ReturnValue to A` (constaté sur `BP_AnimalBase::DebugTick`) — même en séparant chaque étape par un `bind` intermédiaire. Contournement : limiter chaque nœud `+` à DEUX opérandes littéraux/variables simples, et multiplier les appels `DrawDebugString`/lignes plutôt que de construire une seule chaîne longue.
- Une donnée cross-instance (lire la variable d'un AUTRE acteur de même classe, ex. le `HerdID` d'un autre `BP_AnimalBase` pendant `BroadcastAlertToHerd`) n'est PAS accessible via le getter `Variables|Default|GetXxx` généré par la DSL (celui-ci n'a pas de pin `self`/cible, contrairement aux nœuds `Class|MaClasse|MaFonction` qui, eux, exposent bien un `self` substituable). Solution : passer la donnée nécessaire en PARAMÈTRE de la fonction appelée sur l'autre instance plutôt que de tenter de la lire directement (voir `ReceiveHerdAlert(ThreatLocation, CallerHerdID)`).
- Une nouvelle **StateTree** (`unreal.StateTreeService.create_state_tree`) démarre SANS aucun état racine : `add_state(path, "Root", ...)` échoue silencieusement (retourne `False`) tant qu'un premier `add_state(path, "", "Root", "State")` (parent_path **vide**) n'a pas créé l'état racine lui-même.
- Lier une `AC_Stats::OnDamaged` (dispatcher avec paramètres) directement à une fonction Blueprint CLASSIQUE (pas un Custom Event) via `K2Node_CreateDelegate.set_create_delegate_function` **compile sans erreur immédiate** mais casse la compilation à la volée suivante avec `Internal compiler error inside CreateExecutionSchedule` — et peut même faire apparaître des nœuds `AddEvent` parasites (EventTick, EventActorBeginOverlap…) ailleurs dans le graphe. Un dispatcher avec paramètres doit être lié à un **Custom Event** (`add_event` avec un nom arbitraire crée un vrai `K2Node_CustomEvent`, contrairement à `write_graph_dsl`'s `(event Nom ...)` qui n'accepte que les noms d'événements natifs "AddEvent|Nom" connus). Un dispatcher SANS paramètre (ex. `AC_Stats::OnDeath`) ne pose aucun problème lié à une fonction classique.
- (2026-09-14) `BlueprintTools.write_graph_dsl` **échoue en silence** : en cas d'erreur (nœud inexistant, pin incompatible) il ne lève rien, retourne `None` et laisse le graphe inchangé ou VIDE ; le vrai message n'apparaît que dans `Saved/Logs/ProjectFv1.log` (`LogScript: Warning: AssertionError: The node could not be created / … does not exist` ou `RuntimeError: Could not connect pin …`). Toujours vérifier chaque écriture par `read_graph_dsl` (chercher un nœud attendu) avant de sauvegarder. Pièges constatés : (a) `Math|Byte|Equal(Byte)` et `Math|Vector|vector+vector` sont RELUS par `read_graph_dsl` mais REFUSÉS à l'écriture — utiliser les opérateurs `==`/`+` ; (b) les appels de fonction du Blueprint lui-même (`CallFunction|MaFonction`) ont une pin `self` en première position : passer les arguments par mot-clé (`:Anim x :Loop true`), sinon le premier argument est branché sur `self` ; (c) les getters de variables à underscore perdent l'underscore dans le type_id (`Anim_Idle` → `Variables|Default|GetAnimIdle`), et `find_node_types` renvoie aussi `CallFunction|ApplyIdleforState` avec la casse de l'affichage ; (d) `read_graph_dsl` affiche parfois un nœud sous une catégorie trompeuse (`CustomizableObjectInstance|SetCurrentState` pour un appel à `BP_AnimalBase::SetCurrentState`) — vérifier avec `get_node_infos` avant de conclure à un mauvais binding ; (e) `BlueprintTools.create_node` attend un `unreal.IntPoint` pour `pos`, pas un `Vector2D`.
- (2026-09-14) StateTree : une tâche Blueprint qui appelle `FinishTask` dans `EnterState` termine l'état dans la même frame (`TasksCompletion=Any`), et `StateTreeService.set_task_considered_for_completion(..., False)` renvoie `True` mais n'a PAS empêché ce comportement en PIE (UE 5.8). Pour une tâche « fire and forget » (ex. `STT_SetAnimalState`), ne PAS appeler `FinishTask`. Diagnostic : `log LogStateTree Verbose` en PIE puis compter les `Enter state` dans le log.
- (2026-09-14) StateTree : une transition posée sur `Root` (trigger `OnTick`) reste évaluée quand sa CIBLE est déjà active et la ré-entre à chaque tick (Exit/Enter de toutes ses tâches). Toute transition globale doit donc porter une condition « pas déjà dans cet état » (ex. `bIsFleeing == false` pour `Root→Flee`).
- Un **NavMeshBoundsVolume** ajouté par script (`SceneTools.add_to_scene_from_class`) ne génère PAS automatiquement de NavMesh : le `RecastNavMesh-Default` correspondant naît avec `RuntimeGeneration = Static` (aucune régénération, ni en éditeur ni au runtime, sans un "Build Paths" manuel — introuvable dans l'API Python exposée). Fix : `recastNavMesh.set_editor_property("runtime_generation", unreal.RuntimeGenerationType.DYNAMIC)` PUIS `unreal.NavigationSystem.on_navigation_bounds_updated(nav_sys, volume)` pour forcer une première génération immédiate (sans ce second appel, le volume reste sans tuiles jusqu'au premier changement de géométrie pertinent).
- **FAUX AMI corrigé (2026-09-05)** : `read_graph_dsl` insère parfois un `_` de lisibilité dans le nom affiché d'une variable membre commençant par un préfixe court en majuscule (ex. la variable réelle `LContainer` s'affiche `(|GetL_Container)`, PAS `(|GetLContainer)` — idem `LItemName`→`L_ItemName`). Utiliser cette forme AVEC underscore pour créer/écrire un nœud (`create_node`, `write_graph_dsl`) échoue avec "... does not exist", ce qui peut faire croire à tort à une variable locale non-créable (variables locales et membres se comportent en réalité de façon identique côté création). Avant toute chirurgie sur un Get/Set qui échoue ainsi, vérifier le nom SANS underscore via `find_node_types` (ex. filtrer `"LContainer"`) plutôt que de supposer une limitation de l'outil — le nom réel de la propriété (`get_editor_property` en Python inclus) ne contient jamais cet underscore ajouté par l'affichage.
- Un Blueprint qui est la classe d'un **composant actif dans une session PIE en cours** peut compiler sans erreur mais **échouer silencieusement à la sauvegarde** (`save_loaded_asset` renvoie `False` sans exception) tant que le PIE n'est pas arrêté — toujours `StopPIE` avant de sauvegarder un asset qu'une session PIE utilise, et re-tenter la sauvegarde après l'arrêt.
- **CORROLAIRE DANGEREUX** : après tout échec de `save_loaded_asset` dû au PIE, **StopPIE PUIS ressauvegarder IMMÉDIATEMENT**, et **toujours revérifier via `read_graph_dsl`/`find_nodes` après un redémarrage/arrêt du PIE** qu'une édition récente est bien encore présente avant de continuer à construire dessus — une édition compilée avec succès pendant que le PIE tournait peut sembler perdue à la prochaine lecture si la sauvegarde qui a suivi a échoué silencieusement.
- **PIÈGE MAJEUR — graphe d'implémentation d'interface Blueprint fragile et auto-régénéré (2026-09-06)** : le graphe qui implémente une fonction de Blueprint Interface (ex. `BP_Item_HoldableBase:On Item Attached`, implémentant `BPI_HoldableItem::On Item Attached`) peut **revenir tout seul à son état d'origine** après une compilation ultérieure — de N'IMPORTE QUEL Blueprint de la hiérarchie, pas seulement celui qu'on édite — même quand `read_graph_dsl` avait confirmé l'édition juste après une sauvegarde réussie (`save_loaded_asset` → `True`, mtime du `.uasset` à jour). Un `reload_packages` forcé depuis Python confirme que c'est bien le contenu SUR DISQUE qui a régressé, pas juste l'état en mémoire — la persistance de ce type de graphe est donc bien plus fragile qu'une fonction normale. Reproduit 3 fois de suite sur le même graphe dans cette session malgré des re-sauvegardes systématiques. **Ne JAMAIS héberger de logique métier propre (dispatcher broadcast, etc.) directement dans un graphe d'implémentation d'interface** — s'en servir seulement comme passe-plat trivial si besoin, ou mieux : contourner entièrement l'interface et appeler la fonction/le dispatcher cible directement depuis l'appelant via un `Cast` explicite vers la classe concrète (ex. `Inventory_Equipper::AttachItemToOwner` caste `Item` en `BP_Item_HoldableBase` et appelle `CallOnHeldStateChanged` directement, sans jamais passer par l'interface) — cette approche s'est révélée stable après le contournement.
- **Référence d'interface `K2Node_Message`/`K2Node_CallFunction` corrompue après un renommage d'interface (2026-09-06)** : un appel d'interface existant peut afficher un `type_id`/catégorie qui ne correspond à AUCUN asset actuel du projet (ex. `BPIEquippableItem|OnItemAttached` alors que seule `BPI_HoldableItem` existe — probablement un renommage `BPI_EquippableItem`→`BPI_HoldableItem` fait avant cette session) tout en compilant sans erreur et en affichant des types de pins statiquement cohérents (`get_node_type_pins` montrait bien `self: BPI Holdable Item Interface`) — la compilation réussit car un système de redirection (CoreRedirects ou équivalent) fait correspondre le nom au niveau des TYPES, mais l'appel ne déclenche RIEN à l'exécution (confirmé par prints de debug ne s'affichant jamais côté récepteur, malgré la classe cible confirmée implémenter l'interface via `unreal.SystemLibrary.does_class_implement_interface`). Un nœud fraîchement créé avec le MÊME `type_id` peut même se résoudre en un type de nœud DIFFÉRENT (`K2Node_CallFunction` au lieu du `K2Node_Message` d'origine) — signe supplémentaire d'une référence historique corrompue plutôt que d'un vrai type_id valide. Diagnostic : ajouter un print côté récepteur et vérifier empiriquement qu'il se déclenche ; si l'appelant confirme passer par le nœud (print juste avant) mais que le récepteur reste silencieux, suspecter ce piège. Fix : ne pas réutiliser l'ancien nœud ni recréer un nœud du même `type_id` — contourner l'interface entièrement (voir point ci-dessus).
- **Consommer un stock d'inventaire PASSIF (jamais équipé/lâché) ne doit jamais passer par un acteur monde (2026-09-06)** : la macro `ML_InventoryMacros::Get Item Actor` (et donc tout appel `Utilities|GetItemActor`) retourne TOUJOURS invalide pour un item empilé qui n'a jamais été spawné comme acteur (ex. un stack de flèches "Arrow" qui reste en inventaire, jamais équipé) — ce n'est pas un bug ponctuel, c'est le comportement normal : ces items n'ont simplement pas d'acteur tant qu'ils ne sont pas équipés/lâchés dans le monde. Une fonction du type `ConsumeArrow`/`ReduceAmmo` qui suit le patron `FindItem → GetItemActor → SERVER|ReduceAmount(item_actor, ...)` échoue donc silencieusement (retourne false) pour ce genre d'item, même quand `FindItem` a bien trouvé le stack. Fix correct : opérer directement sur les DONNÉES via l'adresse de l'item, avec `Inventory__Main::AddItemAmount(ItemAddress, DeltaAmount)` (négatif pour consommer) — une fonction RPC serveur qui gère nativement le retrait de l'array si le montant tombe à 0, sans jamais nécessiter d'acteur. Le mécanisme `GetItemActor`+fonction-sur-acteur reste correct UNIQUEMENT pour des items dont l'acteur est garanti d'exister (ex. un chargeur d'arme équipé, actif comme `Magazine Reference`).
- **PIÈGE CRITIQUE — brancher UNE sortie de pose sur PLUSIEURS entrées dans un `AnimGraph` casse toute la locomotion (2026-09-06)** : contrairement à un graphe Blueprint normal, une sortie `Pose Link` (`AnimGraphNode_*`) qui alimente directement 2+ entrées fait ÉVALUER EN DOUBLE, à chaque frame, TOUT le sous-graphe en amont — pas seulement recalculer une valeur, mais réellement re-tick les nœuds AVEC ÉTAT (State Machine, Motion Matching, Blend Space avec accumulation de temps, Inertialization) une deuxième fois. Symptôme observé : le personnage "bouge de façon bizarre" (mouvement erratique/saccadé) dès qu'un nœud en amont d'un fan-out a un état interne dépendant du temps — la Motion Matching et les State Machines de ce projet en amont de `Slot 'DefaultSlot'` étaient tickées deux fois par frame après l'ajout (sans précaution) d'un second consommateur sur la sortie de ce Slot. Fix obligatoire : **ne jamais connecter directement une sortie de pose partagée à plusieurs entrées** — insérer un `Save Cached Pose 'NomUnique'` juste après la source, puis un `Use Cached Pose 'NomUnique'` par consommateur (le projet utilise déjà ce patron ailleurs dans `SandboxCharacter_CMC_ABP`, ex. cache `MotionMachin` consommé par `Mirror_0` ET `BlendListByBool_3` — repérable via `find_nodes`/`get_node_infos` avant de dupliquer une sortie, pour voir si le patron existe déjà). Une régression de ce type NE PROVOQUE AUCUNE ERREUR DE COMPILATION — le graphe compile et sauvegarde sans avertissement, le bug n'est visible qu'en jouant.
- **Créer un nœud de Get/Set VARIABLE d'une AUTRE classe (pas une fonction) via `create_node` (2026-09-06)** : `find_node_types` avec `context_pins` pointant vers une pin déjà castée à la classe cible retourne bien le type_id correct (ex. `Variables|Default|SetWeapon`), mais ce type_id échoue à la création via `create_node` (`does not exist`) MÊME avec `declaring_class` renseigné — `declaring_class` ne sert qu'à désambiguïser un type_id déjà trouvé, pas à élargir la recherche. Fix : rappeler `find_node_types` avec `context_pins: []` (SANS contexte) sur le même filtre — la forme SANS contexte révèle le type_id RÉELLEMENT créable, qui suit la convention `Class|<NomClasseSansUnderscore>|<NomPropriété>` (ex. `Class|SandboxCharacterCMC|SetWeapon`), différent de la forme `Variables|Default|...` que le contexte affichait. Une fois créé, le nœud peut ensuite s'afficher avec un LABEL DSL trompeur (catégorie `SandboxCharacterCMCABP` au lieu de `SandboxCharacterCMC` par ex.) — vérifier le type réel de la pin `self` via `get_node_infos` (pas la catégorie DSL) pour confirmer la bonne classe cible.
- **Configurer un nœud `AnimGraphNode_*` (Slot, LayeredBoneBlend, etc.) au-delà de ses pins (2026-09-06)** : le nom d'un `Slot` (`SlotName`) et les filtres de branche d'un `Layered Blend Per Bone` (`LayerSetup[i].BranchFilters`) ne sont PAS des pins — ce sont des propriétés du sous-struct `Node` (le `FAnimNode_*` runtime) porté par le `AnimGraphNode_*`. Invisibles via `get_node_infos`/`create_node`/`set_pin_value`. Accès uniquement via Python : `node.get_editor_property("Node")` renvoie le struct runtime, dont les champs se lisent/écrivent avec `get_editor_property`/`set_editor_property` en snake_case (`slot_name`, `layer_setup`, `blend_weights`...) — mais pour un ARRAY de structs imbriqués (ex. `layer_setup: [InputBlendPose]`, chaque `InputBlendPose.branch_filters: [BranchFilter]`), modifier un élément en place ne suffit pas : construire les structs indépendamment (`unreal.BranchFilter()`, `unreal.InputBlendPose()`), les remplir via `set_editor_property`, PUIS réassigner le tableau complet sur le struct parent (`ibp.set_editor_property("branch_filters", [bf])`, puis `node_struct.set_editor_property("layer_setup", [ibp])`, puis `node.set_editor_property("Node", node_struct)`) — une mutation in-place sans cette réassignation finale ne persiste pas. `to_dict()` sur ces structs renvoie souvent `{}` de façon trompeuse même quand les propriétés sont bien accessibles individuellement via `get_editor_property` — ne pas se fier à `to_dict()` pour vérifier un struct AnimGraph, toujours relire chaque propriété nommément.
- Le cache de découverte de `find_node_types` pour un AUTRE Blueprint référençant fraîchement une fonction ajoutée ailleurs (ex. `Class|InventoryPlayer|MaNouvelleFonction` cherché depuis un Widget qui possède une variable de type `Inventory_Player`) peut rester périmé et ne rien retourner même après compilation+sauvegarde de la classe modifiée — `create_node` avec le `type_id` déduit par convention (`Class|<NomClasseSansUnderscore>|<NomFonction>`) fonctionne quand même ; ne pas conclure à une impossibilité sur la seule base d'un `find_node_types` vide.
- `unreal.get_editor_subsystem(unreal.EditorActorSubsystem).get_all_level_actors()` (et plus généralement les APIs `EditorActorSubsystem`) redevient **silencieusement vide** pendant qu'une session PIE est active — ces APIs ciblent le monde éditeur, pas le monde PIE. Pour inspecter/piloter des acteurs PENDANT une session PIE (vérifier qu'une IA se déplace, lire une variable en temps réel), utiliser `editor_toolset.toolsets.scene.SceneTools.find_actors` (qui résout correctement vers le monde `UEDPIE_0_<NomNiveau>`) puis `unreal.load_object(None, refPath)` sur le chemin PIE retourné.
- **`write_graph_dsl` (réécriture complète d'un graphe) casse sur 2 instances DIFFÉREMMENT TYPÉES d'un même nœud wildcard enum (2026-09-06)** : `Utilities|Enum|NotEqual(Enum)`/`Equal(Enum)` sont des nœuds génériques dont le type se fixe au premier pin connecté — un graphe EXISTANT peut très bien contenir plusieurs instances typées différemment (constaté sur `Get_MMInterruptMode` : 3× `NotEqual(Enum)` + 2× `Equal(Enum)`, types `E_MovementMode`/`E_MovementState`/`E_Gait` mélangés, qui coexistent sans problème). Mais **reconstruire ce même graphe en un seul appel `write_graph_dsl`** en y ajoutant une NOUVELLE instance sur un type enum différent (ex. `Weapon_Equip`) échoue systématiquement avec `Could not connect pin ReturnValue to B`, quel que soit l'ordre des clauses — le compilateur DSL semble partager le typage wildcard entre toutes les instances créées dans une même passe, contrairement au graphe déjà compilé où chaque instance est indépendante. Heureusement l'échec est bien transactionnel (`read_graph_dsl` confirme le graphe intact après l'erreur, aucun état partiel). Fix : ne PAS passer par une réécriture DSL complète pour ce genre d'ajout — construire les nœuds un par un (`create_node` pour les 2 `Variables|Default|GetXxx` + le nouveau `NotEqual(Enum)`, `connect_pins` pour les typer), puis brancher le résultat sur le nœud logique existant. Un nœud `Math|Boolean|ORBoolean`/`ANDBoolean` (`K2Node_CommutativeAssociativeBinaryOperator`) accepte nativement un pin de PLUS via `add_node_pin` (retourne le nouveau `PinID`, ex. `C` après `A`/`B`) — pas besoin de recréer tout l'arbre logique, juste ajouter le pin et y connecter la nouvelle condition. `read_graph_dsl` n'affiche ensuite QUE les 2 premiers pins d'un `or`/`and` à 3+ entrées (limite d'affichage du lecteur DSL) — vérifier un ajout de ce type via `get_node_infos` sur le nœud lui-même, pas via une relecture DSL qui semblerait ignorer l'édition.
- **Architecture Motion Matching — pourquoi une nouvelle base de données "valide" peut être ignorée indéfiniment (2026-09-06)** : `Update_MotionMatching` (fonction ABP thread-safe, tourne chaque frame) fait `EvaluateChooser → SetValidDatabases → MotionMatchingAnimNodeLibrary.SetDatabasesToSearch(node, databases, InterruptMode)` — le 3ᵉ paramètre (`Get_MMInterruptMode`, une fonction séparée) contrôle si le nœud `AnimGraphNode_MotionMatching` a le DROIT de remettre en cause la pose en cours (`DoNotInterrupt` = non, il continue de jouer/boucler l'ancienne sélection MÊME SI elle n'appartient plus à `DatabasesToSearch` ; `InterruptOnDatabaseChange(AndInvalidateContinuingPose)` = oui, force une recherche complète). **Changer `ValidDatabases` ne suffit donc JAMAIS à lui seul à faire réagir Motion Matching** si `Get_MMInterruptMode` ne détecte pas la transition responsable — vérifier scrupuleusement, pour TOUT nouveau contexte de sélection (nouvelle variable de state driving un chooser), qu'il existe bien une condition correspondante dans cette fonction (schéma déjà en place : une paire `GetXxx`/`GetXxxLastFrame`, mise à jour chaque frame dans `Update_States`, comparée avec `Utilities|Enum|NotEqual(Enum)` puis OR-ée dans la condition racine). Diagnostic fiable : `obj dump` sur l'instance `AnimInstance` vivante en PIE (`unreal.SystemLibrary.execute_console_command(actor, 'obj dump "<chemin_instance>"')`, résultat lu via `EditorToolset.LogsToolset.GetLogEntries`) expose le struct COMPLET `AnimGraphNode_MotionMatching=(...)`, notamment `MotionMatchingState.SearchResult.(SelectedAnim|SelectedDatabase|bIsContinuingPoseSearch|SearchCost)` et `AnimPlayers[].InternalTimeAccumulator` (qui doit AVANCER entre deux dumps espacés dans le temps — sinon la pose est réellement figée, pas juste "en cours de transition").
- **`PoseSearchDatabase` — échec silencieux de build d'index et non-avancement figé sur une frame (2026-09-06)** : un `PoseSearchDatabase` en mode `PCAKD_TREE` (valeur par défaut) peut échouer à construire son index dès le chargement du projet si son jeu d'animations sources est trop petit/peu varié pour que le calcul PCA converge — log `LogPoseSearch: Error: <hash> - <NomDatabase> BuildIndex Failed because of 'No Convergence' while calculating PCA data` (visible uniquement via `GetLogEntries` sur `LogPoseSearch`, jamais remonté côté Blueprint/PIE). Tant que l'index reste dans cet état, TOUTE recherche dessus échoue en silence (`SearchCost=FLT_MAX`, `SelectedAnim=None`) et spam `LogPoseSearch: Warning: UPoseSearchLibrary::MotionMatch - some searches have been skipped, since databases AsyncBuildIndex are in still in progress or failed` à chaque tick. Fix testé et qui fonctionne : `db.set_editor_property("PoseSearchMode", unreal.PoseSearchMode.BRUTE_FORCE)` (au lieu de `PCAKD_TREE`) + sauvegarde (`EditorAssetLibrary.save_asset(path, only_if_is_dirty=False)` — nécessite PIE ARRÊTÉ, sinon retourne `False` sans erreur) — `BRUTE_FORCE` n'a pas besoin de PCA et convient très bien à une petite database (coût de recherche linéaire négligeable à cette échelle). **Second piège indépendant, NON contournable trouvé à ce jour** : le tableau `DatabaseAnimationAssets` (alias historique `AnimationAssets`) d'un `PoseSearchDatabase` est protégé en lecture ET écriture pour TOUTE méthode testée (`get_editor_property`/`set_editor_property` Python, ET `ObjectTools.get_properties`/`set_properties` en C++ natif — qui pourtant contournent d'autres restrictions Python) ; seule la lecture BRUTE via `obj dump "<chemin>.<NomAsset>"` (PAS juste `<chemin>` seul, qui ne dump que le Package) expose son contenu texte (`DatabaseAnimationAssets(i)=(AnimAsset=...,SamplingRange=(Min=...,Max=...),...)`), sans équivalent en écriture connu. **ATTENTION à la sémantique de `SamplingRange`** (erreur de diagnostic commise puis corrigée le 2026-09-06) : `(Min=0, Max=0)` ne signifie PAS « plage vide » mais « ÉCHANTILLONNER TOUT LE CLIP » — c'est la valeur NORMALE, utilisée par toutes les databases saines du projet (vérifié sur `PSD_Dense_Stand_Walk_Loops`, `PSD_Dense_Stand_Idles`). Le cas réellement pathologique est `Min == Max != 0`, en particulier `(longueur_du_clip, longueur_du_clip)` : fenêtre de largeur nulle collée à la FIN du clip. Double conséquence : (a) plus rien à lire, et (b) `FPoseSearchDatabaseSequence::IsLooping()` exige `SamplingRange == (0,0)` EN PLUS de `AnimSequence->bLoop`, donc l'asset devient non-bouclable (`bLoopAnimation=False` dans le dump du nœud) même si l'AnimSequence source est bien `Loop=True` — d'où un gel sur une frame unique. Symptôme observable : `AnimPlayers[].InternalTimeAccumulator` identique entre deux `obj dump` espacés de plusieurs secondes réelles en PIE. Correction = remettre la plage à `0 / 0` à la main dans l'éditeur Pose Search Database.
- **PIÈGE CRITIQUE — `EditorAssetLibrary.consolidate_assets()` fait planter l'éditeur sur certains types de classes (2026-09-08, dédoublonnage de l'import Game Animation Sample)** : cette fonction (fusionne toutes les références d'un doublon vers l'asset gardé, supprime le doublon, laisse un `ObjectRedirector`) est **fiable à 100% sur les assets de données pures** (UserDefinedEnum, UserDefinedStruct, CurveFloat, ChooserTable, CameraRigAsset, CameraAsset, ControlRigBlueprint, ProxyAsset — testé sur ~85 assets sans un seul échec) mais **crashe le processus éditeur de façon reproductible** (`Assertion failed: NewEditorElement.Private_GetInternalData()->GetRefCount() <= 1 ... The old and new element both have external references!`, `LogPython: Error: Python execution caused a crash (exception code: 0xC0000005)` — l'éditeur entier finit par `Engine exit requested`, pas juste l'interpréteur Python) sur les **ActorComponent Blueprints activement utilisés comme composant** (constaté sur `AC_PreCMCTick`, `AC_SmartObjectAnimation`) et sur les **Blueprint Interfaces largement implémentées** (`BPI_SandboxCharacter_Pawn`). Les Blueprints "de classe" simples (GameMode, modes de mouvement `Mover`, transitions) consolident sans problème. **Ne jamais retenter `consolidate_assets` une seconde fois sur le même asset après un premier crash** — utiliser à la place, dans l'ordre de préférence : (1) `EditorAssetLibrary.delete_asset()` en brut si `AssetRegistry.get_referencers()` confirme que plus rien ne référence le doublon (le plus sûr, fonctionne même sur les types à risque — mais peut prendre 1 à 4 minutes sur un projet avec des dizaines de milliers d'assets, l'appel `execute_python_code` timeout côté client mais l'opération continue et réussit côté serveur : revérifier via `does_asset_exist` plutôt que de conclure à un échec sur un timeout) ; (2) si des références externes subsistent, les repointer manuellement d'abord — `BlueprintTools.set_parent()` pour un reparentage, `BlueprintTools.retarget_node_class(node, old_class, new_class)` pour un nœud de cast/appel de fonction/événement avec une classe figée à l'ancien doublon (fonctionne bien, contrairement à `consolidate_assets`) — puis `delete_asset` une fois les référenceurs à zéro. **Effet de bord du crash** : le processus éditeur entier redémarre, ce qui **remet l'interpréteur Python à zéro mais PAS l'état sauvegardé sur disque** — toute opération déjà sauvegardée (compile+save) avant le crash est conservée ; seule la commande en cours au moment du crash est perdue. Toujours vérifier `is_in_pie`/un `print("ping")` trivial après CE type d'erreur avant de continuer : contrairement à une simple corruption d'interpréteur (`SystemError: unknown opcode`, récupérable seulement par redémarrage éditeur elle aussi), celle-ci relance le processus tout seul en quelques dizaines de secondes.
- **Corollaire — reparenter un Blueprint dont les enfants référencent des COMPOSANTS PAR NOM (2026-09-08)** : si un Blueprint enfant (ex. `SandboxCharacter_Mover_Ragdoll`) a des nœuds `Variables|Default|GetXxx`/`SetXxx` qui lisent des variables membres du PARENT (ex. `SkeletalMesh`, `Capsule`, `CharacterMover` — des variables de CACHE exposant les composants SCS réels, PAS les composants eux-mêmes) et qu'on reparente vers un parent qui n'a pas ces variables sous ce nom exact, la compilation échoue avec `The property associated with <Nom> could not be found`. **Fix simple et à fort effet de levier** : ajouter au NOUVEAU parent des variables membres du même nom/type exacts (`BlueprintTools.add_object_variable`/`add_struct_variable`/`add_variable`) — TOUS les nœuds orphelins portant ce nom, dans TOUTES les fonctions de TOUS les enfants, se re-résolvent automatiquement à la compilation suivante, sans toucher un seul nœud individuellement (testé sur ~90 références réparties dans 28 fonctions, résolu par l'ajout de 8 variables). Il n'est PAS nécessaire que ces variables soient effectivement peuplées/câblées pour que la compilation réussisse — seule leur EXISTENCE avec le bon nom/type compte pour le compilateur ; les peupler (ex. dans `EventBeginPlay`) reste nécessaire pour un comportement correct à l'exécution.
- **`connect_pins`/`write_graph_dsl` peuvent devenir silencieusement des no-op après une session très longue avec plusieurs crashs éditeur (2026-09-08)** : en fin de session, après plusieurs cycles crash/redémarrage, `connect_pins(PinID_output, PinID_input)` a cessé de produire une erreur mais aussi de produire un effet (`get_node_infos` confirme après coup qu'aucune des deux pins n'est connectée) — reproduit même sur une paire de nœuds fraîchement créés dans le MÊME appel Python, et même sur un Blueprint différent qui avait fonctionné plus tôt dans la session. Aucune cause identifiée avec certitude (suspecté : état de l'éditeur dégradé par l'accumulation de crashs, pas un bug systématique de l'outil — `connect_pins` a fonctionné de façon fiable pendant le reste de la session). Si `connect_pins` semble réussir sans erreur mais que `get_node_infos` ne montre ensuite AUCUNE connexion sur les pins concernées, ne pas insister : passer à une méthode alternative (repenser le fix pour n'avoir besoin que d'ajouts de variables/fonctions, voir point ci-dessus) plutôt que de perdre du temps à re-essayer la même primitive.
- **Écrire dans une `ChooserTable` (colonnes) depuis un script (2026-09-06)** : `ColumnsStructs` se LIT en Python (`get_editor_property` + `.export_text()` sur chaque `InstancedStruct`) mais ne s'ÉCRIT PAS par cette voie — `InstancedStruct.import_text(nouveau_texte)` renvoie `True` en mentant (le contenu de l'élément reste inchangé), et le `set_editor_property("ColumnsStructs", ...)` qui suit ne remonte donc rien, sans lever d'exception. **Voie qui fonctionne** : le toolset Python `editor_toolset.toolsets.object.ObjectTools` (importable directement : `from editor_toolset.toolsets.object import ObjectTools`), qui expose la table en JSON — `json.loads(ObjectTools.get_properties(chooser, ["ColumnsStructs"]))`, modification du dict (ex. `col["rowValuesWithAny"][i] = "MatchAny"`), puis `ObjectTools.set_properties(chooser, json.dumps(data))` qui renvoie `True` et applique réellement. `ResultsStructs` (résultats des lignes) reste inaccessible par toutes les voies testées : on peut donc MODIFIER une ligne existante mais pas en AJOUTER une nouvelle par script.
- **`EditorAssetLibrary.save_asset`/`save_loaded_asset` peuvent renvoyer `False` alors que l'asset est parfaitement sauvegardable, PIE arrêté et fichier non-verrouillé** (constaté sur `CHT_PoseSearchDatabases_Dense` après une écriture via `ObjectTools.set_properties`, probablement parce que le package n'est pas marqué dirty par cette voie). Ne pas en conclure à un échec : passer par `unreal.EditorLoadingAndSavingUtils.save_packages([obj.get_outermost()], False)` qui renvoie `True` et met bien à jour le `mtime` du `.uasset` (à vérifier via `os.path.getmtime`, seule preuve fiable d'écriture disque).

- **Outillage découvert le 2026-09-13 (réparation post-migration)** : (a) `BlueprintEditorLibrary.compile_blueprint` / `BlueprintTools.compile_blueprint` ne lèvent AUCUNE exception sur erreur de compilation — encadrer les compilations de marqueurs `unreal.log_warning("MARQUEUR")` puis lire `Saved/Logs/ProjectFv1.log` entre les marqueurs (`LogBlueprint: Error`). (b) `BlueprintTools.set_pin_value` (et d'autres outils du toolset) peut SAUVEGARDER l'asset sur disque sans le dire — sauvegarder le fichier avant d'expérimenter. (c) `retarget_node_class` / `change_member_variable_type` ne rafraîchissent pas les types de pins en cache (erreurs « X is not compatible with X ») : sauvegarder, `EditorLoadingAndSavingUtils.reload_packages`, recompiler — le rechargement reconstruit les nœuds. (d) Le struct `PinID` n'est pas exposé en Python : pour `connect_pins`/`break_pins`, passer par `ProgrammaticToolset.execute_tool_script` (appel `get_execution_environment` requis avant) avec des PinID JSON `{direction, index_id, node:{refPath}}`. (e) Les pins d'un nœud `Evaluate Chooser` portent le NOM de l'asset struct de contexte : changer/renommer/fusionner la struct laisse des pins orphelines liées (« In use pin ... no longer exists ») à rebrancher. (f) `EditorAssetLibrary.consolidate_assets` sur des `UserDefinedStruct` sauvegarde automatiquement les référenceurs et crée les redirecteurs. (g) `ChooserTable.ContextData` s'écrit via `ObjectTools.set_properties` (JSON `_structType`/`class`/`struct` → `refPath`) + `EditorLoadingAndSavingUtils.save_packages`. (h) Une référence passant par un `.ini` (ex. `GameplayTagTableList`) est invisible pour l'Asset Registry : vérifier `Config/` avant de déclarer un asset « sans référence ».
- **PIÈGE CRITIQUE — `consolidate_assets` sur une UserDefinedEnum (probablement aussi une UserDefinedStruct) vide silencieusement les types de variables des référenceurs (2026-09-14)** : les références dures sont réécrites, mais le `PinSubCategoryObject` des variables membres (et types de valeur de map) typées par l'enum fusionné tombe à `None` : la variable devient un simple `byte`. La classe compilée garde le bon type, donc tout compile. Au rechargement suivant du package (les référenceurs sont auto-sauvegardés par la fusion), les liens devenus incompatibles sont supprimés, des nœuds `Equal/NotEqual (Enum)` redeviennent Wildcard et l'éditeur insère des `CastByteToEnum`. Une entrée qui garde une valeur littérale compile toujours : la logique est fausse SANS erreur (ex. `SandboxCharacter_Mover_ABP` : 19 variables vidées → 2259 erreurs au rechargement ; `BP_NotifyState_EarlyTransition` : 5 liens perdus dont 1 sans erreur). Les `K2Node_SwitchEnum` ne reconstruisent leurs sorties qu'au rechargement du package. Procédure : sauvegarder tous les référenceurs avant la fusion ; juste après et AVANT tout rechargement, scanner `BlueprintEditorLibrary.get_member_variable_type(bp, v).export_text()` (`PinSubCategoryObject=None`) et retyper via `change_member_variable_type` ; si un référenceur a déjà été rechargé cassé, le restaurer depuis la sauvegarde (éditeur fermé) ou comparer ses liens à un jumeau intact (`BlueprintTools.get_node_infos`), rebrancher et supprimer les casts (`delete_node`) ; valider par `reload_packages` d'UN seul package à la fois (jamais un Blueprint en même temps qu'un Blueprint dont il dépend). Pour des Blueprints entiers, préférer un déplacement à une fusion.
- **CRASH ÉDITEUR — handles Python sur des nœuds supprimés (2026-09-14)** : `BlueprintTools.delete_node` puis `compile_blueprint` dans le MÊME `exec`, alors que des variables Python gardent les handles de nœuds / structs de pins (`get_node_infos`) des nœuds supprimés → `EXCEPTION_ACCESS_VIOLATION` dans python311.dll et fermeture de l'éditeur. Fix qui a fonctionné : exécuter l'édition, la compilation/sauvegarde et tout ce qui déclenche un GC (suppression d'assets, `reload_packages`) dans des callbacks `register_slate_post_tick_callback` SÉPARÉS, chacun dans un dictionnaire de globals neuf, avec `scope.clear()` + `gc.collect()` entre les étapes et `unreal.SystemLibrary.collect_garbage()` au début de l'étape suivante. Ne sauvegarder qu'après une vérification : un crash ne laisse alors rien de corrompu sur disque. Relance : `E:\UE_5.8\Engine\Binaries\Win64\UnrealEditor.exe "E:\projet\ProjectFv1\ProjectFv1.uproject"` (MCP disponible ~20 s après).
- **Asset Registry périmé après sauvegarde + rechargement (2026-09-14)** : `get_dependencies`/`get_referencers` peuvent encore lister une référence qu'un asset n'a plus (ex. `PC_Sandbox` → widget de démo retiré, alors que le `.uasset` ne contient plus ce nom). Forcer `AssetRegistry.scan_paths_synchronous([dossier], True)` avant de vérifier des référenceurs.
- **`EditorAssetLibrary.delete_asset` sur une map non chargée** (`/Game/dev_map`) peut renvoyer `True` en laissant le `.umap` sur disque et une dépendance fantôme dans l'Asset Registry (qui ferait recharger/réenregistrer la map lors d'un renommage de ses dépendances). Vérifier le fichier sur disque ; s'il reste, le supprimer puis `scan_files_synchronous([fichier], True)`.
- **Assigner un squelette à une animation qui n'en a pas (2026-09-14)** : `AnimSequence.Skeleton` est en lecture seule pour `set_editor_property` ET refusé par `ObjectTools.set_properties` ; aucun service VibeUE (`SkeletonService`, `AnimSequenceService`, `AnimMontageService`) ne l'expose (lecture/compatibilité seulement). Seule voie : ouvrir l'asset dans l'éditeur, qui propose de choisir un squelette, puis sauvegarder. Avant, vérifier la compatibilité : `AnimationLibrary.get_animation_track_names(anim)` comparé aux os du mesh cible (`SkinnedMeshComponent.get_num_bones`/`get_bone_name` sur le composant mesh du CDO du personnage).
- **Détecter des régressions d'assets binaires via git** : `git show <commit>:<fichier> | git lfs smudge` restitue l'ancien `.uasset` ; comparer l'ensemble des chaînes `/Game/...` (table des noms) entre ancienne et nouvelle version révèle les références perdues (lignes de chooser, bases d'un schéma, BPI d'un canal) sans ouvrir l'éditeur.
- **Déplacer un dossier via `AssetTools.rename_assets`** (liste d'`AssetRenameData`, un seul appel pour tout le lot) réécrit et sauvegarde lui-même les référenceurs, sans laisser de redirecteur quand tous sont chargeables (112 assets en ~32 s le 2026-09-14). Le coût dépend du nombre de référenceurs : un notify utilisé par des milliers d'animations oblige à toutes les réenregistrer.

---

## 10. Maintenir ce document à jour

Ce document **doit toujours refléter l'état réel du projet**. Un skill dédié — **`maintain-architecture-doc`** (`.claude/skills/maintain-architecture-doc/SKILL.md`) — rappelle systématiquement aux modèles d'IA de :

1. Consulter ce document avant de modifier la structure du projet.
2. Le mettre à jour après toute création/suppression/déplacement/renommage de fichier ou dossier important.
3. Ajouter une description pour tout nouveau fichier important.
4. Retirer les entrées obsolètes (fichiers supprimés).
5. Corriger les chemins après un déplacement.
6. Mettre à jour les descriptions quand un système évolue significativement.
7. Vérifier périodiquement la cohérence entre ce document et l'arborescence réelle.
8. Ne jamais laisser ce document dans un état sciemment obsolète après une modification de structure.

**Règle de detail** : un fichier "important" à documenter est un Blueprint/Widget/Data Asset/Struct/Enum/Input Action qui porte de la **logique ou des données de gameplay**. Les assets purement artistiques individuels (textures, meshes, clips d'animation, miniatures) n'ont pas besoin d'entrée dédiée — il suffit que leur **dossier parent** soit listé et décrit (cf. §8).

*Historique de nettoyage :*
- *2026-09-04 : `Content/Systems/Blueprints/d/SandboxCharacter_CMC_ABP` renommé/déplacé vers `Content/Systems/Blueprints/SandboxCharacter_CMC_ABP` via l'outil de renommage Unreal (les 7 références ont été recâblées automatiquement, compilation vérifiée OK).*
- *2026-09-04 : suppression de 8 redirecteurs Unreal morts (résidus de renommages passés, 0 référence chacun, confirmés sans danger) : `Content/Systems/Stats/ACStats.uasset`, `Content/Systems/Movement/BPC_ClimbingComponent.uasset`, `Content/Systems/Movement/ClimbingMaterial.uasset`, `Content/Systems/Movement/CR_ClimbingGraphV2.uasset`, `Content/Systems/Movement/CR_Mannequin_BasicFootIK.uasset`, `Content/BP_TickManager.uasset`, `Content/dqs.uasset`, `Content/E_WeaponType.uasset`. Les vraies versions de ces assets restent à `Content/Systems/Movement/Climbing/`, `Content/Core/Tick/BP_TickManager` et `Content/Data/Enums/E_WeaponType`.*

- *2026-09-13 : réparation après la migration `Project_F` → `ProjectFv1` (voir §8.2) — 782 fichiers UltraDynamicSky restaurés depuis git, contexte de 7 chooser tables remis sur `Systems/Blueprints`, 3 structs identiques de `Content/Blueprints/Data/` fusionnées (redirecteurs), suppression de `Content/Blueprints/SandboxCharacter_CMC` + `_ABP` (doublon GASP), tags `Foley.Event.*`/`SmartObject.ObjectType.*` ajoutés. Compilation complète : 435 Blueprints, 0 erreur.*

- *2026-09-13 (nettoyage, étapes 1-2) : suppression des personnages de démo Echo/Paragon/UE4_Mannequin/UE5_Mannequins, de `MetaHumans/` et des BP `RetargetedCharacters/BP_*` ; rangement de `SandboxCharacter_CMC` → `Core/Character/`, `BP_GameInstance` → `Core/`, `DT_DemoTags` → `Data/` (config mise à jour) ; suppression de `DT_DemoTags.T3D` et des dossiers vides (dont `Content/Collections/`, `Content/Developers/`). Compilation : 405 Blueprints, 0 erreur.*

- *2026-09-13/14 (nettoyage, étape 3) : suppression des redirecteurs morts après re-sauvegarde de leurs référenceurs (dont `Animations/anim_Swim*`, `Core/PlayerController/IA_InitiateClimb|IA_LeapFromClimb|IA_MovingClimb`, `PSD_Relaxed_Stand_Sprint_Pivots`, les redirecteurs du 2026-09-04 encore suivis par git, et les redirecteurs de structs de `Content/Blueprints/Data/`).*

- *2026-09-14 : convergence des enums du framework dupliqué et réparation des Blueprints touchés (voir §8.2) ; `GM_Dev` → `SandboxCharacter_CMC`. Passe complète : 405 Blueprints ; seule erreur restante `BP_Item_AdvancedRifle` (`Reload_Rifle_Hip` sans squelette, antérieure) + avertissement `Ultra_Dynamic_Weather`. Commit intermédiaire (point de restauration) avant le déplacement du reste de `Content/Blueprints/` vers `Content/Systems/Mover/`.*

- *2026-09-14 (isolation du framework du sample) : démo GASP supprimée (`dev_map`, `Content/Levels/LevelPrototyping/`, `Content/Widgets/`) après avoir détaché `AC_TraversalLogic` (branche `LevelBlock_Traversable`) et `PC_Sandbox` (widget de démo) ; 17 redirecteurs d'enum supprimés ; 112 assets déplacés sans fusion (`Content/Blueprints/` → `Systems/Mover/` sauf `AnimNotifies/`, `Aiming/` → `Systems/Aiming/`, `Content/Input/` → `Systems/Mover/Input/`, `E_WaponType` → `Data/Enums/`), références réécrites, aucun redirecteur restant. Contrôle après redémarrage complet de l'éditeur : liens de graphe, valeurs de pins et types de variables des 66 Blueprints concernés encore existants identiques au relevé pris avant le déplacement (seuls écarts : chemins réécrits et artefacts de l'outil de comparaison). Compilation complète : 379 Blueprints, seule erreur `BP_Item_AdvancedRifle` (`Reload_Rifle_Hip` sans squelette, antérieure).*

- *2026-09-14 (reprise) : test PIE sur `MapDev1` — `GM_Dev` fait apparaître `SandboxCharacter_CMC`, aucune erreur de Blueprint à l'exécution. Seuls messages, antérieurs : `Systems/Weather/UltraDynamicSky/Particles/Snow` référence encore l'ancien chemin `/Game/UltraDynamicSky/Particles/UDW_Niagara_Parameters`, et 4 avertissements Pose Search d'entrées vides dans `PSD_SwimmingIdle`/`PSD_SwimmingMovingSprint` (contenu inchangé depuis `d29748b`, de nouveau chargé grâce au chooser restauré). Restauration depuis `d29748b` des 7 données Motion Matching dégradées par la migration (voir §8.2) avec fix MatchAny refait, et de `NS_Tornado`. Compilation complète : 379 Blueprints, seule erreur `BP_Item_AdvancedRifle` (`Reload_Rifle_Hip` sans squelette, antérieure).*

- *2026-09-14 (météo) : corrections du système météo projet (`WB_WeatherControl`/`WB_WeatherZone`, voir §4 Weather). Bugs corrigés : `setWeatherbetweenZone` lisait deux fois Zone2 ; `GetNearZone` ne trouvait jamais de zone (distances locales à 0, poids 0/0 et inversés) ; `SetNuage`/`MakeTemp` retournaient 0 sans zone voisine (return dans la boucle) et clampaient la température à 0–10 ; `makestate` renvoyait un état vide (branche froide nuages ≥ 8) et ne calculait ni vent/brouillard/poussière ni humidité ; `MakeForcast` avait des pas de 0–1 s ; `UpdateWeatherstate` n'avançait jamais le temps (+0) ; rayon d'influence ≈ 900 uu et tri `Trie zone` pouvant boucler à l'infini ; overlaps déclenchés par n'importe quel acteur ; saison en secondes. Nouveaux : fonctions `StepForecast`, `ApplyToUDW`, `GetZoneState` ; variables `ForecastStepMin/Max`, `InfluenceRadius`, `LastUpdateTime` (zone), `SeasonDurationScale` (contrôleur). `[CoreRedirects]` UDS + 10 systèmes Niagara re-sauvegardés. PIE OK (zones prêtes, 16 prévisions, poids 0.52/0.48, UDW alimenté, aucune erreur météo). Restant : `WeatherData` des 2 zones de MapDev1 vide (0 °C / 0 %), `BP_TickManager` transmet un `DeltaTime` ~10× trop petit au contrôleur (saison lente), avertissement d'attache des ChildActor UDS/UDW (mobilité). Sauvegarde des assets avant modification : `E:\projet\ProjectFv1_backup_migration_2026-09-13\weather_before_fixes_2026-09-14\`.*

*`Content/Data/DT_DemoTags.uasset` (anciennement à la racine) : longtemps considéré comme un reste de test sans référence — FAUX (vérifié le 2026-09-13) : c'est la table de tags AGIS déclarée dans `Config/DefaultGameplayTags.ini`, à conserver (voir §2.1).*