198 lines
15 KiB
Markdown
198 lines
15 KiB
Markdown
# 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.
|