ProjectFGame/Architecture_Projet.md

🏗️ 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 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 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

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" :

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.

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

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.

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).

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`
├── 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)

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

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`). `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

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[]
│       ├── 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 → ScrollBox_0 → InventoryPlayer` (WB_InventoryPlayer : équipements + poches + sac à dos dans le même défilement) ; `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, en un seul bloc continu : `EquipsVertical` → `EquipSlotsBox` (SizeBox 740×860) → `SlotsCanvas` avec les 12 EquipSlots, puis `VerticalBox_0` (titre Pockets + `PocketContainer`, et les containers du sac à dos ajoutés dessous par `Add Container Below Pockets`). `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/

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.

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).