[Solved] This breaks my map.. why?

[WereElf]

• treasure notification
  • Events
    • Unit - A unit enters Dig Spot 1 <gen>
    • Unit - A unit enters Dig Spot 2 <gen>
    • Unit - A unit enters Dig Spot 3 <gen>
    • Unit - A unit enters Dig Spot 4 <gen>
    • Unit - A unit enters Dig Spot 5 <gen>
    • Unit - A unit enters Dig Spot 6 <gen>
    • Unit - A unit enters Dig Spot 7 <gen>
    • Unit - A unit enters Dig Spot 8 <gen>
    • Unit - A unit enters Dig Spot 9 <gen>
    • Unit - A unit enters Dig Spot 10 <gen>
    • Unit - A unit enters Dig Spot 11 <gen>
    • Unit - A unit enters Dig Spot 12 <gen>
    • Unit - A unit enters Dig Spot 13 <gen>
    • Unit - A unit enters Dig Spot 14 <gen>
    • Unit - A unit enters Dig Spot 15 <gen>
    • Unit - A unit enters Dig Spot 16 <gen>
    • Unit - A unit enters Dig Spot 17 <gen>
    • Unit - A unit enters Dig Spot 18 <gen>
  • Conditions
    • ((Entering unit) is A Hero) Equal to True
  • Actions
    • Set Temp_Point = (Position of (Triggering unit))
    • Unit - Create 1 Dummy for (Triggering player) at Temp_Point facing Default building facing degrees
    • Unit - Add a 0.50 second Generic expiration timer to (Last created unit)
    • Unit - Add Digging Notification to (Last created unit)
    • Unit - Order (Last created unit) to Undead Necromancer - Unholy Frenzy (Triggering unit)
    • Custom script: call RemoveLocation(udg_Temp_Point)

my dummy works just fine with other spells, and I haven't touched the "digging notification" spell.
When I made this trigger - it was working, and now it's not o.o

another trigger

• treasure not removal
  • Events
    • Unit - A unit leaves Dig Spot 1 <gen>
    • Unit - A unit leaves Dig Spot 2 <gen>
    • Unit - A unit leaves Dig Spot 3 <gen>
    • Unit - A unit leaves Dig Spot 4 <gen>
    • Unit - A unit leaves Dig Spot 5 <gen>
    • Unit - A unit leaves Dig Spot 6 <gen>
    • Unit - A unit leaves Dig Spot 7 <gen>
    • Unit - A unit leaves Dig Spot 8 <gen>
    • Unit - A unit leaves Dig Spot 9 <gen>
    • Unit - A unit leaves Dig Spot 10 <gen>
    • Unit - A unit leaves Dig Spot 11 <gen>
    • Unit - A unit leaves Dig Spot 12 <gen>
    • Unit - A unit leaves Dig Spot 13 <gen>
    • Unit - A unit leaves Dig Spot 14 <gen>
    • Unit - A unit leaves Dig Spot 15 <gen>
    • Unit - A unit leaves Dig Spot 16 <gen>
    • Unit - A unit leaves Dig Spot 17 <gen>
    • Unit - A unit leaves Dig Spot 18 <gen>
  • Conditions
    • ((Leaving unit) is A Hero) Equal to True
  • Actions
    • Unit - Remove Dig Spot buff from (Triggering unit)

 

[GIMLI_2]

i'm not sure, but Unit enters Region is no player-unit-event i think. So Triggering Player should not work, however, that will not break the game.

 

[WereElf]

Sorry for the title. I had another trigger that was breaking the game, but I found out what was causing it. So I edited the thread to something else that's bothering me, but the title didn't change xP
However, TriggeringPlayer is always == Owner of TriggeringUnit (as far as I know), so that's not the problem.

 

[IcemanBo]

GIMLI_2 has a point. He is right that TriggeringPlayer can be used for Player_Unit events, but not for this.

 

[BPower]

Do these regions overlap? Do you have a trigger which instantly moves a unit when entering a region?
From where do you know, that these triggers are causing your game to crash?

He is right that TriggeringPlayer can be used for Player_Unit events, but not for this.

Returns null.

 

[WereElf]

Sorry for the title. I had another trigger that was breaking the game, but I found out what was causing it. So I edited the thread to something else that's bothering me, but the title didn't change xP

~just in case someone didn't see this part ^~
But well, now that you mention it. I think I had created this trigger long ago, and after some time I read a post saying that Owner of Triggering Unit is equal to Triggering Player, and then I changed the 1-st with the latter, in most of my triggers.
I just tested it with "Owner of triggering unit" and it works

 

[ZiBitheWand3r3r]

TriggeringPlayer is always == Owner of TriggeringUnit (as far as I know), so that's not the problem.

if you share other player's units in team (or give control over hero when player leaves) then
TriggeringPlayer != Owner of TriggeringUnit
that's not the same.

 

[Wietlol]

Is "Dummy" by any chance a hero?
That would cause infinite loops of "create unit -> unit enters region -> create unit -> unit enters region" etc.

 

[WereElf]

if you share other player's units in team (or give control over hero when player leaves) then
TriggeringPlayer != Owner of TriggeringUnit
that's not the same.

That's a good point, but this trigger is there only to give a buff to the entering unit, so it doesn't really matter who the owner of the dummy is. I could've even set it to some constant like "neutral extra" or something.

Is "Dummy" by any chance a hero?
That would cause infinite loops of "create unit -> unit enters region -> create unit -> unit enters region" etc.

No, lol, why would I make a 'hero' dummy?

This wasn't the trigger breaking the game. I had another trigger, where I was looping from 0 to 11, creating events for each player, but I had forgotten to put an "i = i + 1" and that was causing the malfunction.
After I realized that - I changed this post to something else, but the initial title didn't change, and it started confusing people xP.

 

[Dr Super Good]

Triggering Player might be returning null for the event. It may still appear to work fine because often when you test you use Player(0) which also happens to be the player that practically every wrong player value evaluates to (owner of null, etc).

if you share other player's units in team (or give control over hero when player leaves) then
TriggeringPlayer != Owner of TriggeringUnit
that's not the same.

This is the case in StarCraft II and a common source of bugs. As far as I can tell in Warcraft III Triggering Player was programmed to mean "Owner of TriggeringUnit" if it is not null. Some unit events it will be null since the native is actually aimed at player events. I guess it only works for unit events for increased usability.

One has to be careful that the player is not null. If null player is passed to some natives it often is assumed to be Player(0) which will appear fine when testing (you mostly test as Player(0)) but then will bug when tested as other players.