This resource is designed to detect and flag players who might be using cheats by comparing their in-game coordinates with their camera focus position. With artifact 12882, it is possible to use GET_PLAYER_FOCUS_POS and IS_PLAYER_IN_FREE_CAM_MODE on the serverside to detect freecam cheats.
Potential Issues
Script Cams: This detection method might have issues with script cams, as they can alter the camera focus position without indicating cheating behavior. Adjust the Config.FlagDistance accordingly to minimize false positives.
Features
Monitors player coordinates and camera focus position.
Requests a screenshot from the client if suspicious activity is detected.
Kicks players who do not upload the requested screenshot within the timeout period.
Configuration
Config.Webhook: The webhook URL where screenshots will be uploaded.
Config.TimeoutScreenshot: The timeout period (in seconds) to wait for the screenshot upload. Default is 30 seconds.
Config.FlagDistance: The distance threshold to flag a player for suspicious activity.
Usage
Place the resource in your resources directory.
Configure the Config parameters as needed.
Start the resource on your server.
Download
You can download the resource from the GitHub repository: Anti-Freecam
For detection, new server-side natives are being used that have only been available in the latest FiveM server builds for a few days. I don’t think they can be bypassed that easily. However, it’s a different story on the client side, where the values can be manipulated.
But wouldn’t server-side detection degrade server performance, for example if you have around 100 players, wouldn’t detection happen for every player and result in worse server-side performance?
You definitely have to keep an eye on that. But with just 3 native calls per player and one distance calculation, it shouldn’t be an issue if you set the refresh rate high enough and avoid frequent checks with a large number of players.
It’s nice, but you will get a few false positives. Players with high latency or connection issues might be flagged incorrectly if their position updates are delayed.
Also, I’m sure the RemoveEventHandler(eventHandler) call is unnecessary because RegisterNetEvent does not return a handler ID that needs to be removed.
Maybe add a grace period or multiple checks before flagging a player to reduce false positives.
Actually, RegisterNetEvent is followed by an AddEventHandler. That AddEventHandler returns a table with a key and name. In the RemoveEventHandler function, this is checked in eventData (see here). So, it should work as expected.
Good point. I haven’t fully tested it yet. It was mainly meant as a demonstration of how to use the new natives.
To further expand upon this, for people who could have issues with other cams and what not… magic thing called “state bags”, do a server call to set the state bag (so you canny be dumped and then the state be manipulated, init) - then if they’re in freecam/not with the correct focus and don’t have the state bag you can just yeet that way.
Obviously it requires some competence to set it up, like what, 2 percent?
