LifePlay-Revival/Docs/Migration/etat/CAM/CAM-COMMUN4-DIAG.md

CAM-COMMUN4-DIAG : déplacement des personnages bloqué en mode « Scene » pendant le sexe (2026-10-13)

Demande de Big Boss : régression probable signalée par l'utilisateur. Pendant une scène de sexe, en caméra « Scene », on ne peut plus déplacer les personnages (Maj + souris, ou touches selon l'aide) ; en « POV », ça marche. Scène de 20:09:18 à 20:13:52 UTC, venant de C2 (20:08:48). Lecture seule, sans UE. Le journal COMMUN-4 n'est pas lu : il est dans l'archive pendant que le jeu tourne. Diagnostic fait sur les dumps.

Sources :

• Room après B2g/h : CAM-B2g-VAL_LPDumpFunction_20261013-211708.txt ;
• PC : CAM-B1-VAL_LPDumpFunction_20261013-085611.txt ;
• CAM-T2-CART.md § 3.3 ;
• CAM-SPEC.md B1-5 et B1-7 ;
• LPDirectControlSubsystem.cpp (STG, MD5 BAAA3982…), lu sans modification.

1. Comment le jeu déplace les personnages pendant le sexe (prouvé, dump de Room)

Les commandes de caméra arrivent dans Room par 5 événements (option 1 de B2b) :

• CircleCamera (souris) ;
• LeftRight (flèches gauche/droite) ;
• ScrollDownUp (molette) ;
• RotateCamera ;
• DownUp (flèches haut/bas). Chacun commence par une branche « C2 ? » : 96, 97, 98, 99, 100. Le comportement d'origine du jeu est dans la branche else. Par exemple :
• CircleCamera → 96.else → 26 (BuilderOn OU SexOn OU SpaceOn) → 19 (MoveObject, Maj) :
  • vrai → 29 (SexOn) → ForEach SexPersons → SetActorRotation : on tourne les personnages ;
  • faux → SetActorRotation(SceneCamera) : on tourne la caméra de scène.
• LeftRight → 97.else → 9 → 14 (MoveObject) → 27 (SexOn) → ForEach SexPersons → SetActorLocation : on déplace les personnages. Si la branche « C2 ? » est vraie, la commande va à C2 (rotation de contrôle, hauteur, distance), et les personnages ne bougent plus.

2. Cause (prouvée par le code ; la séquence exacte de la vue est à confirmer au journal)

• Les conditions sont les suivantes :
  • 96 et 97 = OR_60 = (vue = CamRoom) OU CamC1On (B2h) ;
  • 98, 99 et 100 = PO_8 = (vue = CamRoom) (B2b, B2d).
• (vue = CamRoom) est vrai pendant le sexe quand la scène part de C2. L'entrée en sexe (GI.Sex) ne change pas la vue (CAM-T2-CART.md § 3.3, aucun SetViewTarget sur ce chemin). La vue reste sur CamRoom jusqu'au premier SwitchCamera. Les branches « C2 ? » sont donc vraies, et Maj + souris ou flèches tournent la caméra C2 au lieu de déplacer les personnages.
• CamC1On vaut vrai pendant toute la scène si elle part de C1. Seul CycleRoomCamera l'écrit (VariableSet_55 et _57). Pendant le sexe, la touche C appelle SwitchCamera et pas le cycle (B1-7, garde SexOn). Depuis B2h, une scène lancée en C1 bloque donc 96 et 97 dans tous les modes, POV compris.
• En POV, la vue est un SexPersons[i] (PC nœud 55, CurrentActor). Elle n'est ni CamRoom ni le cas C1 si la scène vient de C2 : les branches else s'exécutent et le déplacement marche. C'est conforme au constat de l'utilisateur.
• En « Scene » après un passage par POV, le PC revient sur ChargenCameras[0] (nœud 353). La vue n'est alors plus CamRoom, et le déplacement devrait de nouveau marcher. Les phases « Scene » bloquées sont donc au moins la première (20:09:18 → première bascule). Les phases suivantes sont à vérifier sur le journal définitif (lignes Indicateur de camera) et en demandant à l'utilisateur dans quelle phase il a essayé.
• Origine :
  • B2b et B2d pour 98-100 et pour la partie « vue = CamRoom » de 96 et 97 : présente depuis COMMUN-2, mais visible seulement quand une scène de sexe part de C2 ;
  • B2h pour la partie CamC1On (scène partie de C1). Ce n'est pas seulement B2h. B2g n'y est pour rien : MakeArray_5 ne sert qu'aux sondes de ComputeC2Target et de UpdateRoomCam.
