TriggerLatentClientEvent: Difference between revisions
m (→Example) |
Fernando187 (talk | contribs) (Remove obsolete Requirements section) |
||
(4 intermediate revisions by 3 users not shown) | |||
Line 18: | Line 18: | ||
*'''bandwidth:''' The bytes per second rate to send the data contained in the arguments. | *'''bandwidth:''' The bytes per second rate to send the data contained in the arguments. | ||
*'''persist:''' A bool indicating whether the transmission should be allowed to continue even after the resource that triggered it has since stopped. | *'''persist:''' A bool indicating whether the transmission should be allowed to continue even after the resource that triggered it has since stopped. | ||
*'''arguments...:''' A list of arguments to trigger with the event. You can pass any | *'''arguments...:''' A list of arguments to trigger with the event. You can pass any Lua data type (except functions). You can also pass [[element]]s. The total amount of data should not exceed 100MB. | ||
===Returns=== | ===Returns=== | ||
Returns ''true'' if the event trigger has been sent, ''false'' if invalid arguments were specified. | Returns ''true'' if the event trigger has been sent, ''false'' if invalid arguments were specified. | ||
===triggerClientEvent vs triggerLatentClientEvent test by DreTaX=== | |||
I used a simple outputChatBox test, and devtools to see the performance results. | |||
Using triggerClientEvent will immediately launch all the data to the client, and will end faster | |||
however when using triggerLatentClientEvent, the server needs an unnoticeable (really small) amount of time to launch | |||
up the event in to a thread. This gives benefits to your server, because as stated above, using latent event the server resource uses 0% CPU (Doesn't hold the main thread back), | |||
but when using the normal trigger It gave me a 15% CPU usage. | |||
Putting both of these in a loop will provide you sufficient understanding. | |||
<syntaxhighlight lang="lua"> | |||
for i = 1, 10000 do | |||
--trigger the event to client side using one of the functions. | |||
end | |||
</syntaxhighlight> | |||
I suggest using latent event instead to ensure your server won't hold back to any sync struggles. | |||
==Example== | ==Example== | ||
Line 44: | Line 58: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
</section> | </section> | ||
==Changelog== | ==Changelog== | ||
Line 53: | Line 64: | ||
==See Also== | ==See Also== | ||
{{Event functions}} | {{Event functions|server}} |
Latest revision as of 15:45, 7 November 2024
This function is the same as triggerClientEvent except the transmission rate of the data contained in the arguments can be limited and other network traffic is not blocked while the data is being transferred.
Syntax
bool triggerLatentClientEvent ( [table/element sendTo=getRootElement(),] string name, [int bandwidth=50000,] [bool persist=false,] element theElement, [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.
- theElement: The element that is the source of the event. This could be another player, or if this isn't relevant, use the root element.
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.
- bandwidth: The bytes per second rate to send the data contained in the arguments.
- persist: A bool indicating whether the transmission should be allowed to continue even after the resource that triggered it has since stopped.
- arguments...: A list of arguments to trigger with the event. You can pass any Lua data type (except functions). You can also pass elements. The total amount of data should not exceed 100MB.
Returns
Returns true if the event trigger has been sent, false if invalid arguments were specified.
triggerClientEvent vs triggerLatentClientEvent test by DreTaX
I used a simple outputChatBox test, and devtools to see the performance results. Using triggerClientEvent will immediately launch all the data to the client, and will end faster however when using triggerLatentClientEvent, the server needs an unnoticeable (really small) amount of time to launch up the event in to a thread. This gives benefits to your server, because as stated above, using latent event the server resource uses 0% CPU (Doesn't hold the main thread back), but when using the normal trigger It gave me a 15% CPU usage. Putting both of these in a loop will provide you sufficient understanding.
for i = 1, 10000 do --trigger the event to client side using one of the functions. end
I suggest using latent event instead to ensure your server won't hold back to any sync struggles.
Example
addEvent("onClientReadFile",true) addEventHandler("onClientReadFile",root,function(data) local file = fileCreate("text.txt") --Save "data" into "text.txt" fileWrite(file,data) fileClose(file) end)
if fileExists("text.txt") then file = fileOpen("test.txt") --Open a file (you can create it yourself). local data = fileRead(file,100*1024*1024) --Max 100 MB fileClose(file) --Close File triggerLatentClientEvent("onClientReadFile",5000,false,root,data) --trigger - Avoid triggering to root element (Read note above) end
Changelog
Version | Description |
---|
1.3.0-9.04570 | Added option to use a list of player elements for the 'sendTo' argument |
See Also
- getCancelReason
- triggerClientEvent
- triggerLatentClientEvent
- Shared
- addEvent
- addEventHandler
- cancelEvent
- cancelLatentEvent
- getEventHandlers
- getLatentEventHandles
- getLatentEventStatus
- removeEventHandler
- triggerEvent
- wasEventCancelled