LifePlay-Revival/Docs/Migration/etat/ST/STD/STD-GIX-DIAG.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

18 KiB
Raw Blame History

Fiche STD-GIX — Niveau N3 — Modèle prévu (modèle de l'agent lp-cart) | utilisé claude-opus-5-5 — Agent lp-cart — Skills sk-protocol, ue-cpp-build, lp-commandlets, lp-paths

STD-GIX-DIAG : GI, causes des familles « Accessed None » R06, R07, R08, R10 (2026-10-10)

Hors gabarit partiel : la fiche demande quatre familles ; une sous-section DIAG 1-5 par famille (même forme que STA-T2b-GIUBER), précédée de constats communs (§ 0), puis tableau de synthèse, dumps manquants et compte rendu. Lecture seule stricte : rien écrit ni lancé dans D:\Game\LifePlay-master 5.8 (copie gelée par STC) ; seul fichier écrit : ce livrable.

Abréviations (chemins complets) :

  • JEU2 = D:\Game\LifePlay_Build_5.8_STB-JEU2_Development\Windows\LifePlay\Saved\Logs\LifePlay.log
  • JEU = D:\Game\LifePlay_Build_5.8_STB-JEU_Development\Windows\LifePlay\Saved\Logs\LifePlay-backup-2026.10.09-20.30.49.log
  • R427 = D:\Game\LifePlay_Build_427_Dev\WindowsNoEditor\LifePlay\Saved\Logs\LifePlay.log (build 4.27 d'origine)
  • R55 = D:\Game\LifePlay-master 5.5\Docs\Migration\etat\U58\U7\P10\5.5\LifePlay.log ; DC4 = ...\etat\U58\U6\LifePlay_55_DC4_avantU6.log
  • EGB = ...\etat\ST\STB\dumps\GI__EventGraph.txt (après STB, nomme les événements) ; EGA = ...\etat\ST\STA\dumps\GI__EventGraph.txt
  • GIF = ...\etat\portage55\L6f\L6f_dump_GI.txt (dump complet de GI, copie 5.5, 2026-09-30)
  • U5A = D:\Game\LifePlay-master 5.8\Saved\Logs\portage\U5_assets_apres.txt (LPDumpAssets du lot U5, copie 5.8)
  • B07 = D:\Game\LifePlay-master 5.5\Saved\Logs\portage\L4-CX-B07_assets_avant.txt (même dump, copie 5.5 avant resave)
  • MAP = D:\Game\LifePlay-master 5.5\Saved\Logs\portage\L7j_map_apres.txt (carte CentralLondon et son Level Blueprint après L7j)
  • SCC = D:\Game\Launcher\Engine\UE_5.8\Engine\Source\Runtime\Engine\Private\Components\SceneCaptureComponent.cpp
  • SCORE = D:\Game\Launcher\Engine\UE_5.8\Engine\Source\Runtime\CoreUObject\Private\UObject\ScriptCore.cpp

0. Constats communs

# Constat Niveau Preuve
0.1 Le message nomme la variable contexte dont la valeur est None (Stack.MostRecentProperty). Si SceneCapture ou Wall étaient None, le message porterait leur nom ; JEU2 n'en contient aucun, ni le temporaire sans suffixe. établi SCORE:3163-3218 ; Grep JEU2 GetRootComponent_ReturnValue in|property (SceneCapture|Wall) in → 0 (motif de même forme que property TintUI in, qui trouve 29)
0.2 Les trois familles TintUI, _1, _2 existent déjà dans la build 4.27 d'origine et en 5.5 ; Companion existe en 5.5. Ce ne sont pas des régressions de la migration. Piège : en 4.27 / 5.5 le message s'écrit « Accessed None trying to read property X » (sans « (real) … in ») ; un Grep avec in les manque. établi R427:8472 (TintUI, HideUI), 8485 (_1, HideRender), 8609 / 8620 (TintUI, _2) ; R55:8299, 8312, 8445, 8456 ; DC4:7377, 7390, 7523, 8518 (Companion, fonction non vérifiée)
0.3 EGB nomme les événements : HideUI = CustomEvent_188, ShowUI = CustomEvent_212, HideRender = CustomEvent_471, ShowRender = CustomEvent_519, SceneStart = CustomEvent_1 (confirme les rattachements estimés de GIUBER). Les noms des nœuds utilisés ici sont identiques entre EGA et EGB. établi EGB:845, 848, 891, 895, 5978 ; EGA:735 / EGB:854 (CF_2310), EGA:767 / EGB:886 (CF_939), EGA:782 / EGB:901 (CF_5578), EGA:794 / EGB:913 (CF_3014), EGA:24993 / EGB:25112 (CF_472)
0.4 GIF couvre tout GI (378 en-têtes de graphe) : aucun VariableSet de TintUI, SceneCapture, Wall, TopRight ; seulement 2 de Companion. Ces quatre variables sont écrites hors de GI. Idem EGB. établi (copie 5.5, 2026-09-30) ; estimé pour la copie 5.8 (EGB concorde) Grep GIF ^=== → 378 ; Grep GIF VariableSet_\d+\s+variable '(TintUI|SceneCapture|Wall|TopRight|Companion)' → 2 (GIF:55847, 69080, Companion) ; même Grep sur EGB → 2 (EGB:7509, 24064)

R06. TintUI in GI_C (HideUI, ShowUI)

1. Symptôme et reproduction

JEU2 : 29 avertissements (Grep property TintUI in → 30 lignes = 29 + la ligne de synthèse JEU2:30945) ; chaque pile se termine par HideUI ou ShowUI (Grep GI_C:(HideUI|ShowUI)\r?$ → 29). Exemples : JEU2:1332-1343 (MainMenu NewGame → CharGenInput → OpenCharGen → HideUI), JEU2:1415-1424 (CloseCharGen → ShowUI), JEU2:1554-1563 (CloseInventory → ShowUI). JEU : 22. Même pile en 4.27 : R427:8472-8483.

2. Hypothèse testée

GI.TintUI n'est jamais affecté : sa seule écriture (dans PC) est sur une chaîne d'exécution débranchée.

3. Essai et résultat brut

  • Lecteurs dans GI : VariableGet_1375 → CF_2310 Widget::SetVisibility(Hidden) (corps de HideUI) ; VariableGet_2515 → CF_939 SetVisibility(HitTestInvisible) (corps de ShowUI) (EGB:854-858, 877-878, 883-890). Écriture dans GI : 0 (0.4).
  • Recherche du nom dans les assets binaires (Grep TintUI fichier par fichier) : présent dans Content\BPs\GI.uasset et Content\BPs\PC.uasset ; absent de UI\TopRight, UI\MainMenu, UI\ScreenTint, BPs\GM, Scenes\CentralLondon.umap (7 assets lus, balayage non exhaustif). PC.uasset importe /Game/UI/ScreenTint et /Game/BPs/GI.
  • U5A (16 lignes TintUI) : seule écriture = PC:EventGraph.K2Node_VariableSet_1 (MemberParent=GI_C, MemberName=TintUI), entrée TintUI ← K2Node_CreateWidget_0.ReturnValue, broche execute vide, then → VariableSet_8 (U5A:570231-570241) ; copie compilée identique dans ExecuteUbergraph_PC (U5A:587738-587748).
  • PC:EventGraph.K2Node_CreateWidget_0 : Class = /Game/UI/ScreenTint.ScreenTint_C, execute vide, then → CF_202 UserWidget::AddToViewport (U5A:564360-564368, 560073-560081). CF_202.then → CreateWidget_4 (TopRight_C), qui reçoit aussi CF_2.then (chemin vivant) (U5A:564432-564439). VariableSet_8 (GI.Cursor) reçoit aussi CF_24.then (U5A:570953-570964).
  • Même état avant la migration : CreateWidget_0.execute vide dans B07:560835-560843 ; avertissements déjà en 4.27 (0.2).

4. Verdict

Confirmée. Mécanisme établi : dans PC.EventGraph, la création du widget ScreenTint et l'affectation GI.TintUI ont été contournées (le chemin vivant CF_2 → CreateWidget_4 saute CreateWidget_0 → CF_202, et VariableSet_1 n'a pas d'entrée d'exécution). TintUI vaut donc None pendant toute la partie (29 / 29 HideUI-ShowUI observés), ce n'est pas un problème d'ordre. Défaut d'affectation d'origine (état identique en 4.27) : le joueur n'a jamais vu ce widget.

Correctif proposé (le choix A / B revient à l'utilisateur) :

  • A, recommandé (garde justifiée, aucun effet visible) : dans GI, Branch(IsValid(VariableGet_1375)) avant CF_2310, faux → VariableSet_1341.execute ; Branch(IsValid(VariableGet_2515)) avant CF_939, faux → CF_760.execute. Variante A' : retirer CF_2310 et CF_939 (CF_5895.then → VariableSet_1341.execute, CF_333.then → CF_760.execute). Effet : 0 avertissement TintUI, comportement inchangé (les deux SetVisibility ne s'exécutaient jamais).
  • B (restaurer la teinte d'écran, effet visible) : rebrancher dans PC CreateWidget_0 sur le chemin vivant et exécuter VariableSet_1 (position exacte à lire dans le dump PC, § Dumps manquants). Effet : un widget plein écran ScreenTint est ajouté au viewport ; ScreenTint.uasset importe /Game/BPs/GI et GI écrit ScreenTint / ScreenTintAlpha (EGB:253-330) : rendu jamais vu depuis 4.27, essai en jeu obligatoire.

5. Hypothèse suivante

Sans objet pour la cause. Pour B seulement : lire le dump PC (D-1) pour retrouver le branchement d'origine, N3.

R07 et R08. CallFunc_K2_GetRootComponent_ReturnValue_1 (HideRender) et _2 (ShowRender)

Traitées ensemble (STA-T2c F.5 : même mécanisme, même lot).

1. Symptôme et reproduction

JEU2 : _1 × 3 — JEU2:1345 (OpenCharGen → HideRender), 1455 (CloseCharGen → InventoryInput → OpenInventory → HideRender), 1680 (TopRight PortraitButton → OpenSpace → HideRender) ; _2 × 2 — JEU2:1426 (CloseCharGen → ShowRender), 1565 (CloseInventory → ShowRender). JEU : _1 4, _2 3. 4.27 : R427:8485-8496 (_1), 8620 (_2). 5.5 : R55:8312, 8456.

2. Hypothèse testée

GI.SceneCapture désigne l'acteur FaceCapture de CentralLondon, dont RootComponent est None dans la carte depuis 4.27 (même défaut qu'ERR-031 sur SecondScreen, que L7j n'a corrigé que pour SecondScreen).

3. Essai et résultat brut

  • Écriture : Level Blueprint de CentralLondon, K2Node_VariableSet_5 (MemberParent=GI_C, MemberName=SceneCapture, self = GI) ← K2Node_Literal_15 = PersistentLevel.FaceCapture (MAP:852-857, 1056-1066) ; Wall : Literal_0 → VariableSet_2.Wall (MAP:834-839).
  • État des acteurs (MAP) : FaceCapture [SceneCapture2D] RootComponent = None, SceneComponent présent, capture vers /Game/Render/FaceRT (MAP:1722-1737) ; SecondScreen RootComponent = SceneComponent après L7j (MAP:2421-2424) ; Wall [StaticMeshActor] RootComponent = StaticMeshComponent0 (MAP:2612-2614). Même RootComponent = None pour FaceCapture dans la carte 5.5 avant L7j et dans la carte 4.27 (...\etat\portage55\L6f\L6f_components_CentralLondon_SceneCapture.txt:2,68 ; ...\L6f_components_CentralLondon427_SceneCapture.txt:2). L7j : « 3 lignes modifiées, toutes sur SecondScreen » (D:\Game\LifePlay-master 5.5\Docs\Migration\Journal_Modifications.md:957-960).
  • Moteur : le constructeur ASceneCapture pose RootComponent = SceneComponent (SCC:81-86) ; le None vient de l'instance sérialisée dans la carte (donnée).
  • Copie 5.8 : la carte contient L7j (af1861b) puis le resave U5 (809102a) (git log --oneline -5 -- Content/Scenes/CentralLondon.umap).
  • Attribution des temporaires (élimination) : HideRender CE_471 ; ShowRender CE_519 → CF_3014 directement (EGB:891-897). CF_5578 (false) vise VG_1912.StaticMeshComponent + VG_3100.RootComponent (self SceneCapture) (EGB:901-906, 937-942) ; CF_3014 (true) vise VG_1811.StaticMeshComponent + VG_3097.RootComponent (self Wall) + VG_3103.RootComponent (self SceneCapture) (EGB:913-918, 931-948). Chaque ShowRender ne produit qu'un message (_2) ; si _1 était un temporaire de CF_3014, il apparaîtrait aussi dans ShowRender : _1 = VG_3100 (CF_5578). Dans ShowRender, la racine de Wall est valide et SceneCapture est le même FaceCapture sans racine : _2 = VG_3103 ; le temporaire sans suffixe (VG_3097) n'apparaît jamais (0.1).
  • Effet en jeu : une capture 2D ne capture que si le composant est visible (SCC:814, 826) ; HideRender devait suspendre FaceCapture pendant les menus, il n'agit pas. FaceRT sert au portrait de TopRight (TopRight.uasset importe /Game/Render/FaceMaterialSquircle) ; CharGen.uasset n'importe rien de /Game/Render.

4. Verdict

Confirmée. R07 établi ; R08 établi par élimination sur les données de la carte 5.5 après L7j ; état de la carte 5.8 estimé identique (resave U5 sans modification de contenu ; dump D-2 pour l'établir). Cause : défaut d'affectation de données, l'acteur FaceCapture n'a pas de composant racine depuis 4.27 ; ce n'est pas un None normal. Conséquence actuelle : FaceCapture capture à chaque image même menus ouverts (coût GPU, estimé), comme en 4.27.

Correctif proposé (choix utilisateur) :

  • A, données (corrige la cause) : donner à FaceCapture sa racine = son SceneComponent existant, rattacher NewSceneCaptureComponent2D sans déplacement (transformation monde conservée). LPFixSceneCapture est retiré de ue5.8 (U2) et impose une transformation -From/-Offset : variante sans déplacement ou retouche manuelle à spécifier. Effet : 0 message R07 / R08 ; HideRender suspend réellement la capture, ShowRender la reprend. Risque à vérifier en jeu : OpenSpace appelle HideRender sans HideUI (JEU2:1679-1689), le portrait de TopRight resterait figé pendant cet écran.
  • B, Blueprint (garde, aucun effet visible) : séparer les cibles multiples de CF_5578 et CF_3014 ; placer les cibles VG_3100.RootComponent et VG_3103.RootComponent derrière Branch(IsValid(<sortie du getter>)) (tester la sortie du getter, pas SceneCapture : nœud pur évalué en entier) ; cibles StaticMeshComponent et Wall.RootComponent inchangées. Effet : 0 message, comportement identique à 4.27 (capture toujours active).

5. Hypothèse suivante

Sans objet pour la cause. Établir l'état 5.8 par le dump D-2 après le gel ; en VAL (A ou B) : rejouer nouvelle partie → création → inventaire → portrait, attendu 0 GetRootComponent_ReturnValue ; pour A, contrôler le portrait de TopRight.

R10. Companion in GI_C (SceneStart)

1. Symptôme et reproduction

JEU2 : 8 avertissements (JEU2:2193, 3291, 4396, 6440, 8606, 11333, 14019, 15239), tous de pile UpdateCheckForScenes → PlayScene → ReadSceneLine → CallFunction → SceneStart (JEU2:2193-2205), chacun suivi dans la même image du TintUI de SceneStart → HideUI (ex. JEU2:2207). Grep JEU2 GI_C:SceneStart\r?$ → 16 = 8 Companion + 8 TintUI. JEU : 5 et U8 : 4 (motif property Companion in /Game/BPs/GI.GI_C, commun à SceneStart et clearScenePersons, non séparé).

2. Hypothèse testée

Au début de SceneStart, Person_C::ClearAllExpressions() est appelé sur PlayerCharacter et Companion (cible multiple) sans garde ; Companion est None quand le joueur n'a pas de compagnon.

3. Essai et résultat brut

SceneStart = CustomEvent_1 → CallArrayFunction_80 Array_Clear(LastHiddenFromScene) → VariableSet_272 ProperScene = true → CF_472 Person_C::ClearAllExpressions(), self = VG_95.PlayerCharacter + VG_96.Companion, execute ← CF_664.then, VariableSet_272.then, then → MacroInstance_21.exec (EGB:5978-5980, 25383-25387, 25339-25342, 25109-25118 ; mêmes noms EGA:24993-24997). Aucun branchement sur ce chemin : CF_472 s'exécute à chaque SceneStart. Un seul message par SceneStart : aucune autre lecture non gardée de Companion n'a fauté dans ces parties. Companion n'est écrit qu'en deux points (EGB:7509, 24064) ; clearScenePersons le protège déjà par IsValid (GIUBER K7, CSP:166-181).

4. Verdict

Confirmée (nœud établi, mécanisme établi). None = état normal (pas de compagnon) : garde justifiée. Correctif : séparer CF_472 en PlayerCharacter.ClearAllExpressions() puis Branch(IsValid(Companion)) → Companion.ClearAllExpressions() ; les deux sorties rejoignent MacroInstance_21.exec ; conserver les deux entrées (CF_664.then, VariableSet_272.then). Effet : 0 message R10, comportement inchangé (la VM sautait déjà l'appel sur la cible None, SCORE:3181-3239).

5. Hypothèse suivante

Sans objet. VAL : début de scène sans compagnon → 0 property Companion in de pile SceneStart.

Constats

Tableau de synthèse

Famille JEU2 / JEU Nœud fautif (preuve) Cause Verdict Correctif proposé Effet
R06 TintUI 29 / 22 VG_1375 → CF_2310, VG_2515 → CF_939 (EGB:854, 886) ; écriture PC.VariableSet_1 sans entrée d'exécution (U5A:570231-570241) défaut d'affectation d'origine (création ScreenTint contournée dans PC, 4.27) confirmée A : IsValid avant 2310 / 939 (ou retrait) ; B : rebrancher PC A : aucun ; B : widget plein écran nouveau
R07 _1 3 / 4 VG_3100 → CF_5578 (EGB:901-906, 937-942), par élimination FaceCapture sans RootComponent (MAP:1722-1725) confirmée A : racine dans la carte ; B : IsValid sur la cible racine A : capture suspendue en menu ; B : aucun
R08 _2 2 / 3 VG_3103 → CF_3014 (EGB:913-918, 943-948), par élimination (Wall valide, MAP:2612-2614) idem R07 confirmée avec R07 idem R07
R10 Companion 8 / 5 (mixte) CF_472 ClearAllExpressions, cible VG_96.Companion (EGB:25112-25117) None normal, cible multiple sans garde confirmée séparer CF_472, Companion derrière IsValid aucun

Dumps manquants (à produire après le gel, non produits)

  • D-1 (R06, option B seulement) : dump requis : -BP=PC -Fn=EventGraph (LPDumpFunction -BP=PC -Fn=EventGraph -Pins -Exec). La cause est établie sans lui (U5A).
  • D-2 (R07, R08, état 5.8) : LPDumpComponents -Map=/Game/Scenes/CentralLondon -Filter=SceneCapture sur la copie 5.8 ; attendu FaceCapture RootComponent = None, SecondScreen RootComponent = SceneComponent.
  • R10 : aucun.

Points à confirmer et questions

  • Q1 (utilisateur) : R06, garde A (recommandée) ou restauration B de la teinte d'écran jamais affichée depuis 4.27 ?
  • Q2 (utilisateur) : R07 / R08, correction de la carte A (cause, change le comportement de la capture) ou garde B ?
  • P1 : balayage binaire de TintUI limité à 7 assets ; U5A (dump d'assets du lot U5, couverture exacte non vérifiée) ne montre aucune autre écriture.
  • P2 : effet visuel de la teinte (GI.ScreenTint / ScreenTintAlpha) non étudié ; utile seulement si B est choisi.

Compte rendu (sk-protocol § 3)

[sk-protocol] — skills présents dans le contexte : sk-protocol, ue-cpp-build, lp-commandlets, lp-paths ; gabarit lu dans D:\Game\LifePlay-Sandbox\Tools\claude\skills\lp-doc\gabarits.md (skill lp-doc non invoqué).

  1. Résultat : réussi ; 4 familles sur 4 confirmées avec nœud et cause ; R06 et R07 / R08 = défauts d'affectation d'origine (4.27), R10 = None normal, garde justifiée.
  2. Preuves : U5A:564360-570241 (PC, TintUI) ; MAP:852-857, 1056-1066, 1722-1725, 2612-2614 (FaceCapture) ; EGB:891-948, 25109-25118, 25339-25387 ; SCC:81-86, 814, 826 ; SCORE:3163-3239 ; R427:8472-8496.
  3. Chiffres (Grep, output_mode=count) : JEU2 property TintUI in 30 lignes (29 + synthèse), GI_C:(HideUI|ShowUI)\r?$ 29, _1 3, _2 2, property Companion in 8, GI_C:SceneStart\r?$ 16 ; JEU TintUI 22, _1 4, _2 3, Companion 5 ; GIF ^=== 378.
  4. Incertitudes : état 5.8 de la carte estimé (D-2) ; couverture de U5A ; effets visuels de A (portrait figé pendant OpenSpace) et de B (R06) non essayés.
  5. Écarts : sortie en DIAG multiple (fiche) ; lp-doc non invoqué ; budget ≈ 66 appels d'outils pour ≈ 60 tours. Fichier écrit : D:\Game\LifePlay-master 5.5\Docs\Migration\etat\ST\STD\STD-GIX-DIAG.md.
  6. Handoff : Suite : l'orchestrateur doit faire trancher Q1-Q2 par l'utilisateur et inscrire R10 (et l'option retenue pour R06, R07-R08) dans la SPEC IMPL-GI-C, état : causes établies, D-1 / D-2 à produire après le gel de STC.