Thread: Syncronisation design

The next revision will use the API I wrote, which features very fast query of the game data. While not true events, this should work out pretty well too; compared to the 'old' system in the current revision 134, it's up to 28 times faster (~700 function calls per second when no CPU limit set, old was around 40)

Events are triggered when the received game data differs from the cached values (e.g. the player position changed). Network packet will be immediately constructed and send to the server. The old system was similar, but suffered from the fact that it received so few game updates per second that lag was inevitable. Unfortunately I will have to write some real game event hooks, such as "Drop Item", "Pickup Item", "Use Item", because there is no way to know whether the player dropped or used an item (the only info we currently have is "it's gone", "it's there&quot

[quote author=Houstin link=topic=151.msg1269#msg1269 date=1314397956]
Not using events for shooting and moving is what has made infinite ammo, teleportation, and godmode possible in samp. I believe that cheating may become a serious issue once the project has grown.
[/quote]
the community will help with anticheats system.

[quote author=Houstin link=topic=151.msg1269#msg1269 date=1314397956]
Not using events for shooting and moving is what has made infinite ammo, teleportation, and godmode possible in samp. I believe that cheating may become a serious issue once the project has grown.
[/quote]
We have some pawn experts to develop such plugins, and the way they get their ammo, etc.
Checking their rounds VIA a script might work, and for teleporation, noticing a big change in numerals of the chords will make it obviously to the admins, a warning but certainly not a ban.
-Aleks

[quote author=Houstin link=topic=151.msg1277#msg1277 date=1314408659]
Anticheats make cheating harder. They simply limit how much you can cheat. On the other hand, prevention makes cheating impossible.

Anticheats have false positives, while prevention does not.

Also, there will be no reliable method to check for godmode, without having ridiculous amounts of false positives.

Last time I played SA:MP, in Crazybob's CnR, all you had to do is rob a store to get enough money to buy a gun. Then once you had a gun, you could simply enable infinite ammo and godmode and cheat until an admin notices and bans. I wouldn't doubt it that infinite ammo is becoming easier to detect, but godmode and teleportation will never be completely detectable.
[/quote]
What about checking if the player has been shot at and if he has, and hes not loosing any health, banzor.

[quote author=Houstin link=topic=151.msg1411#msg1411 date=1314610732]
Actually performing the check is the difficult part. You have to trace a line's, cylinder's, or box's position all the way where it starts to where it ends, and check for any collisions in between. Even if this was managed to be done, it would suffer from desyncronisation inaccuracies, and would still cause false positives. However, if each client is sent something that says a client fired a weapon and where he was aiming, they can do the collision detection and damage calculation on each client. The actual concept for this is complex, and I am not able to explain it at this time .

I should also note that Quake 3 sends multiple updates each packet. For example, consider the following code from Quake 3's source:

typedef struct usercmd_s {
int serverTime;
int angles[3];
int buttons;
byte weapon; // weapon
signed char forwardmove, rightmove, upmove;
} usercmd_t;

These are in an array and are populated and sent each packet. Oh, Call of Duty 4 compresses each packet with huffman. Punkbuster compresses it's packets with zlib, a compression library that guarantees it never makes the data bigger than it originally was. I'm not sure what if any compression RakNet uses, but I'd suggest zlib if it doesn't have any.
[/quote]
I totally understand the concept given, and I understand the part where I was wrong .