[TUTORIAL] Data synchronization

[Simple0x47]

APPENDIX

1. DATA SYNCHRONIZATION.
   1. What is it?
   2. MTA's synchronization methods.
   3. Optimization tips.

 

DATA SYNCHRONIZATION

1. What is it?

Since unmemorable times humanity have faced problems caused mainly due to the storage of different ideas in almost each human. But thank God, machines storage methods are different and they have the possibility of having stored the same values in more than 100 machines. Well this is great, but those values must be set by someone, and here's where the server-side and client-side can be used as example of data synchronization. The server-side store's all the values given by each client-side and give's back those values to the all the client-sides ending up into something like this ( Figure 1 ). This is a way to get the same data in all the client-side, but there's also other methods well known like P2P.

_{Figure 1.}

2. MTA's synchronization methods.

Since data sync it's a base element of every multiplayer game or mod, MTA is not an exception. That's why MTA scripting interface gives us two core ways to sync the server data with the client data or client data with server data. Well this two methods are the following one's.

• Element Data, it consists of assigning values to an element that are being stored under a key ( the key usually being a string like "health" ). This way is being used by a great amount of scripters in MTA because it's easy to use. But there are also negative points if this way is not being used properly like saving small amount of data in just one key and syncing it with the server or client's. An example of it would be:

[[--CLIENT.LUA--]]

local value = 0

local function handleStart()
  value = getTickCount() -- WE GET THE TIME THE SERVER HAS BEEN WORKING WHEN THE RESOURCE START
  
  setElementData( localPlayer, "start_tick", value, true ) -- WE SAVE THE 'value' VARIABLE INTO THE 'localPlayer' ELEMENT WITHIN THE KEY 'start_tick' AND WE SYNC IT TO GET THIS DATA TO THE SERVER.
end
addEventHandler( "onClientResourceStart", getResourceRootElement( getThisResource() ), handleStart )

[[--SERVER.LUA--]]

local function handleCMD( thePlayer )
  local mineTick = getElementData( thePlayer, "start_tick" ) -- WE RETRIEVE THE DATA, THAT HAS BEEN SAVED INTO 'thePlayer' DATA.
  local resultTick = getTickCount() - mineTick -- GET HOW MUCH TIME HAS PASSED SINCE THE RESOURCE STARTED FOR THE PLAYER
  outputChatBox( resultTick, thePlayer ) -- PRINT INTO THE CHAT THE RESULT
end
addCommandHandler( "mytime", handleCMD )

-- IN CASE YOU WANT TO TRY IT SAVE THE CODE WITH THE NAME MARKED ABOVE THEM.

[[--META.XML--]]

<meta>
	<script src="server.lua" type="server"/>
	<script src="client.lua" type="client"/>
</meta>

• Events, this method is the one that elementData's one bases on, which means this is a 'rawer' method which can also be faster than elementData if it's being used efficiently. An event is just a message that's being send to one or various systems, if these systems handle the message then when the message is sent to the system there's a trigger which calls the functions that are defined like a reaction to that message that has been sent. It's pretty easy to understand, just think of this. You say hello to someone, the message in this case is 'Hello' and the system where is pointed to mainly is the person, the person gets the message and handles it by calling some cognitive functions, these functions at their time trigger another message as result which in the most common case would be 'Hello' or just a strange face motion because he or she doesn't know you. Maybe you will ask yourself about what does a hello to someone have to do with Events in MTA. Well let's convert the situation above into script. We've got to define first the message by using addEvent( "Hello" ), good we have defined our message, but if we stop here then we have made some useless stuff that's not going to be used ever, that's why we have to use this message somewhere and here is when we simulate the action of saying something the message by using triggerEvent( "Hello" ) but... wait who's supposed to say the message? Let's make it look like the localPlayer was saying the message so it would be like triggerEvent( "Hello", localPlayer ), okay we have said the message but do we talk alone? Maybe but it's not pretty normal, so we must find a receptor which in this case will be a ped so we add the a ped to the game by using createPed( 0, 105, 20, 5.5 ) supposing we are located in the position 104, 20, 5.5. Okay we have the receptor now but it won't answer to our message so let's obligate him to answer us by adding a handler for the message to the ped like this addEventHandler( "Hello", thePed ), okay but this way it will do the same as we wouldn't have used addEventHandler that's why we need to pass also a function to call like an argument which in this case is going to be called 'answerToHello' and we would finish up with addEventHandler( "Hello", thePed, answerToHello ). All this and little bit more of code below for simulating an answer to hello from a person in a non-realistic way.

