ci(seatbelt): pass seatbeltOn boolean as a param when calling the seatbelt:client:ToggleSeatbelt event

[vipexv]

Why are we not passing the seatbeltOn bool as a param when calling the seatbelt:client:ToggleSeatbelt event, like what is the benefit in not doing that?

This change simply passes it as a param, and it doesn't break anything, it simply adds an extra feature, and it is an optional param that players/developers can use to make their life easier.

Questions (please complete the following information):

• Have you personally loaded this code into an updated qbcore project and checked all it's functionality? Yes
• Does your code fit the style guidelines? Yes
• Does your PR fit the contribution guidelines? Yes

[Qwerty1Verified]

I don't mind the idea, could be helpful for clear declaration of data being derived from one source. I do want to know which use case you see for this to be a functional improvement for since you mentioned it's an extra feature?

[vipexv]

I was working on a commission recently, and i found it to be easier to just handle it this way, it just generally doesn't have any cons to it, it only brings benefits and makes things easier.

[Qwerty1Verified]

Yeah that's what I'm referring to I'd just like to hear your use case on it to know how you used it and how it helped you. Was it to update states on a UI without storing them yourself?

Most other use cases would pretty much require you to store a variable yourself which doesn't change too much.

[vipexv]

For me personally, especially when debugging and having to restart the resource multiple times, it caused the seatbelt to be offsync, there's other use cases for this like you stated, if someone wants to instantly update their Interface without storing a variable they can do that, but i would rather have it guaranteed to be synced rather than just toggling it and your never really 100% sure if its synced, and yes 99.99% of the time it will be, but i would rather have that 100% mark :o

And looking at it, there is no drawbacks to this, and it causes no compatibility issues.

[vipexv]

Even when your storing a variable, i personally would it rather pass it as a prop/argument that is always synced.

[Qwerty1Verified]

Sounds good, just wanted to make sure it had an actual use case. Although it could be said that state desync isn't a big issue since resources shouldn't really be restarted in "production", I do often argue that if need be then sometimes it must happen for the show to roll on. Then there's the other use case I can think of where you're just handing it off to a UI and don't want to worry about storing it, and updating it.

[vipexv]

For me it's more convenient this way, and it doesn't cost or break anything, which is mostly the primary reason for the suggestion, it simply adds something extra which doesn't break compatibility at all, and can optionally be used.

[Qwerty1Verified]

Yes, it's more of a development quality of life change, with better practice of handling data at one source.