Question about triggering

[Overkillz]

Hello dear community, Im having a question about which one is the best way to do a trigger (From server to client)

Well, my problem is that Im dealing with different rooms for players. Obyously for each room I have stored the players in different arrays depending of the room. When the player joins into a room I set them a data with the roomID

So, imagine, I want to create a deathlist that draw the player who has just dead in the same room as me.

Here goes my question, whats the best way to do it.

#1 - Make a loop with the array that contents the list of players in the room and do the trigger to each one. (Something like this)

for i,k in pairs(room) do
	trigger ...
end

#2 - Make a trigger to all the players using root and later in the clientside check if the room player data is the same as mine one.

Im not sure when you make a trigger to root players it does a loop to all the players or it just uses an efficent method.

Thanks for reading, I hope you can bring me a hand.

Regards.

Edited November 20, 2019 by Overkillz

[IIYAMA]

1 hour ago, Overkillz said:

Thanks for reading, I hope you can bring me a hand.

You do not need to use a loop, you can also provide a table with players as the first argument.

 

When streaming data, root is perfect.

 

But for bring data from one side to the otherside, with the purpose to help with initial loading (prepare the client before using the resource), making use of the root might be a bad idea.

You have no guarantee that the client has loaded his resource, which means you do not know if he can receive it.

In that case you only want to send a message to the players that have downloaded and loaded the resource.

client > onClientResourceStart > triggerServerEvent > server > add the player to the the table 'loadedPlayers = {}'

+ send all the server-to-client initial data  > triggerClientEvent > client

 

 

 

 

 

 

[Overkillz]

I got it, thanks so much. I wasn't aware that trigger allows to use tables as argument instead players.

I will take care about using root. Looks like is not a good choice if im dealing with different rooms which practical need to send few datas.

Thanks newly

[Overkillz]

Sorry for bumping this topic again, but ...

I have just been trying to use the table to trigger instead looping the table that containts the player.

So, I have just face off with some issues like

Previously I used to do the trigger like everyone (It works perfectly)

for i,player in ipairs(arenaSrv.players) do
	triggerClientEvent(player,"onDestroyCurrentMap",player)
end

So I decided to test to use the table (It drops me the warning previously mentioned),

triggerClientEvent(arenaSrv.players,"onDestroyCurrentMap",arenaSrv.players)

but looks like there is a problem with the 3rd argument. I tried to read carefully the definition at the wiki but I can't get it at all.

Might the right way to do it is the following one?

triggerClientEvent("onDestroyCurrentMap",root,arenaSrv.players)

However, Im worried that the event is triggered wrongly..

Thanks for reading.

Edited November 20, 2019 by Overkillz

[IIYAMA]

32 minutes ago, Overkillz said:

So I decided to test to use the table (It drops me the warning previously mentioned),

triggerClientEvent(arenaSrv.players,"onDestroyCurrentMap",arenaSrv.players)

You filled in a table as base element. Base elements do not decide which players receive the event. They are only used for the addEventHandlers.

 

 

triggerClientEvent(arenaSrv.players,"onDestroyCurrentMap",resourceRoot)

 

addEvent("onDestroyCurrentMap", true)
addEventHandler("onDestroyCurrentMap", resourceRoot, function () 
  
end, false --[[ << Disable propagation ]])

 

 

 

 

[Overkillz]

Alright,  thanks mate. The same way is applicable to triggerEvent ?

triggerEvent("onDestroyCurrentMap",arenaSrv.players,arg)

 

[IIYAMA]

31 minutes ago, Overkillz said:

Alright,  thanks mate. The same way is applicable to triggerEvent ?

triggerEvent("onDestroyCurrentMap",arenaSrv.players,arg)

 

triggerEvent("onDestroyCurrentMap",arenaSrv.players,arg)

TriggerEvent is not used to be send to players or to the server. It stays on the same side as it is triggered from.

so yes, the same adjustment to the code:

triggerEvent("onDestroyCurrentMap",resourceRoot,arg)

 

 

In case of cross resource triggering: (two different resources)

