Syncronisation design

[Houstin]

Let's look at Quake 3. It's spawned hundreds(maybe thousands) of great games, with properly syncronised multiplayer. How? It uses events. Let's make up an example of what some events might be:

ENTITY_EVENT_SHOOT
ENTITY_EVENT_DIE
ENTITY_EVENT_MOVE <- unsure about this, they might of synced what buttons were being pressed/held every update
ENTITY_EVENT_LOOK <- unsure about this too, viewangles might be sync'd every update
ENTITY_EVENT_RELOAD

and so on... The outcome is a nice and efficient level of syncronisation which is not too bandwidth intensive. I believe that if we can implement something like this for Vault-MP, we can have a fully functional multiplayer that doesn't lag.

There would ofcourse have to be some "adaptions". For example, only sending events if the event would be meaningful for the client. Let's say Malcolm is on the bottom of the map, and Sally kills a mole rat at the top of the map. This event shouldn't be sent to Malcolm because he wouldn't know it ever happened, or would it affect him.

As for NPC's, they'll have to be executed server side. . .

[foxtacles]

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")

[Houstin]

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.

[CTCCoco]

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.

the community will help with anticheats system.

[Aeronix]

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.

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

[Houstin]

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.

[Aeronix]

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.

What about checking if the player has been shot at and if he has, and hes not loosing any health, banzor.

[Houstin]

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.

[Aeronix]

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.

I totally understand the concept given, and I understand the part where I was wrong :p.

[Houstin]

The concept that I mentioned but did not explain was how the server handled the data. I decided to ask one of my friends, Google. He seemed to know a lot about this and gave me the following useful links.

https://warriors.eecs.umich.edu/games/papers/quakefinal.pdf
https://www.bluesnews.com/abrash/chap70.shtml
https://www.gameproducer.net/2006/12/16/planning-is-essential-in-writing-multiplayer-network-code/

The last one is exceptionally great, because it references efficient RakNet programming, along with some other network models.

[Kar]

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.


sorry if offtopic but in sa-mp you could detect it using onplayerkeystatechange, getweaponstate and getweapondata. (it won't work if a player shoots with ctrl though ;\ secondary fire key)

maybe if recycler plans those functions, you could try it here too.

[Volumed]

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.


sorry if offtopic but in sa-mp you could detect it using onplayerkeystatechange, getweaponstate and getweapondata. (it won't work if a player shoots with ctrl though ;\ secondary fire key)

maybe if recycler plans those functions, you could try it here too.


I am sure that is possible with mods.