SC2Mapster

I have been told not to use triggers like Any unit dies, any unit is created, unit takes damage, because they create lag, and I know this is true.

So are there any less laggy alternatives to using the 'any unit dies' event then a condition so the trigger only uses the unit marine (or events like this)?

I believe you are trying to prematurely optimize... Chances are a single trigger or some badly designed data will be cause for performance degradation before on death unit events like the one you listed above, even with dozens of such triggers.

Such events can cause performance problems however only if an excessive number of such triggers are running at the same time or if the workload is computationally intensive. Unit death is generally such an infrequent event that there is no problem having even 20 such events as long as the workload they run is light weight (eg not iterating through every unit on the map).

If you want this to happen only for marines then your current trigger solution is fine. If you want it for multiple unit types consider combining the triggers into a single trigger and using a case statement to filter for unit type. If you have other generic unit death events you can consider combining the triggers into a single trigger to reduce thread creation overhead.

The most efficient alternative would be to explicitly attach specific unit death events to a trigger for each unit of the type. This requires using the event bind natives as an action, something not part of the standard GUI library and must be manually added or added with a third party extension library. This way the trigger will only fire when those units die.

Any ideas?

Tried using the trigger debugger/profiler? It allows you to see where most of the time is being spent in triggers. At such low frame rates some triggers/functions must be running up significant execution times.

 

The trigger debugger/profiler can only be run when testing a map from the editor and the game must be in windowed mode for it to be selectable. It can be turned on under the editor preferences (under File menu) when the game is set to test in Windowed mode (not available in full screen mode).

 

When the map is tested, a new window will pop up which is the trigger debugger/profiler. It works entirely from a galaxy level however within the galaxy trigger names it should be obvious which GUI trigger it corresponds with. If you start to see a trigger running up times such as 300 seconds execution time over 10 minutes there is probably the case of your performance problems. AI functions are also profiled so you can see if AI is the cause.

 

If no triggers run up high execution times, then it is a data problem.

So it is not a trigger problem then as after 10 minutes you checked the profile tabs and saw no major time waster?

ImperialGood already did a great job answering this question, but I thought I'd throw out that there's a moba map that checks for unit damage to track assists. I've attached a screenshot of the event trigger. I'm in the process of updating and reworking the triggers for this map (haven't gotten to this one yet), so I still need to run the profiler to figure out if the late-game lag we sometimes experience is related to this trigger. However, this map has been out for a while and we've had no consistent problems with lag.

 

No I have not checked the profile tabs, where exactly should I look for a time waster, just so I know exactly what I am looking for?

Order by execution time total (click header) and after 10 minutes check if there are some insane numbers sticking out.  If a trigger/function is running up an execution time of 300 seconds over 10 minutes something is clearly wrong with it.

 

Late game performance problems are more likely caused by task leaks. This is when a data thread, trigger thread or actor is created and kept running for an extended period of time beyond its usefulness. Eventually enough tasks build up that game performance has to suffer as real time deadlines cannot be met.

 

Another form of late game performance problems are state complexity. What one might think of as trivial might turn out to be extremely complex to compute. If one uses this too much then eventually performance starts to suffer as game complexity increases. For example stacking a buff with a periodic effect 100 times, so as to allow its effect magnitude to increase, results in the periodic effect firing 100 times for 1 unit, instead of firing 1 time with a stronger effect. Do such a buff to 100 odd units with 100 stack count and performance might easily drop to be unplayable.

Gotcha - thanks for the tip. I'm already aware of a number of things happening on the trigger side that aren't being cleaned up properly, but I haven't found any serious issues. My suspicion has been that the lag we experience is related to a specific late-game weapon. Everytime this weapon fires, it creates like 8 missile actors. We usually start seeing serious lag issues when like 6+ of these weapons are firing at once. I hate working in the data editor, so chances are I won't ever attempt to fix that one. Luckily, 90% of games don't go that long and the lag usually isn't too bad. Honestly, I was hoping it was this trigger that causes the lag spikes (lots of units receiving non-fatal damage lots of times), but I suppose there are other weapons that hit a bunch of units much earlier in the game, without causing lag.

Is there some way to get a trigger that activates the 'kill trigger' only when a 3/4 human controlled players are active?

Yes, you do exactly what you wrote in trigger form...

 

Count number of active human controlled players and if that number is greater than 2 then run "kill trigger" otherwise do nothing. Counting the number of active human controlled players is as simple as counting the number of players that are human controlled and still playing by looping through all players and incrementing a counter if a player meets that condition.

Something like the following should do the trick...

Active Player Count Test
    Events
    Local Variables
        active player count = 0 <Integer>
        p = 0 <Integer>
    Conditions
    Actions
        Player Group - For each player p in (All players) do (Actions)
            Actions
                General - If (Conditions) then do (Actions) else do (Actions)
                    If
                        (Controller of player p) == User
                        (Status of player p) == Playing
                    Then
                        Variable - Modify active player count: + 1
                    Else
        General - If (Conditions) then do (Actions) else do (Actions)
            If
                active player count > 2
            Then
                ------- "kill trigger" stuff goes here
            Else

 The logic to find active player count could be put into any trigger you want or even made into an action for convenience.

Quote from Forge_User_04585675 >>

Is there some way to get a trigger that activates the 'kill trigger' only when a 3/4 human controlled players are active?

Yes, you do exactly what you wrote in trigger form...

 

Count number of active human controlled players and if that number is greater than 2 then run "kill trigger" otherwise do nothing. Counting the number of active human controlled players is as simple as counting the number of players that are human controlled and still playing by looping through all players and incrementing a counter if a player meets that condition.

Hey, quick question on this topic. I've noticed that a lot of people perform actions on all active players without using the "Active Players" function. Is there currently any good reason to not use this? For example, in this situation, it seems to me like it would be easier to simply get the number of players in active players. Of course, if you were filtering for some other criteria, you'd want to do that filtering yourself, but I assume that the Active Players function returns a player group of only current human players.

Is there currently any good reason to not use this?

I do not know the exact behaviour of the native/function. As such I cannot suggest it to anyone as I might suggest its use incorrectly.

 

Specifically "active players" meaning is ambiguous to some extent. Computers could technically be active if they have not been defeated/won and were defined as slot controllers before the start. Like wise players that were active at the start of the game might have been defeated/won/left so might be considered inactive. It obviously has a well defined behaviour with what it returns just I do not know what that is and cannot be bothered to extensively test it and will likely forget it in years to as well.

 

As such I suggested a for all player loop with filters. These filters I can explicitly define and do know what they do so I can be sure the trigger would work. Performance wise it might not be the most efficient solution or the most compact solution code wise, but none of that matters as it will make no difference to gameplay at all.