As to my current knowledge, there is no functionality for the following request (if there is, please do inform me and then you can disregard the request)
The request I’m making is regards to general security to prevent any cheaters/hackers.
The request is rather simple: when a native is executed on the client, have a message from that client, be sent to the server and be accessible via a server event. For example:
AddEventHandler("playerTriggeredNative", function(source, native)
local plyID = GetPlayerIdentifiers(source)
print(plyID[1] .. " has executed the following native: " .. native)
end)
"steam:1234567 has executed the following native: SetEntityInvincible"
With the ability for the server to know which natives were executed by which player, it allows the opportunity to detect whether the player is cheating (whether they are spawning in props, vehicles, executing the native to give them invincibility, and so forth).
Although cheaters aren’t that big of a problem, from what I’ve seen, this feature is still neat to have. The cheat would also have to be sophisticated enough to block that message that is being sent to the server, so this feature is pretty good.
Please do consider about this feature, as it essentially prevents cheaters/hackers.
Although that message can be blocked from being sent to the server, it can still prevent plenty of cheats that simply use whatever bypass is known, and run any trainer which executes simple natives such as SetEntityInvincible, CreateObject, CreateVehicle, etc. And the possibility of that message being blocked by cheats, is quite low and can quickly be patched.
Any ways, it is still extremely useful for the server to know which client executed what native, rather than it not knowing at all. Combined with some logic, a good (to an extent) anti-cheat can be made and ran on the server.
This would be completely impractical, easy to bypass anyway, and is simply not going to happen.
This would completely cripple CPU performance for both clients and servers, lead to ~1 Mbit/s extra bandwidth usage for uplinks per client or more, all for something that could be prevented with a single no-op instruction and still have the same effect.
OneSync will provide events to handle game-specific things on the server side, other than that no completely ignorant workarounds like this are going to be added ever.
Ah, didn’t know that of OneSync. And yes, I totally agree with you but I was thinking more on the bases of certain natives oppose to every single one to not hinder performance.