Passer du corps A au corps B donnait une silhouette feminine peinte avec la
peau et les abdominaux du modele masculin.
OverrideMaterials appartient au COMPOSANT et pas au mesh : SetSkeletalMeshAsset
remplace l'asset sans y toucher, donc le MID derive de MI_BodyA_a restait colle
a l'element 0. Le symptome trompe, parce que le mesh, lui, avait bien change --
seule sa peau ne suivait pas.
SetPartMesh() vide les overrides avant d'assigner, et rend la main sans rien
faire quand le mesh est deja le bon : un changement de couleur seul continue
ainsi de reutiliser les MID en place au lieu de tout reconstruire.
Vaut pour toutes les pieces, pas seulement le corps -- changer de tete ou de
coiffure donnait le meme symptome.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Lot 3 : l'apparence survit desormais au respawn, au changement de map et au
relancement du jeu, et les trois autres joueurs la voient.
Elle vit sur ASurvivalPlayerState et pas sur le pawn : c'est le JOUEUR
qu'elle decrit, pas le corps. Le pawn meurt et reapparait, le PlayerState
non -- reapparaitre avec le visage de quelqu'un d'autre n'aurait aucun sens,
alors que perdre son inventaire au sol est la regle du jeu.
SubmitCharacterAppearance() sur AFpsPlayerController est le point d'entree
UNIQUE : il persiste ET annonce au serveur, jamais l'un sans l'autre.
Persister sans annoncer laisserait le joueur seul a se voir change, annoncer
sans persister le ferait repartir au visage par defaut au lancement suivant.
C'est par la que passent les commandes console, et par la que passera
l'ecran du lot 4.
La course pawn / PlayerState est resolue des DEUX cotes. Chez un client ils
arrivent par deux chemins de replication independants et rien ne dit lequel
gagne : OnRep_CharacterAppearance monte le personnage si le pawn est deja la,
AFpsPlayer::OnRep_PlayerState va chercher l'apparence si c'est l'inverse. Les
deux appellent la meme fonction idempotente. Chez l'hote aucun OnRep ne se
declenche, d'ou l'appel local dans SetCharacterAppearance -- sans lui, l'hote
serait le seul a ne pas voir son propre personnage.
Rien n'est valide cote PlayerState, deliberement : borner un index demande le
catalogue, que seul UCharacterAppearanceComponent connait, et celui-ci passe
deja tout ce qu'il monte par Catalog->Sanitize() sur chaque machine.
Piege de test note dans CLAUDE.md : en PIE a deux joueurs, les deux fenetres
lisent le meme .ini, donc les deux personnages demarrent identiques.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Lot 2 du chantier : le corps du lot precedent devient assemblable. Tete,
coiffure, sourcils, barbe et moustache sont montes en leader pose sur le
mesh du Character, et les couleurs sont posees sur des MID.
FCharacterAppearance tient en 11 octets : des INDEX et jamais des chemins
d'assets. Un chemin couterait une chaine a chaque replication, alors qu'un
index tient dans un octet et se VALIDE contre le catalogue -- un client ne
peut donc pas demander un asset arbitraire.
Le corps se monte depuis une LISTE de meshes meme si elle n'a qu'une case.
Le pack livre exprès SKM_BodyA_torso, _arms, _legs_01/02/03 pour qu'une
armure puisse eteindre les segments qu'elle recouvre : le jour venu la case
0 devient SKM_BodyA_empty et les huit segments suivent, sans que ce code
change. Un pointeur unique imposerait de tout reprendre au premier plastron.
Trois pieges rencontres, aucun visible depuis le code :
- Les UFUNCTION(Exec) d'un UActorComponent ne sont JAMAIS appelees. La
chaine de routage (UPlayer::Exec) interroge le monde, le PlayerInput, le
controller, le pawn, le HUD, le GameMode, le CheatManager, le GameState et
le camera manager -- jamais les composants, AActor ne surchargeant pas
ProcessConsoleExec. Et rien ne proteste. D'ou EmberPart / EmberColor /
EmberAppearanceDump posees sur AFpsPlayer, qui delegue.
- L'ordre des slots de materiau varie d'un mesh a l'autre : sur
SKM_HeadA_01 l'Element 0 est celui des YEUX et le 1 celui de la peau. Les
six tetes venant de deux packs, on cherche le slot par son NOM et on ne
pose rien si aucun ne correspond -- ecraser le slot de la peau repeint le
visage entier de la couleur des yeux.
- Un nom de parametre materiau se lit dans le Material INSTANCE, pas dans
les chaines du master : M_Head_Base contient « Skin Base color » mais le
parametre expose s'appelle « Skin ». D'ou des UPROPERTY de catalogue
plutot que des constantes, pour corriger sans recompiler.
Body B reste a remplir dans DA_CharacterParts, avec son ABP_PlayerBody_B et
sans barbes ni moustaches -- le pack n'en livre pas, et une liste vide se
comporte deja comme NoPart.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
SoStylized, CustomizationPack01, StylizedCharacters, StylizedFood_JC,
Vefects et Wooden_Chest quittent la racine de Content pour Content/External.
Le but est de rendre visible d'un coup d'oeil ce qui nous appartient et ce
qui vient d'un pack : un asset de External ne se modifie pas, une mise a
jour du pack l'ecraserait. C'est ce qui a decide du deplacement des
animations retargetees vers Game/Animation/ThirdPerson au commit precedent
-- elles vivaient dans un dossier Demo_Levels qu'on voudra supprimer.
Deplacement pur : LFS retrouve les memes hashes, rien n'est reuploade.
Les .uasset modifies ne le sont que par la mise a jour de leurs references.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Le pawn n'avait aucun mesh 3e personne : en coop, les autres joueurs
voyaient un pseudo flotter au-dessus du vide. C'est aussi le prerequis de
la customisation de personnage, qu'on ne peut pas empiler sur un corps
inexistant.
UPlayerBodyAnimInstance publie l'etat du pawn pour ABP_PlayerBody_A, sur
le meme partage des roles que UFpsArmsAnimInstance : le C++ lit et
republie, le Blueprint choisit l'animation. Rien n'est replique -- tout
derive d'un etat que le moteur ou le projet synchronisent deja (Velocity,
bIsCrouched, bIsSprinting, RemoteViewPitch).
VerticalSpeed distingue le SAUT de la CHUTE : bIsFalling vaut vrai dans
les deux cas, le moteur appelant "falling" tout ce qui n'est pas au sol.
Sans son signe, sortir d'une falaise jouerait l'animation de detente.
Le Cast du pawn est relance dans NativeUpdateAnimation : chez un client
le mesh arrive par replication et peut s'animer avant que le pawn soit
la, ce qui figerait le corps de l'ami en pose de reference pour toute la
partie -- invisible en solo comme chez l'hote.
Dev_Scene rejoint MapsToCook : GameLevel peut pointer sur elle le temps
d'un test, et une reference soft n'est pas suivie par le cooker.
Limites connues : pas d'animation accroupie (absente du pack) et le
BlendSpace s'arrete a 500 alors que le sprint est a 650.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Coffres : AStorageContainer, un UInventoryComponent configure en conteneur,
affiche comme panneau de WBP_InventoryScreen plutot que dans un ecran a lui.
Deplacement unifie par UInventoryComponent::TransferSlot / TransferAllTo.
Panneau de detail : UItemDetailsWidget, pose DANS WBP_Inventory a droite de la
grille. Icone, nom, separation, description, barre d'usure. Il recoit un couple
(inventaire, index) et s'abonne a OnInventoryChanged, donc une charge consommee
sous le curseur se voit.
Une case ne connait plus sa grille : elle diffuse OnHoverChanged. La barre
rapide s'y abonne aussi et relaie par le PlayerController, seul a posseder a la
fois le HUD et l'ecran. Le panneau efface la case qu'on QUITTE et non lui-meme,
sinon passer de la barre a la grille viderait ce qui vient d'etre affiche.
L'ecran allume et eteint le panneau (SetItemDetailsEnabled) : WBP_Inventory
etant instancie deux fois en mode coffre, une case a cocher par instance serait
un bug qui attend qu'on oublie de la decocher.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Boucle de jeu complète : récolte, inventaire, consommation, stats de survie,
mort et respawn. Gameplay en C++, Blueprints réservés au câblage d'assets.
Assets binaires (.uasset, .umap, textures, audio) suivis via Git LFS.
Binaries/, Intermediate/, Saved/ et DerivedDataCache/ sont ignorés :
régénérés au build, ils pèsent 3 Go pour 1,3 Go de contenu utile.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Mathew