I'm hoping someone can help me with a mysterious issue I'm having with a set of triggers in one of my co-op multiplayer scenarios. Everything is done using the standard StarEdit campaign editor, with Blizzard approved triggers. I'm using a set of four triggers to cause groups of spawning zerg to move away from their spawn location to one of four randomly chosen gathering zones. The conditions for each of these triggers are based on the status of two switches, which are randomized at the start of the map. Because there are 2 switches, there are 4 possible permutations on the set/cleared status of these switches, each of which activates a single trigger. Here are the relevent triggers:

Conditions:
-Always
Actions:
-Randomize 'Move 1'
-Randomize 'Move 2'

Conditions:
-'Move 1' is cleared.
-'Move 2' is set.
Actions:
-Issue order to all any unit owned by Player 5 at 'Respawn': Attack to 'Creatures go 1'
-Randomize 'Move 1'.
-Randomize 'Move 2'.
-Preserve Trigger

Conditions:
-'Move 1' is set.
-'Move 2' is cleared.
Actions:
-Issue order to all any unit owned by Player 5 at 'Respawn': Attack to 'Creatures go 2'
-Randomize 'Move 1'.
-Randomize 'Move 2'.
-Preserve Trigger

Conditions:
-'Move 1' is set.
-'Move 2' is set.
Actions:
-Issue order to all any unit owned by Player 5 at 'Respawn': Attack to 'Creatures go 3'
-Randomize 'Move 1'.
-Randomize 'Move 2'.
-Preserve Trigger

Conditions:
-'Move 1' is cleared.
-'Move 2' is cleared.
Actions:
-Issue order to all any unit owned by Player 5 at 'Respawn': Attack to 'Creatures go 4'
-Randomize 'Move 1'.
-Randomize 'Move 2'.
-Preserve Trigger


By theory, I should end up with a random distribution of creatures at each of the destination locations; however, for some reason position 4 is overwhelmingly favored and something like 80% of the units gather there. About 5% gather at position 1, and the remaining units spread themselves evenly between the last two destinations.

Can anyone think of a reason why this is occuring? My math skills are not so good, but I cannot think of any reason other than some obscure mathematic principle that would explain why my random location choosing system is failing. Any help would be appreciated.

The scenario is attached to this message if you want to witness the phenomenon yourself or tinker with the triggers. I would suggest you load the map as a custom game and play defensively for a while, then "Black Sheep Wall" to see where the orange zerg have chosen to gather. You'll immediately see what I mean.

Attachments:

I never seen that effect this strong, but it is known that the randomness that computers generate is not really random. There are other ways to achieve a (pseudo) randomness.

For example instead of switches use a death counter that counts from 0-3. If that STILL should create not-random results let it count from 0 to 15 and create 4 triggers for each order to the location. Then you can values connected to the conditions to 'trim' it to be evenly.

The problem is your method.

Lets say for example Move1 and 2 are both set.
Trigger 1 runs, sends units to Loc1 and randomize move1 and 2 again.
There is 75% chance that one of the following 3 triggers will run again and overide the 1st one.

so theoritecally your
trigger 1 has 3.06% chance to take effect
trigger 2 has 15.31%
trigger 3 has 32.8%
and trigger 4 has 48.83%

use: (Red is to remove)
Conditions:
-Always
-P5 brings at least 1 [anyunit] to respawn
Actions:
-Randomize 'Move 1'
-Randomize 'Move 2'

and

Conditions:
-'Move 1' is cleared.
-'Move 2' is set.
Actions:
-Issue order to all any unit owned by Player 5 at 'Respawn': Attack to 'Creatures go 1'
-Randomize 'Move 1'.
-Randomize 'Move 2'.
-Preserve Trigger

and so on...

@y10k:

Ureka! I knew someone with an understanding of math and logic would have a solution for me. Thanks for your help, I adjusted the triggers with your changes and the distribution now behaves as I expect.

@NudeRaider
Thanks for your suggestion; however, I cannot use the kill counters in this trigger because all the kill counters are already in use in another set of triggers in this map, and their values stay zeroed most of the time.

Oh... lol... I didn't look at the triggers exactly... I just didn't see that you randomize again...
Well then it's obvious.

And Bone, don't tell me you have 1600 death counters / units in use.
There are about 200 units and a good portion of it cannot be used in game, such as neutral - neutral - cantina.
Multiply it by 8 players and you have 1600.
(However, you can still stick to switches, their randomness is usually good enough.)

Perhaps I am unclear on your method and usage of the death counters. What I mean to say is, the death count for every species of zerg unit for Players 1 & 5 are in use for this scenario; specifically, each time the human players kill a unit belonging to Player 1, it triggers a script which spawns that same unit for Player 5 at a given location, then reduces the kill count for Player 1 for that unit by 1, to ensure a 1:1 ratio of kills to spawns. The trigger repeats until the kill counter hits for each unit type. The same process repeats for Player 5 so the orange army is essentially immortal, but can only grow larger and more diverse based on the interaction between Player 1 and the human players.

I'm something of a purist and I do not believe in 3rd party editors for SC or other mods, so everything I'm doing is within the bounds of what can be done with StarEdit. For that reason, it's entirely possible that I am not equipped to intelligently discuss death counters with you because we may not be refering to the same thing. The limiting factor, no doubt, is my general ignorance of the Starcraft modding community and the tools which are commonly in use.

Again, I appreciate your suggestions and feedback, as well as your efforts to relieve some of my ignorance on the topic at hand.

If you use SCMDraft (or Starforge) you have access to the unused units such as the Cantina, Independent Starport, and the Independent Command Center. These units crash in game, but you can use them for death counters.

Forgive me if I say things about stuff that has already been corrected.


Well, technically there are 227 units, so you have 1816 possible units, and if he doesn't use that many units in the game, there isn't a problem. He could also use units that WERE being used, and remove deaths if kills of those units are detected.

Now, I looked at what you did, and it's kinda obvious, you are giving each trigger less and less chance as you go, so, the first one has a tiny chance of happening, since you can't have any of the other randomizations run, or it will be overrode, so if you randomize it once, then run through all the possibilities, then rerandomize it, there won't be a problem.

And Bone, I don't think you realize the usefulness of Death Counts, here's a tutorial that shows the basics of them:
http://Falkoner.CoW.GooglePages.com/Death_Counts.html

That's correct. How clever.

Condition 4 is true when the game starts unless the first randomize always happens first.
Preserve trigger on the randomize trigger.