[Discussion] Need Advise

[maartehhh]

Hi there.

I want to make a periodic resource system. I made a trigger for each team which consists of 3 players. See attachment for the trigger I made for that (I made of of this trigger, for each team seperately). There are 2 teams, so there is a total amount of 6 players.


The action General - Wait has a time variable [Real]. The real can be modified for each team.

Now, I want to make it personally, that player can modify the real on their own when they made a certain upgrade.


So to accomplish this I can make 6 seperate triggers for each player with a var [Real] with an array of 6.

But my question. The trigger runs every 0.5 sec at slowest rate, and can be reduced at a maximum of 48%. If i would make for each player a seperate trigger that would mean that every second 12 triggers will be activated and even more when the the time will be reduced in game when the var [Real] will be triggered.

I think thats maybe a bit too much triggers in that short amount of time for running a propper game. I'm afraid that the game will overrun on triggers when I use this method and cause lagg and that kind of stuff.

So I need a little bit advise about this one. Is it causing any trouble running 12 triggers and mayb up to 18 triggers per second (and not mentioned about the other triggers which can be triggered in game). Or is there maybe a more efficient way to accomplish why i'm trying to do?


Thanks for any input on this one.

Kind Regards.

 

[Muhahahahaaa]

run only one trigger and check with execution count of trigger and the modulo function which action is to run.
example: trigger runs every 0,1 seconds.
execution count modulo 5 = 1 as condition would mean it runs every 0,5 seconds (starting with 0,1 or 0,2).

 

[Dr Super Good]

Be aware the smallest resolvable time unit (smallest wait) is 1/16 game time seconds. It is impossible for anything to happen faster than that, be it timer, event or wait as the game only updates 16 times a game second. With very small values you can get break points as the period is based on game frames and not actual time. The solution in this case is parallelism or a delay pattern.

Running 12 triggers in parallel is not a problem and will not cause lag. It does eat up trigger threads (making the map more prone to too many thread trigger faults) but that is only a problem if you really run too much in parallel.

Using different triggers causes maintainability problems as a small change in one needs all others to be updated. It also may not be necessary (as hinted above, you can use 1 trigger firing every 1/16 seconds game time with a pattern of sorts).

What really causes bad performance is unit spamming (avoid hundreds of units being created every minute) and inefficient searches (going through all units on the map multiple times a frame).

 

[maartehhh]

First of all, thanks for answering.

But with that one trigger, is it possible to modify the time in that case?

as long as I know Variables won't work in Events.

@ Muhahahhahaaa: Can you show me an expample of what you mean? I never worked with that and I dont know how to start or how to make that.


@Dr Super Good: Thanks, is some good information to know.


Kinda Regards

 

[Dr Super Good]

But with that one trigger, is it possible to modify the time in that case?

Each player has its own counter that is incremented by 1. You compare this counter with a value and if it equals the value you do whatever and reset the counter. For non round numbers (not an exact fame number) you can use a pattern (an array of different counter values) that cause it to fire sooner or later so that on average the exact time is reached. Patterning is a very old technique that was used for NES games, especially to perform NTSC->PAL conversions.

The overhead is not a concern as long as the timing is correct.

 

[maartehhh]

Aahhh.. I see .. I'll try to make that.. Thanks!!

I was wondering, how many triggers can the editor trigger at the same time at maximum?

 

[Dr Super Good]

Enough to hit the limit of maximum number of active threads so there is no real limit on events running triggers. The limit comes down to how the galaxy virtual machine has a thread limit. If you create persistent threads (trigger uses wait or synchronization based calls) then you will eventually hit the thread limit and so events will fail to run the triggers as they cannot create the necessary thread.

Due to how the game engine works I think it first generates all the threads in response to events and then executes them so this does limit how many events can fire triggers at once.

The limit is multiple hundred and only very badly made maps could possibly generate that many events in a single frame.