LifePlay-Revival/Docs/Migration/etat/CAM/CAM-B2r-FICHE.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.4 KiB

CAM-B2r : remise de SpaceOn et MainMenuOn après CharGen, et témoins C1 (C++, fiche lp-impl, 2026-10-14)

Origine : CAM-COMMUN6-DIAG.md § 10 (priorité 1 de l'utilisateur : « injouable à cause de C1 »). Fichier CAM seul : Source/LifePlay/LPCameraModeSubsystem.cpp et .h. Aucun Blueprint, aucun .ini, ni GI, ni PC, ni Person, ni STG. Aucune écriture sans GO de Big Boss. Le correctif écrit en jeu, par réflexion, deux variables de GI : cela relève du domaine GI, et Big Boss le valide avec le GO.

Barème

a0 b1 c1 d0 e1 f0 = 3 → N1, ajusté à N3 (C++ compilé, lp-impl) ; S = C3 0 + f 0 = 0 : une fiche. Environ 70 lignes. Case C9a : MD5 et structure du fichier relus le jour même (.cpp FE9236BD138A46BBC2B63027977B3CD9, 503 lignes ; .h 7DA111CB65B267A9E2F7482CBA368BE9, 66 lignes).

Conditions d'entrée

  • GO de Big Boss sur B2r (validation de l'écriture de GI.SpaceOn et GI.MainMenuOn).
  • MD5 des deux fichiers égaux à ceux ci-dessus ; sinon, relire et adapter, puis compte rendu.
  • Instantané : .\Tools\Snapshot.ps1 -Lot CAM-B2r -Path Source\LifePlay\LPCameraModeSubsystem.cpp,Source\LifePlay\LPCameraModeSubsystem.h (PowerShell, depuis la racine).
  • Compilation sous jeton UE (Tools/Build.ps1). L'écriture du code ne demande pas le jeton.

Écritures

R1 : sortie de CharGen (dans Tick, à chaque passage, 0,1 s)

  • Nouveaux noms dans LPCameraModeLocal : GICharGenOn (CharGenOn), GIMainMenuOn (MainMenuOn), GIJournalOn (JournalOn), GIContactsOn (ContactsOn), PCMoveCamera (MoveCamera), et une fonction WriteBool(UObject*, FName, bool) (FBoolProperty trouvée par nom ; rien si absente).
  • Nouveaux membres du .h : bool bCharGenSeen = false;, float CharGenRepairTimeout = 0.f;.
  • Logique :
    • si GI.CharGenOn est vrai : bCharGenSeen = true, CharGenRepairTimeout = 10.f ;
    • sinon, si bCharGenSeen : décompter CharGenRepairTimeout. Dès que la vue est une caméra de pièce, on répare. Caméra de pièce : le joueur avec Room.CamC1On, ou Room.CamRoom, ou Room.SceneCamera avec Room.CamC3On. On ne répare jamais si la vue est GI.Birdview (carte de la ville) ;
      • si GI.SpaceOn est faux : WriteBool(GI, SpaceOn, true) et une ligne CharGen : SpaceOn remis a vrai (vue %s) ;
      • si GI.MainMenuOn est vrai et aucun widget MainMenu_C n'est à l'écran (parcours de MenuOnScreen, limité à cette classe) : WriteBool(GI, MainMenuOn, false) et une ligne CharGen : MainMenuOn remis a faux (menu principal ferme) ;
      • puis bCharGenSeen = false ;
    • si le délai de 10 s s'écoule sans caméra de pièce (retour sur la carte de la ville) : bCharGenSeen = false, sans écriture, et une ligne CharGen : sortie sans camera de piece (vue %s), rien remis.
  • Garde : GI, Room, PC et la vue sont lus par ReadObject et IsValid, comme les témoins existants. Aucune lecture Accessed None n'est possible depuis le C++.

R2 : témoin « Touche C » étendu (LogSwitchKey)

Ajouter à la fin de la ligne existante : ; MainMenuOn=%d JournalOn=%d ContactsOn=%d CharGenOn=%d MoveCamera=%d (MoveCamera lu sur le PC). Cela tranche H-M au prochain essai.

R3 : témoin C1 (dans Tick, quand le libellé est « Camera: C1 First person »)

Toutes les 0,5 s, au plus une ligne par seconde, seulement si l'écart dépasse un seuil :

  • position : distance entre FirstPersonSM (composant du joueur, lu par nom) et le milieu des douilles lEye et rEye du maillage, au-delà de 8 cm ;
  • orientation : tangage de FirstPersonSM hors de ±25°, ou écart de lacet avec le lacet de contrôle au-delà de 30°.

Ligne : Temoin C1 : camera a %.0f cm des yeux, tangage %+.0f, ecart de lacet %+.0f, assis=%d, minuterie=%d.

  • assis : OccupyingFnt valide ;
  • minuterie : Room.RoomCamTimer actif, lu par UKismetSystemLibrary::K2_IsTimerActiveHandle sur la structure FTimerHandle.

Ce témoin prouve à l'essai si B2k suit bien la position, et mesure l'écart d'orientation que corrige B2s (P5).

VAL (lp-validator distinct)

  • Relecture du diff : seuls LPCameraModeSubsystem.cpp et .h changent ; aucune écriture hors des quatre cas ci-dessus. WriteBool n'est appelé que dans R1.
  • Fins de ligne (lp-validate, LF ou CRLF comme le fichier d'origine).
  • Compilation Build.ps1 : 0 erreur, aucun avertissement nouveau dans ce fichier.
  • V7 (build suivant) : CAM-50 à CAM-53 ci-dessous.

Essais

N° Action Attendu
CAM-50 En C1, Échap, changer de personnage, valider, revenir en jeu. Journal : « CharGen : SpaceOn remis a vrai ». C marche ; la souris tourne la vue C1.
CAM-51 Même chose depuis C2 et depuis C3. Même résultat ; mode de caméra conservé.
CAM-52 Nouvelle partie (CharGen de départ). Aucune ligne « remis » si l'inventaire a déjà remis SpaceOn ; jeu inchangé.
CAM-53 En C1 : s'asseoir, se lever, marcher, sortir d'une scène. Lignes « Temoin C1 » éventuelles (avant B2s) : on note la distance et le tangage.

Retour arrière

.\Tools\Restore.ps1 -Lot CAM-B2r -Only Source\LifePlay\LPCameraModeSubsystem.cpp,Source\LifePlay\LPCameraModeSubsystem.h, puis recompilation.

Estimation

Écriture 30 min, VAL statique 15 min, compilation environ 10 min sous jeton UE. Correctif simple : il peut passer avant ORG4, s'il a un créneau de compilation. Il ne demande ni éditeur ni MCP.