• STG écarté :
  • RestoreAnim ne touche que l'animation du joueur, une seule fois (bAnimCaptured) ;
  • la partie C1 de Walk (FirstPersonView) est dans Walk, qui n'est pas appelé pendant le sexe (ScenePlaying = SexOn, l. 759) ;
  • aucun de ces chemins ne touche SexPersons ni les commandes de Room.

3. Correctif proposé : B2i, garde « hors sexe » sur les 5 branches « C2 ? » (Room, lp-mcp-bp)

Il rend le comportement d'origine pendant tout le sexe, sans toucher à la scène : GI, PC et la logique de sexe ne changent pas. Seules les conditions de branchement de Room changent.

• (N) NOT (Math|Booléen|NOTBoolean) : entrée ← GI.SexOn. Le getter existe déjà (VariableGet_86.SexOn, self ← GI) ; sinon en créer un.
• (N) AND n° 1 (Math|Booléen|ANDBoolean) : A ← OR_60.ReturnValue, B ← NOT → sortie vers IfThenElse_96.Condition et IfThenElse_97.Condition. Cela remplace le lien venant de OR_60.
• (N) AND n° 2 : A ← PromotableOperator_8.ReturnValue, B ← NOT → sortie vers IfThenElse_98, _99 et _100.Condition. Cela remplace les liens venant de PO_8.
• PO_8 garde IfThenElse_91 (UpdateRoomCam) et OR_60.A ; OR_60 ne va plus qu'à AND n° 1.
• Au total : 3 nœuds et 10 liens. Pas de garde Accessed None : SexOn est un booléen de GI, et GI est toujours valide.
• Instantané CAM-B2i, Room attendu 0C8EB59F55CB02AD2C4FA1413840B84B. Relecture des 5 conditions et des liens de PO_8, OR_60 et 86 ; is_dirty, compilation stricte, save_assets, MD5. V5 : 1264 nœuds, seules ces différences. V6 = référence.
• Barème : a0 b1 c0 d0 e1 f1 = 3 → N1, ajusté à N3 (MCP) ; S = C3 1 + f 1 = 2 < 3 : une fiche.
• Effet attendu pendant le sexe : souris, flèches, molette et Maj font comme avant CAM. Si la scène est partie de C2 et que la vue reste sur CamRoom jusqu'au premier C, la souris sans Maj tourne SceneCamera, qui n'est pas la vue. Elle ne fait donc rien de visible jusqu'au premier C. Maj + souris et flèches déplacent bien les personnages.
• Effet hors sexe : aucun. NOT SexOn = vrai, donc les conditions sont identiques à B2h.

