Element data: Difference between revisions

From Multi Theft Auto: Wiki
Jump to navigation Jump to search
(Updated)
mNo edit summary
 
(5 intermediate revisions by 5 users not shown)
Line 1: Line 1:
Each [[element]] that is loaded is able to have [[element data]] values attached to it. These are values that can be accessed using a keyword string and directly correspond to the element's attributes in the map file, unless changed via scripting. Element data is a good way to store distributed information you want associated with an element, for example you could use it to associate a score with a player, or a team with a vehicle.
Each [[element]] that is loaded is able to have [[element data]] values attached to it. These are values that can be accessed using a keyword string and directly correspond to the element's attributes in the map file, unless changed via scripting. Element data is a good (but expensive) way to store distributed information you want associated with an element, for example you could use it to associate a score with a player, or a team with a vehicle.


Element data is synchronized between the server and the client. Setting data from any of the two sides will force an update in the other, triggering the corresponding element data change events. This is very useful, as it provides a simple way to keep element properties synced without having to set special events to do it manually.
Element data is synchronized by default between the server and the client (you can disable it via fourth argument in [[setElementData]]. Setting data from any of the two sides will force an update in the other, triggering the corresponding element data change events. This is very useful, as it provides a simple way to keep element properties synced without having to set special events to do it manually.  This also means that excessive use of element data to store variables that are not required by both server and client becomes a waste of bandwidth.


Since not all datatypes can be packetized to be transferred, there are some restrictions. The types that cannot be stored as element data are ''non-element userdata'' (see [[MTA Classes]]), ''functions'' and ''threads''. Also, you may not send tables which contain one or more values of any of these types.
Since not all data types can be packetized to be transferred, there are some restrictions. The types that cannot be stored as element data are ''non-element userdata'' (see [[MTA Classes]]), ''functions'' and ''threads''. Also, you may not send tables which contain one or more values of any of these types.


==Relevant functions==
==Relevant functions==
* [[setElementData]]: Sets an element data value.
* [[setElementData]]: sets an element data value.
* [[getElementData]]: Retrieve an element data value.
* [[getElementData]]: retrieves an element data value.
 
==Relevant events==
* [[onElementDataChange]]: triggered on the server after element data is changed.
* [[onClientElementDataChange]]: triggered on the client after element data is changed.
[[pt-br:Element_data]]
[[pl:Element data]]
 
[[Category:Scripting Concepts]]

Latest revision as of 16:52, 12 September 2024

Each element that is loaded is able to have element data values attached to it. These are values that can be accessed using a keyword string and directly correspond to the element's attributes in the map file, unless changed via scripting. Element data is a good (but expensive) way to store distributed information you want associated with an element, for example you could use it to associate a score with a player, or a team with a vehicle.

Element data is synchronized by default between the server and the client (you can disable it via fourth argument in setElementData. Setting data from any of the two sides will force an update in the other, triggering the corresponding element data change events. This is very useful, as it provides a simple way to keep element properties synced without having to set special events to do it manually. This also means that excessive use of element data to store variables that are not required by both server and client becomes a waste of bandwidth.

Since not all data types can be packetized to be transferred, there are some restrictions. The types that cannot be stored as element data are non-element userdata (see MTA Classes), functions and threads. Also, you may not send tables which contain one or more values of any of these types.

Relevant functions

Relevant events