You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: functions/Event/triggerClientEvent.yaml
+16-21Lines changed: 16 additions & 21 deletions
Original file line number
Diff line number
Diff line change
@@ -3,21 +3,13 @@ server:
3
3
description: |
4
4
This function triggers an event previously registered on a client.
5
5
This is the primary means of passing information between the server and the client.
6
-
Clients have a similar [triggerServerEvent](/reference/triggerServerEvent "TriggerServerEvent")
7
-
function that can do the reverse. You can treat this function as if it was an
8
-
asynchronous function call, using [triggerServerEvent](/reference/triggerServerEvent
9
-
"TriggerServerEvent") to pass back any returned information if necessary.
10
-
11
-
Almost any data types can be passed as expected, including [elements](/reference/Element "Element") and complex nested [tables](/reference/table "Table"). Non-element MTA data types like [xmlNodes](/reference/xmlnode "XML Node") or resource pointers will not be able to be passed as they do not necessarily have a valid representation on the client.
12
-
13
-
Events are sent reliably, so clients will receive them, but there may be (but shouldn't be) a significant delay before they are received. You should take this into account when using them.
14
-
15
-
Keep in mind the bandwidth issues when using events - don't pass a large list of arguments unless you really need to. It is marginally more efficient to pass one large event than two smaller ones.
6
+
Clients have a similar [[triggerServerEvent]] function that can do the reverse. You can treat this function as if it was an
7
+
asynchronous function call, using [[triggerServerEvent]] to pass back any returned information if necessary.
16
8
parameters:
17
9
- name: sendTo
18
10
type: 'table/element'
19
11
description: The event will be sent to all [players](/reference/player "Player") that are children of the specified element. By default this is the [root](/reference/root "Root") element, and hence the event is sent to all players. If you specify a single player it will just be sent to that player. This argument can also be a table of player elements.
20
-
default: getRootElement(
12
+
default: getRootElement()
21
13
- name: name
22
14
type: string
23
15
description: The name of the event to trigger client side. You should register this event with [[addEvent]] and add at least one event handler using [[addEventHandler]].
@@ -44,17 +36,20 @@ server:
44
36
arguments were specified.
45
37
notes:
46
38
- type: info
47
-
content: It is marginally more efficient to pass one large event than two smaller
48
-
ones.
39
+
content: |
40
+
- Almost any data types can be passed as expected, including [elements](/reference/Element "Element") and complex nested [tables](/reference/table "Tables"). Non-element MTA data types like [xmlNodes](/reference/xmlnode "XML Node") or resource pointers will not be able to be passed as they do not necessarily have a valid representation on the client. **Elements of the [Vector](/reference/Vector "Vector") or [Matrix](/reference/Matrix "Matrix") classes cannot be passed!**
41
+
- Events are sent reliably, so clients will receive them, but there may be (but shouldn't be) a significant delay before they are received. You should take this into account when using them.
42
+
- Keep in mind the bandwidth issues when using events - don't pass a large list of arguments unless you really need to. It is marginally more efficient to pass one large event than two smaller ones.
49
43
- type: important
50
44
content: |
51
-
- Non-element MTA data types like [xmlNodes](/reference/xmlnode "XML Node") or resource pointers will not
52
-
be able to be passed as they do not necessarily have a valid representation
53
-
on the client.
54
-
- To save client CPU, you should avoid setting theElement to the [root](/reference/root "Root") element
45
+
To save client CPU, you should avoid setting theElement to the [root] element
55
46
where possible - it should be used as a last resort (rather questionable thing
56
-
to do, limited to very specific tasks, if any). Using target element ( [player](/reference/player "Player")
47
+
to do, limited to very specific tasks, if any). Using target element [[player]]
57
48
who should receive event, if expected to be delivered to particular one) is
58
-
preferred and highly advisable. [resourceRoot](/reference/resourceRoot "ResourceRoot") can also be used as alternative
59
-
choice, if [addEventHandler](/reference/addEventHandler "addEventHandler") is bound to [root](/reference/root "Root") element, or to [resourceRoot](/reference/resourceRoot "ResourceRoot") when
60
-
there is need to restrict event to single certain resource.
49
+
preferred and highly advisable. [[resourceRoot]] can also be used as alternative
50
+
choice, if [[addEventHandler]] is bound to [[root]] element, or to [[resourceRoot]] when
51
+
there is need to restrict event to single certain resource.
52
+
meta:
53
+
- changelog:
54
+
- version: 1.3.0-9.04570
55
+
description: Added option to use a list of player elements for the **sendTo** argument.
Copy file name to clipboardExpand all lines: functions/Event/triggerEvent.yaml
+3-2Lines changed: 3 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -4,11 +4,12 @@ shared:
4
4
a specific [[element]] in the [element tree](/reference/Element_tree
5
5
"Element tree"). See [event system](/reference/Event_System "Event System") for more
6
6
information on how the event system works.
7
-
You can use the value returned from this function to determine if the event was cancelled by one of the event handlers. You should determine what your response (if any) to this should be based on the event's purpose. Generally, cancelling an event should prevent any further code being run that is dependent on whatever triggered that event. For example, if you have an onFlagCapture event, cancelling it would be expected to prevent the flag being able to be captured. Similarly, if you have onPlayerKill as an event you trigger, canceling it would either be expected to prevent the player being killed from dying or at least prevent the player from getting a score for it.
7
+
8
+
You can use the value returned from this function to determine if the event was cancelled by one of the event handlers. You should determine what your response (if any) to this should be based on the event's purpose. Generally, cancelling an event should prevent any further code being run that is dependent on whatever triggered that event. For example, if you have an `onFlagCapture` event, cancelling it would be expected to prevent the flag being able to be captured. Similarly, if you have `onPlayerKill` as an event you trigger, canceling it would either be expected to prevent the player being killed from dying or at least prevent the player from getting a score for it.
8
9
parameters:
9
10
- name: eventName
10
11
type: string
11
-
description: The name of the event you wish to trigger
12
+
description: The name of the event you wish to trigger.
12
13
- name: baseElement
13
14
type: element
14
15
description: The element you wish to trigger the event on. See [event system](/reference/Event_System "Event System") for
0 commit comments