This is where networking and replication starts to get tricky, and takes a lot of forethought.
So when you run spawn event on Server, it creates that Actor on Server. If that actor is set to Replicate, Server will also tell each Client that actor exists, and so Clients will see it.
Similarly, if you use an RoS RPC to have Server spawn actor, Server is still doing all that work (except on requesting Client, because that work has already been done by that particular Client).
If, as you describe above, all Server and all Clients attempt to spawn an actor, they will EACH spawn an actor. So if your Character Blueprint attempts to actor without any network consideration, there will be an instance on each Client that only those Clients can see, as well as one on Server for EACH Client that attempted to spawn. Remember that Character actor, like most actors, exists on Server AND on Client.
That leads to many instances of same actor, some of which are set to properly replicate and some of which aren’t, depending on who spawned them. Additionally, depending on how you set your references, if you attempt to reference spawned actor, you may be referencing incorrect one.
This can obviously cause a lot of confusion. That’s why it’s generally better to let Server do its job, which is to run game for Clients and communicate all important information (such as projectiles, damage, health, etc) to Clients.
And yes, that’s correct, re: replicated variables. Remember that all communication happens from Server to Client or Server to all Clients, and not from Client to Server (except when using a Run on Server RPC). It won’t matter if a variable is replicated if you attempt to change it on Client.
I’ll take a look at your updated project when I get a chance, and let you know why it’s not working.