[[--CLIENT--]]
-- EVENTS

	addEvent( "Hello", false ) -- LET'S MAKE IT LIKE JUST THE CLIENT CAN TRIGGER IT SO WE MAKE SURE JUST WE ARE GOING TO TALK TO THE PED

-- VARIABLES

	local thePed = createPed( 0, 105, 20, 5.5 ) -- WE ADD THE PED SO WE DON'T FEEL LONELY

-- FUNCTIONS

	-- SAY HELLO

	local function sayHello() -- THIS FUNCTION WILL BE USED TO SEND UP THE MESSAGE TO THE PED
  		triggerEvent( "Hello", thePed ) -- WE SAY HELLO TO THE PED
  	end

	-- ANSWER

	local function answerToHello() -- WE DEFINE THE MESSAGE HANDLER SO WE MAKE SURE THE PED ANSWERS TO US
  		outputChatBox( "Hello to you too!" ) -- THE PED GET'S THE MESSAGE AND GIVES US BACK A MESSAGE THAT WE CAN CHECK INTO THE CHAT.
  	end

-- COMMANDS

	addCommandHandler( "sayit", sayHello ) -- WE'VE GOT TO SAY SOMEHOW HELLO TO THE PED SO LET'S USE A COMMAND

-- EVENT HANDLERS

	addEventHandler( "Hello", thePed, answerToHello )

3. Optimization tips.

Well both methods can be used in large development but there are some tips you can follow to make sure your script will run in an efficient way.

• Pack reasonable amount of data into one's element data key, don't save values like ( health, armor, money ) into different keys, compress them into an only one by using tables, by using this method we pass 3 values packed in one sync meanwhile separating each value with one key creates upon 3 different syncs which would end up in a greater amount of packets sent between the server and the client. This tip can be used for both methods [ elementData, Events ].

local basic_data = { health = 100, armor = 100, money = 100 } -- COMPRESSED PLAYER INFO 

setElementData( thePlayer, "main", basic_data, true ) -- WE GIVE 3 DIFFERENT VALUES TO 'main' KEY BY USING JUST A VARIABLE THAT'S A TABLE 'basic_data'
triggerClientEvent( thePlayer, "onSync", thePlayer, basic_data ) -- WE SEND A MESSAGE TO THE CLIENT IN ORDER TO MAKE IT SYNC THE DATA OF THE PLAYER TO THE ONE THAT IS BEING STORED IN THE SERVER

• Lua is a garbage collection language so the reduce the amount of global variables as much as possible in order to make it run faster.

Hope you enjoyed the tutorial, if you have any question just feel free to ask it in this post or by PM, Skype ( killer.68x ) or Email ( [email protected] ) or Discord ( Simple01#1106 ).

Edited August 4, 2018 by Simple01

[myonlake]

You made my day.

Sadly, your Google translation is unfortunately too obvious. I suggest you post the tutorial in your language to your language section so it can reach the right audience...

[Simple0x47]

On 7/28/2017 at 01:57, myonlake said:

You made my day.

Sadly, your Google translation is unfortunately too obvious. I suggest you post the tutorial in your language to your language section so it can reach the right audience...

Google translation, lol, I've wrote all this by myself, just quote the errors to learn from them. No google traductor, first make you sure what you're talking about.

[myonlake]

3 hours ago, Uknown. said:

Google translation, lol, I've wrote all this by myself, just quote the errors to learn from them. No google traductor, first make you sure what you're talking about.

Oops, seems like my phone was doing something weird, it looked like random words all through the post. Nevermind for that

[Simple0x47]

Would you like guys more tutorials like this one?

[Senpai]

yep we would like more from you

[Berko]

Good luck

[DiGiTal]

Very usefull lesson

[SycroX]

keep on