Setting a state on client is not replicated

[CeebDev]

What happened?

Setting a state on a client with replicated arg to true don't replicate to server and other clients

Expected result

if replicated arg is set to true it should replicate to server + other clients

Reproduction steps

• Execute on a client LocalPlayer.state:set("test", true, true)
• print server side print(Player(playerId).state.test)
• it return nil
• same for other clients

Importancy

Slight inconvenience

Area(s)

FiveM, OneSync

Specific version(s)

Release or Canary client same - b8509 server

Additional information

No response

[AvarianKnight]

Try upgrading to 8510+ the old builds didn't handle state bag packets d1b50ba

[CeebDev]

why this fix is not on latest update branch if it's a known bug and a fix is already pushed ?

[slashkeyvalue]

It's not a client branch thing, just update your server artifacts

[CeebDev]

It's not a client branch thing, just update your server artifacts

Yes but i mean here https://changelogs-live.fivem.net/api/changelog/versions/linux/server

latest just got updated and the fix was pushed yesterday, so the latest branch was broke for +1day

[yannbcf]

Even tho, it does not make sense to replicate a state set by the client, there is a design issue here

[AvarianKnight]

Even tho, it does not make sense to replicate a state set by the client, there is a design issue here

This doesn't make much sense, there are times where it makes complete sense to replicate data sent by the client.

What doesn't make any sense is that there is no way to reject data that is sent by the client and there is no way to set what data is expected to be allowed inside of a state. See some more discussion about that here which also includes a bunch of other discussion about when client replication should be allowed.

[yannbcf]

It looks like an attempt to disguise a design issue behind a need to be fair.

What you ask for is a mechanism to reject a behavior that should not happen in the first place, the server developers should have the control over what is synchronized by their gamemodes, and this by design.

I dont see the issue behind sending a classic event to the server, which verifies if it's legit and then, it is the server responsibility to synchronize the state. This way you dont have undefined behaviors if you dont handle the rejection or whatever