The bug:
On the first trigger execution, the unit is always created on the OTHER region. I mean : If ObliterateZone == 1, it's created it TW_ZGreen (instead of ZRed) and if ==2, it's created on TW_ZRed (instead of ZGreen)
But it ONLY happens on the first execution and works very well on next occurrences.
I check 3 times the ObliterateZone :
To display a message, to prevent which zone will be obliterated (Red or Green). Message is always good even on first execution.
To create the invisible purifier in the correct zone. Unit is created on the wrong place during first trigger execution.
To deal damage to all units in the correct zone (another trigger). Damage are dealt on the good zone, even during first execution.
I tried to replace the 2 "if" by :
"If ==1
then TW_ZRed
else TW_ZGreen"
Don't work.
"Switch depending on ObliterateZone
if (1) then TW_ZRed
if (2) then TW_ZGeen"
Don't work.
"If then else-if
else-if == 1 then TW_ZRed
else-if == 2 then TW_ZGreen"
Don't work.
...
If I display the current value of ObliterateZone before the unit spawning, the value is correct, but the unit is created on the wrong place. WTFFFFFFF.
It might be related to the actions. You tell it to create the unit at the center of the region then instantly move the last created unit to the center of the same region. Revoke the second part and try it.
@happy04: Go
I forgot to tell: I move the unit instantly to the same region as a "security", because I have the same bug without it (on the first place, the move action was not here).
But with or without, not working.
But even if it was that, that wouldn't explain why the unit is created on the opposite region ;)
This looks very similar to a problem I experienced. Turns out it's actually a bug in the trigger editor. You've likely copied the If statement in which the unit is created, and somehow, sometimes, the actual script behind the triggers will be mangled. I've had this happen on several occasions. Closing and re-opening the editor should cause the trigger editor to properly reflect the actual script.
@WallArcher: Go
Unfortunately, I've got that bug for weeks and close/reopened editor dozens of times. :/
You had the same problem occuring on the first trigger execution then working properly too?
Perhaps double check the actual script for consistency. Data -> View Script.
Also, I assume no other timers are started during the execution of this segment? The 'last started timer' reference may be screwed. IMO it's always better to create a global timer variable instead of having a bunch of 'last started timer' references. You're asking for trouble like this.
You're referencing (Last created unit) after calling Wait. I don't know if that's specifically causing your bug, but that's a HUGE no-no as it is likely to lead to race conditions when a unit is created while the trigger is waiting.
The fix is easy enough, before calling wait, save (Last created unit) in a variable then post-wait you can reference that variable.
@WallArcher: Go
In the script, everything is fine. And if something was wrong, I presume the trigger would be broken all the time, not only on the first execution.
Indeed there is no other timers. But fortunately that wouldn't bet a problem anyway, because "last created" refer to the "last created in the trigger" and don't care about other things created in other triggers. ;)
@RileyStarcraft: Go
Mmmh... I don't really understand.
I use "last created unit" after calling Wait, but I create the unit after calling Wait too, just before using "last created unit".
If you refer to the "Remove (last created unit) from the game", there is no bug with that action. The unit is correctly removed, because "last created unit" only check the last created unit by the trigger itself.
(I don't understand that sentence at all: "but that's a HUGE no-no as it is likely to lead to race conditions when a unit is created while the trigger is waiting." ^-^ (not english ftw))
what riley is saying about the wait. is that your waiting 3 seconds before using the last created unit. in that 3 seconds. whos to say another unit has been created and the one your wanting to remove is no longer the last created unit.
you should be storing the unit you want to use through there as a variable for consistency
is obliteratezone a variable of type interger? where else does this variable get used/changed. because you have so many waits in your trigger. the variable could be changed before the 2nd half of your trigger.
Like I said :
Unit - Create 1 Purifier for player 0 at (Center of TW_ZRed) facing 270.0 degrees (No Options)
Unit - Move (Last created unit) instantly to (Center of TW_ZRed) (No Blend)
Unit - Hide (Last created unit)
Unit - Order (Last created unit) to (Purifier - Planet Cracker) (Replace Existing Orders)
I use "last created unit" directly. The Wait is before the Remove, and the Remove works well ;)
"whos to say another unit has been created and the one your wanting to remove is no longer the last created unit."
Because there is no other "Create unit" in the trigger. No matter if another unit is created is another trigger during this 3 seconds, because the "Last created unit" don't care about that ;)
It's just checking units created by the trigger itself.
"is obliteratezone a variable of type interger? where else does this variable get used/changed. because you have so many waits in your trigger. the variable could be changed before the 2nd half of your trigger."
Yes it's an integer, only changed here "Variable - Set ObliterateZone = (Random integer between 1 and 2)" (in that trigger).
It's used in another trigger (turned on by the "ObliterateDamage = true") which is work well.
And like I said earlier, the variable is correct when I display it before creating the unit :)
Anyways, if the variable changed before the 2nd half of the trigger, the damage would be dealt in the wrong place and not the right one.
Its not the point of of there being no other last created unit. its bad coding and practice to keep doing it, you should be storing the last created unit as a variable. It is your choice whether you do this. but it is generally frowned upon among other programmers.
can you post a screenshot of the other trigger that obliteratezone variable is in.
"Anyways, if the variable changed before the 2nd half of the trigger, the damage would be dealt in the wrong place and not the right one."
is that not what the problem is? that its happening in the wrong place?
@nevjmac: Go
"Its not the point of of there being no other last created unit. its bad coding and practice to keep doing it, you should be storing the last created unit as a variable. It is your choice whether you do this. but it is generally frowned upon among other programmers."
Hum... maybe but there is no point between the bug and "last created unit".
And if I want to quibble: why creating a new variable and additionnal code lines if there is a function which prevent me to do that? :p (unless if "last created unit" = massive amount of code in script)
"is that not what the problem is? that its happening in the wrong place?"
The unit is created in the wrong place, but damage are dealt in the good place.
"can you post a screenshot of the other trigger that obliteratezone variable is in."
Sure. The other trigger:
my next question. why do you have 4 seperate "if then else" when this could be put into one with half the code, see a summary below:
if
- obilteratezone ==1
then (red zone)
- display message
- wait for timer
- create units
- move unit
- hide unit
- order unit
else (green zone)
- display message
- wait for timer
- create units
- move unit
- hide unit
- order unit
why are you using a neutral player rather than a computer player? try changing from player 0 and add a computer player in?
and what is calling this trigger? how is this trigger activated?
another thing I just noticed yuo make variables for your timer but you still refer to it as last created timer >.< why not use the variables you created, this is the same thing for the last created unit lol
"my next question. why do you have 4 seperate "if then else" when this could be put into one with half the code, see a summary below:"
Because I said I had it in the first place but didn't worked (like switch or else-if). I tried every solutions, so the stupidest (4 if) was the last.
"why are you using a neutral player rather than a computer player? try changing from player 0 and add a computer player in?"
Same problem.
If I use player 0 it's because I don't have to add a computer player in the lobby (or maybe it changed since WC3). But anyways, player 0 is a computer player ;)
"and what is calling this trigger? how is this trigger activated?"
The trigger is called here:
"another thing I just noticed yuo make variables for your timer but you still refer to it as last created timer >.< why not use the variables you created, this is the same thing for the last created unit lol"
Because I need to stop the Obliterate (so timer) when the map ends (when someone achieves the objective) and destroy the timer window.
I also need to reset everything when I start the auto-remake system.
First of all: nice titel, you know how to attact attention :D
Then: Try to put in some Wait ( 0 seconds), this often is a wonderful debugging tool ;)
One right after setting the variable ObliterateZone to the random value, then: right after you created your purifier(s). I could imagine that the game needs longer to load and create the unit the first time since all values have to be loaded into memory.
And yes, it would be better to save the purifier unit in a local unit variable, I heard that LastCreated functions are local to triggers now, but it's simply better, then you know what unit it is when looking at the variable name ;)
So:
Create Purifier at...
Set LittlePuri = LastCreatedUnit
Wait 0 seconds
Move Purifier to center of region Red/Green
And one more idea: Save the to points (Center of Red and center of green) in an global point array variable. Do that at map initialization and use index=1 for red and index=2 for green.
And then simply do: Create Purifier at center of TheSpawnLocs[ObliterateZone]
"One right after setting the variable ObliterateZone to the random value, then: right after you created your purifier(s). I could imagine that the game needs longer to load and create the unit the first time since all values have to be loaded into memory. "
Agree in theory, but have you ever seen a map in your life (something like Dota or Golem Wars) creating the unit in the bad region for that purpose? :p
I thought like you some weeks ago so I already tried to create the unit with a separate trigger after beginning of the map, and guess what? Don't work :p
True I've not tried to set the two regions in a array, let's see what's the editor behavior with that. :)
I'm confiant with that. That's how every randoms work in my map, dunno why I didn't made that in the first place.
Edit : Hahaha, don't work xD (it's not funny at all in fact :/)
I also replaced the "last created unit" by a var and put/remove the Wait 0 second.
If the trigger is on his first execution, I ask to create the unit on the WRONG region.
If the trigger is not on his first execution, I ask to create the unit on the good region.
And it's WORK... YES! I have to ask a unit creation on another region to have my unit created in the right place!
Seriously WTF? What's wrong with the editor? It's just a nonsense. It shouldn't be possible.
Anyways, I keep my $10,000 ;) But if you got an explanation to that editor bug, feel free to post.
I would rewrite the trigger from scratch with no copy and pasting. I know I have had some serious problems copy and pasting parts of triggers and so I write them all from scratch.
Your telling your trigger to run with out checking conditions.... Why?
I bet if you use a local variable for the random integer and set it = 1 for an initial value I bet you dont have this problem. Your Global Region Variables there may also be an issue if they are not initialized before running this trigger.
By defualt only player 1-14 can be a given slot in the lobby from my understanding.
player 0 = neutral computer
player 15 = hostile computer
If your really wanna debug stuff like this then
Disable Waits
Disable Timers
Disable Camera stuff
Disable the random integer
Disable the Recursive Call to itself.
WTF is that condition "MapSelection" == 15 ???
Tell us what is running this trigger
Set your RandomInteger Variable = 0 when your done using it
Then just set it up to trigger for a -Destroy "Value" text command and actually test it. From looking at your code, you have a mess there. Its not the editor its your sloppy code. Simplify code and test/learn.
The trigger:
The bug:
On the first trigger execution, the unit is always created on the OTHER region. I mean : If ObliterateZone == 1, it's created it TW_ZGreen (instead of ZRed) and if ==2, it's created on TW_ZRed (instead of ZGreen)
But it ONLY happens on the first execution and works very well on next occurrences.
I check 3 times the ObliterateZone :
To display a message, to prevent which zone will be obliterated (Red or Green). Message is always good even on first execution.
To create the invisible purifier in the correct zone. Unit is created on the wrong place during first trigger execution.
To deal damage to all units in the correct zone (another trigger). Damage are dealt on the good zone, even during first execution.
I tried to replace the 2 "if" by :
"If ==1
then TW_ZRed
else TW_ZGreen"
Don't work.
"Switch depending on ObliterateZone
if (1) then TW_ZRed
if (2) then TW_ZGeen"
Don't work.
"If then else-if
else-if == 1 then TW_ZRed
else-if == 2 then TW_ZGreen"
Don't work.
...
If I display the current value of ObliterateZone before the unit spawning, the value is correct, but the unit is created on the wrong place. WTFFFFFFF.
It might be related to the actions. You tell it to create the unit at the center of the region then instantly move the last created unit to the center of the same region. Revoke the second part and try it.
@happy04: Go I forgot to tell: I move the unit instantly to the same region as a "security", because I have the same bug without it (on the first place, the move action was not here).
But with or without, not working.
But even if it was that, that wouldn't explain why the unit is created on the opposite region ;)
This looks very similar to a problem I experienced. Turns out it's actually a bug in the trigger editor. You've likely copied the If statement in which the unit is created, and somehow, sometimes, the actual script behind the triggers will be mangled. I've had this happen on several occasions. Closing and re-opening the editor should cause the trigger editor to properly reflect the actual script.
@WallArcher: Go Unfortunately, I've got that bug for weeks and close/reopened editor dozens of times. :/
You had the same problem occuring on the first trigger execution then working properly too?
Perhaps double check the actual script for consistency. Data -> View Script.
Also, I assume no other timers are started during the execution of this segment? The 'last started timer' reference may be screwed. IMO it's always better to create a global timer variable instead of having a bunch of 'last started timer' references. You're asking for trouble like this.
You're referencing (Last created unit) after calling Wait. I don't know if that's specifically causing your bug, but that's a HUGE no-no as it is likely to lead to race conditions when a unit is created while the trigger is waiting.
The fix is easy enough, before calling wait, save (Last created unit) in a variable then post-wait you can reference that variable.
@WallArcher: Go In the script, everything is fine. And if something was wrong, I presume the trigger would be broken all the time, not only on the first execution.
Indeed there is no other timers. But fortunately that wouldn't bet a problem anyway, because "last created" refer to the "last created in the trigger" and don't care about other things created in other triggers. ;)
@RileyStarcraft: Go Mmmh... I don't really understand.
I use "last created unit" after calling Wait, but I create the unit after calling Wait too, just before using "last created unit".
If you refer to the "Remove (last created unit) from the game", there is no bug with that action. The unit is correctly removed, because "last created unit" only check the last created unit by the trigger itself.
(I don't understand that sentence at all: "but that's a HUGE no-no as it is likely to lead to race conditions when a unit is created while the trigger is waiting." ^-^ (not english ftw))
@Sntenshi: Go
what riley is saying about the wait. is that your waiting 3 seconds before using the last created unit. in that 3 seconds. whos to say another unit has been created and the one your wanting to remove is no longer the last created unit.
you should be storing the unit you want to use through there as a variable for consistency
is obliteratezone a variable of type interger? where else does this variable get used/changed. because you have so many waits in your trigger. the variable could be changed before the 2nd half of your trigger.
@nevjmac: Go
Like I said :
Unit - Create 1 Purifier for player 0 at (Center of TW_ZRed) facing 270.0 degrees (No Options)
Unit - Move (Last created unit) instantly to (Center of TW_ZRed) (No Blend)
Unit - Hide (Last created unit)
Unit - Order (Last created unit) to (Purifier - Planet Cracker) (Replace Existing Orders)
I use "last created unit" directly. The Wait is before the Remove, and the Remove works well ;)
"whos to say another unit has been created and the one your wanting to remove is no longer the last created unit."
Because there is no other "Create unit" in the trigger. No matter if another unit is created is another trigger during this 3 seconds, because the "Last created unit" don't care about that ;)
It's just checking units created by the trigger itself.
"is obliteratezone a variable of type interger? where else does this variable get used/changed. because you have so many waits in your trigger. the variable could be changed before the 2nd half of your trigger."
Yes it's an integer, only changed here "Variable - Set ObliterateZone = (Random integer between 1 and 2)" (in that trigger).
It's used in another trigger (turned on by the "ObliterateDamage = true") which is work well.
And like I said earlier, the variable is correct when I display it before creating the unit :)
Anyways, if the variable changed before the 2nd half of the trigger, the damage would be dealt in the wrong place and not the right one.
Its not the point of of there being no other last created unit. its bad coding and practice to keep doing it, you should be storing the last created unit as a variable. It is your choice whether you do this. but it is generally frowned upon among other programmers.
can you post a screenshot of the other trigger that obliteratezone variable is in.
"Anyways, if the variable changed before the 2nd half of the trigger, the damage would be dealt in the wrong place and not the right one."
is that not what the problem is? that its happening in the wrong place?
@nevjmac: Go "Its not the point of of there being no other last created unit. its bad coding and practice to keep doing it, you should be storing the last created unit as a variable. It is your choice whether you do this. but it is generally frowned upon among other programmers."
Hum... maybe but there is no point between the bug and "last created unit".
And if I want to quibble: why creating a new variable and additionnal code lines if there is a function which prevent me to do that? :p (unless if "last created unit" = massive amount of code in script)
"is that not what the problem is? that its happening in the wrong place?"
The unit is created in the wrong place, but damage are dealt in the good place.
"can you post a screenshot of the other trigger that obliteratezone variable is in."
Sure. The other trigger:
But the state is changed to "true" after unit creation...
(edit: btw, I already tried to create unit in TW_EntireX instead of TW_ZX, don't work either)
my next question. why do you have 4 seperate "if then else" when this could be put into one with half the code, see a summary below:
if
- obilteratezone ==1
then (red zone)
- display message
- wait for timer
- create units
- move unit
- hide unit
- order unit
else (green zone)
- display message
- wait for timer
- create units
- move unit
- hide unit
- order unit
why are you using a neutral player rather than a computer player? try changing from player 0 and add a computer player in?
and what is calling this trigger? how is this trigger activated?
another thing I just noticed yuo make variables for your timer but you still refer to it as last created timer >.< why not use the variables you created, this is the same thing for the last created unit lol
sorry for all the questions >.<
@nevjmac: Go
"my next question. why do you have 4 seperate "if then else" when this could be put into one with half the code, see a summary below:"
Because I said I had it in the first place but didn't worked (like switch or else-if). I tried every solutions, so the stupidest (4 if) was the last.
"why are you using a neutral player rather than a computer player? try changing from player 0 and add a computer player in?"
Same problem.
If I use player 0 it's because I don't have to add a computer player in the lobby (or maybe it changed since WC3). But anyways, player 0 is a computer player ;)
"and what is calling this trigger? how is this trigger activated?"
The trigger is called here:
(just the part of the trigger calling Obliterate)
"another thing I just noticed yuo make variables for your timer but you still refer to it as last created timer >.< why not use the variables you created, this is the same thing for the last created unit lol"
Because I need to stop the Obliterate (so timer) when the map ends (when someone achieves the objective) and destroy the timer window.
I also need to reset everything when I start the auto-remake system.
Np for questions :)
First of all: nice titel, you know how to attact attention :D
Then: Try to put in some Wait ( 0 seconds), this often is a wonderful debugging tool ;)
One right after setting the variable ObliterateZone to the random value, then: right after you created your purifier(s). I could imagine that the game needs longer to load and create the unit the first time since all values have to be loaded into memory.
And yes, it would be better to save the purifier unit in a local unit variable, I heard that LastCreated functions are local to triggers now, but it's simply better, then you know what unit it is when looking at the variable name ;) So:
Create Purifier at... Set LittlePuri = LastCreatedUnit Wait 0 seconds Move Purifier to center of region Red/Green
And one more idea: Save the to points (Center of Red and center of green) in an global point array variable. Do that at map initialization and use index=1 for red and index=2 for green. And then simply do: Create Purifier at center of TheSpawnLocs[ObliterateZone]
"One right after setting the variable ObliterateZone to the random value, then: right after you created your purifier(s). I could imagine that the game needs longer to load and create the unit the first time since all values have to be loaded into memory. "
Agree in theory, but have you ever seen a map in your life (something like Dota or Golem Wars) creating the unit in the bad region for that purpose? :p
I thought like you some weeks ago so I already tried to create the unit with a separate trigger after beginning of the map, and guess what? Don't work :p
True I've not tried to set the two regions in a array, let's see what's the editor behavior with that. :)
I'm confiant with that. That's how every randoms work in my map, dunno why I didn't made that in the first place.
Edit : Hahaha, don't work xD (it's not funny at all in fact :/)
I also replaced the "last created unit" by a var and put/remove the Wait 0 second.
the map would be good :) i need to see it in the editor
@HellGateSc2: Go You can download it in the maps section.
Edit : http://www.sc2mapster.com/maps/bounty-hunters/files/
Ok guys this is ridiculous. I finally found a way to fix it, but just take a look to that:
If the trigger is on his first execution, I ask to create the unit on the WRONG region.
If the trigger is not on his first execution, I ask to create the unit on the good region.
And it's WORK... YES! I have to ask a unit creation on another region to have my unit created in the right place!
Seriously WTF? What's wrong with the editor? It's just a nonsense. It shouldn't be possible.
Anyways, I keep my $10,000 ;) But if you got an explanation to that editor bug, feel free to post.
I would rewrite the trigger from scratch with no copy and pasting. I know I have had some serious problems copy and pasting parts of triggers and so I write them all from scratch.
Your telling your trigger to run with out checking conditions.... Why?
I bet if you use a local variable for the random integer and set it = 1 for an initial value I bet you dont have this problem. Your Global Region Variables there may also be an issue if they are not initialized before running this trigger.
If your really wanna debug stuff like this then
Then just set it up to trigger for a -Destroy "Value" text command and actually test it. From looking at your code, you have a mess there. Its not the editor its your sloppy code. Simplify code and test/learn.