#what use case do you have for such a
drifting monolith
if i have a server initiated ability that spawns a replicated actor, and then i want to run logic after the client gets that actor, a super easy way would just be to replicate the actor ref and then wait for client to sync and continue with some logic
as an example
something like this seems perfectly fine to me and probably works perfectly fine right now
atleast for me in my coop scenario
i guess another situation is if i already had a replicated actor spawned right before the ability fires and the reference has to be aquired nicely on the client
rain stream
Well, you don't need a replicated variable for that ...
Spawning s replicated actor from server will work. The rep actor could send a server rpc after it has ben rep if you want ...
There is also the possibility to avoid replicating the actor, and just "sync" yhe properties that are required
I made something similar where all simulated proxies have a copy of an actor.
He's not replicated.
It's properties are, from a replicated actor component on the main char
Ex: position, rotation, model etc ...
Plus, what can be soft pointers are, which avoid the sync load of the replication
I async load the properties and spawn on each client at the same place, attached to the same actor etc
@drifting monolith
Sure that's more work
But that's way more efficient
We have 100+ players.
Oh, and the server rpc just has to fire an event for the GA to tell it: rep is done
drifting monolith
yea i currently use just have server and owner spawn an actor and use RPC to send properties around
in which if i really wanted to have some rep actor the actor itself could in theory use property replication for those values to get around not having property rep in ga, but like i said i do understand its generally a bad practice in this case
but it would be nice for epic to let me stub my own toes 😄