Element data: Difference between revisions
No edit summary |
mNo edit summary |
||
| (7 intermediate revisions by 6 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. | 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 functions== | ||
* | * [[setElementData]]: sets 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: | [[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
- setElementData: sets 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.