Point laissé à la décision de Big Boss (non proposé pour l'alpha) : faire démarrer la scène sur ChargenCameras[0] quand elle part de C2, comme avant CAM. Il faudrait un SetViewTarget dans UpdateRoomCam quand SexOn et vue = CamRoom. C'est plus près du comportement d'origine, mais cela change la vue en début de scène. Les scènes étant gelées, je ne le recommande pas sans accord de l'utilisateur.

4. Cas de test (pour COMMUN-5 ou la reprise de COMMUN-4)

N°	Action	Résultat attendu
CAM-29	Depuis C2, lancer une scène de sexe ; sans appuyer sur C, Maj + souris, puis flèches.	Les personnages tournent et se déplacent comme avant.
CAM-30	Depuis C1, lancer une scène de sexe ; Maj + souris en mode Scene puis en POV.	Les personnages tournent et se déplacent dans les deux modes.
CAM-31	Pendant la scène, C plusieurs fois (Scene ↔ POV), puis Maj + souris dans chaque mode.	Déplacement possible dans tous les modes.
CAM-32	Après la scène, en C2 puis en C1 : souris et flèches.	Comme à COMMUN-4 (C2 tourne autour du personnage, C1 tourne la vue).

5. Second KO de COMMUN-4 : la touche C ne change plus de caméra après CharGen (lecture seule)

Journal lu en lecture seule : le jeu a été relancé à 22:28 locale. Le journal de la session est devenu …\COMMUN-4_Development\Windows\LifePlay\Saved\Logs\LifePlay-backup-2026.10.13-20.27.59.log (MD5 4b039fd2…). Le journal actif LifePlay.log est celui de la nouvelle session.

Faits (journal)

• Dernière ligne de l'indicateur : « C1 First person » à 20:20:37. Entrée dans CharGen en C1 : LOAD ROOM chargenroom à 20:23:06, menus=[CharGen_C] de 20:23:07 à 20:23:32.
• Sortie : LOAD ROOM cafe à 20:23:33, puis la suite du jeu (street 20:24:56, community_centre 20:25:00). Plus aucune ligne Indicateur de camera jusqu'à la relance.
• Le clavier arrive au jeu : focus=SViewport presque tout le temps, et la marche fonctionne (accel=2048, speed=200 à 20:25:07-27, menus=[]).
• Aucune Accessed None ni pile d'appels sur les événements CAM (ApplyRoomCamera, CycleRoomCamera, RestoreC1, UpdateRoomCam, PlaceC2, EnsureCamRoom) après 20:23. Le seul avertissement à l'entrée de CharGen (GetSkeletalMesh_ReturnValue) est hors CAM.
• Le joueur reste le même acteur (PlayerCharacter), mais CharGen a changé son genre : fnt_new048-m-0-sit → -f-, et animation Daily_C → Daily_F_C.
• Rien ne trace un appui sur C (le PC ne journalise rien), ni la cible de vue (non relevée par LPDebug).

Ce que le silence de l'indicateur veut dire (prouvé par le code)

L'indicateur n'écrit une ligne que quand le libellé change et n'est pas vide (Tick, l. 150-155). Deux lectures sont possibles :

• (i) le libellé est resté « C1 First person » : vue = joueur et CamC1On vrai ;
• (ii) le libellé est vide : vue non reconnue, aucun texte à l'écran. Dans les deux cas, C n'a jamais conduit CycleRoomCamera jusqu'à un changement de vue. Un seul passage C1 → C2 aurait posé CamRoom (ApplyRoomCamera → PlaceC2 → SetViewTargetWithBlend(CamRoom)) et écrit « C2 Follow ».

Hypothèses, par ordre de vraisemblance

• H4 (en tête) : les actions d'entrée du PC ne se déclenchent plus après CharGen, alors que les touches brutes arrivent.
  • La marche ne le contredit pas : LPDirectControlSubsystem::AxisValue lit l'état brut des touches (PC->PlayerInput->IsPressed, l. 1-20 de la fonction), sans passer par l'InputComponent du PC.
  • La touche C, elle, passe par l'action SwitchCamera du PC (InpActEvt_SwitchCamera).
  • Un DisableInput, un mode d'entrée laissé par CharGen (SetInputMode_GameAndUIEx à l'ouverture, VariableSet_296), ou une pile d'entrées modifiée couperaient C sans couper la marche.
  • H4 explique tout : le libellé reste « C1 », LOAD ROOM street et community_centre remettent C1 (aucun changement, donc aucune ligne), et C n'a aucun effet.
  • La souris (CircleCamera, via le PC et Birdview) devrait alors être coupée elle aussi : c'est une question à poser à l'utilisateur.
• H1, garde de la touche C dans le PC (B1-7) :
  • chaîne : InputAction SwitchCamera → IfThenElse_65 (GI.BuilderOn) → PlayClick → IfThenElse_23 (SexOn) → Branche(GI.SpaceOn) → Room.CycleRoomCamera (cible GI.Room) ;
  • après CharGen, sexOn=0 est relevé ; SpaceOn est mis à vrai par CreateCharGenWidget (GI VariableSet_296), et à faux seulement par CloseSpace et le chemin VariableSet_233 ;
  • BuilderOn n'est écrit ni par GI (dump L6f, 378 graphes : 0 écriture) ni par CharGen (widget non dumpé), mais par Room (VariableSet_2, _12) et par le constructeur ;
  • non tranché : un SpaceOn faux ou un BuilderOn vrai laissé par CharGen bloquerait C sans aucune trace.
• H2, vue posée par CharGen hors des caméras connues, puis jamais reprise :
  • CharGen montre le joueur avec sa propre caméra ;
  • si, à la sortie, la vue reste sur une caméra qui n'est ni dans ChargenCameras, ni CamRoom, ni SceneCamera, le libellé est vide (cas ii) ;
  • mais C devrait tout de même appeler CycleRoomCamera, et donc changer la vue : H2 seule n'explique pas que C reste sans effet. Elle va avec H1.
