The 2nd trigger has the Constructor and Constructed Unit Group with the same unit in it.
Unit Group - Add (Triggering unit) to Constructor
Unit Group - Add (Triggering unit) to Constructed
For the first trigger, try adding a debug message to confirm that your conditions are correct. I'm not sure why it isn't working.
Make sure you aren't using a static random seed. It defaults to OFF, but if you go to: File -> Preferences -> Test Document -> Use Fixed Random Seed, make sure this option is not checked. If it is checked, your shuffles will always produce the same result (assuming you aren't using random numbers anywhere else).
Also, there is a small logical error in the shuffle function that everyone has posted in this thread. When you choose the random number, you should pick a number from your loop bounds to the end of the list instead of from 1 to the end. For example:
General - Pick each integer from 1 to 5, and do (Actions)
Actions
Variable - Set randomInteger = (Random integer between (Picked Integer) and 5)
Variable - Set randomCardValue = TheDeck[randomInteger]
Variable - Set TheDeck[randomInteger] = TheDeck[(Picked integer)]
Variable - Set TheDeck[(Picked integer)] = randomCardValue
The reason is so that every combination has an equal chance of being generated. It's easiest to see this if you use a small set. Run through both algorithms with 3 items:
Possible permutations: ABC, ACB, BAC, BCA, CAB, CBA (Total of 6)
With the original algorithm, possible randoms generated: 111, 112, 113, 121, 122, 123, 131, 132, 133, 211, 212, 213, 221, 222, 223, 231, 232, 233, 311, 312, 313, 321, 322, 323, 331, 332, 333 (Total of 27)
Therefore, since 27 divided by 6 is not a whole number, it follows some possible permutations are more common than others.
With the modified algorithm: 123, 133, 223, 233, 323, 333 (Total of 6)
If you look at the resulting permutations with this algorithm, you can see that they produce the 6 possible permutations irrespective of the initial sorting of the cards.
The more items you have in your list, the less OBSERVABLE the issue is, but it's still very much in effect. I doubt this is the cause of the issue you are seeing, OP.
0
0
General - Pick each integer from 1 to 5, and do (Actions) Actions Variable - Set randomInteger = (Random integer between (Picked Integer) and 5) Variable - Set randomCardValue = TheDeck[randomInteger] Variable - Set TheDeck[randomInteger] = TheDeck[(Picked integer)] Variable - Set TheDeck[(Picked integer)] = randomCardValueThe reason is so that every combination has an equal chance of being generated. It's easiest to see this if you use a small set. Run through both algorithms with 3 items: Possible permutations: ABC, ACB, BAC, BCA, CAB, CBA (Total of 6) With the original algorithm, possible randoms generated: 111, 112, 113, 121, 122, 123, 131, 132, 133, 211, 212, 213, 221, 222, 223, 231, 232, 233, 311, 312, 313, 321, 322, 323, 331, 332, 333 (Total of 27) Therefore, since 27 divided by 6 is not a whole number, it follows some possible permutations are more common than others. With the modified algorithm: 123, 133, 223, 233, 323, 333 (Total of 6) If you look at the resulting permutations with this algorithm, you can see that they produce the 6 possible permutations irrespective of the initial sorting of the cards. The more items you have in your list, the less OBSERVABLE the issue is, but it's still very much in effect. I doubt this is the cause of the issue you are seeing, OP.