Element Data

[MAB]

Hi, i am Michael Amir and i am going to explain setElementData and getElementData because much people don't understand them also i didn't at first.

This is for you to understand them only, don't use them much and try to avoid them as possible as you can.

I'd suggest you to use a custom system based upon triggerClientEvent, since element datas have a few issues:

They're synced to everyone

Whenever you change an Elementdata on the server/client the information will be synced to any connected client. This is often not necessary, but simply a waste of bandwidth. Why would a remote player be required to know the exact amount of fuel in a vehicle far away? That information is only useful for the driver of the vehicle, so you'd waste a ton of bandwidth which could be used by MTA for better synchronization.

Anyone can modify them

Without some additional security scripts (which is easily possible, but often overlooked) any client can modify Elementdatas of any element. This allows cheaters with modified clients to cheat themselves various things like money or even admin rights.

Lets say you are wearing a coat with 100 pockets.

You want but your wallet on one of them without forgetting it, so we will name that pocket "wallet pocket" and put a mark on it. That is what setElementData do.

The server got million of places to store data (like pockets to put stuff in) and it mark them too.

setElementData will go to one of these places and name it and store something in it for example:

setElementData(localPlayer,"carKeys",true) 

what we did here is that we went to a pocket of localPlayer pockets and named it "carKeys" and we stored the value "true" on it.

You can name the pocket whatever you want and store whatever you want too. string, int, float and etc .. any thing you want.

now getElementData returns the stored value in the given place. example:

getElementData(localPlayer,"carKeys") 

This returns us the value "true" because we set it to "true" before (look up)

What will happen if we used getElementData

on a empty place? it will return us the value "false".

Example:

getElementData(localPlayer,"watchPocket") 

It returns false because the place "watchPocket" is empty. we stored nothing in it.

Example of script using element data to shortcut coding on shops resource:

idea : creating a marker and storing the data of the place and rotation it should send the player too when the player hit it and also creates a marker to exit that place.

"x,y,z" are the positions of the enter marker

"b" is the blip of the marker and "i" is the interior that the marker that the marker will send the player to.

"ix,iy,iz,ir" are the positions of the place that the player will be sent too and "ir" is the rotation of the player when he/she enter

"emx,emy,emz" are the positions of the exit marker in the interior

"ex,ey,ez,er" are the positions that the exit marker will send the player to and "er" are the rotation of the player when he/she hit the exit marker.

for "f" which is not an argument but is it to defend whether the player will be blocked/allowed to shoot fire on marker hit or not

code:

function createShopMarkers(x,y,z,b,i,ix,iy,iz,ir,emx,emy,emz,ex,ey,ez,er) 
m = createMarker(x,y,z+1,"arrow",1.2,255,255,0,255) 
createBlipAttachedTo(m,b) 
setElementData(m,"shopMarker",true) 
setElementData(m,"i",i) 
setElementData(m,"x",ix) 
setElementData(m,"y",iy) 
setElementData(m,"z",iz) 
setElementData(m,"r",ir) 
setElementData(m,"f",false) 
e = createMarker(emx,emy,emz+1,"arrow",1.2,255,255,0,255) 
setElementInterior(e,i) 
setElementData(e,"shopMarker",true) 
setElementData(e,"i",0) 
setElementData(e,"x",ex) 
setElementData(e,"y",ey) 
setElementData(e,"z",ez) 
setElementData(e,"r",er) 
setElementData(e,"f",true) 
end 
  
function onShopMarkersHit(h,m) 
    if (getElementType(h) == "player" and m) and getElementData(source,"shopMarker") == true then 
       local i,x,y,z,r = getElementData(source,"i"),getElementData(source,"x"),getElementData(source,"y"),getElementData(source,"z"),getElementData(source,"r") 
       setElementInterior(h,i,x,y,z) 
       setElementRotation(h,0,0,r) 
       local f = getElementData(source,"f") 
       toggleControl(h,"fire",f) 
       toggleControl(h,"aim_weapon",f) 
       setPlayerHudComponentVisible(h,"radar",f) 
    end 
end 
addEventHandler("onMarkerHit",root,onShopMarkersHit) 
  
createShopMarkers(-2626.62305,208.87181,4.59640,6,4,285.66870,-84.37949,1001.51563,359.64569091797,285.75504,-86.46339,1001.51563,-2626.56763,210.01926,4.59868,2.7548522949219) 

Edited February 22, 2016 by Guest

[Noki]

That script you provided in the last example is a good example of poor use of element data. You really don't need to set the coordinates of a marker as element data. You can easily get the position with getElementPosition coupled with a marker hit event.

Element data syncs to every player. It is also insecure as it can be set client side then synced to all other players. Overuse of element data is a poor scripting practice. Try to only use element data for information that needs to be available to every player and use it sparingly.

[MAB]

That script you provided in the last example is a good example of poor use of element data. You really don't need to set the coordinates of a marker as element data. You can easily get the position with getElementPosition coupled with a marker hit event.

Element data syncs to every player. It is also insecure as it can be set client side then synced to all other players. Overuse of element data is a poor scripting practice. Try to only use element data for information that needs to be available to every player and use it sparingly.

Hahahaha. Read it well and you will see that i wasn't setting the marker position as data.

If you don't use element data functions much that doesn't mean that others do the same. You just don't know how useful they are.

[Dealman]

