@LordPerenolde II ahh gotcha, thanks for sharing the triggers! And no sweat, we all gotta start somewhere!
After reviewing your triggers, I saw a sneaky lil line that might explain the bugs you're seeing:
-
Set OrcAvailableWaves = (OrcAvailableWaves - 1)
-
Leaderboard - Change the value for Player 4 (Purple) in OrcsLeaderboard to (OrcAvailableWaves - 1)
For example, let's say OrcAvailableWaves is 3, and then the depletion trigger runs. It'll first decrement OrcAvailableWaves, so now it is 2. But since OrcAvailableWaves is now 2, the next line will update the leaderboard to show (2 - 1) which is
1.
This probably causes a lot of confusion, because the leaderboard is showing one thing (1)--but internally variable is actually (correctly) "2". Try fixing that and testing it again!
-
Set OrcAvailableWaves = (OrcAvailableWaves - 1)
-
Leaderboard - Change the value for Player 4 (Purple) in OrcsLeaderboard to OrcAvailableWaves
That's how I'd fix it^. Usually, when you see yourself doing arithmetic in multiple places, it might be a good idea to consolidate the arithmetic in one area if possible to avoid these tricky bugs.
Another example would be your incrementing--even though that one
doesn't have this bug, it might be good to reverse the order just to keep things simple and consistent!
-
-------- --------
-
-------- This is what your code currently is --------
-
-------- --------
-
Leaderboard - Change the value for Player 4 (Purple) in OrcsLeaderboard to (OrcAvailableWaves + 1)
-
Set OrcAvailableWaves = (OrcAvailableWaves + 1)
-
-------- --------
-
-------- This is what I would recommend --------
-
-------- --------
-
Set OrcAvailableWaves = (OrcAvailableWaves + 1)
-
Leaderboard - Change the value for Player 4 (Purple) in OrcsLeaderboard to OrcAvailableWaves
That'll be a good practice--this way you're always just updating your "state" (e.g. OrcAvailableWaves) in one place and then your views (e.g. the leaderboard) are simply displaying that state directly as-is.
Hopefully that fixes some of your problems! But as an aside, I do still recommend trying it out with the "A unit dies" event to try to avoid the delays you're describing (and any potential other bugs).
And you might want to take a look at this tutorial on memory leaks:
Memory Leaks
It doesn't affect the "functionality" of your code, but long-term--it'll be useful to read it up to fix the "point" leaks in that trigger. Basically, any time you use a "point" (e.g. Center of region, position of unit, etc.), it creates an object in memory that needs to be manually removed. Typically, you'll just have one or two variables for that, e.g. TempLoc, and then you can use them and remove them right after you finish your function call:
-
Set TempLoc = (Center of Region 000 Copy 11 Copy <gen>)
-
Unit - Create 1 Grunt BHol for Player 3 (Teal) at TempLoc facing 124.70 degrees
-
Custom script: call RemoveLocation(udg_TempLoc)
It might look a bit complicated at first, but it is pretty easy once you do it once or twice. Then it just becomes second-nature.
Good luck! Feel free to ask if you run into any more problems.
that detects when the current wave you command drops to/under 6 elements.
I usually have eyes to spot oversights such as this, but how come I haven't noticed this silly one? smh Thank you! 
I don't know how you set up the locations of your regions in your map but there must be a better way to prevent all those leaks if not to do so one by one. You could try to use array variables and a loop to make your task less tedious, for example:
