# 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.