Okay, devilisk, just to prove my point, I did this: [code]Trigger("Player 1"){ Conditions: Elapsed Time(At least, 3); Actions: Set Switch("Switch1", set); } //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Switch("Switch1", set); Actions: Display Text Message(Always Display, "First?"); Move Unit("Player 1", "Terran Marine", All, "Location 0", "Location 1"); Kill Unit("Player 1", "Terran Marine"); } //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Switch("Switch1", set); Bring("Player 1", "Terran Marine", "Location 1", Exactly, 1); Actions: Display Text Message(Always Display, "Second?"); } //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Switch("Switch1", set); Actions: Display Text Message(Always Display, "Third?"); } //-----------------------------------------------------------------// [/code] Now, it still displayed first, second, and third, in the correct order, even though the unit was dead. It seems that Move Unit and Create Unit both update the conditions. It seems that removing a unit may also update it, but from other tests it does not seem to do so.

Okay, devilisk, just to prove my point, I did this:

Code

Now, it still displayed first, second, and third, in the correct order, even though the unit was dead. It seems that Move Unit and Create Unit both update the conditions. It seems that removing a unit may also update it, but from other tests it does not seem to do so.

[quote=name:Falkoner]Devilisk, building units does not update it, removing them does not, killing them does not. I would not post it if I had no reason.[/quote] Removing them actually does. Killing doesn't, but that's not the result of the bring condition, because killing doesn't even occur until after the end of the trigger cycle. At the time the bring condition is checked, the unit is still actually there. This problem has to do with [b]actions[/b]. Which I actually stated before. [IMG]http://i29.tinypic.com/1rf4uo.jpg[/IMG] [quote] Trigger("Player 1"){ Conditions: Always(); Actions: Create Unit("Player 1", "Terran Marine", 1, "Location 0"); } //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Elapsed Time(At least, 3); Actions: Set Switch("Switch1", set); } //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Switch("Switch1", set); Actions: Move Unit("Player 1", "Terran Marine", All, "Location 0", "Location 1"); } //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Switch("Switch1", set); Actions: Remove Unit At Location("Player 1", "Terran Marine", All, "Location 1"); } //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Switch("Switch1", set); Actions: Display Text Message(Always Display, "FALKONER IS"); } //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Bring("Player 1", "Terran Marine", "Location 1", Exactly, 0); Switch("Switch1", set); Actions: Display Text Message(Always Display, "A DUMBASS"); } //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Switch("Switch1", set); Actions: Display Text Message(Always Display, "LULZ NOOB"); } //-----------------------------------------------------------------// [/quote] Refer back to my first post: [quote]This isn't a concept. It's just a test map demonstrating how specific conditions function. Bring is "updated" instantly during the trigger cycle and command is updated at the end. There's more examples of this such as [b]killing vs removing a unit[/b]. There's also removing all of a unit vs removing all of a transport unit or something like that, but I know it has to do with transports, shuttles, overlords, dropships, bunkers.[/quote]

Quote from Falkoner

Devilisk, building units does not update it, removing them does not, killing them does not. I would not post it if I had no reason.

Removing them actually does.

Killing doesn't, but that's not the result of the bring condition, because killing doesn't even occur until after the end of the trigger cycle. At the time the bring condition is checked, the unit is still actually there. This problem has to do with actions. Which I actually stated before.

Quote

Trigger("Player 1"){
Conditions:
Always();

Actions:
Create Unit("Player 1", "Terran Marine", 1, "Location 0");
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Elapsed Time(At least, 3);

Actions:
Set Switch("Switch1", set);
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Switch("Switch1", set);

Actions:
Move Unit("Player 1", "Terran Marine", All, "Location 0", "Location 1");
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Switch("Switch1", set);

Actions:
Remove Unit At Location("Player 1", "Terran Marine", All, "Location 1");
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Switch("Switch1", set);

Actions:
Display Text Message(Always Display, "FALKONER IS");
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Bring("Player 1", "Terran Marine", "Location 1", Exactly, 0);
Switch("Switch1", set);

Actions:
Display Text Message(Always Display, "A DUMBASS");
}

