Iris Replication of TWeakObjectPtr inside a struct

Development Programming & Scripting Multiplayer & Networking
, ,
1

Hi,

I have come across a nuance of Iris and would like to know if this is intentional or not, and subsequently what the intended pattern should be.

  • If I replicate a TWeakObjectPtr inside an actor, this gets replicated to the client.
  • If I replicate a TWeakObjectPtr inside a struct, this does NOT get replicated to the client.
  • If I replicate a TObjectPtr inside a struct, this gets replicated to the client.

If I override NetSerialize and write out the TWeakObjectPtr on the struct, this then falls back on legacy replication and it works fine again (at the presumed cost of losing some benefits of using Iris for this struct).

Is this intended behaviour, or should Iris be able to handle weak pointers? If this is intended, would the suggestion be to use legacy serialisation as above, to write a custom Iris serialiser, or to avoid replicating TWeakObjectPtr altogether? It feels reasonable to want to replicate a TWeakObjectPtr in cases where the client and/or server don’t want to prevent GC, but it’s possible I’m abusing them in this instance.

Thanks,

Steve

[Attachment Removed]

2

Hi,

I believe this should be supported, and in my own basic test project, I was able to replicate a TWeakObjectPtr inside a struct.

Could you provide some more information on how your struct, TWeakObjectPtr, and the object it is pointing to are being set up and used?

Thanks,

Alex

[Attachment Removed]

3

Hey Alex,

Thanks for looking at this so quickly. Clearly I’ve been a little premature again, so I’ll do a bit of digging and see if I can isolate the problem down further. This could be a result of an overloaded == operator preventing it from getting clocked as dirty for some reason, for example.

Cheers

Steve

[Attachment Removed]

4

Okay, so after spending a while trying to reproduce this in a clean build, this turned out to be totally unrelated to what I thought - it was some unusual Iris interactions with dormancy that meant it just happened to be dormant when I was using it with TWeakObjectPtr because my test case was non-deterministic.

Broadly speaking:

  • Dormancy had been turned off on our project in legacy due to some problems we were having before cutting a build, but turning it off in legacy did not also turn it off in Iris.
  • Some objects (such as this one) were marked as DORM_DormantAll and then woken up on replicated variable change. This does not appear to work under Iris, and requires DORM_Initial instead to ensure it is initially registered correctly.
  • Additionally, even with DORM_Initial, we had problems with objects getting registered correctly with Iris, so had to turn dormancy back on. Which isn’t a problem for us any more, but interesting to note.

It will be super low priority because not many people will have a good reason for turning off dormancy (especially not long term), but it might be worth looking into how dormancy and Iris interact when it is turned off.

Cheers

Steve

[Attachment Removed]

5

Hi,

Great, I’m glad you were able to track down the cause of the problem!

As for the dormancy issue, while it is likely that most projects may not disable dormancy long-term, I do agree that it’s worth making a note of this issue at least, especially since it is a difference in behavior between the generic replication system and Iris. I’ve made a new issue for this, UE-365983, which should be visible in the public tracker in a day or so.

Thanks,

Alex

[Attachment Removed]