LifePlay-Revival/Docs/Migration/etat/CAM/CAM-CIBLE.md

Fiche CAM-CIBLE — Niveau N2 — Modèle prévu opus | utilisé claude-opus-5-5 — Agent orchestrateur (session « Camera ») — Skills lp-lot, sk-orchestrate

CAM-CIBLE : écart à la cible et plan de réduction proposé (2026-10-11)

Hors gabarit : proposition de l'orchestrateur (phase 1). Rien n'est décidé ici : chaque choix revient à l'utilisateur (§ 4). Base : CAM-AUDIT.md (identifiants K1-K8). Copie D:\Game\LifePlay-master 5.8, HEAD 4283c13.

1. Cible de l'utilisateur (citée)

« Je souhaite que 3 caméra suivent les mouvments du MC. 1 caméra à la première personne. caméra à la 3ième personnes, lors de l'initialisation, elle est situé à 1,75m du MC est regarde toujours dans sa direction, elle suit ses ses déplacvements.. La 3ièmé caméra est collé au plafon au centre est observe la salle ou elle est toujours à moins de 3m de haut du MC. les caméras de rues prennent toujours les rues en enfilades. »

2. Écart, cible par cible

Cible	Existant le plus proche	Écart
C1 1re personne du MC	K5 FirstPersonSM (composant FirstPerson_C de Person), attaché à la tête par PC SwitchCamera	n'existe que pendant le sexe ; vise aussi les partenaires (SexPersons[i]) ; une instance par Person ; regard souris par AddWorldRotation
C2 3e personne, 1,75 m, regarde le MC, le suit	K6 FollowView (C++, mort : 340 cm derrière, visée pawn + 50 cm, FOV 70, collision, lissage) ; K2 CameraScene + Room.AutoCamera (regarde la tête du MC, recalage ponctuel)	aucune caméra active ne suit le MC ; FollowView a déjà la mécanique (suivi, collision, lissage) mais distance 3,40 m, ne tourne que depuis Birdview pendant la marche, et n'est appelée par personne
C3 plafond, centre de la salle, < 3 m au-dessus du MC	aucun	à créer ; le plafond WallT des pièces est à Z relatif 2040 × échelle 0,2-0,4 = 4,1 à 8,2 m au-dessus de la racine de Room (calcul, CAM-T3 § 3.5) : la règle « < 3 m au-dessus du MC » contredit « collée au plafond » dans la plupart des pièces
Rues en enfilade	aucune ; K1 Birdview = vue de dessus de la ville (carte) ; 7 lieux extérieurs = des Room à échelle Z 0,01	à définir : le jeu n'a pas de rue 3D parcourue ; les routes UStreetMap existent en 2D (RoadPoints, sans hauteur), elles pourraient donner l'axe d'une rue
Moins de caméras	6 sortes de caméras de vue (4 placées, 1 composant × N Person, 1 C++ morte)	voir § 3

3. Plan de réduction et de repositionnement proposé (options)

3.1 Bilan proposé (à valider)

Caméra	Proposition	Motif
K6 FollowView (C++)	réutiliser pour C2 (distance 175 cm, déclenchement hors Birdview) ou supprimer	mécanique de suivi déjà écrite, jamais branchée
K5 FirstPersonSM	devient C1 ; option : ne garder que l'instance du MC (POV des partenaires supprimée) ou garder l'existant	une instance par PNJ, utilisée seulement en sexe
K2 CameraScene	remplacée par C2 / C3 pour la pièce ; reste pour les scènes scriptées si elles sont gardées	surchargée (pièce, scène, sexe, CharGen)
K3, K4 CameraFullBody / CameraPortrait	garder pour le CharGen (hors jeu) ou fusionner en une caméra + zoom	ne suivent pas le MC, hors cible
K1 Birdview	garder comme carte de la ville (hors cible « MC ») ou en tirer les caméras de rue	vue de navigation de la ville
K7, K8 SceneCapture	hors lot (rendus vers texture, pas des vues)	—
C3 plafond	à créer	aucune base
Rues	à créer selon la définition retenue (Q1)	aucune base
Résultat visé si tout est retenu : en jeu, C1 + C2 + C3 (+ caméras de rue) au lieu de CameraScene, FollowView morte et
N instances FirstPersonSM ; Birdview et les caméras de CharGen restent à part.

3.2 Deux voies d'implémentation (phase 2)

