A little background on how we got here I think is required,
We’ve got a large shared inventory for the players. Each item is a unique UObject instance because it’s a lot easier to track state changes to a given object this way. Originally we were using a FastArrayReplication before moving to Iris - but we moved away from that approach because when a new client would come along, they’d suddenly get the full array dump and it would overload the channel size for a single update. So - we created wrapper actors instead, one actor per item AItemInstanceWrapper, and an item can represent N number in a stack - but due to not wanting to refactor everything the actors were just ignored. They were (before iris) simply always replicated by the replication graph to all users.
The items, themselves are always moving around, they are in different forms, sometimes a player is holding it, sometimes they throw it, sometimes it’s on a shelf. No matter what state it’s in, the Actor and the subobject itemInstance do not worry about that state - for the most part.
Instead - what happens is that the Item instance is told about some other temporary actor, e.g. maybe it’s temporarily owned by an another actor the player is holding. in this situation the ItemInstance is NOT a subobject of the HoldActor, it is merely referenced by it. Similarly when it’s thrown, one item from the ItemInstance stack may be split of, shoved into a new ItemInstance, given a new AItemInstanceWrapper, and then a new AThrownItem gets created and is given the ItemInstance as a reference and thrown into the world.
This brings us to the problem - If this problem occurred before in the legacy system, we were blind to it, but,
We throw an Item, splitting it from the stack. This does what i mentioned above. But - AThrownActor, referencing the ItemInstance (but isn’t the subobject owner), gets the OnRep event for the ItemInstance before any of the properties set replicated for it. Then some time later, the AItemInstanceWrapper (the proper subobject owner of ItemInstance) gets its OnRep for the ItemInstance, and at that point the ItemInstance is wholly replicated.
I thought that I could simply add ItemInstance to both actors ReplicatedSubObject list, but got the error about it not owning it - so that was a bust.
Any solutions? here’s what I’m hoping there are solutions for, and I hope to uncover unknown features of Iris.
Iris seems to internally handle dependencies for ordering updates - can I somehow tell Iris, that I need ItemInstance to be depended on in AThrownActor the same as it is for AItemInstanceWrapper, because I don’t want to get the OnRep before the thing has actually been repped and setup.
Can non-actors be directly replicated yet? Or would ItemInstance need to become an Actor directly? I feel like this would solve it, but is an annoying refactor.
Umm - Open to other ideas?