LifePlay-Revival/Docs/Migration/etat/REL/KEY2/KEY2-DIAG-02.md

KEY2-DIAG-02 : V / X sans effet et flèches haut / bas sans effet en scène (essai COMMUN-16)

Fiche KEY2-DIAG-02 — Niveau N3 — Modèle prévu opus (Medium) | utilisé Opus 5.5 — Session « Medium · KEY2 » — Skills : sk-protocol. Date : 2026-10-20. Ordre de Big Boss local_104ff22d. Lecture seule du code, du journal de COMMUN-16 et de KEY2-CART-02 ; aucune écriture hors de ce livrable (dégel non donné). Journal : D:\Game\LifePlay_Build_5.8_Development_COM16\Windows\LifePlay\Saved\Logs\LifePlay.log (noté « J » ci-dessous).

1. Constat (cité par Big Boss)

« V/X pas d'action en vue. pour les flèches seul droite /gauche fonctionnent haut/bas ne fonctionnent pas » (en scène).

2. Question 1 : CoupleMoveY (V / X) n'a aucun effet (cause établie)

1. Le code de KEY2 (LPCameraModeSubsystem.cpp, fin de TickSceneKeys (:1344), bloc « KEY2 (§ 8c, 4) ») s'arrête avant tout déplacement si la pièce n'est pas cachée : if (bGrabbing || FMath::IsNearlyZero(MoveAxis) || Couple.Num() == 0 || !MoveRoom || !MoveRoom->IsHidden()) return;. Cette garde a été reprise de celle de PC pour le X (KEY2-CART-02 § 5 ; SPEC § 8c, 4).
2. Dans la scène de l'essai, la pièce est visible : J l. 10478, « Sexe : couple deplace hors prise de (+0, +0, +9) ; … ; Room cachee=0 ».
3. La garde rend donc la main à chaque image : V et X sont lus (AxisValue), mais le couple ne bouge jamais. Aucune ligne de journal n'existe pour ce bloc, d'où le silence relevé par Big Boss.
4. Ce n'est ni un axe non lié ni un consommateur absent :
   • les liaisons existent : LPKeyboard.ini de COMMUN-16, l. 64-65 (CoupleMoveY V +1 / X −1) ;
   • le C++ lit l'axe par interrogation (AxisValue, qui appelle PlayerInput->IsPressed), sans InputComponent ni consommation.

3. Question 2 : flèches haut / bas sans effet (comportement d'origine, pas une régression de KEY2)

1. Entrée intacte (établi) :
   • git diff HEAD -- Config/DefaultInput.ini ne touche aucune ligne DownUp ni LeftRight ;
   • les flèches arrivent au jeu : J l. 10440-10451, fleches=-1/+0, +0/-1, +0/+1, etc. ;
   • KEY2 ne consomme pas ces axes : le C++ les lit seulement pour le journal (:1241-1250 de la révision d'origine) ;
   • l'option CoupleDrag ne joue que sur le clic gauche (TickCoupleMouse).
2. Routage d'origine dans PC (établi par KEY2-CART-02 § 5) : K2Node_InputAxisEvent_3 (DownUp) ne déplace le couple sur X que si GI.Room.bHidden est vrai. Sinon, il appelle Birdview.DownUpBirdview. LeftRight appelle CircleSexPersons si la pièce est cachée, sinon Birdview.LeftRightBirdView. Dans une pièce visible (cas de l'essai, Room cachee=0), aucune des deux flèches n'agit donc sur le couple par PC.
3. Ce que montre J (établi) : pendant les appuis sur les flèches (l. 10440-10451), le lacet du couple reste à −90. Gauche et droite ne le font donc pas tourner non plus dans cette scène. Ce que l'utilisateur voit « fonctionner » à gauche et à droite est sans doute la vue Birdview ou la caméra de scène (estimé, non lu : Birdview.LeftRightBirdView). Les petits écarts de position du couple entre deux lignes (quelques dizaines d'unités) ont lieu aussi sans touche (l. 10466, 10471) : ils ne sont pas attribuables aux flèches.
4. La molette, elle, déplace le couple en Z dans une pièce visible (J l. 10478 : « molette=+1.0 », Z +9). C'est le code « B2p-R » de Room cité par le C++ (commentaire de BuildControlsHelp). L'aide du jeu, qui affiche « flèches : déplacer le couple », ne vaut donc que pour une pièce cachée.
5. Classement : comportement d'origine de PC (une pièce visible ne reçoit pas les flèches pour le couple). KEY2 n'y est pour rien. Le défaut de KEY2 est d'avoir reproduit la même garde pour V / X.

4. Correctif proposé (à écrire au dégel, dans LPCameraModeSubsystem.cpp, coordonné avec CAM2)

1. CoupleMoveY dans les deux cas :
   • retirer la condition !MoveRoom->IsHidden() ;
   • pièce visible : borner la nouvelle position du couple à l'intérieur de la pièce, par ComputeRoomInterior (déjà utilisé par CAM2, FRoomInterior.Area), avec la marge CoupleFloorMargin (30 cm, :144) ;
   • pièce cachée : pas de borne, comme le X de PC aujourd'hui ;
   • repère : Y du monde, décision 15 ; constante CoupleMoveSpace inchangée.
2. Flèches haut / bas : deux options, à trancher par l'utilisateur (ce comportement est d'origine) :
   • (a) ne rien changer : les flèches restent à Birdview dans une pièce visible. Seule l'aide est corrigée : « flèches : déplacer le couple (pièce cachée) » ;
   • (b) ajouter en C++ un déplacement du couple sur X du monde par DownUp dans une pièce visible, borné comme en 1. Les flèches haut / bas déplaceraient alors le couple partout, et gauche / droite resterait à PC. Risque : un double effet si Birdview.DownUpBirdview agit lui aussi en scène (non lu ; KEY2-CART-02 § 7). Recommandation : (b), avec une ligne de témoin, si l'utilisateur veut que les flèches déplacent le couple comme l'annonce l'aide ; sinon (a).
3. Témoin de journal (demande de Big Boss) : une ligne par appui, au front montant de l'axe, et non à chaque image :
   • Scene : CoupleMoveY=%+.0f, Room cachee=%d, couple deplace de (%+.0f, %+.0f) [borne : oui/non] ;
   • ou … ignore (raison : prise / pas de couple / pas de piece). Même forme pour l'option (b) avec DownUp.

5. Preuves exigées après l'IMPL

• Pièce visible : V et X déplacent le couple sur Y du monde ; le couple s'arrête à 30 cm du bord du sol ; une ligne de témoin par appui.
• Pièce cachée (scène d'extérieur) : V et X déplacent le couple sans borne.
• Option (b) seulement : les flèches haut et bas déplacent le couple sur X dans une pièce visible, sans autre effet visible (vérifier Birdview).

6. Limites

• Birdview.DownUpBirdview et Birdview.LeftRightBirdView ne sont pas lus (aucun MCP dans cette fiche).
• Le sens de Room.bHidden (scène d'extérieur ou autre) vient du commentaire du C++ (« Piece cachee (scene d'exterieur) ») : estimé.

Fichiers écrits : ce livrable. Aucun autre fichier modifié.