[Tutorial] Understanding the SA-MP sync
#21

Thats really a cool story and all bro.

But what you just explained is common sense.
Reply
#22

There are a few ways to halfly Stop that from happening:
1. Record How Many Anti Cheat KICKS(not bans) Been done
2. Ban if there are 3 or 5 kicks (This would proof its a script kiddie)
3. An AFK Kicker and Max Ping Kick
4. Be sure to have 3-10 admins online Constantly (depending on the amount of players, with Mass player Servers about 20-30 Admins)
5. That SAMP gets something like this:
server.cfg setting: noresponseactions (0,1,2 or 3) and noresponselimit (seconds) noresponsetimes (optional)
setting 0:
No action on no response of client for x seconds.
setting 1:
Informing Client for no response of client for x seconds after message sent
setting 2:
Kicking & Informing the Client for no response of client for x seconds for x times (noresponsetimes)
setting 3:
Banning & Informing the Client for no response of client for x seconds for x times
Reply
#23

..stop what from happening?
Reply
#24

God man,good job !!xD
Reply
#25

I have a question:

If a player has 200 armour.
he gets shot, and looses 10 armour
-> Package gets sent
he gets shot again, and looses 10 armour
-> Package gets sent

The server receives the packages in a wrong order,
and is told that the player's armour changes from 100 to 80 and to 90

Now the quesrion is: If the player now doesn't loose or get armour for the next 1 minute.
will the server then think one minute long that the player's armour is 90?
or will the client (player) also send new updates while his doesn't change?
Reply
#26

Also available in Spanish. Thank you very much to MrDeath.
Reply
#27

Quote:
Originally Posted by ғαιιοцт
View Post
I have a question:

If a player has 200 armour.
he gets shot, and looses 10 armour
-> Package gets sent
he gets shot again, and looses 10 armour
-> Package gets sent

The server receives the packages in a wrong order,
and is told that the player's armour changes from 100 to 80 and to 90

Now the quesrion is: If the player now doesn't loose or get armour for the next 1 minute.
will the server then think one minute long that the player's armour is 90?
or will the client (player) also send new updates while his doesn't change?
I think it will be corrected on the next update.
BTW I learned more from this
Now I'm going to improve my code
(Adding functions for double checking)
Reply
#28

A great tutorial for scripters about SA-MP sync, I've learnd some more about sa-mp sync from it.^^


But there're few arguments in this thread, still.
Quote:

The server runs on a single thread
The server runs on a single thread. This might sound complicated for some people, allow me to explain: All the actions the server does are always after waiting for the latest action to finish.
For example, if you have code that takes 3 seconds to run in OnPlayerConnect (such as the old GeoIP plugin), then the server will wait for that code to finish before doing anything else.

Personally, I don't agree the topic.
It is the code runtime(bytecode?) that runs on a single thread, but data such as network process(player-position, dialog, text, etc) not.
Assume it has a priority list.
Code:
1 - gtasa ingame action(position, aimming, shooting, etc)
2 - sa-mp info(scores, text, dialog, etc)
3 - plugin data
Particularly, sa-mp build-in sqLite and most of mySQL plugins do process while sa-mp code runtime, on the contrary of simple File input/output.

Now we can explain why dialog shows delayed half-seconds when typing a command to show a specfic dialog, and during the short period the player can play as usual.
So I prefer "Your sa-mp code runs on a singlee thread" than "The server runs on a single thread" for this topic.


Quote:

The client is currently paused so the message is put in a pool and will be handled once the player is unpaused and all the messages in the pool before it was handled.

It is the client-server data exchange paused/unpaused.
Reply
#29

The more correct statement would be "the scripts run on a single thread". Any incoming info from the bit-stream is put in a buffer/queue then called when the PAWN script isn't busy. By default, the server will wait for SQLite to finish writing/reading to the file - you can allow it to do this in a different thread by running the following query.
pawn Code:
db_query( db, "PRAGMA synchronous = 0" );
Why the dialos is delayed is simply because:
  • Player types command.
  • Command is recieved by the server.
  • After ~5ms, the server calls OnPlayerCommandText.
  • The outgoing data to show the dialog is sent to Player.
  • Player recieves the data and the dialog is shown.
So basically, PAWN can't be doing two things at a time.

How MySQL plugins are threaded is when they get the action to perform, a new thread is started and when the data is ready to be sent back into the PAWN script it will call a PAWN callback when it isn't busy (usually at ProcessTick).

Player position and everything does go through the PAWN script before it is sent to the other clients - through OnPlayerUpdate. That callback is called every time any player-related info is about to get sent to the other clients. If you return 0 in OnPlayerUpdate, the server won't send that information. This clearly indicates it has to go through the PAWN thread just like everything else.

I hope you understand me a bit better now.
Reply
#30

Firstly, I totally agree on that your description of player sync, it makes my mind clear.
Which ought to be arguments is just the topic "The server runs on a single thread", and text,dialog,etc sync.

And unfortunetally, this bug reoprot shows that the server doesn't run on single thread, probably.
So I hope you could change the topic "The server runs on a single thread" to "The script runs on a single thread", as you said, which I also do think so.
Reply
#31

Quote:
Originally Posted by yezizhu
View Post
Firstly, I totally agree on that your description of player sync, it makes my mind clear.
Which ought to be arguments is just the topic "The server runs on a single thread", and text,dialog,etc sync.

And unfortunetally, this bug reoprot shows that the server doesn't run on single thread, probably.
So I hope you could change the topic "The server runs on a single thread" to "The script runs on a single thread", as you said, which I also do think so.
I thought I changed that before. Oh well.
When you set a player's interior a packet will get sent that's basically saying "set interior to x" (obviously not in plain english, lol). When the player recieves that message and is unpaused the interior will change and the player sends a message back saying basically "my interior just changed to x". After that is recieved by the server, GetPlayerInterior will show that new interior.
Reply
#32

Very nice tutorial. Clearly explained.
Reply
#33

Very useful thanks
Reply
#34

Looks very useful & great, Good job
Reply
#35

This helped me to understand why innocent players get auto-banned on my server.
But how do i detect the packet loss of a player and automatically kick them for, let's say a certain amount of packet loss percentage?
Reply
#36

Quote:
Originally Posted by RedFusion
View Post
This helped me to understand why innocent players get auto-banned on my server.
But how do i detect the packet loss of a player and automatically kick them for, let's say a certain amount of packet loss percentage?
See this function. You'll have to use strfind to find where it says packet loss, then strmid to extract the value, then floatstr.
Reply
#37

Got it, thanks
Reply
#38

I have a question.
How do timers work in a single threaded application??
I have been programming in VC++ for years and I never ever got a chance to setup timers in a single thread.

Really Strange!! -_-
Reply
#39

Really nice tutorial - I've learned a lot of new information from your tutorial.
Reply
#40

EDIT: Nevermind
Reply


Forum Jump:


Users browsing this thread: 4 Guest(s)