Properly sync actors created from glTF

[stevenvergenz]

Prior to this PR, patches to actors created from glTF (other than the root actor) were getting stored but never sent.

[tombuMS]

[eanders-ms]

type: 'actor-update', [](start = 44, length = 21)

Interesting. Agreed the payload needs a type, but this is going to break in the sync layer. You'll need to filter these messages out of the set returned by session.creatableChildrenOf.

There may be other places in the code that assumes the message is a create actor type message.

If this message going to sometimes be an actor-update message, the design should clearly reflect that. The created field is no longer a good name, for instance. Renaming this field might be a good way to find all the places in the code that may need some adjustment. #Resolved

[eanders-ms]

Actually, I see how this will get the desired result. In the create-actors stage of synchronization, these actor-update messages will be queued for delivery to the client, and will be sent once the create-actors stage completes. Maybe this design is ok after all.

Interesting to note that even if these actor-update messages were sent during the create-actors sync stage, things would still work due to message queuing in the client. actor-updates synchronization rules should be revisited. We might want to always allow them through now that they'll be queued properly client side.

Please add a comment here clearly describing how/why this works.

---

In reply to: 275422153 [](ancestors = 275422153)

[stevenvergenz]

Maybe instead of "created", we should name the messages "initialized". This works because gltf-created actors are always children of the gltf root, so by the time we sync them, clients will have already received and queued the "create-from-gltf" that generates them. they already exist on the client, so all we have to do at this stage is update their states. Our current sync mechanism is inadequate because we sync state by updating the create message, but these actors' states are not in the create message.

---

In reply to: 275430377 [](ancestors = 275430377,275422153)

[eanders-ms]

Maybe

initialization: {
    message: {
         payload: {
            ...
        }
    }
}

---

In reply to: 275453527 [](ancestors = 275453527,275430377,275422153)

[eanders-ms]

On a related note, the rule for actor-update may have a bug. Here's how its synchronization behavior is configured right now:

        synchronization: {
            stage: 'create-actors',
            before: 'ignore',
            during: 'queue',
            after: 'allow'
        },

What this does is drop actor-update messages before the create-actors sync stage, which I think is wrong. I think it should be set to allow. The actors being updated won't exist on the client yet, but that's ok. The messages will be queued.

I also think that during should be set to allow, which I why I'm bringing this up now. As configured today it will queue these messages, this includes the actor-update payloads created by previous object-spawned replies. Now that we can queue them in the client, we don't need to wait to send them. It's fine for the client to receive them while the glTF is still loading. #Resolved

[stevenvergenz]

before: allow wouldn't work though, because even though the messages are queued, they'd potentially be queued before the create-from-gltf message. Shouldn't we session queue them?

---

In reply to: 275546962 [](ancestors = 275546962)

[eanders-ms]

🕐

[eanders-ms]