LifePlay-Revival/Docs/Migration/etat/CAM/CAM-B2d-TPS.md
edujiro5972 8084622450 LifePlay UE 5.8 : état de développement au 2026-10-19
Tickets : REP1-T4

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-19 22:57:42 +02:00

5.5 KiB

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.