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