# CAM-B2d : maniement du personnage à la troisième personne (analyse et proposition, 2026-10-13)

Demande de l'utilisateur (directe) : « le personnage est difficile à manier, renseigne-toi comment gérer un personnage
à la troisième personne ». Lecture seule ; aucune écriture d'asset.

## 1. Référence : le modèle Third Person d'Epic (UE 5.8 installé)
Source : `D:\Game\Launcher\Engine\UE_5.8\Templates\TP_ThirdPerson\Source\TP_ThirdPerson\TP_ThirdPersonCharacter.cpp`.

Le modèle s'organise autour d'**une seule référence partagée, la rotation de contrôle** (`ControlRotation` du
contrôleur) :

| Rôle | Réglage du modèle | Ligne |
|---|---|---|
| La souris ou le stick fait tourner la rotation de contrôle | `AddControllerYawInput(Yaw)`, `AddControllerPitchInput(Pitch)` | 113-120 |
| La caméra se place derrière la rotation de contrôle, et non derrière le personnage | `CameraBoom->bUsePawnControlRotation = true`, `TargetArmLength = 400` | 39-42 |
| Le déplacement se fait par rapport au lacet de contrôle : avant = « vers où regarde la caméra » | `ForwardDirection` / `RightDirection` tirés de `GetControlRotation().Yaw` | 93-110 |
| Le personnage se tourne vers sa direction de marche, sans suivre la caméra | `bUseControllerRotationYaw = false`, `bOrientRotationToMovement = true`, `RotationRate = (0, 500, 0)` | 21-27 |
| Démarrage et arrêt | `MaxWalkSpeed 500`, `BrakingDecelerationWalking 2000`, `MinAnalogWalkSpeed 20` | 33-35 |
| Collision de la caméra | le `SpringArm` recule la caméra devant un obstacle (sonde de collision) | 39-42 (composant) |

Conséquence : avancer éloigne toujours de la caméra et gauche/droite restent gauche/droite à l'écran. Le personnage
tourne sous la caméra, mais la caméra ne tourne que si le joueur la tourne.

## 2. LifePlay aujourd'hui (B2b)
| Rôle | LifePlay | Preuve |
|---|---|---|
| Déplacement ZQSD | par rapport au **lacet de contrôle du PC** (comme le modèle) | `Source/LifePlay/LPDirectControlSubsystem.cpp:885-892` |
| Orientation du personnage | `bOrientRotationToMovement = true`, `bUseControllerRotationYaw = false` (comme le modèle) ; `RotationRate` non réglé (valeur du Blueprint Person, non lue) | `LPDirectControlSubsystem.cpp:864-868` |
| **Rotation de contrôle** | **jamais écrite** : 0 écriture dans PC, GI, Room (dumps) ni dans le C++ (seulement 3 lectures, `:887, :913, :929`). Elle reste fixe, donc Z va toujours dans la même direction du monde | grep `ControlRotation\|AddYawInput\|SetControlRotation` : PC 0, GI 0, Room 0 ; `Source` : 3 lectures |
| **Caméra C2** | placée derrière **l'avant du personnage** (`GetActorForwardVector`, + `C2Yaw`) ; la souris et les flèches font varier `C2Yaw` | `CAM-SPEC.md` B2-3, B2b-5, B2b-6 |

**Cause du maniement difficile (établie par le code ; le ressenti reste à confirmer)** : la caméra et les commandes
n'ont pas la même référence. Exemple : le joueur appuie sur D. Le personnage part vers la droite du monde et se tourne
dans ce sens, la caméra C2 pivote derrière lui, et Z désigne alors la gauche de l'écran. À chaque virage, l'image
tourne alors que les commandes restent fixes dans le monde.

## 3. Proposition B2d : aligner C2 sur le modèle d'Epic (Room seul, sans C++)
1. **C2 derrière le lacet de contrôle** : dans `ComputeC2Target`, la direction arrière vient de
   `GetControlRotation(GI.PC).Yaw` au lieu de `GetActorForwardVector(MC)` (remplace 453 → 454 → PO17 → 497).
   `C2Yaw` devient inutile : il est retiré, ou laissé à 0.
2. **La souris et les flèches font tourner la rotation de contrôle** : dans `CircleCamera` et `LeftRight` (branches C2
   de F6a), on remplace `C2Yaw += …` par `GI.PC.SetControlRotation(lacet + …)`. Le déplacement ZQSD suit alors
   la caméra, sans changement du C++ (il lit déjà ce lacet).
3. **Départ derrière le personnage** : dans `PlaceC2` (entrée en C2), on fait d'abord
   `SetControlRotation(0, lacet du personnage, 0)`, pour que la caméra parte derrière lui comme aujourd'hui.
4. Inchangés : hauteur (`C2Height`), distance (`C2Dist`), confinement dans la pièce, repli, lissage et balayages de B2b.
5. En option, à décider : un recentrage automatique derrière le personnage après N s sans toucher la caméra
   (comportement de nombreux jeux, absent du modèle d'Epic).

Effets attendus : Z éloigne toujours de la caméra ; Q et D vont à gauche et à droite de l'écran ; le personnage se
tourne vers sa marche sans faire tourner la caméra ; la caméra ne tourne qu'à la souris ou aux flèches.

## 4. Coût, risques, partage avec STG
- Room seul, ≈ 12 nœuds (2 `GetControlRotation`, 3 `SetControlRotation`, opérations de lacet, suppression de 3 nœuds
  de la chaîne 453 → 497). ≈ 25 min de MCP par `lp-mcp-bp` (1 fiche), V5 et V6 ≈ 5 min, puis build et essai.
- Risque faible : la rotation de contrôle n'a aujourd'hui aucun autre lecteur que la marche (`:887`) et la
  `FollowCamera` morte (`:913, :929`, retrait prévu en B6). Birdview et les menus ne la lisent pas (0 occurrence dans
  les dumps PC et GI).
- **Partage avec STG** : la marche (`LPDirectControlSubsystem::Walk`) appartient au chantier de STG (perte du
  déplacement, B-SOL). B2d ne la modifie pas, mais change ce qu'elle lit. À coordonner par Big Boss. Le réglage
  éventuel de `RotationRate` ou des vitesses (modèle : 500°/s, 500 cm/s, freinage 2000) relève de STG ; leurs valeurs
  actuelles chez Person ne sont pas lues ici.
- Barème : a1 b2 c1 d1 e1 f1 = 7 → N3 ; S = C3 1 (procédure `lp-mcp`, fiches B2b) + f 1 = 2 < 3 : une fiche.