Leaderboard

APPENDIX DATA SYNCHRONIZATION. What is it? MTA's synchronization methods. 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 ).

ارسلها هنا خلنا نستفيد

ذا صوتك ؟

اهب هذي كيف سويتها

Oh, I see rightly, thank you very much and I understand what to use many SetTimer

reason is found, thanks There was event onClientPlayerDamage, it killed player by setElementHealth Close topic please

قم بتجربة هذا local ID_Database = dbConnect ( "sqlite", "ID_Database.db" ) dbExec ( ID_Database, "CREATE TABLE IF NOT EXISTS `ID` (`Account`,`Number`)") getLastUsedID = function ( ) local id = 0 local db = dbPoll ( dbQuery ( ID_Database, "SELECT * FROM `ID`" ), -1 ) if #db > 0 then for i, v in ipairs ( db ) do id = v.Number end end return tonumber(id) end getAccountID = function ( acc ) if acc then local db = dbPoll ( dbQuery ( ID_Database, "SELECT * FROM `ID` WHERE `Account`=?", tostring(acc) ), -1 ) if #db > 0 then return tostring(db[1].Number) end end return false end giveAccountID = function ( acc ) if acc then if not getAccountID ( acc ) then local id = getLastUsedID ( ) +1 dbExec ( ID_Database, "INSERT INTO `ID` VALUES(?,?)", tostring(acc), tostring(id) ) return tostring(id) end end return false end loadPlayerID = function ( player ) local account = getPlayerAccount ( player ) if not isGuestAccount ( account ) then local acc = getAccountName ( account ) local id = getAccountID ( acc ) if id then setElementData ( source, "playerid", id ) return id else local newID = giveAccountID ( acc ) if newID then setElementData ( source, "playerid", newID ) return newID end end end return false end addEventHandler ( "onPlayerLogin", root, function ( ) loadPlayerID ( source ) end ) addEventHandler ( "onResourceStart", resourceRoot, function ( ) for i, v in ipairs ( getElementsByType ( "player" ) ) do loadPlayerID ( v ) end end )

It really depends who you hire. If I did paid scripting(which I do not), I would charge you around 10 euro per hour. The length of the project depends on your criteria. But there are people who do it for 3 euro per hour... or 5 cent per code line.

If you play MTA then there's always that guy who you've seen at some server who knows someone whose cousin's brother's nephew knows some sort of scripting. And that guy probably knows other guys who know scripting. Don't hurry to give your money just yet. Maybe someone will do it for you for free. I know a lot of lua scripters all thanks to simply playing MTA. We all help each other for free. Good luck

كل يوم اجي اشوف من قوة الابداع

I thnik what he meant was "It makes the server vulnerable to hackers who would use the same nick". The point is, Chronic uses it only on his local server so he doesn't have to type in his credentials every time he joins. As far as he doesn't use it on a public server, it's fine.

Hack servers? What is that?