Added Location: "Unit Finder"
Added DC: "Floor Gun Trap" renamed to "Spawn (Timer)"

Attachments:

This trigger is pretty inefficient, it's going to spam unnecessary "Brings" conditions and a "Remove" action 12 times a second for the entire game. Additionally, it won't necessarily remove the units which were created, since the units don't need to stay within the Unit Finder location.

Also, the Unit Finder centering action shouldn't be split up into player-specific triggers. It'll make it much more difficult to edit it later.

Post has been edited 2 time(s), last time on Jul 7 2013, 1:18 pm by Azrael.

@Demon Sorry, I got confused and I forgot that 2 switches makes 4 and 1 switch makes 2
@MetalGear Thankyou so much, but Im confused about the 26 death counter part in the Activate triggers
@Azrael So should I should delete it, or is there a better way to work this out?

It was originally his trigger, I just merged it from two triggers into one. I'm not going to go through his entire map and change every single detail to make it flawless. I don't have the time for that. But you're right for pointing that out, there are technically smoother triggers. Maybe you could take over from this point and make the necessary modifications? To be completely honest though, it's an amateur project (no offense QPreach) and I don't think such precision is needed.

I'm not sure what you mean by the Unit Finder comment. It's a highly efficient system design that saves a lot of trigger space.

Okay, QPreach, I'll briefly explain the process of how it works.


Does that make more sense now, or do you need me to go more in depth about how the switches work?

@Metalgear none taken

And I somewhat understand the switches; the 5 Activation triggers are the 5/8 outcomes and 25 death counter is to let it go down to 24 death counter for the 2 seconds delay right?

Yes that's exactly right. Whilst we're here, I'll just give you a quick lesson in using switches.


So, using just two switches, the outcomes would look like this...


Cool, that's easy, right? Now, imagine if you used 5 switches for 32 outcomes, and you had to write 32 triggers which each held a different combination. That would be tricky as hell, right? That's why the pros use a special system which assigns a unique number to each combination.

Here, I'll show you how it works. Let's use 3 switches this time, to give 8 possible outcomes. Now, imagine the first switch = 1, the second switch = 2, the third switch = 4, the fourth switch = 8, and so on. Let's say we want to find the 3rd, 4th, and 5th combinations. Simply add the switches, starting from the highest switch working down until you get your combination number, and you set those switches. Look below to see what I mean...


Sorry if that's too confusing. It's not essential for you to learn that, but it may provide you some good insight.

So we just add the number of each set switch? I'm not understanding the "highest switch working down"

Yes, exactly. We add the value of each set switch, and you start from the highest value. For example, if we were using 5 switches, the values would be assigned as such...


So if we wanted to find out combination 10, for example, we'd start at Switch 5. Here's what you do...


To conclude, combination 10 would look like this...

OH! Now that makes sense. Thank you very much, thats very enlightening

I didn't mean to suggest you should, only that his trigger was inefficient.


I mean, "Center location Unit Finder on unit owned by Current Player" shouldn't be in 5 different triggers owned by 5 different players. It should be in one trigger owned by all five players. Not a big deal, but if anyone needs to modify that trigger in any way, it's going to be five times more work.

Unless you mean the "it won't necessarily remove the units which were created, since the units don't need to stay within the Unit Finder location" comment. If that's the part you're not sure about, I meant that the spawned units are created at Unit Finder, but they don't have to stay there. The player and the spawned unit don't have to stay next to each other, and plenty of things can happen to split them up, especially if it's a ranged unit. Then when the player leaves, it tries to remove the spawned unit at Unit Finder, except Unit Finder is centered on the player's unit, where the spawned unit may not be located.

Also, when checking for percentages, the lower percentage is the one that should generally be checked for, since it saves trigger space and good trigger consolidation makes it easier to edit triggers later. Rather than five triggers checking when it succeeds, there can be three triggers checking when it fails.


If it's working for you, then that's all you really need to worry about at this stage of mapping. Eventually you'll want to take trigger efficiency into account, where triggers are only running when necessary, and Brings checks are only being done when necessary (StarCraft checks the conditions of a trigger in order, and if one of them is false, it skips the rest without checking them; that's why conditions should have the easiest to check ones first (Switches, then Death Counts, Accumulates, etc) and the hardest to check ones last (Brings)).

I see what you mean. Yes, it could be made into one trigger, but it's no issue since it is conveniently coupled with an event of the same function that does need to be unique to each player.


Sorry, I forgot to respond to this. The original trigger removed units from the whole area, which would interrupt other players. But yer, this system is still faulty. One other possibility, QPreach, is that you could have a trigger that gives all the spawn at locations Follow P1, Follow P2, Follow P3, Follow P4, Follow P5, to player 12, then remove all the units for player 6 at the whole spawn area, then give player 12 units back to player 6. So it will only remove the units that are not near other players, and still work for the whole area.

And like Azreal was saying, the less triggers you have being activated the least number of times, is always better, but you'll naturally learn these things as you go along. Just make a conscious effort to keep improving.

That's what I mean, it isn't more convenient, it's inherently less convenient Things that aren't unique to a player shouldn't be in a trigger that's unique to each player.

It's merely a tip for this mapmaker who is looking for such information. The idea is to consolidate triggers for ease of editing and reading. It's also less likely that you'll make a mistake (and easier to find a mistake) if you're only putting an action into one trigger, rather than five separate ones.