RESOLVED: 2018.25850 - Replicator within a replicator

Hello everyone,

I am in the very early stage of a new project and noticed a couple problems with the Replicator COMP.

In the attached file (it might take a while to open it), you will notice that project1/replicator1 will replicate the systemMaster1 COMP. Another replicator is present within systemMaster1.

If you go within the freshly replicated project1/system1, you will notice that there is a few replicated components, but some with different types ! The 2 first seem to be Containers, while the rest in Geos. If you look at project1/system1/replicator1, you will notice that the MasterOperator is bodyMaster1, which is a Geometry COMP.

The solution I found is to either manually click on Recreate All Operators on project1/system1/replicator1 or eventually, uncomment line 69 of project1/replicator1_callbaacks.

I am not sure if it really is a bug or if I am doing that is not recommended, but thought that it might be interesting to discuss it anyways.

Thank you for your time,
Michel
JetXS_LocalGroup_Debug.zip (638 KB)

I am getting the same thing. I have a cue system for a live event. It creates a container for each speaker with the first replicator, then the next replicator inside that container will create a button for each cue / media file to play. If I drill in and look it seems like it replicated correctly but visually it didn’t update. The Dat Execute also doesn’t fire or print out any of the debug info i put in it. But once I hit re-init on it or any of the parent containers it all fires off and looks correct.

Update: Added Zip file example code from my project. When you press on on of the buttons across the top in cues it should refresh the list, each row should have buttons. Currently you have to re-init network to get it to work properly.
CueMenuTest.zip (19.2 KB)

I can confirm similar behavior on build 2018.25850 on WIN10 Pro. Will update and see if behavior changes, but I’m curious if this is normal behavior?

Hi Michel.
On load, replicators do the equivalent of ‘Replicate Missing’.
Since the first two replicants already exist when your toe was last saved, they are not re-created.

The toe file seems to have been saved in a state where the master was changed after the last replication.
If you resave in the corrected state, does it resolve your issue?

We’re considering if ‘Replicate Missing’ should be expanded to re-create replicants that are no longer the same type as the master.
Any thoughts on that?

Cheers,
Rob

Thanks for this example. Confirmed as well, and investigating.

Hi @JetXS.

After some discussion, we decided we won’t automatically delete replicants of different types.
They might be changed intentionally after creation in a script for example.
In your file, I’d do a ‘Recreate All’ on your replicants and resave, to get rid of those geos.
If you can reproduce the issue where you think they didn’t recreate automatically, please let us know and we’ll address that issue.

So I think the issue is the DAT Execute not firing as you noticed.
Namely the replicated replicator is replicating before the DAT Execute fires.
Changing the behaviour/order will still lead to some ambiguity or 2nd cooks.

I’d suggest instead, getting rid of the Execute DAT altogether, and build the Buttons table with an Evaluate DAT directly.

This should solve your order-of-operations issue.

Let me know if that solves the issue,

Cheers,
Rob.