Continuing the discussion from GitHub (see my bottom comment): (ServerGameState): sv_filterRequestControl defaults to NoFilter instead of Default · Issue #1543 · citizenfx/fivem · GitHub
I do not have any additional info to add beyond that at this time, and am just trying to gather information for future reference.
Other relevant past topics:
Regarding this post, if we could set some criteria for testing then we can actively request for someone with a server of let’s say 25 players to test for us because realistically, this would be an insanely good feature for future anti-cheat systems.
The intended testing scenario is ‘does the “default” flag make sense with some common scripts used on real-world servers’.
I recall a report somewhere (might have been some chat room - these suck for long term discovery) saying that one of the other flags might’ve been a better default for script compatibility, too.
If I’m correctly assuming what you mean here by ‘systems’, the intended design of this feature and any future such functionality, is that it would have somewhat expected and safe behavior by default without the user needing to develop or otherwise obtain any ‘systems’, given this market is filled with abusive and otherwise undesirable practices.
Feedback (~200-300 players)
I am using this feature for a few months now, currently not having any issues regarding it.
We started using it, because players using forbidden software were taking ownership about other player’s vehicles.
We are using value 2, because we have a script that allows players to carry specific networked objects, and they have to be controlling the entity for it to be attached on them.
It would be problematic if no request control would be routed, because then, when the entities current owner is in range of the entity itself, but not in range of the player trying to carry the entity, this would cause the owner not being able to attach it to the (for him unknown, because out of range) player.
Suggestions
True, but realistically a feature such as this would be used as more of an ‘add-on’ to existing anti-cheat systems - for the sole purpose of enhancing the effectiveness of detecting cheaters.
That matches @Orel65’s scenario from the post linked earlier, too: entity attachment.
Server-side ‘cooperative’ entity attachment calls might be a proper fix for this, perhaps? IIRC entity attachment is also fairly popular with cheaters. 
As such, a sensible default for compatibility however may indeed be the ‘only player and player-occupied vehicle’ one, or maybe a new mode in between that still allows peds and objects but disallows vehicles and players?
More filtering events are a no-go sadly, these enable the ‘mitigating’ behavior of often-abusive anti-cheat scripts a lot instead of encouraging proper code be written.
If the community had at least not turned anti-cheat scripts into the weirdest ring of ‘personal gain’ zero-sum abuse, this might’ve been different, but currently this anti-cheat script ecosystem has turned outright malicious by weaponizing code execution vulnerabilities in our software and selling them to users as ‘protection’, while being as hostile to us as cheaters often are.
As such, any future functionality kind of has to be doable without requiring any such parties being involved.
That is a discussion for another topic, anyway, to not detract too much from the issue at hand here.
Yeah, we had this issue to. A fix for this would be for servers to set the lockdown mode for their main routing bucket to strict and creating any networked entities serverside, letting the server auto-assign an owner. Doing this disallows cheaters to create entities, effectively making them unable to attach any entities that should not exist (like cages for players).
That would be exactly what i wanted to write right now. Does this bring issues when players want to “swap” driver of a vehicle? Or is the owner automatically set when a new player is on the vehicle’s driver seat? We had issues for players even entering a vehicle when the owner is too far away, the ped just gets stuck at the enter animation.
Please explain why such an event would be a no-go, what do you mean by these enable the ‘mitigating’ behavior of often-abusive anti-cheat scripts? Wait for abusive anti-cheat developers for beginning to sell patched server dll’s, so that they can add events like these…, thats exactly (instead of dlls, it was packed jar files / bytecode IL files) what happened a few years ago in the Minecraft community. I understand your concern about these anti-cheats, they are often encrypted, use their own licensing system, etcetera. But what would such an event change?
That is unrelated to script control requests and rather is an unrelated ownership/range issue that has been reported a few times (again mostly in transient chat rooms, sigh) but needs reproduction steps.
The ‘request-control’ event is only used for script control requests, vehicle entering works in entirely different ways.
Perfect, can i create a PR for this?:
At this time, yes, I’d prefer you didn’t, or at best post a patch (in git format-patch format?) in here to reduce the pressure on merging such, while also having your tested implementation at the ready.
It’s easier to implement this myself when I get time and am able to concretely think about this functionality, than to have to deal with reviewing and merging a pull request while having the pressure of appearances regarding community pull requests - the issue is getting started on any such tasks, not the complexity-of, but the pressure of GitHub as a ‘social platform’ doesn’t help there.
Maybe that kind of stuff will pick up at some later time when more people are actually able to work on the project again. 
Summer months seem to slow things down a lot.
, will look into this today, thanks for the opportunity 
Who are the people working on the project? Are they all members of a specific company / do you take on new team members?
It’s a mix of community members and parties interested to work as a contractor. We do take on new people from time to time, so if you’re interested, you’re always welcome to drop me a message
Hey @d-bubble, here’s my patch:
0001-feat-gamestate-server-add-vehicle-control-request-fi.patch (5.6 KB)
Quick summary:
NoFilter (4), because putting it before NoFilter could break some server configs.)IsEntityAVehicle helper (as wanted in your todo: // #TODO: turn this into a 'is this type a vehicle' helper)NoFilter (before it was just checked if it was Default (currently NoFilter) - which is why the warning was never printed)netId to the request rejection warning message, so that the player can easily be identified via txAdminCommit: feat(gamestate/server): add vehicle control request filter mode · 0xLuca/fivem@7f146ba · GitHub
Just a quick note - not reviewing the full code yet,
This logic was mainly as such because the ‘issues’ log thing doesn’t exist yet, and the warning would as such only be relevant when upgrading and wondering why scripts don’t work.
(too spammy for when having set a different configuration, I believe)
Hmm, does FiveM have a Debug/Verbose Mode? I think that this log can be very useful to catch players that are actively trying to harm the Server by using cheats. (Because when the scripts are adjusted to work with the chosen setting, this warning will only show up when a player is executing injected code.)
Or am i missing something? 
DPrintf does that but it still isn’t going to be as suitable as a proper persistent log of behavior.
… thanks for reminding me why the log didn’t include the player’s server ID, I was indeed wondering why I didn’t add it to the log.
It’s solely meant for compatibility stuff, and that’s also why it’s only enabled in default mode, not for ‘catching players’ as my belief was and still is ‘catching players’ is the wrong way to go about this entirely, as it puts the focus way too much on the negative + post-hoc mitigation rather than designing stuff in the first place so cheaters can’t do any noticeable or persistent harm.
I again do not wish to discuss this further at this time, since you also disagree on that perspective and I’m not in the mood for trying to discuss that yet again.
The constant near-obsession of the server owner base with ‘but cheats do this and that and we would love systems to more effectively enforce!’ and then blaming us for anything no matter what we do or do not do is a major factor in my being burnt out of working on this project, and it seems 99%+ of the vendors of these ‘systems’ prefer working against us rather than with us for whatever reason.
There is no reason such systems must be a third-party paid offering and ideally we’d have a free, bundled solution that does all the weird things players want and does them consistently well, but since the focus for most these folks is on odd resale and ‘making big loads of money’, any normal payment we could provide a team for doing so would pale in comparison to what server owners pay them for this kind of system, especially since most if not all of them sell their stuff off-platform and whatnot so we have no oversight on this, and blocking stuff they do doesn’t work (giant rat race better spent on real cheaters) or just leads to angry raid of misled customers brigading because ‘duh, you’re wrong here! whatever anticheat product is way better than what you could ever imagine doing! you suck!’.
I’ve got a massive negative emotional burden tied to any anti-abuse work since we just get screwed from all directions with anything we do here:
I think you misunderstood me there, i agree on your perspective and understand & like your idea of designing things so that cheaters dont even have the chance to do such things. Ill update it tomorrow and reset the check to default
This was most of the original platform design - assuming script authors would at least understand basic concepts of validation given that there’d been decades of prior art in teaching software developers to never trust user inputs.
That was a bit too hopeful, sadly.
Now it’s mostly focused on trying to get a decent middle-ground between all of that without getting too annoyed at people using things in unintended ways… which seems difficult given the amount of scripts that allow persistent damage to be done without any obvious means of recovering from that.
Preventing all cheating ever is impossible, but one can at least prevent or otherwise mitigate anything that can noticeably affect others. Similarly, real-time punishment isn’t needed in absence of any real-time ‘crime’, and we’re hopeful that actual client-side detections can still cover most publicly-sold cheating tools with time (but not instantly due to some information asymmetry, that’s a part that should be solved with server logic, yes).
Actually, i did have nothing to do right now, so heres the patch:
0002-revert-gamestate-server-revert-warning-message-addit.patch (1.9 KB)
…and the new commit: revert(gamestate/server): revert warning message additions & check · 0xLuca/fivem@2e1ea19 · GitHub