TriggerClientEvent: Difference between revisions
No edit summary |
m (→See Also) |
||
(20 intermediate revisions by 11 users not shown) | |||
Line 2: | Line 2: | ||
-->__NOTOC__ | -->__NOTOC__ | ||
{{Server function}} | {{Server function}} | ||
This function triggers an event previously registered on a client. This is the primary means of passing information between the server and the client. Clients have a similar [[triggerServerEvent]] function that can do the reverse. You can treat this function as if it was an asynchronous function call, using [[triggerServerEvent]] to pass back any returned information if necessary. | This function triggers an event previously registered on a client. This is the primary means of passing information between the server and the client. Clients have a similar [[triggerServerEvent]] function that can do the reverse. You can treat this function as if it was an asynchronous function call, using [[triggerServerEvent]] to pass back any returned information if necessary. | ||
Almost any data types can be passed as expected, including [[element]]s and complex nested [[table]]s. Non-element MTA data types like xmlNodes or resource pointers will not be able to be passed as they do not necessarily have a valid representation on the client. | Almost any data types can be passed as expected, including [[element]]s and complex nested [[table]]s. Non-element MTA data types like xmlNodes or resource pointers will not be able to be passed as they do not necessarily have a valid representation on the client. | ||
Line 8: | Line 8: | ||
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. | 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. | ||
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. | 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'''. | ||
{{Important Note | Non-element MTA data types like xmlNodes or resource pointers will not be able to be passed as they do not necessarily have a valid representation on the client.}} | |||
{{Note|It is marginally more efficient to pass one large event than two smaller ones.}} | |||
==Syntax== | ==Syntax== | ||
<syntaxhighlight lang="lua"> | <syntaxhighlight lang="lua"> | ||
bool triggerClientEvent ( [table/element sendTo=getRootElement()] | bool triggerClientEvent ( [ table/element sendTo = getRootElement(), ] string name, element sourceElement [, arguments... ] ) | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Line 17: | Line 20: | ||
*'''name:''' 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]]. | *'''name:''' 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]]. | ||
*'''sourceElement:''' The element that is the [[Event system#Event handlers|source]] of the event. | *'''sourceElement:''' The element that is the [[Event system#Event handlers|source]] of the event. | ||
{{Note|To save client CPU, you should avoid setting | {{Important Note|To save client CPU, you should avoid setting theElement to the [[root]] element where possible - it should be used as a last resort (rather questionable thing to do, limited to very specific tasks, if any). Using target element ([[player]] who should receive event, if expected to be delivered to particular one) is preferred and highly advisable. [[resourceRoot]] can also be used as alternative choice, if [[addEventHandler]] is bound to [[root]] element, or to [[resourceRoot]] when there is need to restrict event to single certain resource.}} | ||
===Optional Arguments=== | ===Optional Arguments=== | ||
Line 37: | Line 40: | ||
end | end | ||
addEvent( "onGreeting", true ) | addEvent( "onGreeting", true ) | ||
addEventHandler( "onGreeting", | addEventHandler( "onGreeting", localPlayer, greetingHandler ) | ||
</syntaxhighlight> | </syntaxhighlight> | ||
</section> | </section> | ||
Line 43: | Line 46: | ||
<syntaxhighlight lang="lua"> | <syntaxhighlight lang="lua"> | ||
function greetingCommand ( playerSource, commandName ) | function greetingCommand ( playerSource, commandName ) | ||
triggerClientEvent ( "onGreeting", | triggerClientEvent ( playerSource, "onGreeting", playerSource, "Hello World!" ) | ||
end | end | ||
addCommandHandler ( "greet", greetingCommand ) | addCommandHandler ( "greet", greetingCommand ) | ||
Line 60: | Line 63: | ||
end | end | ||
addEvent( "onGreeting", true ) | addEvent( "onGreeting", true ) | ||
addEventHandler( "onGreeting", | addEventHandler( "onGreeting", localPlayer, greetingHandler ) | ||
</syntaxhighlight> | </syntaxhighlight> | ||
</section> | </section> | ||
Line 69: | Line 72: | ||
local thePlayer = getPlayerFromName ( playerName ) | local thePlayer = getPlayerFromName ( playerName ) | ||
if thePlayer then | if thePlayer then | ||
triggerClientEvent ( thePlayer, "onGreeting", | triggerClientEvent ( thePlayer, "onGreeting", thePlayer, "Hello World!" ) | ||
else | else | ||
-- invalid player name specified | -- invalid player name specified | ||
Line 82: | Line 85: | ||
This works like the first example except an extra ''thePlayer'' argument is specified for triggerClientEvent. | This works like the first example except an extra ''thePlayer'' argument is specified for triggerClientEvent. | ||
===Example 3=== | |||
This example uses resourceRoot to avoid being called by resources other than the same one that was created. (it can still be circumvented with [[getResourceRootElement]] but it makes it more difficult for cheating players). | |||
<section name="Client" class="client" show="true"> | |||
<syntaxhighlight lang="lua"> | |||
function nameFunction(message) | |||
if source == resourceRoot then | |||
outputChatBox(message) | |||
end | |||
end | |||
addEvent("toClientSide", true ) | |||
addEventHandler("toClientSide", resourceRoot, nameFunction) | |||
</syntaxhighlight> | |||
</section> | |||
<section name="Server" class="server" show="true"> | |||
<syntaxhighlight lang="lua"> | |||
function commandFunction(source) | |||
triggerClientEvent(source, "toClientSide", resourceRoot, "Hello World!") | |||
end | |||
addCommandHandler("cool", commandFunction) | |||
</syntaxhighlight> | |||
</section> | |||
==Changelog== | ==Changelog== | ||
Line 88: | Line 114: | ||
==See Also== | ==See Also== | ||
{{Event functions}} | {{Event functions|server}} | ||
[[ru:triggerClientEvent]] | [[ru:triggerClientEvent]] |
Latest revision as of 22:33, 6 September 2024
This function triggers an event previously registered on a client. This is the primary means of passing information between the server and the client. Clients have a similar triggerServerEvent function that can do the reverse. You can treat this function as if it was an asynchronous function call, using triggerServerEvent to pass back any returned information if necessary.
Almost any data types can be passed as expected, including elements and complex nested tables. Non-element MTA data types like xmlNodes or resource pointers will not be able to be passed as they do not necessarily have a valid representation on the client.
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.
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.
Important Note: Non-element MTA data types like xmlNodes or resource pointers will not be able to be passed as they do not necessarily have a valid representation on the client. |
Syntax
bool triggerClientEvent ( [ table/element sendTo = getRootElement(), ] string name, element sourceElement [, arguments... ] )
Required Arguments
- name: 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.
- sourceElement: The element that is the source of the event.
Important Note: To save client CPU, you should avoid setting theElement to the root element where possible - it should be used as a last resort (rather questionable thing to do, limited to very specific tasks, if any). Using target element (player who should receive event, if expected to be delivered to particular one) is preferred and highly advisable. resourceRoot can also be used as alternative choice, if addEventHandler is bound to root element, or to resourceRoot when there is need to restrict event to single certain resource. |
Optional Arguments
NOTE: When using optional arguments, you might need to supply all arguments before the one you wish to use. For more information on optional arguments, see optional arguments.
- sendTo: The event will be sent to all players that are children of the specified element. By default this is the 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.
- arguments...: A list of arguments to trigger with the event. You can pass any lua data type (except functions). You can also pass elements.
Returns
Returns true if the event trigger has been sent, false if invalid arguments were specified.
Example
Example 1
This example shows how you can pass a simple "Hello World" message from the server to the all the clients using an event.
function greetingHandler ( message ) outputChatBox ( "The server says: " .. message ) end addEvent( "onGreeting", true ) addEventHandler( "onGreeting", localPlayer, greetingHandler )
function greetingCommand ( playerSource, commandName ) triggerClientEvent ( playerSource, "onGreeting", playerSource, "Hello World!" ) end addCommandHandler ( "greet", greetingCommand )
When the command "greet" is executed (by typing it in the server console or the player's console), the server's greetingCommand function is called. This triggers the client side event onGreeting with the string "Hello World!". This event is then handled by the greetingHandler function client side which then displays the message.
Example 2
This example shows how you can pass a simple "Hello World" message from the server to a single client using an event.
function greetingHandler ( message ) outputChatBox ( "The server says: " .. message ) end addEvent( "onGreeting", true ) addEventHandler( "onGreeting", localPlayer, greetingHandler )
function greetingCommandOne ( playerSource, commandName, playerName ) if playerName then local thePlayer = getPlayerFromName ( playerName ) if thePlayer then triggerClientEvent ( thePlayer, "onGreeting", thePlayer, "Hello World!" ) else -- invalid player name specified end else -- No player name specified end end addCommandHandler ( "greet_one", greetingCommandOne )
This works like the first example except an extra thePlayer argument is specified for triggerClientEvent.
Example 3
This example uses resourceRoot to avoid being called by resources other than the same one that was created. (it can still be circumvented with getResourceRootElement but it makes it more difficult for cheating players).
function nameFunction(message) if source == resourceRoot then outputChatBox(message) end end addEvent("toClientSide", true ) addEventHandler("toClientSide", resourceRoot, nameFunction)
function commandFunction(source) triggerClientEvent(source, "toClientSide", resourceRoot, "Hello World!") end addCommandHandler("cool", commandFunction)
Changelog
Version | Description |
---|
1.3.0-9.04570 | Added option to use a list of player elements for the 'sendTo' argument |