addEvent("onDestroyCurrentMap", true)
addEventHandler("onDestroyCurrentMap", root, function () 
  
end, true --[[ << Enable propagation ]])

 

 

[Overkillz]

Well, I've got 2 new doubts about this. The first one is that if I haven't the event created in the same resource, I must use root instead resourceRoot right ? However this creates me another doubt that If can create a "Fake Empty" event in the same resource with the propagation enabled. Also, all the "extra" resources must have enabled the propagation in the "Method 2 from Right way to to use the trigger" that comes below

Spoiler

--####### RESOURCE 1
-- SERVER SIDE
triggerEvent("onDestroyCurrentMap",resourceRoot,arg)

-- CLIENT SIDE
-- It doesn't containt the event onDestroyCurrentMap

--####### RESOURCE 2
-- CLIENT SIDE
addEvent("onDestroyCurrentMap", true)
addEventHandler("onDestroyCurrentMap", root, function () 

end, true --[[ << Enable propagation ]])

--###############
--## RIGHT WAY TO USE THE TRIGGER ?
--###############

--METHOD 1
--####### RESOURCE 1
-- SERVER SIDE
triggerEvent("onDestroyCurrentMap",root,arg)

--METHOD 2
-- SERVER SIDE
triggerEvent("onDestroyCurrentMap",resourceRoot,arg)

-- CLIENT SIDE
addEvent("onDestroyCurrentMap", true)
addEventHandler("onDestroyCurrentMap", root, function () 

end, true --[[ << Enable propagation ]])

--####### RESOURCE 2,3,4,n...
-- CLIENT SIDE
addEvent("onDestroyCurrentMap", true)
addEventHandler("onDestroyCurrentMap", root, function () 

end, true --[[ << Enable propagation ]])

 

Well, my second question is, leaving out the extra question I've got previously,

In case I want to use triggerClientEvent() just for the player when he joins the room should I do it like this

triggerClientEvent(source, "onPlayerJoinRoom", source, arg)

or

triggerClientEvent(source, "onPlayerJoinRoom", root, arg)

I need to clear out that the function onPlayerJoinRoom is managed by other resources aswell

Thats all for now, thanks for helping me newly @IIYAMA, best regards.

Edited November 21, 2019 by Overkillz

[IIYAMA]

8 hours ago, Overkillz said:

The first one

It starts with the addEventHandler, which is called in JavaScript the addEventListener. (might have been a better name)

This attached handler is something that listens to events, as if it is a microphone which listens to everything you say.

 

But there is a catch, the listener/handler does have a filter ability. It does only it's thing (calling the function attached to it, when all conditions are met. This makes sure that not every addEventHandler triggers for every event.

 

The first filter moment is the eventName.

"onPlayerJoinRoom"

Only eventHandlers do trigger with the exact same event.

 

 

The second filter moment is the baseElement.

local baseElement = root

triggerClientEvent(source, "onPlayerJoinRoom", baseElement, arg)

 

local handlerElement = root

addEvent("onPlayerJoinRoom", true)
addEventHandler("onPlayerJoinRoom", handlerElement, 
function () 
  
end)

 

---

 

Trigger

"onPlayerJoinRoom"

 

Rules

- If the baseElement is the same as the handlerElement.

OR

- If the baseElement is an (indirect) child of the handlerElement. AND propagation enabled

<root>
	<console/>
	<player dontRespawn="false"/>
	<player dontRespawn="false" lastSpawnarea=""/>
	<resource id="resourcebrowser"/>
	<resource id="assault">
		<map id="dynamic">
			<team/>
			<team/>
			<blip/>
			<marker/>
			<colshape/>
			<blip/>
			<blip/>
		</map>
	</resource>
</root>

 

Root parent > console child

Root parent > player child

Root parent > resource child

Resource parent > map child

Map parent > team child

Map parent > marker child

 

See element tree:

https://wiki.multitheftauto.com/wiki/Element_tree

 

 

Feedback

Call the handler function

 

 

 

 

 

 

 

 

 

 

 

Edited November 21, 2019 by IIYAMA