• Voie A — C++ (sous-système LPCameraSubsystem, nouveau), sur le modèle de LPDirectControlSubsystem et LPSecondScreenSubsystem (ticker, acteurs transitoires, « aucun Blueprint n'est modifié ») : crée C1 (attachée au socket head du MC), C2 (reprise de FollowCamera, 175 cm), C3 (centre de la boîte de la pièce, Z = min(plafond − marge, Z du MC + 300 cm), regard vers le MC) ; commutation par une touche. Avantages : pas d'écriture dans GI, Room, PC, Person (assets que STE vient de commiter), réversible par git, compilable et testable. Risques : coexistence avec les SetViewTargetWithBlend des BP (Birdview, HideRender, fin de sexe) qui reprendraient la vue ; il faut une règle de priorité.
• Voie B — Blueprint par MCP : modifier Person (C1), Room / PC (C2, C3, commutation), niveau CentralLondon (caméras de rue). Avantage : intégré aux BP existants. Risques : écritures dans des assets partagés avec STE et U8 (GI, Room, Person, carte), instantanés et gel de la copie UE, recuisson ; .umap modifié (niveau de jeu).
• Mixte : C++ pour C1/C2/C3, et seulement les points d'entrée BP indispensables (par ex. HideRender / SwitchCamera).
• Avis d'arbitrage de Big Boss (2026-10-11) : voie A sans conflit avec les autres lots (compilation et build ordinaires dans la file) ; voie B touche les assets de STE (GI, Room) et invalide le candidat Shipping d'U8 : seulement après la porte T11 d'U8 ou sur un gel décidé par l'utilisateur. CAM-T4 inscrite au rang 2, derrière le BUILD-FIN d'U8. Choix : utilisateur.
• Contrainte de file (Big Boss, 2026-10-11) : après T11, STE écrit aussi dans GI (IMPL C0, GI.destroyDummy) ; CAM et STE passent l'un après l'autre (instantané et commit chacun), ordre fixé par Big Boss ; la SPEC de phase 2 doit lister précisément les fonctions de GI touchées par CAM.

3.3 Étapes proposées (chacune sur décision)

1. CAM-T4 (phase 1b, lecture seule, copie UE) : commandlets pour fixer les réglages non établis (§ 5).
2. CAM-SPEC : spécification exécutable de la voie retenue (fichiers, ordre, repli, critères de VAL).
3. CAM-IMPL (instantané Tools/Snapshot.ps1 -Lot CAM, ticket TAG CAM-avant), CAM-BUILD, CAM-VAL (agent distinct), test en jeu par l'utilisateur (pièce, rue, scène, sexe, CharGen, sauvegarde et rechargement), puis DOC (CHG) et ticket au gardien.

4. Questions à trancher par l'utilisateur

• Q1 Rues : qu'appelles-tu « rue » dans le jeu ? (a) la vue de la ville Birdview ; (b) les 7 lieux extérieurs (Room « dehors ») ; (c) une nouvelle vue 3D au niveau du sol le long des routes StreetMap. Et « en enfilade » = caméra placée au bout de la rue, regard dans l'axe de la rue : d'accord ?
• Q2 C2, 1,75 m : distance horizontale au MC, distance totale, ou hauteur de la caméra ? Hauteur de visée (tête, poitrine) ? Placée derrière le MC (regard dans le sens de sa marche) ?
• Q3 C3, plafond : quand le plafond est à plus de 3 m au-dessus du MC (cas de la plupart des pièces : 4 à 8 m au-dessus de la racine), quelle règle prime : « collée au plafond » ou « < 3 m au-dessus du MC » ? Proposition : hauteur = min(plafond, MC + 3 m), au centre de la pièce, regard vers le MC.
• Q4 Commutation : la touche C (SwitchCamera) passe-t-elle C1 → C2 → C3 hors sexe ? Pendant le sexe, garde-t-on le cycle actuel des vues POV des partenaires ?
• Q5 C1 : vue 1re personne du MC seul (on retire FirstPersonSM des PNJ), ou garder la POV des partenaires ?
• Q6 Caméras hors cible : Birdview (carte de la ville) et les 3 caméras du CharGen / contacts restent-elles telles quelles, ou entrent-elles dans la réduction ?
• Q7 Voie d'implémentation : A (C++ seul, aucun BP modifié), B (BP par MCP) ou mixte ?
• Q8 Scènes scriptées : les commandes cameraMove / cameraFocus / cameraLock (aucun module livré ne s'en sert) doivent-elles continuer à piloter une caméra (laquelle) ?
• Q9 Défauts constatés : le pivot de l'acteur Room par CameraFocus, les chaînes mortes (minuterie AutoCamera, suivi mort dans Person) et le code FollowCamera entrent-ils dans le lot CAM ?
• Q10 Phase 1b : d'accord pour CAM-T4 (≈ 15 min de copie UE, lecture seule, derrière U8) ?

4b. Réponses de l'utilisateur (2026-10-11, citées)

Second message : « 6 oui. Q2 oui Q3 à partir du sol Q8 oui. a 10 oui » « la rue est une des vue exterieur 2, 1,75m du MC est en hauteur la taille du MC + 50cm. 3 on colle réellement au plafond sauf en extérieur. ou on est à 3,80m. 4 oui. 5 les deux. par modification des Blueprints. 8 oui. 9 oui. Explique le 6 un peu mieux »

Q	Décision lue	Reste à préciser
Q1	(b) rue = une des vues extérieures (les 7 lieux extérieurs, Room à échelle Z 0,01)	—
Q2	C2 à 1,75 m du MC ; hauteur de la caméra = taille du MC + 50 cm ; regard vers le MC	confirmé (« Q2 oui »)
Q3	C3 réellement collée au plafond en intérieur (la règle « < 3 m » tombe) ; en extérieur, à 3,80 m au-dessus du sol	confirmé (« Q3 à partir du sol »)
Q4	oui : touche C = C1 → C2 → C3 hors sexe ; cycle POV actuel gardé pendant le sexe	—
Q5	les deux : POV du MC et des partenaires	—
Q6	« 6 oui » : recommandation retenue : Birdview gardée telle quelle ; CameraFullBody et CameraPortrait gardées pour le CharGen et les contacts (fusion non retenue) ; CameraScene perd son rôle de pièce (remplacée par C1-C3), garde le CharGen	lecture de l'orchestrateur du « oui »
Q7	voie B, Blueprints, après la porte T11 d'U8 (« a »)	—
Q8	oui : les commandes de scène (cameraMove, cameraFocus, cameraLock) pilotent C2	confirmé (« Q8 oui »)
Q9	oui : CameraFocus, chaînes mortes et FollowCamera dans le lot	—
Q10	oui : CAM-T4 (phase 1b) accordée	BUILD-DEMANDE envoyée à Big Boss

4c. Réponses de l'utilisateur aux questions de la SPEC (CAM-SPEC.md § 4, Q1-Q20), 2026-10-11, citées

« q4 lissage et évitement, le reste oui » ; puis « approuvé » (amendement de la SPEC et suite).

• Q4 : C2 en poursuite lissée avec évitement des murs (portage en BP de la mécanique de FollowCamera : minuterie, balayage anti-collision, interpolation), au lieu de l'attache rigide proposée → amendement de la SPEC (CAM-T5b).
• Toutes les autres propositions de la SPEC sont retenues : Q1 derrière le MC, 175 cm à l'horizontale ; Q2 taille = tête − sol + 10 cm ; Q3 regard vers la tête ; Q5 C3 intérieure fixe, rotation qui suit le MC ; Q6 enfilade au bout opposé au MC ; Q7 C2 à l'entrée, mode gardé non sauvegardé ; Q8 étape hors POV = caméra de pièce ; Q9 constructeur et édition de personnage gardent CameraScene ; Q10 flèches / molette / souris sans effet en pièce (premier passage) ; Q11 C1 masque cheveux, soleil, mur, pas de regard souris ; Q12 scène hors pièce → C2 ; Q13 cameraMove détache C2, lock inchangé ; Q14 AutoCamera supprimée ; Q15 FollowCamera C++ supprimée ; Q16 sonde B0 accordée ; Q17 post-traitement de CameraScene copié ; Q18 Person non touchée ; Q19 un seul CameraActor pour C2 et C3 ; Q20 retour à l'utilisateur si le MCP échoue.
• Redump -Pins -Exec de Birdview, ContactMenu, Person (≈ 3 min, lecture seule) : accordé (« le reste oui »).

5. Phase 1b proposée : CAM-T4 (commandlets en lecture seule, copie UE)

Options vérifiées dans Source/LifePlayEditorTools/LPDumpComponentsCommandlet.h:8-11 et LPDumpCDOCommandlet.cpp:24-30.

#	Commande (-run=)	But
1	LPDumpComponents -Map=/Game/Scenes/CentralLondon -Filter=Camera -All	transform, FOV, post-traitement de CameraScene, CameraFullBody, CameraPortrait
2	LPDumpComponents -Map=/Game/Scenes/CentralLondon -Filter=Birdview -All	position, projection, OrthoWidth de Birdview
3	LPDumpComponents -BP=Birdview -All	composants et défauts de la classe
4	LPDumpComponents -BP=Person -All	FirstPersonSM : transform relatif, FOV, bAutoActivate
5	LPDumpComponents -BP=FirstPerson -All	défauts de la classe C1
6	LPDumpCDO -Class=/Game/BPs/GM.GM_C -Out=… -Props=DefaultPawnClass,PlayerControllerClass	classes par défaut
7	LPDumpCDO -Class=/Game/BPs/PC.PC_C -Out=… -Props=PlayerCameraManagerClass	gestionnaire de caméra
8	LPDumpCDO -Class=/Game/BPs/GI.GI_C -Out=… -Props=CameraSceneTransformDefault	position par défaut de la caméra de pièce
9	LPDumpFunction -BP=Birdview -Fn=*	graphe de Birdview (relais vers Room, suivi éventuel)
10	LPDumpFunction -BP=ContactMenu -Fn=*	SelectCamera, ReturnFromChargen
11	LPDumpFunction -BP=Person -Fn=EventGraph	redump à HEAD (le dump L6f date d'avant le commit ee2821a)
Lancement par lp-builder via Tools/RunCommandlet.ps1 (journaux dans etat\CAM\), après BUILD-GO de Big Boss ;
aucun asset écrit (MD5 de Person, GI, Room, PC, Birdview et de CentralLondon.umap relevés avant et après).