Doesn’t seem too far away from what I have working… I personally retrieve locally set variables from the game instance on the player controllers since they have total access to any local variable set there. If I wish to persist changes after the game is closed or have certain loadouts, I’ll use save game so I can always instantiate those on the game instance when the player fires up the game.
From there I can replicate any of these game instance variables to any other player from the *player controllers over to the player state and player character and so on… I’m sure this method isn’t cheat proof, but it works. It is a little tricky syncing everything in the appropriate order to replicate and fire, so that is the only major hurdle I think.
I find it easy to communicate those replicated actions and variables(character changes and such) to the player character from the player controllers with RPC’s and Rep Notify functions. That is once they are retrieved from the local player’s game instance via the controller.
I can move between servers and levels and pull all these variables anywhere since they persist until I change them back and forth and any player controller you use can access them as well at any time.
As far as I have tinkered with on skeletal meshes, I was able to just Set Skeletal Mesh on the character blueprint to easily change between already targeted skeletal meshes in-game(not addressing replication). You could expose that variable on spawn and run the Set Skeletal Mesh on event begin play of the character blueprint…
If you have components attached to that character, you may need to show/hide each of them when you make the changes unless all your meshes are very similar and replicate those actions.
You could easily store these mesh variables on the game instance and run your replicated logic from any player controller after post login.
So in the menu if the player selects a character, you could set that variable on the game instance to something like “SkeletalMeshToSpawn” and then when you travel into the level, the new player controller or the same one will restart and you can get that non replicated game instance variable and set it on the appropriate blueprint, but at this point you would need to replicate it.
I feel like you can use any number of player controllers, levels and game modes without causing any issues or changing anything. I find personally the only way to keep all those in sync without any hiccups is using a single Game State across the whole game. I use the level blueprint to tell the game state where it is and it will run anything anywhere accordingly. I do know that no matter what, unless the game is switched off, I can always find stored variables on the game instance no matter where the player is.
There are other ways, but people rarely talk about them apart from using a database, which is probably a more secure, but proportionally difficult way lol.
