(The triggers are attached below in a text file. Apparently there is a limit to the characters in these posts :[)
I have a series of triggers that assigns six unique options randomly, one for each player. Every player receives exactly one option, and no two players receive the same way. I discussed this problem in a previous post where I did at first a brute force solution. I reworked it and now have a more simple system that simply keeps generating a random number until it is matched to an option not chosen. Thus the core of the triggers is this:
Code
options = {City1, City2, City3, City4, City5, City6}
for each player 1 to 6 do:
choice = options[random_int(1, 6)]
while choice is already taken do:
choice = options[random_int(1, 6)]
assign choice to player i
for each player 1 to 6 do:
choice = options[random_int(1, 6)]
while choice is already taken do:
choice = options[random_int(1, 6)]
assign choice to player i
Now this is the behavior I get from the triggers below. And I do observe some kind of "exponential" slow down of assignment, since it becomes increasingly more unlikely to generate a more constrained range of numbers (i.e. approaches 1/N probability where N = number of choices). The first player always gets his choice assigned first, but the last player takes a bit longer because it's a 1/6 chance repeating every trigger cycle.
Now I am not here to discuss making a better system (that was in the previous thread). Instead, while my system works when all 6 players are in game, it breaks when a player slot is empty. In particular I have been testing the following scenario, where P2 is empty but all other slots are taken.
When P2 is empty, I observe the following behavior.
1. P1 is correctly assigned an option randomly
2. P2 is correctly assigned an option randomly
3. P3-6 are never assigned anything afterwards--the system halts dead in its tracks.
The way the system constrains the choices is by a death counter (Zerg Queen's Nest) that is decremented each time a player is given an option.
When the DC = 6, only P1 can be assigned an option. When DC = 5, only P2 can be assigned an option, etc, etc.
Thus the normal behavior is this:
1. DC = 6
2. P1 assigned, --DC, DC = 5
3. P2 assigned, --DC, DC = 4
4. P3 assigned, --DC, DC = 3
5. P4 assigned, --DC, DC = 2
6. P5 assigned, --DC, DC = 1
7. P6 assigned, --DC, DC = 0
8. Finish, DC = 0
The bad behavior in the first case, however, sets DC = 0 after P2 runs (step 3) rather than decrement it by 1.
2. P1 assigned, --DC, DC = 5
3. P2 assigned, --DC, DC = 0 (????????????????????????)
4. Finish, DC = 0
I verified this by watching the leaderboard kills for the DC. Now I am not sure how being an empty player suddenly throws the system out. It's not in the semantics or logic that I understand. I know empty players cannot run triggers, and I also know conditions like "Command" do not work for empty players. But these triggers are run by P8, who is always in game, and the conditions use a series of "Brings," which DO work for empty players.
What am I misunderstanding here?
Attachments:
None.
