You added client-side version of setGlitchEnabled. I think you should keep this name instead of setPlayerGlitchEnabled.

Security wise this approach with onPlayerGlitchStateChange just as useless as onPlayerChangesWorldSpecialProperty. It doesn't stop cheaters from exploiting it without sending this packet to the server (advanced cheats call internal functions just like with world properties). Adding this packet / event is questionable.

There are also some things in InitialDataStream that are not needed. Server side glitch states are handled in CMapInfoPacket.cpp. You don't need to send it again.

ResetPlayerGlitchOverrides() is not used?
This logic with glitch state overrides doesn't make much sense. Wouldn't it be easier to simply add interface for glitches on client side without additional logic? In the end it's a client side function. Don't make it complicated.

This is a gift for cheaters.

This is a gift for cheaters.

Cheaters already do crazy things that are waaaaaaay worse than exploiting the glitches.

What about a server-side solution? Wouldn’t it be better to avoid relying on the client side ?

This is a gift for cheaters.

Cheaters already do crazy things that are waaaaaaay worse than exploiting the glitches.

Does that mean we should give them even more opportunities to harm MTA just because they're already doing worse things?

Besides, take a look at the list of glitches. Do you see any entries there that make sense to be enabled per player on the client side? Aside from vehicle_rapid_stop.

Thanks for the PR, @truedinoplayz

Due to some inner working of the anticheat, and the potential of making it easier for cheaters to abuse functionality like this we would like to see this implemented differently.

Instead of a client side function, and a request-flow to the server, we would like this to be entirely server authorative.

This would result in a situation with 2 server side functions:
SetPlayerGlitchEnabled
IsPlayerGlitchEnabled

These could then just use the existing packets that are already sent by the setGlitchEnabled function, but only send them to the relevant player. There shouldn't be any client side changes needed

If you wish to learn more about our considerations, please join the MTA development discord and see today's #refactoring channel discussion. This notification is what we gathered from it.

Also, you don't need to refactor anything for now, please just implement your feature. If you want to refactor, please open separate PR's afterwards. Please for this feature also keep modifications to networking logic minimal or none, and don't add any methods your feature isn't using.

Sidenote: the closing and re-opening of your PR was by mistake, so don't mind it.

Thanks for the clarification.

Yeah, I’m on the Discord and saw the whole discussion in #refactoring. I totally get the concerns about overcomplicating things

I’ll keep it simple and just implement the feature the way you suggested

Also, just want to say I had no bad intentions at all. I genuinely wanted to contribute something useful

That said, I understand there might’ve been issues or mistakes in the code, and I’m always open to feedback and corrections no problem at all