tweak(server): state bags can now be created by clients and replicated

[thorium-cfx]

• Any client that owns an entity can now create its replicating state bags on the server.
• Clients will queue their state bag changes and send them after getting an ACK from the server (meaning the server now knows of the entity).
• State bag updates to clients are now being sent after the clone creation packets.
• State bag updates are not being sent to clients that just got a call to remove the associated entities.

resolves #1335 resolves #1304

[fkk-cz]

Any client that owns an entity can now create its replicating state bags on the server.

Couldn't this cause issues where clients would be able to arbitrarily create/set state bag values that are unneeded or unwanted by the server? Or would the server still have to initialize the state bag on the entity first (current behavior) before it can be modified by the owning client?

[thorium-cfx]

Couldn't this cause issues where clients would be able to arbitrarily create/set state bag values that are unneeded or unwanted by the server? Or would the server still have to initialize the state bag on the entity first (current behavior) before it can be modified by the owning client?

Current conditions on creation of state bags are unchanged, i.e.: the entity must exist, and the requester must be the owner of said entity. But yes, this would allow clients to create state bags on the server without the server initializing these state bags first (by its own scripts), still above conditions apply.

[blattersturm]

Couldn't this cause issues where clients would be able to arbitrarily create/set state bag values that are unneeded or unwanted by the server?

As above, not in any different way than is the case now. Filtering is still a later concern, including I guess some way to preemptively reject any client-side updates.

Also, I guess this feature should check for 'entity lockdown' being enabled as well, since in those cases the specific race this part tries to solve wouldn't ever apply.

[thorium-cfx]

Whole different setup, no more timers, and a potential base to include throttling later

[blattersturm]

'd be nice if someone'd test these with 'real' use cases before I'd merge. :)

[thorium-cfx]

That would be great.

This is what I kept on testing while developing this:

1. A StateBagChangeHandler to see changes the moment they are applied, directly getting the entityId by NetToVeh(netId) or NetworkGetEntityFromNetworkId(netId), where netId = tonumber(string.match(bagName, "entity:(%d+)")), on both client and server.
2. Spawned vehicle on client, then straight after the create call: Entity(entityId).state:set("apple", "banana", true) and other fruit pairs, fruit is important.
3. Spawned vehicle on server, applied state bag changes, then on client; move far away, then come back, seeing state bag changes being applied (doing this a few times for good measure).
4. Retrieve state bag values on both server and client at different moments.

[BuddiesTV]

That would be great.

This is what I kept on testing while developing this:

1. A StateBagChangeHandler to see changes the moment they are applied, directly getting the entityId by NetToVeh(netId) or NetworkGetEntityFromNetworkId(netId), where netId = tonumber(string.match(bagName, "entity:(%d+)")), on both client and server.
2. Spawned vehicle on client, then straight after the create call: Entity(entityId).state:set("apple", "banana", true) and other fruit pairs, fruit is important.
3. Spawned vehicle on server, applied state bag changes, then on client; move far away, then come back, seeing state bag changes being applied (doing this a few times for good measure).
4. Retrieve state bag values on both server and client at different moments.

So, i've tested these things with scripts from a production server, everything worked fine. Also i tested it with a script that was just made to test these things. I'll link a video from that test-script that everything is working as it should.

Video

[Ekinoxx0]

I also tested these changes on a dev server and it fixes many issues we encountered when using state bags.

Before :

• A lot of issues with applying vehicle properties that are stored in state bags (Entity doesn't exist when receiving the state bag, need to wait multiple frames before it sync correctly, not ideal)
• Server cant verify model of entities that it doesn't know of when receiving the state bag

Using this fix :

• Vehicle properties are applied as soon as the state bag is received (Entity exist correctly on creation)

Thanks for the good work thorium 👍

[mythicalbro]

Did anyone test it with more than one client? I understand that the client that sets the state needs to be the owner of the entity, but the state change should be applied, received for all other clients no matter if they own that entity or not, right? I tested it and currently the state changes are not being applied, received for client if other client owns it. As soon as this client becomes the owner of that entity the latest state applies. Also, it seems like the state changes are being applied if client is not owner but has had ownership of that entity. One more thing I noticed when spawning vehicle and setting its state right after spawning it on client, is that this state change is received by other clients even if it doesn't exist for them/is outside their culling radius.

[thorium-cfx]

... but the state change should be applied, received for all other clients no matter if they own that entity or not, right?

If they are in the vicinity then yes.

I've tested it and currently the state changes are not being applied, received for client if other client owns it.

Could you give us a step-by-step repro?

... is that this state change is received by other clients even if it doesn't exist for them/is outside their culling radius.

Could you elaborate on what culling you are referring to? Need to make sure we talk about the same thing.

I wonder if this issue wasn't there before, as these changes shouldn't change who is getting the packets and who isn't, it only enables clients to create the initial state bag and moves the sending of state bag updates packets until after the entity's creation.

Also when you got a repro can you create a separate issue on this?

[AvarianKnight]

This seems very easy to reproduce:

1. Spawn a vehicle with two clients in the vicinity
2. Try to set the state bag on the owning client
3. Only the owning client gets the replication back

If the other client gets ownership of the vehicle it starts to get the sync requests.

It mainly looks like you don't get sync requests until you've owned the entity, after you've owned the entity you will get the sync requests (its no longer limited to just the owning player)

[mythicalbro]

Could you give us a step-by-step repro?

@AvarianKnight provided repro is the way I was able to reproduce it myself.

Could you elaborate on what culling you are referring to? Need to make sure we talk about the same thing.

Onesync infinity player, player vehicle culling I suppose. It does not happen when the vehicle is spawned from server using CreateVehicleServerSetter native.

Also when you got a repro can you create a separate issue on this?

@AvarianKnight did - #1691