Trigger/tables

[IIYAMA]

23 minutes ago, majqq said:

What i want to say it's good habit to send whole table with updated data instead of sending only certain indexes?

only on initialization, it is a good idea to send the whole table. Else it is just a waste of data including the risks of de-synchronize the data.

[ds1-e]

On 09/08/2019 at 22:40, IIYAMA said:

only on initialization, it is a good idea to send the whole table. Else it is just a waste of data including the risks of de-synchronize the data.

Does triggerEvent have a big performance impact on same side? Need to ask, because i thought about separating some parts of code on certain files. 

Edited September 17, 2019 by majqq

[IIYAMA]

1 hour ago, majqq said:

Does triggerEvent have a big performance impact on same side? Need to ask, because i thought about separating some parts of code on certain files. 

A lot more than exports yes. Events are global.

But that doesn't mean they are bad. They can be very useful for `events`.

But if you can use exports, those can handle really a lot of data. If you observe those closely, you could even write your own event scope based on exports.

 

---

 

The main issues lie with:

• Propagation (while triggering)

Like you do this:

setElementPosition(root, 0,0,0)

This will move every possible element to 0,0,0. Players, vehicles, objects, peds, elements without physics.

 

And for triggerServerClient event, no it probably doesn't send multiple messages (I hope lol).

But it does go over every element.

 

This might give the lowest impact. Not sure if propagation will help if there are no children, but at least it will not search for children.

local element = createElement("triggerElements", "resource-" .. getResourceName(getThisResource()))
setElementCallPropagationEnabled ( element, false)

 

• With the amount of listeners. The longer this list the longer it takes. (depending on the context)

 

 

 

[ds1-e]

On 17/09/2019 at 19:56, IIYAMA said:

A lot more than exports yes. Events are global.

But that doesn't mean they are bad. They can be very useful for `events`.

But if you can use exports, those can handle really a lot of data. If you observe those closely, you could even write your own event scope based on exports.

 

---

 

The main issues lie with:

• Propagation (while triggering)

Like you do this:

setElementPosition(root, 0,0,0)

This will move every possible element to 0,0,0. Players, vehicles, objects, peds, elements without physics.

 

And for triggerServerClient event, no it probably doesn't send multiple messages (I hope lol).

But it does go over every element.

 

This might give the lowest impact. Not sure if propagation will help if there are no children, but at least it will not search for children.

local element = createElement("triggerElements", "resource-" .. getResourceName(getThisResource()))
setElementCallPropagationEnabled ( element, false)

 

• With the amount of listeners. The longer this list the longer it takes. (depending on the context)

 

 

 

 

Exports are faster? I mean that this events will be in same resource, just another file on same side, also they would be attached to resourceRoot. 

Edited September 20, 2019 by majqq

[IIYAMA]

1 hour ago, majqq said:

Exports are faster? I mean that this events will be in same resource, just another file on same side, also they would be attached to resourceRoot. 

Have you noticed that the event system is Asynchronous? (You can't make use of the return keyword functionality after all. Stopping the code with it does work.)

And exports are Synchronous. (You can use the return keyword to return values)

 

 

An understanding of what I am talking about in JavaScript:

 

After you watched this, you know which one is way faster.

 

Edited September 20, 2019 by IIYAMA