(Feat) Customisation -- replication et persistance

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>

Source/Survival_projet/Public/FpsPlayerController.h

@@ -6,6 +6,7 @@
 // ESlateVisibility n'est que declare en avant par le moteur : il faut le type
 // complet pour en stocker une valeur par defaut. Meme raison pour
 // ECraftingStation, stocke en membre.
+#include "CharacterAppearanceTypes.h"
 #include "Components/SlateWrapperTypes.h"
 #include "CraftingRecipeDataAsset.h"
 #include "GameFramework/PlayerController.h"
@@ -115,6 +116,19 @@ public:
 	UFUNCTION(BlueprintCallable, Category = "Coop")
 	void ShowInviteFriends();
 
+	/**
+	 * Le point d'entree unique d'un changement d'apparence : persiste dans les
+	 * reglages du joueur ET l'annonce au serveur.
+	 *
+	 * Les deux ensemble et 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 prochain lancement. C'est par ici
+	 * que passent les commandes console, et par ici que passera l'ecran de
+	 * customisation.
+	 */
+	UFUNCTION(BlueprintCallable, Category = "Apparence")
+	void SubmitCharacterAppearance(const FCharacterAppearance& InAppearance);
+
 	/** Faux quand Steam est absent ou qu'aucune session n'a pu etre creee. */
 	UFUNCTION(BlueprintPure, Category = "Coop")
 	bool CanInviteFriends() const;
@@ -572,6 +586,20 @@ private:
 	UFUNCTION(Server, Reliable)
 	void Server_SetPlayerNickname(const FString& Nickname);
 
+	/**
+	 * Meme chemin que le pseudo, et pour la meme raison : le serveur ne peut
+	 * pas deviner l'apparence choisie par un client, elle vit dans le fichier
+	 * de reglages de SA machine. C'est donc lui qui l'annonce.
+	 *
+	 * Treize octets envoyes une fois a la connexion -- l'apparence ne change
+	 * pas en cours de partie, l'ecran de customisation vit dans le menu.
+	 */
+	UFUNCTION(Server, Reliable)
+	void Server_SetCharacterAppearance(const FCharacterAppearance& InAppearance);
+
+	/** Lit l'apparence persistee et l'envoie au serveur. Appelee au BeginPlay. */
+	void AnnounceCharacterAppearance();
+
 	FTimerHandle RespawnTimerHandle;
 
 	/** Le fondu d'arrivée attend le pawn. */