[Repro] Server-side GetVehicleDoorLockStatus returns 0 when it should be 1

I am currently in the process of updating one of my scripts which saves and automatically updates vehicle data on server side ( AdvancedParking ). In the current version is a very minor bug that can cause an unnecessary update right after spawning a vehicle (doesn’t break anything but causes unnecessary performance loss).

For the new version I was researching in to that problem and found the cause:
I read the vehicleDoorLockStatus from the vehicle and compare it to the saved one. IF the client side lock status is 0 (none) OR 1 (unlocked), the server will ALWAYS read 0 (none) from the vehicle, which automatically triggers the update in my script as soon as a vehicle spawns with status 1 (unlocked) and the server simply reads 0 (none) in its next update cycle.
There are no problems when setting it to 2 (locked). Works without a problem for like more than a year now in that script for all of my customers.

Since there is basically no difference between 0 and 1 in this case for the base game, it is not really that big of a problem.
But some scripts might treat the 0 as something else than just “none” and those might break under those conditions.

  1. Client and FXServer version
    Client: 5628 beta and Server: latest recommended 5562 (set onesync on)

  2. What you expected to happen
    Server and Client having the same value for vehicle door lock status.

  3. What actually happens
    When client sets door lock status to 1 (unlocked), server will report 0 (none) instead.

  4. Category of bug
    client/server sync

  5. Reproducible steps
    5.1. ReproResource.zip (1.2 KB)
    5.2. Sit in any vehicle
    5.3. Press E to toggle lock status
    5.4. Run checklock command for server status
    5.5. Run checklock2 command for client status

For reference: GetVehicleDoorLockStatus - FiveM Natives @ Cfx.re Docs

I have not yet tested all the other values that can be returned but this is how it is currently:

client server
0 0
1 0
2 2

How would you even prefer to see this ‘solved’?

  1. Changing this would break any existing server-side code that assumes ‘1’ isn’t ever going to be returned.
  2. Having to send the difference between ‘unset’ and ‘unlocked’ would be oddly inefficient.
  3. Seeing 2, I would be surprised if remote clients differentiate between these values if, say, a vehicle had just been created by coming into scope, and even client code that expects ‘0’ and ‘1’ to not be equivalent would be broken.

At best what can be done is making a documentation note for both commands as anything else would be blatantly wrong.

It just felt to me like an oversight when implementing the server side native. One would assume that both would return the same values, especially since both share the same documentation in the native reference:

enum VehicleLockStatus = {
    None = 0,
    Unlocked = 1,
    Locked = 2,
    LockedForPlayer = 3,
    StickPlayerInside = 4,
    CanBeBrokenInto = 7,
    CanBeBrokenIntoPersist = 8,
    CannotBeTriedToEnter = 10
}

Even if it would break existing scripts, would it really be that many? Having seen so much code on this platform, it feels like barely anyone uses server side natives at this point.

So you are saying that is not something that will be looked into? For me this sounds like a bug, but if you feel like this would break compatibility past the benefits of fixing a bug, I can live with that.

Just wanted to report something that looks like a bug / sync issue to me. Easy enough to workaround in my code to fix my updating issue.

The server-side native just reads the data the game sends. I guess the enum is shared but game code doesn’t ever distinguish between 0 and 1 when sending state, since they’re probably equivalent in behavior.

That would probably be an oversight but again one that wouldn’t have been known beforehand I presume, especially given all other values make sense and there being a difference between ‘none’ and ‘unlocked’ being something definitely not obvious in the first place.

This server-side native was added via a community pull request (onesync: complete CVehicleGameStateDataNode and add new server natives by PichotM · Pull Request #267 · citizenfx/fivem · GitHub) back in 2019, with it being like this for three years there could be a non-zero amount of code inadvertently relying on it.

It’s impossible to tell how many, with how there’s tens of thousands of servers on the platform, and perhaps someone else noticed this before, didn’t report it, but did end up with the empirical observation of ‘it never returns 1, so one wouldn’t have to check for 1’.

Given this is much easier to fix as a doc edit than trying to deal with potentially causing an incompatibility (and having to dig through perhaps complex game code and potentially cause broken sync behavior if R* didn’t distinguish between the two for other reasons than performance), and again the case above of 3) in my prior post, I don’t think it’s worth risking a change to game behavior here especially compared to editing the docs to indicate such.

In an ideal world where we had infinite time and infinite insight into what people did on the platform, sure, but neither are the case - this is just one of 600+ pending tasks by now, and the impact analysis weighs heavily against changing this behavior, as we simply don’t have the data for this nor the capacity to deal with any angry fallout from someone having, say, bought some server script from someone which relies on this fluke, and would blame us for ‘breaking their script and their community!!!’ or such. It’s happened over more ‘obvious’ inadvertent API breakages before, even before we even allowed selling scripts at all.

2 Likes

I’ll take this as my solution then :slight_smile:
If even the game code itself doesn’t “care” about differentiating, it may be something deprecated or who-knows-what.

You’re probably right given how outrageous the community can be about some tiny things sometimes :smiley:

Yea, keep up the great work and prioritize more important things!

Thanks for the clarification!