• H3, état C1 laissé incohérent : C1Hidden vrai alors que la tête et les cheveux ont été recréés par le changement de genre.
  • ApplyRoomCamera en C1 avec C1Hidden vrai ne fait que SetViewTarget(joueur) (nœud 434), sans rattacher FirstPersonSM (430-433).
  • La vue C1 pourrait donc être fausse. Mais C ferait quand même passer en C2 : comme H2, H3 seule n'explique pas le KO.
• Lien avec B2h : aucun. B2h ne touche que les conditions de 96 et 97 (souris, flèches). La touche C passe par le PC et CycleRoomCamera, que B2h ne lit pas. B2g : aucun lien non plus (sondes de C2).

Ce qu'il faut pour trancher

1. Questions à l'utilisateur :
   • après CharGen, que montrait le bas gauche de l'écran : « Camera: C1 First person », un autre texte, ou rien ? Cela sépare (i) et (ii) ;
   • la souris tournait-elle encore la vue ? Les autres touches du jeu (menus, Échap, E) marchaient-elles ? Si non, c'est H4.
2. Témoin C++ « touche C » (LPCameraModeSubsystem.cpp, sans Blueprint, à passer avec B2i) :
   • à chaque appui sur une touche de l'action SwitchCamera (lecture des ActionMappings d'UInputSettings, front montant de PlayerInput->IsPressed, vérifié à chaque image), une ligne : Touche C : BuilderOn=… SpaceOn=… SexOn=… CamC1On=… CamC3On=… C1Hidden=… entree PC=<InputEnabled> regard ignore=<IsLookInputIgnored> viewport ignore=<IgnoreInput> vue=<nom> (<classe>) Room=<nom> PC=<nom> ;
   • quand le libellé devient vide hors menu, une ligne Indicateur de camera : aucun (vue <nom>, classe <classe>), une fois par changement de vue. Au prochain essai, un seul passage par CharGen en C1 suivi d'un appui sur C désigne la garde ou l'état fautif. Le correctif viendra ensuite (Room ou PC, ou un passage ApplyRoomCamera au retour de CharGen), en DIAG séparé.
   • Une touche brute vue par le témoin sans aucun changement de vue après, avec entree PC=0 ou un drapeau bloquant, tranche entre H4 et H1.
   • Barème : a0 b0 c0 d0 e1 f0 = 1 → N1 ; S = 0 (code exact écrit à la fiche).
3. Contournement pour l'utilisateur, à vérifier : sortir de la pièce (vue de la ville) puis rentrer. LoadRoom → ApplyRoomCamera reprend alors la vue selon le mode choisi. À confirmer : la sortie de 20:24:56 (LOAD ROOM street) n'a rien changé non plus. C'est cohérent avec H4 (le libellé reste C1 et C est coupé) et va contre un simple état de vue (H2).

Complément du 2026-10-13, passage UE de B2i (jeton CAM)

• Dump du widget CharGen : CAM-C4D-DIAG_LPDumpFunction_20261013-225931.txt (-BP=CharGen -Fn=* -Pins -Exec, code 0, 33 graphes).
  • Aucun appel touchant aux entrées, au focus d'entrée, à la vue ou au PC : ni SetInputMode, ni Enable/DisableInput, ni SetIgnore*Input, ni SetViewTarget, ni Possess, ni OpenSpace/CloseSpace, ni LoadRoom ou événement de caméra de Room.
  • Les 4 GetPlayerController ne servent qu'à l'OwningPlayer de 4 CreateWidget.
  • Il appelle GI.PlayerChangeGender. Celui-ci refait le maillage, les morphs, la pilosité et les cheveux (UpdatePlayerMeshWithMorphs, UpdateDefaultHair), sans rien sur les entrées ni la vue.
• Conséquence :
  • H4 n'a pas sa cause dans CharGen lui-même. Si les actions du PC sont coupées, c'est ailleurs, au retour en jeu, côté GI ou PC : chemin non dumpé de la page finale, ou Cursor.ResetAndCheckMouseForUI appelé par ClearCharGenWidget ;
  • H1 (SpaceOn) reste possible ;
  • aucun correctif ne peut être prouvé dans Room aujourd'hui. Aucun changement de Room n'est fait pour ce KO.
• Fait nouveau de Big Boss : à la relance du jeu, C refonctionne. Il s'agit donc d'un état d'exécution laissé par le passage dans CharGen, et non d'un asset abîmé.
• Suite proposée, inchangée : témoin C++ « touche C » (§ 5, point 2), plus les questions à l'utilisateur. Le correctif viendra après un essai qui passe par CharGen en C1.