[Trigger] Nested Looping

[blancfaye7]

Hello once again, Hive.

I have a quick question that has sprung to my mind. I could have tested it, but I have no access to World Editor currently, and when I go back to my Computer with World Editor, I don't have to test it manually.

I made a trigger in my mind:

• Loop Sample
  • Events
    • Some Event
  • Conditions
    • Some Condition
  • Actions
    • Player Group - Pick every player in PlayerGroupUser and do (Actions)
      • Loop - Actions
        • Set PickedPlayerLooping = (Picked player)
        • Player Group - Pick every player in PlayerGroupUser and do (Actions)
          • Loop - Actions
            • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
              • If - Conditions
                • PickedPlayerLooping Not equal to (Picked player)
              • Then - Actions
                • Player - Make PickedPlayerLooping treat (Picked player) as an Enemy
              • Else - Actions

Assume that PlayerGroupUser contains all players controlled by a User.
Will the trigger work correctly?
I want all players to become enemies to each other (except to itself).
Thanks Hive.


I hope i got the trigger format correctly.

 

[ZiBitheWand3r3r]

didnt test it, but it looks it will work.
importand part is to do that both sides: player(0) treat player(1) AND player(1) treats player(0). yeah, it should work

 

[Wietlol]

Make Player(1) treat Player(1) as an enemy...
Either Blizzard is stupid or this will have 0 effect.

 

[blancfaye7]

I was more worried about how the (Picked Player) will be determined. The (Picked Player) might be confused of what loop to seek. I am rather confused of what it gets.

And yeah I had to update my posted trigger into that so that the same Player won't be treated as an enemy by itself. Aha!

 

[Dr Super Good]

Make Player(1) treat Player(1) as an enemy...
Either Blizzard is stupid or this will have 0 effect.

Chances are your units will start attacking each other unless they added a special case.

It is just like you can have full shared unit control and vision of enemies, a feature very useful to debug maps with. Doing this you can control all sides of a battle and even cast damaging abilities targeting your own units.

 

[Wietlol]

Yea when you set you as an enemy of yourself, the game will be FFA with one player.
But the thing is that a unit will also treat itself as enemy.

In theory, it will start attacking itself =D

 

[Dr Super Good]

In theory, it will start attacking itself =D

If the target allowed fields had any meaning (like they do in SC2) you could stop that by disallowing self or any similar meaning word as a target.

 

[Fingolfin]

Another thing worthy of note is that attempting to declare war on neutral passive will cause the game to crash. Not a common situation, but still something to keep in mind.

I don't think units would be able to acquire themselves, since Blizzard would be smarter than to include the acquiring unit in the target search.

 

[Dr Super Good]

I don't think units would be able to acquire themselves, since Blizzard would be smarter than to include the acquiring unit in the target search.

Or would they be smart enough to exclude it from the search? If they use space based mapping such as a quad tree then it is quite possible that the search could return the unit acquiring targets.

 

[Wietlol]

In any case, he is using GUI:

function SetPlayerAllianceBJ takes player sourcePlayer, alliancetype whichAllianceSetting, boolean value, player otherPlayer returns nothing
    // Prevent players from attempting to ally with themselves.
    if (sourcePlayer == otherPlayer) then
        return
    endif

    call SetPlayerAlliance(sourcePlayer, otherPlayer, whichAllianceSetting, value)
endfunction

If you would use the native instead, the game might either crash, do weird stuff or (if there is the same check inside the native) do nothing.

 

[Tal'Rarity]

blancfaye7 your system won't work because your looping the same group with the same group and it isn't running through anything new/else so it won't function properly as in it won't ally or make enemies since it can't identify the condition.
You can't un-ally yourself however you can ally yourself. Though it won't matter since you already are allied so it is just a repeat that doesn't cost much.

This works perfectly.

• Melee Initialization
  • Events
    • Map initialization
  • Conditions
  • Actions
    • Player Group - Pick every player in (All players) and do (Actions)
      • Loop - Actions
        • Set pp = (Picked player)
        • Player Group - Add pp to UserPlayers
        • Player Group - Pick every player in UserPlayers and do (Actions)
          • Loop - Actions
            • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
              • If - Conditions
                • pp Not equal to (Picked player)
              • Then - Actions
                • Player - Make pp treat (Picked player) as an Enemy
                • Player - Make (Picked player) treat pp as an Enemy
              • Else - Actions

 

[Wietlol]

I think that UserPlayers is the group of all "Player" players. (real people)
So in that case you
- Player Group - Pick every player in (All players) and do (Actions)
---- Set pp = (Picked player)
---- If
------- if pp is in UserPlayers equal to true
---- Then
------- Player Group - Pick every player in UserPlayers and do (Actions)
---------- Make pp treat (Picked player) as an Enemy
---------- Make (Picked player) treat pp as an Enemy

The check if pp is not equal to (Picked player) doesn't matter as that check is already done inside the alliance change.