//-----------------------------------------------------------------//

Trigger("Player 1"){
Conditions:
Switch("Switch1", set);

Actions:
Display Text Message(Always Display, "LULZ NOOB");
}

//-----------------------------------------------------------------//

Refer back to my first post:

Quote

This isn't a concept. It's just a test map demonstrating how specific conditions function. Bring is "updated" instantly during the trigger cycle and command is updated at the end.

There's more examples of this such as killing vs removing a unit. There's also removing all of a unit vs removing all of a transport unit or something like that, but I know it has to do with transports, shuttles, overlords, dropships, bunkers.

Yes, removing does seem to update, killing does not, and neither does giving. Your explanation does not show why giving does not work. And bring and command definitely take time to update, as you can see in many maps, where something should be instantaneous, but is not due to units being part of the equation.

Yes, removing does seem to update, killing does not, and neither does giving. Your explanation does not show why giving does not work. And bring and command definitely take time to update, as you can see in many maps, where something should be instantaneous, but is not due to units being part of the equation.

[quote=name:Falkoner]Yes, removing does seem to update, killing does not, and neither does giving. Your explanation does not show why giving does not work. And bring and command definitely take time to update, as you can see in many maps, where something should be instantaneous, but is not due to units being part of the equation.[/quote] The goalpost shifting continues... [img=http://www.fstdt.com/winace/pics/shifting_goalposts.jpg]

Quote from Falkoner

Yes, removing does seem to update, killing does not, and neither does giving. Your explanation does not show why giving does not work. And bring and command definitely take time to update, as you can see in many maps, where something should be instantaneous, but is not due to units being part of the equation.

The goalpost shifting continues...

Still, in many cases my maps have had problems due to problems with Bring and Command, and knowing this really helps with that. Which is the main reason why I posted those two maps.

Still, in many cases my maps have had problems due to problems with Bring and Command, and knowing this really helps with that. Which is the main reason why I posted those two maps.

[quote=name:Falkoner]Still, in many cases my maps have had problems due to problems with Bring and Command, and knowing this really helps with that. Which is the main reason why I posted those two maps.[/quote] There is only one distinction between the bring and command conditions. Bring is during the trigger cycle, command is at the end, period. Actually, it seems to be inconclusive at this point. There could be many explanations for the behavior rather than the cause of the bring. One possibility is that giving adds to some sort of queue which gets cleared at the end of a trigger cycle, or when remove, move, or kill has been encountered, in which case SC then clears the queue. So basically, the bring might not detect the give because it might not have happened yet. And I don't see how one could test it, because theoretically if you used lets say a "remove" action to remove the things that were supposed to be given, that remove action itself might cause the give to execute, as your theory suggests that remove should cause the bring to update.

Quote from Falkoner

Still, in many cases my maps have had problems due to problems with Bring and Command, and knowing this really helps with that. Which is the main reason why I posted those two maps.

There is only one distinction between the bring and command conditions. Bring is during the trigger cycle, command is at the end, period.

Actually, it seems to be inconclusive at this point. There could be many explanations for the behavior rather than the cause of the bring. One possibility is that giving adds to some sort of queue which gets cleared at the end of a trigger cycle, or when remove, move, or kill has been encountered, in which case SC then clears the queue.

So basically, the bring might not detect the give because it might not have happened yet. And I don't see how one could test it, because theoretically if you used lets say a "remove" action to remove the things that were supposed to be given, that remove action itself might cause the give to execute, as your theory suggests that remove should cause the bring to update.

[quote=name:Tuxedo-Templar][quote=name:stickynote][quote=name:devilesk][quote=name:Falkoner]Yes, removing does seem to update, killing does not, and neither does giving. Your explanation does not show why giving does not work. And bring and command definitely take time to update, as you can see in many maps, where something should be instantaneous, but is not due to units being part of the equation.[/quote] The goalpost shifting continues... [img=http://www.fstdt.com/winace/pics/shifting_goalposts.jpg][/quote] Lol.[/quote] Devilesk may not be able to help the way he is, but the way I see, unless we're aiming to create a satellite community of 4chan with SEN, the rest of you should really think twice about finding this stuff acceptable. [/quote] The irony...

Quote from Tuxedo-Templar

Quote from stickynote

Quote from (U)devilesk

Quote from Falkoner

Yes, removing does seem to update, killing does not, and neither does giving. Your explanation does not show why giving does not work. And bring and command definitely take time to update, as you can see in many maps, where something should be instantaneous, but is not due to units being part of the equation.

The goalpost shifting continues...

Lol.

Devilesk may not be able to help the way he is, but the way I see, unless we're aiming to create a satellite community of 4chan with SEN, the rest of you should really think twice about finding this stuff acceptable.

The irony...

We've got evil midgets over in the Null forum currently, you may want to check that out. [quote=name:Tuxedo-Templar]But I've nothing more to say on this. Let whoever wants to be fooled stay that way.[/quote]This is the best way to end any argument. It sort of reminds me of the "yes dear" method of ending an argument in a marriage. I would like to put my vote in, since I try to post only when a portion is relevant: While Falkoner's maps are informative, I don't believe they constitute a concept. If, perhaps, he found some way to (ab)use this, it could be considered a concept. It definitely should go into the wiki, and inform people of the way these conditions work, and ways around it. Inverted locations in a map isn't a concept, they're just nerfed regular locations. The use of inverted locations as a selection system, however, is something I see as an acceptable concept. It wasn't exactly discovered by any one person, even though inverted locations and how they work in starcraft may have been discovered by one person. I consider one of my own creations a concept, though it is by far not original, but a modification of another system: [url=http://whathuh05.googlepages.com/KillstoCashPerfect.scx]Kills to Cash Perfect[/url] (originally by Legacy Weapon). The way he had done it forced one person to get a kill each trigger run, and only that one person. This leads to a large backup if you are going to be killing a lot of people. My system instead adds in a tracker which notes when someone has killed something, and lets multiple people get minerals every trigger run, rather than just 1. Right now, there's not too many new concepts that are useable. I mean, would a reaver ban system, where you build a certain number of scarabs, then move the reaver to a beacon to ban the corresponding player be a concept? To me it just seems like common sense, and is already common knowledge in selection systems. Maybe I'm just rambling.

We've got evil midgets over in the Null forum currently, you may want to check that out.

Quote from Tuxedo-Templar

But I've nothing more to say on this. Let whoever wants to be fooled stay that way.

This is the best way to end any argument. It sort of reminds me of the "yes dear" method of ending an argument in a marriage.

I would like to put my vote in, since I try to post only when a portion is relevant: While Falkoner's maps are informative, I don't believe they constitute a concept. If, perhaps, he found some way to (ab)use this, it could be considered a concept. It definitely should go into the wiki, and inform people of the way these conditions work, and ways around it. Inverted locations in a map isn't a concept, they're just nerfed regular locations. The use of inverted locations as a selection system, however, is something I see as an acceptable concept. It wasn't exactly discovered by any one person, even though inverted locations and how they work in starcraft may have been discovered by one person.

I consider one of my own creations a concept, though it is by far not original, but a modification of another system: Kills to Cash Perfect (originally by Legacy Weapon).

The way he had done it forced one person to get a kill each trigger run, and only that one person. This leads to a large backup if you are going to be killing a lot of people. My system instead adds in a tracker which notes when someone has killed something, and lets multiple people get minerals every trigger run, rather than just 1.

Right now, there's not too many new concepts that are useable. I mean, would a reaver ban system, where you build a certain number of scarabs, then move the reaver to a beacon to ban the corresponding player be a concept? To me it just seems like common sense, and is already common knowledge in selection systems.



Maybe I'm just rambling.

Oooo.... :omfg: Returning to bring/command conditions. Finally I've lost the point of all the discussion about bring/command... Not long ago I've discoverd an interesting thing concerning bring/command. We've been discussing the problem of the order in which conditions are checked on warbox forums. I want to cite from there: [quote=name:Wormer]You see, I've found an interesting thing about command and bring actions behaving with create units. T1c = {P command 0 any unit | create U1} T1b = {P bring 0 any unit | create U1} T2c = {P command 0 any unit | create U2} T2b = {P bring 0 any unit | create U2} T3c = {P command 0 any unit | preserve trigger} T3b = {P bring 0 any unit | preserve trigger} T4 = {P bring 0 any unit, elapsed time > 5 | preserve trigger} T4' = {elapsed time > 5, P bring 0 any unit | preserve trigger} In sequence T1c T2c or T1b T2b the unit U1 which is created by the first trigger is 'invisible' to the T2's condition of the same type. That way U1 and U2 would be created together. But in sequence T1c T2b or T1b T2c different conditions somehow make unit U1 visible to the second condition and U2 is not created at the same triggers loop. Then checking another condition between these two triggers will make created units 'visible' to the second trigger: T1c T3b T2c or T1b T3c T2b. So the fact of checking in T3 could be tested. Sequence T1c T4 T2c will create only U1 and sequence T1c T4' T2c will create both U1 and U2. I have a simple test map: [url=http://webfile.ru/1870357][/quote]

Oooo....
Returning to bring/command conditions. Finally I've lost the point of all the discussion about bring/command...
Not long ago I've discoverd an interesting thing concerning bring/command.

We've been discussing the problem of the order in which conditions are checked on warbox forums. I want to cite from there:

Quote from Wormer

You see, I've found an interesting thing about command and bring actions behaving with create units.

T1c = {P command 0 any unit | create U1}
T1b = {P bring 0 any unit | create U1}
T2c = {P command 0 any unit | create U2}
T2b = {P bring 0 any unit | create U2}
T3c = {P command 0 any unit | preserve trigger}
T3b = {P bring 0 any unit | preserve trigger}
T4 = {P bring 0 any unit, elapsed time > 5 | preserve trigger}
T4' = {elapsed time > 5, P bring 0 any unit | preserve trigger}

In sequence T1c T2c or T1b T2b the unit U1 which is created by the first trigger is 'invisible' to the T2's condition of the same type. That way U1 and U2 would be created together. But in sequence T1c T2b or T1b T2c different conditions somehow make unit U1 visible to the second condition and U2 is not created at the same triggers loop. Then checking another condition between these two triggers will make created units 'visible' to the second trigger: T1c T3b T2c or T1b T3c T2b. So the fact of checking in T3 could be tested. Sequence T1c T4 T2c will create only U1 and sequence T1c T4' T2c will create both U1 and U2.

I have a simple test map: http://webfile.ru/1870357

Oooooh! That's what you were saying! Sorry, the symbolic use you used to describe your theory gave me the wrong the idea at first. So what you're implying is that the trigger's [i]condition[/i] actually has a say in whether the Create Unit action registers by other triggers? Hmm. I'm really not too sure about that. I know for a fact that I can do subsequent Create Unit triggers where the following one's Bring Unit conditions successfully register. However, I do know I've hit weird bugs in the past that seemed to have stemmed from Brings conditions not firing correctly for seemingly unknown reasons. I'll need to put this to some more tests. I don't think it's quite as simple as you make it out, but that does seem close to an answer. (This might also help explain that stupid Order Unit + Give Unit P12 issue I've been having with my Starport launcher...)

Oooooh! That's what you were saying! Sorry, the symbolic use you used to describe your theory gave me the wrong the idea at first.

So what you're implying is that the trigger's condition actually has a say in whether the Create Unit action registers by other triggers? Hmm. I'm really not too sure about that. I know for a fact that I can do subsequent Create Unit triggers where the following one's Bring Unit conditions successfully register. However, I do know I've hit weird bugs in the past that seemed to have stemmed from Brings conditions not firing correctly for seemingly unknown reasons.


I'll need to put this to some more tests. I don't think it's quite as simple as you make it out, but that does seem close to an answer.

(This might also help explain that stupid Order Unit + Give Unit P12 issue I've been having with my Starport launcher...)

Oh, I see. That's a good method for determining if a condition itself has any effect on the actions or other conditions where you just have a condition and a preserve trigger with no other actions. I like how this eliminates any question of create/remove/kill/move etc having any effect on the condition. Now better tests can be performed. Since there's several cases here and certain triggers are being disabled in each one, I think it would be best to clearly organize the data, that way it's easier to read, instead of keeping it in paragraph form.

Oh, I see. That's a good method for determining if a condition itself has any effect on the actions or other conditions where you just have a condition and a preserve trigger with no other actions.

I like how this eliminates any question of create/remove/kill/move etc having any effect on the condition. Now better tests can be performed.

Since there's several cases here and certain triggers are being disabled in each one, I think it would be best to clearly organize the data, that way it's easier to read, instead of keeping it in paragraph form.

[code]//-----------------------------------------------------------------// // T1 Commands //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Command("Player 1", "Any unit", Exactly, 0); Actions: Create Unit("Player 1", "Terran Marine", 1, "Anywhere"); } //-----------------------------------------------------------------// // T1 Brings //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Bring("Player 1", "Any unit", "Anywhere", Exactly, 0); Actions: Create Unit("Player 1", "Terran Marine", 1, "Anywhere"); } //-----------------------------------------------------------------// // T2 Commands //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Command("Player 1", "Any unit", Exactly, 0); Actions: Create Unit("Player 1", "Terran Medic", 1, "Anywhere"); } //-----------------------------------------------------------------// // T2 Brings //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Bring("Player 1", "Any unit", "Anywhere", Exactly, 0); Actions: Create Unit("Player 1", "Terran Medic", 1, "Anywhere"); } //-----------------------------------------------------------------// // T3 Brings //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Bring("Player 1", "Any unit", "Anywhere", Exactly, 0); Actions: Display Text Message(Always Display, "Hiya!"); Preserve Trigger(); } //-----------------------------------------------------------------// // T3 Commands //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Command("Player 1", "Any unit", Exactly, 0); Actions: Display Text Message(Always Display, "lolwut"); Preserve Trigger(); } //-----------------------------------------------------------------// // T4 //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Bring("Player 1", "Any unit", "Anywhere", Exactly, 0); Elapsed Time(At least, 5); Actions: Display Text Message(Always Display, "Hiya!x2"); Preserve Trigger(); } //-----------------------------------------------------------------// // T4' //-----------------------------------------------------------------// Trigger("Player 1"){ Conditions: Elapsed Time(At least, 5); Bring("Player 1", "Any unit", "Anywhere", Exactly, 0); Actions: Display Text Message(Always Display, "lolwutx2"); Preserve Trigger(); } //-----------------------------------------------------------------//[/code] Testing this out nao. [b]Edit:[/b] Well I'll be! The kid is onto something. Sure enough, both the medic and the marine got placed when I isolated the brings and controls pairs separately. Wormer, I owe you one! This discovery will help me out big time!

Code

Testing this out nao.


Edit: Well I'll be! The kid is onto something. Sure enough, both the medic and the marine got placed when I isolated the brings and controls pairs separately.

Wormer, I owe you one! This discovery will help me out big time!

Wow I just tested this: Bring("Player 1", "Any unit", "Location 0", Exactly, 0); Create Unit("Player 1", "Terran Marine", 2, "Location 0"); Bring("Player 1", "Any unit", "Location 0", Exactly, VARIABLE); Create Unit("Player 1", "Terran Firebat", 1, "Location 0"); Two simple triggers. The first one creates two marines. The second one creates a firebat based on a bring condition. I tested three cases. In each case the bring condition for the second condition was different. I tested when it was 0, 1, and 2. The results are quite surprising. When it was 0, the two marines and the firebat were made in the same cycle. When it was 1, the two marines were made but the firebat was not. When it was 2, the two marines were made and the firebat was made in the next cycle. EDIT: I just tried one more test. I changed the condition of the first trigger from a bring to always, and the second trigger's bring condition was set to 0. One would expect it to behave the same as the previous case when the second trigger's bring condition was 0, two marines and a firebat should both be made at the same time. But for some reason when the bring in the first trigger is removed, the firebat is never made.

Wow I just tested this:


Bring("Player 1", "Any unit", "Location 0", Exactly, 0);
Create Unit("Player 1", "Terran Marine", 2, "Location 0");

Bring("Player 1", "Any unit", "Location 0", Exactly, VARIABLE);
Create Unit("Player 1", "Terran Firebat", 1, "Location 0");

Two simple triggers. The first one creates two marines. The second one creates a firebat based on a bring condition.

I tested three cases. In each case the bring condition for the second condition was different. I tested when it was 0, 1, and 2. The results are quite surprising.

When it was 0, the two marines and the firebat were made in the same cycle.
When it was 1, the two marines were made but the firebat was not.
When it was 2, the two marines were made and the firebat was made in the next cycle.

EDIT: I just tried one more test. I changed the condition of the first trigger from a bring to always, and the second trigger's bring condition was set to 0. One would expect it to behave the same as the previous case when the second trigger's bring condition was 0, two marines and a firebat should both be made at the same time.

But for some reason when the bring in the first trigger is removed, the firebat is never made.

[quote=name:devilesk]Wow I just tested this: Bring("Player 1", "Any unit", "Location 0", Exactly, 0); Create Unit("Player 1", "Terran Marine", 2, "Location 0"); Bring("Player 1", "Any unit", "Location 0", Exactly, VARIABLE); Create Unit("Player 1", "Terran Firebat", 1, "Location 0"); Two simple triggers. The first one creates two marines. The second one creates a firebat based on a bring condition. I tested three cases. In each case the bring condition for the second condition was different. I tested when it was 0, 1, and 2. The results are quite surprising. When it was 0, the two marines and the firebat were made in the same cycle. When it was 1, the two marines were made but the firebat was not. When it was 2, the two marines were made and the firebat was made in the next cycle.[/quote] That seems logical. Assuming the fact that the first 2 marines [i]not[/i] being registered is itself 'logical'. :lol: God. Lazy damn Blizzard programmers. Edit: [quote]EDIT: I just tried one more test. I changed the condition of the first trigger from a bring to always, and the second trigger's bring condition was set to 0. One would expect it to behave the same as the previous case when the second trigger's bring condition was 0, two marines and a firebat should both be made at the same time. But for some reason when the bring in the first trigger is removed, the firebat is never made.[/quote] It seems there's some function that 'updates' the status of units found within a location/the map, where that status is being cached between each consecutive activation of the Brings/Commands conditions. Then there appears to be something that resets that cache when the brings/commands consecutive occurrences gets broken (during the same trigger cycle?).

Quote from (U)devilesk

Wow I just tested this:


Bring("Player 1", "Any unit", "Location 0", Exactly, 0);
Create Unit("Player 1", "Terran Marine", 2, "Location 0");

Bring("Player 1", "Any unit", "Location 0", Exactly, VARIABLE);
Create Unit("Player 1", "Terran Firebat", 1, "Location 0");

Two simple triggers. The first one creates two marines. The second one creates a firebat based on a bring condition.

I tested three cases. In each case the bring condition for the second condition was different. I tested when it was 0, 1, and 2. The results are quite surprising.

When it was 0, the two marines and the firebat were made in the same cycle.
When it was 1, the two marines were made but the firebat was not.
When it was 2, the two marines were made and the firebat was made in the next cycle.

That seems logical. Assuming the fact that the first 2 marines not being registered is itself 'logical'.

God. Lazy damn Blizzard programmers.

Edit:

Quote

EDIT: I just tried one more test. I changed the condition of the first trigger from a bring to always, and the second trigger's bring condition was set to 0. One would expect it to behave the same as the previous case when the second trigger's bring condition was 0, two marines and a firebat should both be made at the same time.

But for some reason when the bring in the first trigger is removed, the firebat is never made.

It seems there's some function that 'updates' the status of units found within a location/the map, where that status is being cached between each consecutive activation of the Brings/Commands conditions. Then there appears to be something that resets that cache when the brings/commands consecutive occurrences gets broken (during the same trigger cycle?).

[quote=name:Tuxedo-Templar][quote=name:devilesk]Wow I just tested this: Bring("Player 1", "Any unit", "Location 0", Exactly, 0); Create Unit("Player 1", "Terran Marine", 2, "Location 0"); Bring("Player 1", "Any unit", "Location 0", Exactly, VARIABLE); Create Unit("Player 1", "Terran Firebat", 1, "Location 0"); Two simple triggers. The first one creates two marines. The second one creates a firebat based on a bring condition. I tested three cases. In each case the bring condition for the second condition was different. I tested when it was 0, 1, and 2. The results are quite surprising. When it was 0, the two marines and the firebat were made in the same cycle. When it was 1, the two marines were made but the firebat was not. When it was 2, the two marines were made and the firebat was made in the next cycle.[/quote] That seems logical. Assuming the fact that the first 2 marines [i]not[/i] being registered is itself 'logical'. :lol: God. Lazy damn Blizzard programmers. Edit: [quote]EDIT: I just tried one more test. I changed the condition of the first trigger from a bring to always, and the second trigger's bring condition was set to 0. One would expect it to behave the same as the previous case when the second trigger's bring condition was 0, two marines and a firebat should both be made at the same time. But for some reason when the bring in the first trigger is removed, the firebat is never made.[/quote] It seems there's some function that 'updates' the status of units found within a location/the map, where that status is being cached between each consecutive activation of the Brings/Commands conditions. Then there appears to be something that resets that cache when the brings/commands consecutive occurrences gets broken (during the same trigger cycle?).[/quote] I think with more tests using many different cases, we'll be able to put together a more definitive explanation and model for how it's working, but I'm going to bed now.

Quote from Tuxedo-Templar

Quote from (U)devilesk

Wow I just tested this:


Bring("Player 1", "Any unit", "Location 0", Exactly, 0);
Create Unit("Player 1", "Terran Marine", 2, "Location 0");

Bring("Player 1", "Any unit", "Location 0", Exactly, VARIABLE);
Create Unit("Player 1", "Terran Firebat", 1, "Location 0");

Two simple triggers. The first one creates two marines. The second one creates a firebat based on a bring condition.

I tested three cases. In each case the bring condition for the second condition was different. I tested when it was 0, 1, and 2. The results are quite surprising.

When it was 0, the two marines and the firebat were made in the same cycle.
When it was 1, the two marines were made but the firebat was not.
When it was 2, the two marines were made and the firebat was made in the next cycle.

That seems logical. Assuming the fact that the first 2 marines not being registered is itself 'logical'.

God. Lazy damn Blizzard programmers.

Edit:

Quote

EDIT: I just tried one more test. I changed the condition of the first trigger from a bring to always, and the second trigger's bring condition was set to 0. One would expect it to behave the same as the previous case when the second trigger's bring condition was 0, two marines and a firebat should both be made at the same time.

But for some reason when the bring in the first trigger is removed, the firebat is never made.

It seems there's some function that 'updates' the status of units found within a location/the map, where that status is being cached between each consecutive activation of the Brings/Commands conditions. Then there appears to be something that resets that cache when the brings/commands consecutive occurrences gets broken (during the same trigger cycle?).

I think with more tests using many different cases, we'll be able to put together a more definitive explanation and model for how it's working, but I'm going to bed now.

Here's some of my research with Brings:[list] [*]Test with 3 or more consecutive Brings/Commands triggers:[list] [*]Goes on indefinitely until "reset". [/list] [*]Test with At least/At most modifiers:[list] [*]Modifiers don't appear to produce any new effect. [/list] [*]Test between multiple trigger cycles. [*]Test with different numbers/types of units:[list] [*]Checking for unit type appears to have no affect. [*]Only the [i]absence[/i] of the unit registers with the condition; the [i]presence[/i] is never detected the "cache" resets. [/list] [*]Test with different locations:[list] [*]Using different locations for Brings Unit appears not to register the same together when overlapped. [*]Even checking with a Brings Unit with a different location appears to reset the "cache" for the original Brings Unit's location. Even different locations will "reset" the cache, apparently.[/list] [*]Test with different condition types. [/list] Bah. That's enough for now. This gonna take some time.

Here's some of my research with Brings:

• Test with 3 or more consecutive Brings/Commands triggers:
  • Goes on indefinitely until "reset".
    
• Test with At least/At most modifiers:
  • Modifiers don't appear to produce any new effect.
    
• Test between multiple trigger cycles.
  
• Test with different numbers/types of units:
  • Checking for unit type appears to have no affect.
    
  • Only the absence of the unit registers with the condition; the presence is never detected the "cache" resets.
    
• Test with different locations:
  • Using different locations for Brings Unit appears not to register the same together when overlapped.
    
  • Even checking with a Brings Unit with a different location appears to reset the "cache" for the original Brings Unit's location. Even different locations will "reset" the cache, apparently.
• Test with different condition types.
  

Bah. That's enough for now. This gonna take some time.

Wow, one full page of spam. I don't want this to be over because of two idiots deciding to battle it out. . .

Wow, one full page of spam. I don't want this to be over because of two idiots deciding to battle it out. . .

The two of them had it out, but have chosen not to continue arguing. Any further posts related to that exchange will be deleted.

The two of them had it out, but have chosen not to continue arguing. Any further posts related to that exchange will be deleted.

[quote=name:Tuxedo-Templar]So what you're implying is that the trigger's condition actually has a say in whether the Create Unit action registers by other triggers?[/quote] Yes, that is what I'm impying. [quote=name:Tuxedo-Templar]Hmm. I'm really not too sure about that. I know for a fact that I can do subsequent Create Unit triggers where the following one's Bring Unit conditions successfully register. However, I do know I've hit weird bugs in the past that seemed to have stemmed from Brings conditions not firing correctly for seemingly unknown reasons.[/quote] The reason is that the first bring (or command) action influence on the result. Let's discuss bring conditions, with commands it is the same. There is a template (BringCondition -> CreateAction -> BringCondition -> AnotherBringCondition -> EvenMoreBringConditions...) when the bring conditions following the create action do not notice the created unit. But, if there is no first BringCondition like it is in the next template (AnotherCondition -> CreateAction -> BringCondition) conditions following the create action easily detect the created unit. [quote=name:Wormer]Then checking another condition between these two triggers will make created units 'visible' to the second trigger: T1c T3b T2c or T1b T3c T2b.[/quote] One more thing I want to point out. The parameters of the condition in trigger T3b or T3c (which executes in the middle) does not matter at all. The condition could check any unit controlled by the other player, it could be true or false. All this does not influence the result at all. The essencial thing turns out to be just the fact of executing (or checking) the condition of the other type.

Quote from Tuxedo-Templar

So what you're implying is that the trigger's condition actually has a say in whether the Create Unit action registers by other triggers?

Yes, that is what I'm impying.

Quote from Tuxedo-Templar

Hmm. I'm really not too sure about that. I know for a fact that I can do subsequent Create Unit triggers where the following one's Bring Unit conditions successfully register. However, I do know I've hit weird bugs in the past that seemed to have stemmed from Brings conditions not firing correctly for seemingly unknown reasons.

The reason is that the first bring (or command) action influence on the result. Let's discuss bring conditions, with commands it is the same. There is a template (BringCondition -> CreateAction -> BringCondition -> AnotherBringCondition -> EvenMoreBringConditions...) when the bring conditions following the create action do not notice the created unit. But, if there is no first BringCondition like it is in the next template (AnotherCondition -> CreateAction -> BringCondition) conditions following the create action easily detect the created unit.

Quote from