[pests]

Did you read the article? The code sections show the player_name and position variables being synced with the position being synced every 16ms/62.5Hz.

The sentence right before your first quote answers your question -

"Note that the client code doesn't "instantiates" the scene explicitly. However, since the scene is marked for replication [... your quote]"

In this case its sending the scene for the clients to instantiate.

They gave an example of messaging as well - RPC.

[mrspeaker]

Hmm, I've read it a bunch of times now but am still unsure: they ARE sending every bit of data - position, scale, rotation etc - about every cube/model/asset for a scene ("Since the scene is marked for replication [...your quote]")... and then after that they are syncing selected properties of that data ("player_name", "positions") every 16ms. Is that right? If you have a Fortnite-style map, every time you joined a game you would get all the map/model pos/rot/scale data sent to you?

And for messaging, I wrote "Why is integrating state synchronization with messaging a useful thing?" but I guess it would have been clearer if I asked "Why is integrating state synchronization with RPC a useful thing?"... what are some examples of what that's used for?

[pests]

That does sound right. Apologies if my tone was rude earlier I was posting with little sleep.

I believe you want state sync and RPC integrated because you want a meaningful order to events.

Say a bomb exploding is done via an RPC call for legacy reasons and now position is via state sync. Youd want to ensure the explosion was ordered in respect to position updates to ensure it goes off in the right place.