That script you provided in the last example is a good example of poor use of element data. You really don't need to set the coordinates of a marker as element data. You can easily get the position with getElementPosition coupled with a marker hit event.

Element data syncs to every player. It is also insecure as it can be set client side then synced to all other players. Overuse of element data is a poor scripting practice. Try to only use element data for information that needs to be available to every player and use it sparingly.

If I recall correctly MTA already uses element data for pretty much all entities. For example;

local oX, oY, oZ = getElementPosition(object) 
-- Is the same as 
local oX, oY, oZ = getElementData(object, "posX"), getElementData(object, "posY"), getElementData(object, "posZ") 

@Godbless:

Noki is right, however. You're making very poor use of the element data. The general idea is good and you can use element data for it with good results - but it's your way of executing it that is bad.

Instead of adding 7 new data entires for every marker, you could just add one containing an array instead.

Better yet, you could use tables instead of element data.

[MAB]

That script you provided in the last example is a good example of poor use of element data. You really don't need to set the coordinates of a marker as element data. You can easily get the position with getElementPosition coupled with a marker hit event.

Element data syncs to every player. It is also insecure as it can be set client side then synced to all other players. Overuse of element data is a poor scripting practice. Try to only use element data for information that needs to be available to every player and use it sparingly.

If I recall correctly MTA already uses element data for pretty much all entities. For example;

local oX, oY, oZ = getElementPosition(object) 
-- Is the same as 
local oX, oY, oZ = getElementData(object, "posX"), getElementData(object, "posY"), getElementData(object, "posZ") 

@Godbless:

Noki is right, however. You're making very poor use of the element data. The general idea is good and you can use element data for it with good results - but it's your way of executing it that is bad.

Instead of adding 7 new data entires for every marker, you could just add one containing an array instead.

Better yet, you could use tables instead of element data.

I understand, i am just giving an example of any element data use and the main and only target from it is explaining more about element data functions for better understanding.

[Noki]

That script you provided in the last example is a good example of poor use of element data. You really don't need to set the coordinates of a marker as element data. You can easily get the position with getElementPosition coupled with a marker hit event.

Element data syncs to every player. It is also insecure as it can be set client side then synced to all other players. Overuse of element data is a poor scripting practice. Try to only use element data for information that needs to be available to every player and use it sparingly.

Hahahaha. Read it well and you will see that i wasn't setting the marker position as data.

If you don't use element data functions much that doesn't mean that others do the same. You just don't know how useful they are.

I didn't read the code properly, you're right. My apologies.

I do use element data, but I use it only when I need to. For example, I have a script that calculates a percentage that is required client side, but the calculations themselves are performed server-side for standardization purposes. I use element data so it gets synced client-side without having to use triggerClientEvent and keep client variable in check. I don't use it for markers as I find tables are much cleaner. I am aware of how useful element data is when used correctly.

I was just saying I thought your usage of it in your example was poor. If you're going to write a tutorial, do it properly.

If I recall correctly MTA already uses element data for pretty much all entities.

Wow, TIL.

[MAB]

I understand, i am just giving an example of any element data use and the main and only target from it is explaining more about element data functions for better understanding.

[Bonus]

You should really write that element data should be avoided if not necessary.

I see so many guys here using setElementData for every little storage.

Your last code is the best example how to make your code as unperformant as possible.

Only use setElementData if you want something to be synced with every player and every resource + if it's not that bad if someone changes it (NOT adminlevel, NOT money etc.)

If you only want it clientsided you can use triggerClientEvent and save it serversided in a table.

If you only want it serversided, use a table.

If you want to use it in another resources, use export functions.

Here a quote from sbx320:

I'd suggest you to use a custom system based upon triggerClientEvent, since element datas have a few issues:

They're synced to everyone

Whenever you change an Elementdata on the server/client the information will be synced to any connected client. This is often not necessary, but simply a waste of bandwidth. Why would a remote player be required to know the exact amount of fuel in a vehicle far away? That information is only useful for the driver of the vehicle, so you'd waste a ton of bandwidth which could be used by MTA for better synchronization.

Anyone can modify them

Without some additional security scripts (which is easily possible, but often overlooked) any client can modify Elementdatas of any element. This allows cheaters with modified clients to cheat themselves various things like money or even admin rights.

[MAB]

You should really write that element data should be avoided if not necessary.

I see so many guys here using setElementData for every little storage.

Your last code is the best example how to make your code as unperformant as possible.

Only use setElementData if you want something to be synced with every player and every resource + if it's not that bad if someone changes it (NOT adminlevel, NOT money etc.)

If you only want it clientsided you can use triggerClientEvent and save it serversided in a table.

If you only want it serversided, use a table.

If you want to use it in another resources, use export functions.

Here a quote from sbx320:

I'd suggest you to use a custom system based upon triggerClientEvent, since element datas have a few issues:

They're synced to everyone

Whenever you change an Elementdata on the server/client the information will be synced to any connected client. This is often not necessary, but simply a waste of bandwidth. Why would a remote player be required to know the exact amount of fuel in a vehicle far away? That information is only useful for the driver of the vehicle, so you'd waste a ton of bandwidth which could be used by MTA for better synchronization.

Anyone can modify them

Without some additional security scripts (which is easily possible, but often overlooked) any client can modify Elementdatas of any element. This allows cheaters with modified clients to cheat themselves various things like money or even admin rights.

Done