And then you have to replicate it manually, like so:
bool UArenaMovementComponent::ReplicateSubobjects(class UActorChannel *Channel, class FOutBunch *Bunch, FReplicationFlags *RepFlags)
{
bool wrote = Super::ReplicateSubobjects(Channel, Bunch, RepFlags);
if (MoveState){
wrote |= Channel->ReplicateSubobject(MoveState, *Bunch, *RepFlags);
}
return wrote;
}
Now I probably missed some important stuff, it’s probably not wise to just return true in “IsSupportedForNetworking”. I update this thread once I know more.
Thanks but I have also looked at this class. I want to implement something similar to the “State pattern”, the GameplayTask system comes very close but it supports multiple tasks where I want to be limited to 1 task.
I noticed most stuff inherits from AActor, I wonder if I should too? But there is so many stuff in AActor that I don’t need, like the MovementComponent, InputComponent, Transform, Velocity and the list goes on.
Hm, AActor is the first class that normally supports replication. It’s correct that they have a lot of stuff that you may not need, but then you could just not use it.
As long as Actors have not 3D representation like a Mesh or something, they are good to be used for Object like things.
So they are just invisible Actors somewhere in the world that you don’t have to think about. Epic does the same in several other projects of them.
UObjects are cool to use for non replicated Stuff though.
I’d also suggest to go with the AActor. AActors are linked to the world and have nice lifecycle methods you can use to handle certain events. See BeginPlay, EndPlay etc.
Also there is a good way to implement the states of a state machine with the “Within” class specifier (see here). You can find an example for that within the Unreal Tournament Project. Just look at the WeaponStates (e.g. UTWeaponStateFiring, UTWeaponStateActive, etc.).
Not entirely true. Actors are big (about 2KB) while plain object is less than 300 bytes.
Using actor just for the replication is just wasteful. If something doesn’t need physical representation in world, but you still need reflection and polymorphism, UObjects are very good choice for replication. The only cevat is that you have to replicate them trough actor or actor component. But that’s not really hard.
Unless the you only have very few replicated actors, then whatever. For anything more than 20 I would think twice.
I came to the same conclusion, Actors are great for single long lived objects, but I need many small short lived objects. For example I currently have around 15 different movement states for my MovementComponent like GameplayState_MoveToLocation, GameplayState_MoveToTarget, GameplayState_DashToLocation etc. Those objects may only live for a few seconds until they get replaced. Considering that this movement component will be used by every “unit” in my game and I can have ~100 of active units in my game things might matter.
Also it’s very easy to replicate an UObject, I mean it’s “basically” one line if they are owned by an Actor or ActorComponent.
Are you sure, you are creating objects on server.?The outer is part of the problem. It seems like you trying to replicate uobject from different actor than it’s owner(ie outer and where the replicated uproperty is). This might happen indirectly, by copying reference to other object and tryingvto replicate it here.
This actually resulted in a strange behavior. Once the object was marked as replicated, the client and server had access to the exact same object in memory.
I think this might be a bug with “Use Single instance” in the editor. Unfortunately I can’t disable it because it will result in a crash if I do so.
Should I make a bug report or is this “expected” behavior?