PDA

View Full Version : Replicators Gambit and a troop with 0 or less health - enter play triggers



nicosharp
05-25-2014, 10:11 AM
Scenario:
Buccaneer with the Replicators gambit trigger
Is hit in my hand by a shadowgroove witch. Becomes a 0/0
I play the buccaneer
Its enter play effect triggers to bounce a card.
It then goes into the graveyard
The replicators gambit trigger does not go off as well when it enters play.

Maybe something about the stop between the two enter play abilities? Im not sure why this happened? 1 enter play triggers, and the other does not.

ossuary
05-25-2014, 11:47 AM
I'm guessing there's a state-based check after any trigger resolves (because the engine has to decide if something is dead). So basically, you get one enters play ability even if the troop hits the board dead, but you don't get two (because it dies in between the 1st and 2nd).

nicosharp
05-25-2014, 12:46 PM
I'm guessing there's a state-based check after any trigger resolves (because the engine has to decide if something is dead). So basically, you get one enters play ability even if the troop hits the board dead, but you don't get two (because it dies in between the 1st and 2nd).

That is my assumption as well. Either way, both should trigger.

Xenavire
05-25-2014, 12:56 PM
But shouldn't they both go on the stack before the state is checked? And anything on the stack should resolve regardless of death. I think the bug would be elsewhere (like maybe the trigger from gambit can't 'target' the troop if it isn't in play when it should trigger?)

ossuary
05-25-2014, 02:55 PM
That is my assumption as well. Either way, both should trigger.

No, they shouldn't. Triggers don't use the chain, they fire off automatically. But since they don't use the chain, they can't go on the stack. You're thinking of it like all the triggers go on the stack all at once, then they should all resolve. But that's not how triggers function. They fire off one at a time, in order. In between each trigger, there's a state-based check. Anything that's supposed to be dead, dies. If it was GOING to fire off a trigger, it never gets a chance to, because it's already dead. It's not a matter of the trigger getting interrupted or fizzling, it's a case of the 2nd trigger never being activated in the first place.


But shouldn't they both go on the stack before the state is checked? And anything on the stack should resolve regardless of death. I think the bug would be elsewhere (like maybe the trigger from gambit can't 'target' the troop if it isn't in play when it should trigger?)

Nope. See above.

nicosharp
05-25-2014, 04:10 PM
No, they shouldn't. Triggers don't use the chain, they fire off automatically. But since they don't use the chain, they can't go on the stack. You're thinking of it like all the triggers go on the stack all at once, then they should all resolve. But that's not how triggers function. They fire off one at a time, in order. In between each trigger, there's a state-based check. Anything that's supposed to be dead, dies. If it was GOING to fire off a trigger, it never gets a chance to, because it's already dead. It's not a matter of the trigger getting interrupted or fizzling, it's a case of the 2nd trigger never being activated in the first place.

I completely disagree with this, The last trigger should be whether or not the troop stays in play after it enters play. Not the second or third or fourth/etc. "enters play" power. It makes absolute zero sense for the game to check for the troops ability to stay in-play before another enter's play trigger. Or using your terminology, they both should fire off at the same time before the "state-based check".

zadies
05-25-2014, 04:13 PM
I don't think he was making a rules ruling only saying how the current code was working.

ossuary
05-25-2014, 06:58 PM
It doesn't really matter whether you agree or not. It's a rules-based system, and that is how the rules function. There need to be state-based checks between each trigger for a variety of reasons. The primary one is that the game doesn't run properly if dead troops are hanging around on the board. Every time a troop COULD be dead, the engine needs to check whether or not they ARE, so they can be wiped away and processed correctly otherwise you end up with some of the weird situations we saw in alpha, with the 0/0 pack raptors and honeycaps that stayed on the board.

Imagine if you had two abilities added to a troop that was in your hand. One of them says "when this troop enters play, deal X damage to all troops in play, where X is the number of cards in your hand." The other says "when this troop enters play, draw X cards, where X is the number of troops you control." It is impossible for these two effects to resolve simultaneously. They MUST be done in order. If they're not, the game gets stuck in an infinite loop and the game cannot continue.

In addition, the results of the first trigger affect the variables of the second. You can't get an accurate count of the number of troops in play until you finish resolving the first trigger. A state-based check is required in between each trigger to ensure an accurate calculation, mathematically. It simply must be this way. It doesn't matter whether or not you agree with it, or whether or not you like it. It's how the system is programmed, and it's how it NEEDS to be programmed in order to avoid logic loops in potential future triggers.

Disordia
05-25-2014, 07:19 PM
Ossuary, I don't think a single thing you said in this thread is accurate. An ETB effect will trigger, even if the troop is a 0 toughness troop.

How it should play out is something like this:
Play Buccaneer.
Buccaneer resolves.
Before you get priority again, state based effects are checked, and Buccaneer goes to the graveyard.
You get priority. Now the Buccaneer's ETB effects are placed on the stack in whichever order you choose.
Second ETB effect resolves.
First ETB effect resolves.

If it doesn't work like this, then that is an issue.

hex_colin
05-25-2014, 08:27 PM
Ossuary, I don't think a single thing you said in this thread is accurate. An ETB effect will trigger, even if the troop is a 0 toughness troop.

How it should play out is something like this:
Play Buccaneer.
Buccaneer resolves.
Before you get priority again, state based effects are checked, and Buccaneer goes to the graveyard.
You get priority. Now the Buccaneer's ETB effects are placed on the stack in whichever order you choose.
Second ETB effect resolves.
First ETB effect resolves.

If it doesn't work like this, then that is an issue.

Actually, it'll work however the team has designed it to work. Seems to me like they decided that troops need to be alive for their come into play effects to trigger. Now, that might be different from other games, or it might not be exactly how you'd interpret the language on the cards, but that's the way it works in HEX.

ossuary
05-25-2014, 08:58 PM
My experience has been that even a troop who is "dead on arrival" will trigger a single "enters play" ability. Example: have Shadowgrove Witch hit a troop, then cast that troop anyway (Moon'ariu Sensei is a good test card). You will still get to draw a card. Or use Venomscorn's champion ability to kill a Corpse Fly, then bring it back onto your own board with Uruunaz. Your opponent will have to discard a card from Corpse Fly, even though it dies right away.

However, when you add a second "comes into play" trigger onto a troop that is DOA, the 2nd one doesn't trigger (exactly as I've been describing in my previous posts). Easiest way to replicate this is to combine Moon'ariu Sensei with Dream Dance (so it gets a new trigger after its built in one that says "when this troop enters play, draw a card, then discard a card." Get your opponent to get the Sensei's defense to zero by whatever means, then get it back into play. You will draw one card from its built-in ability, then the state-based check will happen, and it will go to the graveyard. Its second draw/discard ability will not trigger.

This supports my statement that the triggers are not using the chain in the traditional sense, and that there is a state-based check between each one. If they were using the chain, not only would both effects trigger, but it would also be LIFO, so you would actually get the added draw then discard effect rather than the troop's normal draw effect.

I have done this with several different combinations of troops and abilities, it is not limited to just Buccaneer / Replicator. It is clearly how the engine is designed, rather than a single case bug.

zadies
05-26-2014, 06:17 AM
Actually a single enter play ability will activate so if the card has multiple enter play abilities is when there is an issue Colin so it's actually gives the impression it is miss coded because either no enter play abilities should trigger or all of them should.

Either way really works but having a single one trigger just makes no sense at all other then from a coding standpoint

Oss your focusing on how the game is working currently, that does not mean it is working as intended. I can't for the life of me think how a hard copy game with a written rule book would have a rule that says only one enter battle ability triggers when a dead drop is played. The fact that it is coded that way does not mean it should be working that way.

ossuary
05-26-2014, 07:03 AM
But you can't compare this to a paper game, zadies, because a paper game can't add new text to a card. That whole system is designed around only a single "enters play" ability ever being on a card.

Like I said, in order for the programming and game engine to function properly, there has to be a state-based check after each trigger resolves before it moves on to the next one. Now, I could see there being merit in the argument that a troop should have a state-based check BEFORE it triggers anything after you cast it (i.e. no triggers resolve at all because it dies instantly), and if CZE decides to change the game engine to do that, that would still be logical and functional. But that's not how it works.

Imagine it this way, instead, because I think people may be getting hung up on the idea that the troop is 0/0 when you cast it. What if you had a troop that was listed as a 1/1, but had an ability that said "when this troop enters play, it gets permanent -1/-1." And you have modified this troop with Dream Dance, so that when it comes into play, you draw and then discard a card. Here's how it would work:

1) You cast the troop.
2) The troop enters play.
3) First ability resolves. It's now 0/0.
4) State-based check: the troop is found to be dead - it goes to the graveyard, preventing any further "enters play" triggers from firing, because it is no longer in play.

If the "enters play" abilities used the chain, it would be a different scenario, because then they would all already be queued or initiated, so they would all resolve. But they don't. They go one at a time. If you Dream Dance a Buccaneer, it doesn't put the draw/discard action on the chain when you cast it; that effect doesn't occur until you finish resolving the first ability (to unsummon a troop). That effect resolves, THEN you draw and discard a card. The draw/discard never shows up on the chain at all. If it was using the chain and LIFO, you'd actually draw/discard before choosing which troop to unsummon.

I totally get what you guys are saying that it can be a bit confusing to a new player, but it's completely logical and functional based on how the game engine is written. Again, if CZE changes it, I would expect them to add a state-based check BEFORE enters play triggers start to resolve - but barring that, you will always be able to get one (and only one) enters play trigger even from a DOA troop.

zadies
05-26-2014, 07:27 AM
Oss your arguing from the perspective of how it's coded... my argument is that it is coded wrong.

If your trying to convince someone that it is coded correctly you can't rely on the actual code to explain it.

It would be just as easy to do the state based are you alive check after a check to see if all enter play abilities activated.

If one enter play abilities activate all of them should. It shouldn't just be a single one is what we are saying.

Xenavire
05-26-2014, 07:45 AM
I do think someone chipping in here officially would clear this up beyond a doubt. Any takers? :p

ossuary
05-26-2014, 07:59 AM
Oss your arguing from the perspective of how it's coded... my argument is that it is coded wrong.

If your trying to convince someone that it is coded correctly you can't rely on the actual code to explain it.

It would be just as easy to do the state based are you alive check after a check to see if all enter play abilities activated.

If one enter play abilities activate all of them should. It shouldn't just be a single one is what we are saying.

OK, let me try another angle, then. :)

When alpha FIRST launched, DOA troops did not trigger their abilities when they died. My first day playing, I tried to cast a Moon'ariu Sensei that had been Shadowgrove Witched, figuring I would at least get the drawn card out of it. I didn't. It went straight to the graveyard with no effect.

It was only about a month or two later that they changed it to the current system, where you get one trigger, but not more. That means it USED to be bugged, and they changed it to how they want it to work, how it is supposed to work, how it was meant to work in the first place.

Does that help any? :)

Xenavire
05-26-2014, 08:11 AM
OK, let me try another angle, then. :)

When alpha FIRST launched, DOA troops did not trigger their abilities when they died. My first day playing, I tried to cast a Moon'ariu Sensei that had been Shadowgrove Witched, figuring I would at least get the drawn card out of it. I didn't. It went straight to the graveyard with no effect.

It was only about a month or two later that they changed it to the current system, where you get one trigger, but not more. That means it USED to be bugged, and they changed it to how they want it to work, how it is supposed to work, how it was meant to work in the first place.

Does that help any? :)

They might have overlooked the interaction, Oss. I agree that the evidence does side with you, but it isn't fullproof. :p

SacrificialToast
05-26-2014, 08:13 AM
Replicator's Gambit didn't even work at the start of Alpha, though, and Dream Dance certainly wasn't in. Triggered abilities also went on the stack at that point. Just because they fixed one bug with ETB effects doesn't preclude them from still being bugged.

nicosharp
05-26-2014, 08:40 AM
Just because they fixed one bug with ETB effects doesn't preclude them from still being bugged.

^this

i could care a less about this from a programming standpoint. i want the functionality of the cards printed text to work as intended.

Disordia
05-26-2014, 09:51 AM
Lol it makes absolutely zero sense to trigger one etb effect and not more. Occam's razor tells me this is just a bug in the code. Again, it would be nice if they would give us a rule book or at least comment here, but I seriously doubt it's working as intended. I mean if you guys could give a real reason why it should work how it is currently, I'm all ears.

Xenavire
05-26-2014, 10:23 AM
Ossuarys theory is a real reason that does make sense, on the basis that all the triggers would have to be checked in order, and that the death of a troop would interrupt them.

It isn't a crazy assessment, and I understand where he is coming from. But it isn't the intuitive answer, nor is it guaranteed to be the right one. If CZE refuses to respond, we should default to assuming Oss is right until we hear otherwise (but really, we should get an official answer on this one, because there are multiple ways to reach this outcome, making it common enough to be a problem.)

nicosharp
05-26-2014, 01:02 PM
....why even post any of that Xen?

zadies
05-26-2014, 04:00 PM
I think he is hoping if the thread gets long enough that someone official will post.

Tbh the people that coded the correction given they aren't the people designing the cards could just have forgotten that it was possible to have multiple enter play effects on a single card when they coded the iniral fix.

zadies
05-26-2014, 04:00 PM
Dbl post

Tinfoil
05-27-2014, 06:00 AM
I certainly agree that from a game design point of view, it makes no sense to have some effects trigger and some not trigger, when they trigger at the same time, though I understand that you can't have events that trigger simultaneously with no priority from a coding perspective.

Disordia
05-27-2014, 07:39 AM
I certainly agree that from a game design point of view, it makes no sense to have some effects trigger and some not trigger, when they trigger at the same time, though I understand that you can't have events that trigger simultaneously with no priority from a coding perspective.

You actually can do this and I doubt it would be at all difficult.

ossuary
05-27-2014, 08:47 AM
No, you can't (or rather, shouldn't), because it could very easily cause a logic loop. Each event has to be handled individually - you cannot process multiple events all at the same time. It simply isn't feasible, logical, or sensical to run a system this way, because of the potential conflicts it could create. That's the whole reason the chain exists in the first place.

Even if you take death out of the equation, you shouldn't be processing multiple triggers at once.

Here's a fun card:

Backdraft - 4(RR)
Quick Action
Deal 3 damage to all troops in play.
Deal 1 damage to you for each troop in play.

With your system, this card would never really be possible, because you would just kill yourself with it trying to wipe out an army. With a properly built system, like the one we actually have, this card wipes out the army, but penalizes you for every troop you didn't kill. Fun, no? :)

Disordia
05-27-2014, 09:29 AM
Again you can't seem to differentiate between a triggering an ability and resolving said ability. There's no issue with one event triggering multiple triggers. It's a pretty common occurrence in games that use stacks or chains or queues or heaps or however you want to call them.They'll all go into the chain, then they can be resolved individually.

ossuary
05-27-2014, 10:51 AM
OK, I know what you're saying, but you're still fundamentally missing the main point. The developers clearly intend for multiple triggers to resolve individually, so that any chain reactions that occur are based on the developing board position as each resolves. They don't WANT to add them all to the chain at the same time based on the current board state when the process starts, or that's what they would have done. They intend for each effect to resolve fully before the next one grabs any variables based on the new board state, and then resolve each trigger one by one based on that.

It doesn't really matter if you think it's possible to resolve them all simultaneously or not, because that's not how it works. This issue got clouded a little bit because of the whole DOA troop thing, but the fact remains that when multiple enters play triggers are created by a single troop or spell or event, each one resolves one by one, they don't all resolve simultaneously, and they don't all use the original board state from when the event first created them - each trigger resolves, one by one, doing a state-based check in between to update any variables.

You can see this behavior pretty easily if you combine Replicator's Gambit + Sword Trainer. If it worked the way you're saying it should, all 7 Sword Trainers would hit the board at the same time, and simultaneously check each others' power, giving +12/+0 to each other, and you'd end up with 7 identical 14/2 Sword Trainers. But that's NOT what happens. Each one's trigger resolves one by one, seeing each of the previous Sword Trainers already on the board, resulting in a 2/2, 4/2, 6/2, 8/2, 10/2, 12/2, and 14/2 Sword Trainer. This is proof of exactly how the trigger system works. Any claim to the contrary is irrelevant. It doesn't matter if you like it or not, it's just how it works.

nicosharp
05-27-2014, 10:55 AM
Backdraft - 4(RR)
Quick Action
Deal 3 damage to all troops in play.
Deal 1 damage to you for each troop in play.

With your system, this card would never really be possible, because you would just kill yourself with it trying to wipe out an army. With a properly built system, like the one we actually have, this card wipes out the army, but penalizes you for every troop you didn't kill. Fun, no? :)
Hey Oss,
I have to say, that is a pretty good example. However, you are comparing apples to oranges.
Effects that deal damage should be following that logical stop. Where the first effect resolves, checks game-state, and then the second line resolves.
This can basically be summed up as an If, Then statement

However, Entering Play triggers on a single entity should not be If, Then statements. They should be If, And, Then statements. The "And" being the second, third, fourth, etc. enters play trigger. The "Then" being the troops ability to stay in play.

(I have very minimal programming knowledge, but I do a lot of excel work - I am trying to use this as an example, even if it may be off, to argue the "Enters play" mechanic as it is intended, not as it is intended through current game programming to avoid logic loops)

(Edit: Also I think damage based checks always happen to the player not on the play first. For example, if a spell or ability did a damage to both champions that you cast, and would kill both of you, the damage will result first on your opponent, and you would end up with the win.)

ossuary
05-27-2014, 10:56 AM
nico, read my post that I posted right above yours while you were typing that one up. I think it's an even better example (and proof that the trigger system really does work that way). :)

Edit: BTW - I want Backdraft to be a real card, I think it's awesome ;)

nicosharp
05-27-2014, 11:11 AM
You can see this behavior pretty easily if you combine Replicator's Gambit + Sword Trainer. If it worked the way you're saying it should, all 7 Sword Trainers would hit the board at the same time, and simultaneously check each others' power, giving +12/+0 to each other, and you'd end up with 7 identical 14/2 Sword Trainers. But that's NOT what happens. Each one's trigger resolves one by one, seeing each of the previous Sword Trainers already on the board, resulting in a 2/2, 4/2, 6/2, 8/2, 10/2, 12/2, and 14/2 Sword Trainer. This is proof of exactly how the trigger system works. Any claim to the contrary is irrelevant. It doesn't matter if you like it or not, it's just how it works.
This is actually not a good example. Because you are dealing with 7 separate instances of enters play triggers on individual entities. Even though they all come into play at virtually the same time.
If a single entity has 2 or more enters play triggers they don't need to fire off on the same time, but should both go on the stack before a game-state check against the cards ability to stay in play.

Another example is if you have 7 Blood Bearers in play. If they all die at the same time, you heal for 49, not 7+6+5+4+3+2+1 = 28. Game state checks for death happen simultaneously and so do death triggers....


I would really like to see a quick post from CZE here to clarify either how they want the game to work, or how the game has to work due to programming logic... This is honestly a big deal to how the game will be played going forward, as this situation will present itself more often than not.

Disordia
05-27-2014, 11:39 AM
OK, I know what you're saying, but you're still fundamentally missing the main point. The developers clearly intend for multiple triggers to resolve individually, so that any chain reactions that occur are based on the developing board position as each resolves. They don't WANT to add them all to the chain at the same time based on the current board state when the process starts, or that's what they would have done. They intend for each effect to resolve fully before the next one grabs any variables based on the new board state, and then resolve each trigger one by one based on that.

It doesn't really matter if you think it's possible to resolve them all simultaneously or not, because that's not how it works. This issue got clouded a little bit because of the whole DOA troop thing, but the fact remains that when multiple enters play triggers are created by a single troop or spell or event, each one resolves one by one, they don't all resolve simultaneously, and they don't all use the original board state from when the event first created them - each trigger resolves, one by one, doing a state-based check in between to update any variables.

You can see this behavior pretty easily if you combine Replicator's Gambit + Sword Trainer. If it worked the way you're saying it should, all 7 Sword Trainers would hit the board at the same time, and simultaneously check each others' power, giving +12/+0 to each other, and you'd end up with 7 identical 14/2 Sword Trainers. But that's NOT what happens. Each one's trigger resolves one by one, seeing each of the previous Sword Trainers already on the board, resulting in a 2/2, 4/2, 6/2, 8/2, 10/2, 12/2, and 14/2 Sword Trainer. This is proof of exactly how the trigger system works. Any claim to the contrary is irrelevant. It doesn't matter if you like it or not, it's just how it works.

I'm not sure how you aren't getting the difference between triggered and resolve, but whatever. Even if they want each trigger to be triggered and resolved before the next one is triggered, that still doesn't change the fact that they should all still be triggered, since the triggering event happened. To not do so is illogical and speaks of changing rule design to fit the ability, or in this case lack thereof, of their programmers.

Also with the sword trainer example, I would like to see them all see each other and buff each other, but it seems they are currently unable to have troops enter or leave the battlefield simultaneously, which again speaks to programmers ability if this is intended. We've had these issues before, with cards like immortality. Also, that example is completely irrelevant in regards to our current discussion.

Gwaer
05-27-2014, 11:45 AM
All enters play abilities should activate, even if a card is doa. They entered play. That's the end of it. If they aren't activating all of their enters play abilities, then it's a bug. Even if it's an understandable bug from a programming perspective.

ossuary
05-27-2014, 11:51 AM
Another example is if you have 7 Blood Bearers in play. If they all die at the same time, you heal for 49, not 7+6+5+4+3+2+1 = 28. Game state checks for death happen simultaneously and so do death triggers....

This is a bad example, because death is a different event. You are triggering 7 troops dying 1 time. It's still 1 event though, because it's death from combat (or extinction, or heatwave, or whatever). It's not the same thing as multiple distinct triggers.

Back at my original example, the Replicator's Gambit is creating the 7 Sword Trainers (or rather, 6 additional Sword Trainers, the 1st is entering play alone). If the system resolved everything simultaneously, the only possible scenario would be for either all 6 of them to get JUST the first Sword Trainer's buff, or all 6 of them to get the full buff from each other. That doesn't happen - they go in order. Because that's how the trigger resolution system works - trigger, resolve, state-check, trigger, resolve, state-check...

Disordia
05-27-2014, 11:52 AM
Gwaer, stop agreeing with me. I'm not used to it and it feels weird. :p

ossuary
05-27-2014, 11:53 AM
IF enters play triggers used the chain and queued up, you guys would be right. Since they DON'T, you're wrong. You can say "it ought to work that way" all you want; it still doesn't.

Disordia
05-27-2014, 11:55 AM
This is a bad example, because death is a different event. You are triggering 7 troops dying 1 time. It's still 1 event though, because it's death from combat (or extinction, or heatwave, or whatever). It's not the same thing as multiple distinct triggers.

Back at my original example, the Replicator's Gambit is creating the 7 Sword Trainers (or rather, 6 additional Sword Trainers, the 1st is entering play alone). If the system resolved everything simultaneously, the only possible scenario would be for either all 6 of them to get JUST the first Sword Trainer's buff, or all 6 of them to get the full buff from each other. That doesn't happen - they go in order. Because that's how the trigger resolution system works - trigger, resolve, state-check, trigger, resolve, state-check...

It's not a bad example, they all enter play or leave play at the same time, with triggers on entering or leaving play. What is said to me it's that they haven't figured out how to have multiple troops leave play or enter play simultaneously. Like I said, they had the same kind of issue with immortality in alpha, and I'd bet it's the same thing here.

nicosharp
05-27-2014, 12:00 PM
This is a bad example, because death is a different event. You are triggering 7 troops dying 1 time. It's still 1 event though, because it's death from combat (or extinction, or heatwave, or whatever). It's not the same thing as multiple distinct triggers.

Back at my original example, the Replicator's Gambit is creating the 7 Sword Trainers (or rather, 6 additional Sword Trainers, the 1st is entering play alone). If the system resolved everything simultaneously, the only possible scenario would be for either all 6 of them to get JUST the first Sword Trainer's buff, or all 6 of them to get the full buff from each other. That doesn't happen - they go in order. Because that's how the trigger resolution system works - trigger, resolve, state-check, trigger, resolve, state-check...
Oh, Okay. Oss. I think I see the disconnect.

Let's clarify a few things:
#1 - The Replicated copies of the 0/0 Buccaneer never "entering play" is not the issue.
#2 - The Replicated copies of the Buccaneer would have all been 2/2 Buccaneer's because replication is on the original card, not the permanently modified card.
#3 - The issue is that the 0/0 Buccaneer that was played did not have both enters play triggers proc.
#4 - This above example is similar in a way to death triggers, as like death, triggers should fire off simultaneously for a single entity when they enter play.
#5 - The Blood Bearer example was used to show, triggers can fire off at the same time in the programming, not that death for multiple units is the same as entering play for a single unit.\

I know you are saying there needs to be a game-state check in-between the two enters play powers, but I am saying there can be a game-state check, but it should not be on whether or not the troop stays in play yet.. That check should happen after all enters play powers at least go on the chain.

I think the only thing this thread is short of, is writing the code for the developers to fix the issue...

ossuary
05-27-2014, 12:06 PM
No, I got what you were saying in the first place. I know all the Buccaneers wouldn't have been DOA. I'm with you on that, as the supposition of the OP. I've just been trying to explain why it doesn't work that way, because of the state-based check preventing subsequent triggers from ever going into the hopper for resolution in the first place.

Since the triggers aren't using the chain, a state-based check that removes the source from play is effectively a hard stop for any additional triggers that source might have. If they were targeted abilities instead of triggers, and therefore going onto the chain, THEN they would all process no matter what. But triggers and abilities aren't the same thing, and they work differently.

nicosharp
05-27-2014, 12:09 PM
No, I got what you were saying in the first place. I know all the Buccaneers wouldn't have been DOA. I'm with you on that, as the supposition of the OP. I've just been trying to explain why it doesn't work that way, because of the state-based check preventing subsequent triggers from ever going into the hopper for resolution in the first place.

Since the triggers aren't using the chain, a state-based check that removes the source from play is effectively a hard stop for any additional triggers that source might have. If they were targeted abilities instead of triggers, and therefore going onto the chain, THEN they would all process no matter what. But triggers and abilities aren't the same thing, and they work differently.
If this is truly the limitation. They need to have a secondary state-based check written for all troops in regards to "enters play", that does not interfere with the standard state-based check.

MatWith1T
05-27-2014, 12:20 PM
IF enters play triggers used the chain and queued up, you guys would be right. Since they DON'T, you're wrong. You can say "it ought to work that way" all you want; it still doesn't.

If enter play triggers don't queue up, then your 'trigger, resolve, state-check, trigger' order wouldn't hold true. One happens before the other, therefore there is a queue. There may not be a stack, but there is certainly a queue that sets the order for trigger resolution.

But if we follow your rule of 'trigger, resolve, state-check, trigger' because of your "thats the way it is" policy... why does the recall trigger resolve first? What is the rule about which trigger would be resolved first in that scenario? Should there also be a "Set Card Priority" pop-up whenever two triggers would occur? If so, shouldn't that same "Set Card Priority" option be required for the aforementioned simultaneous death triggers (blood bearer)?

Your "It doesn't work that way because it doesn't" argument would carry a lot more weight if this weren't a Beta version - which is exactly the time when you seek to find these sort of discrepancies and inconsistencies, and attempt to resolve them. And right now, simultaneous effects are totally inconsistent - there is no "official rule" you can make that would be consistent with the way simultaneous events currently handle. The closest thing we have is the FAQ ruling on Eye Of Creation, which differentiates between "When" triggers and "As" triggers - and applying that rule, there is no reason that Buccaneer and Replicators Gambit should not have both resolved here, as both are "When" triggers.

Gwaer
05-27-2014, 12:21 PM
Sorry oss, by no reading of any rules of any game that lay out triggered abilities is your interpretation correct. It's a bug. I can point you to the MTG comp rules on the issue if you like http://wiki.mtgsalvation.com/article/Triggered_ability The cards were not designed to work as they are working now, the underlying system is not designed to work as it is working now, it's a bug.

Instead of going back and forth on the issue forever, how about we make it more interesting. I bet you a spectral lotus garden that my interpretation is correct, and that it is a bug. If you're so certain put your valuables where your mouth is =P

Disordia
05-27-2014, 12:34 PM
How do you still think triggered abilities don't go on the chain? This disconnect is simply baffling to me. Have you never played a Buccaneer? The triggered ability goes on the chain. If a triggering event happens, then the triggered ability will go on the stack. That's the only thing that matters with a triggered ability. Anything else is pure idiocy or sloppy programming.

DionyzRex
05-27-2014, 02:11 PM
We have confirmed internally that this is broken. When a 0/0 troop enters play, it's not triggering Replicator's Gambit.

It -is- still triggering the added text from Dream Dance though, which is intriguing.


Regardless, we've shipped it off to engineering.


For future reference, regardless of what happens to a troop after it enters play (such as dying to state-based effects) it should still trigger -all- of its enters play triggers.

MatWith1T
05-27-2014, 02:18 PM
We have confirmed internally that this is broken. When a 0/0 troop enters play, it's not triggering Replicator's Gambit.

It -is- still triggering the added text from Dream Dance though, which is intriguing.


Regardless, we've shipped it off to engineering.


For future reference, regardless of what happens to a troop after it enters play (such as dying to state-based effects) it should still trigger -all- of its enters play triggers.

Thanks!

nicosharp
05-27-2014, 02:40 PM
I think once again, Gwaer is owed a Spectral Lotus Garden by his own proclamation. What is that now Gwaer.... 244?

DionyzRex
05-27-2014, 02:52 PM
OK, I know what you're saying, but you're still fundamentally missing the main point. The developers clearly intend for multiple triggers to resolve individually, so that any chain reactions that occur are based on the developing board position as each resolves. They don't WANT to add them all to the chain at the same time based on the current board state when the process starts, or that's what they would have done. They intend for each effect to resolve fully before the next one grabs any variables based on the new board state, and then resolve each trigger one by one based on that.

It doesn't really matter if you think it's possible to resolve them all simultaneously or not, because that's not how it works. This issue got clouded a little bit because of the whole DOA troop thing, but the fact remains that when multiple enters play triggers are created by a single troop or spell or event, each one resolves one by one, they don't all resolve simultaneously, and they don't all use the original board state from when the event first created them - each trigger resolves, one by one, doing a state-based check in between to update any variables.

You can see this behavior pretty easily if you combine Replicator's Gambit + Sword Trainer. If it worked the way you're saying it should, all 7 Sword Trainers would hit the board at the same time, and simultaneously check each others' power, giving +12/+0 to each other, and you'd end up with 7 identical 14/2 Sword Trainers. But that's NOT what happens. Each one's trigger resolves one by one, seeing each of the previous Sword Trainers already on the board, resulting in a 2/2, 4/2, 6/2, 8/2, 10/2, 12/2, and 14/2 Sword Trainer. This is proof of exactly how the trigger system works. Any claim to the contrary is irrelevant. It doesn't matter if you like it or not, it's just how it works.


As an aside, the Replicator's Gambit effect on Sword Trainer is also a bug and has been in our database for almost a month. :)

nicosharp
05-27-2014, 02:54 PM
As an aside, the Replicator's Gambit effect on Sword Trainer is also a bug and has been in our database for almost a month. :)
Interesting.... So does that mean that should all proc at once making them only 4/2's
Or they should not even proc off the first copy making them 2/2's
Or they should all proc off each other making them 14/2s?

Also thanks for clarifying above.

ossuary
05-27-2014, 02:57 PM
As an aside, the Replicator's Gambit effect on Sword Trainer is also a bug and has been in our database for almost a month. :)

Well how am I supposed to form an accurate understanding of everything if the known bugs aren't documented? ;)

nicosharp
05-27-2014, 03:08 PM
Well how am I supposed to form an accurate understanding of everything if the known bugs aren't documented? ;)
Having previous TCG rule knowledge (even if fuzzy), mainly from WOWTCG and MTG really help address things that are working as intended and things that may be bugged or programmed incorrectly.

Gwaer
05-27-2014, 03:10 PM
I think once again, Gwaer is owed a Spectral Lotus Garden by his own proclamation. What is that now Gwaer.... 244?
Something like that.

DionyzRex
05-27-2014, 03:12 PM
Interesting.... So does that mean that should all proc at once making them only 4/2's
Or they should not even proc off the first copy making them 2/2's
Or they should all proc off each other making them 14/2s?

Also thanks for clarifying above.

Assuming nothing else is affecting it, you should receive a 2/2 (original) and 6 4/2s.


Well how am I supposed to form an accurate understanding of everything if the known bugs aren't documented? ;)


No worries, just wanted to clarify so everyone knows what to expect.

Disordia
05-27-2014, 04:02 PM
Assuming nothing else is affecting it, you should receive a 2/2 (original) and 6 4/2s.




No worries, just wanted to clarify so everyone knows what to expect.

Wait, so troops that come into play at the same time don't see each other?

DionyzRex
05-27-2014, 04:06 PM
They do see each other enter play, but they are not already IN play when their friends arrive. For example, Gambit + Sword Trainer is 2/2 and 6 4/2s while Gambit + War Machinist = 42 damage to opponent.


The difference here is that the inspire trigger is an "As another troop enters play" whereas War Machinist is "When..."

Essentially, "As" means that the troop with the inspire ability has to be fully in play before the second troop enters play, otherwise inspire troops would inspire themselves. For "When" its just checking to make sure that something DID just enter play, so it 'sees' itself enter.

ossuary
05-27-2014, 04:07 PM
Wait, so troops that come into play at the same time don't see each other?

Yes (sort of, see above), that much was confirmed before, when they were working on getting Eye of Creation to function properly. For example, if you drop two 3-cost troops with inspire with Eye of Creation, they won't inspire each other. Apparently, multiple replicated copies resolving simultaneously are the same scenario. I guess Replicator's Gambit is putting out 6 copies one at a time instead of all 6 at once, and they want it to have the all at once behavior instead.


Assuming nothing else is affecting it, you should receive a 2/2 (original) and 6 4/2s.

So basically, you're capturing all of the relevant variables at the time the originating troop goes into play, and basing all subsequent triggers off of that state? Not updating the board state as you go, in other words?

If so, my Backdraft card will need to be reworded to work properly. :(

DionyzRex
05-27-2014, 04:11 PM
So basically, you're capturing all of the relevant variables at the time the originating troop goes into play, and basing all subsequent triggers off of that state? Not updating the board state as you go, in other words?

If so, my Backdraft card will need to be reworded to work properly. :(

When replicating a Sword Trainer there are no variables to update as you go, so I'm not sure what you mean.

A 2/2 enters play and triggers the Gambit effect of 'create 6 copies of this thing.'

As 6 2/2s are entering play, they get inspired by the first one, and enter play as 4/2s.


Once they have entered play, the chain is clear.


I'm not sure what all subsequent triggers and variables to update you would mean in that scenario.

nicosharp
05-27-2014, 04:14 PM
while Gambit + War Machinist = 42 damage to opponent.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!Awesome...
Time for a new favorite target for replication.

ossuary
05-27-2014, 04:15 PM
I'm not sure what all subsequent triggers and variables to update you would mean in that scenario.

Sorry, I was just thinking of it in terms of the 6 individual copies vs all at once, I keep forgetting that Inspire is special compared to other triggers because it's "as" instead of "when."

Take my theoretical Backdraft card as an example of what I mean by multiple triggers.

Say you have a quick action that says:

"Deal 3 damage to each troop in play.
Deal 1 damage to yourself for each troop in play."

Assuming the system is built to treat these as 2 distinct actions instead of a single event done all at once, would the 2nd piece count all troops that were in play when it started? Or would it only count the troops that were still in play after the 1st piece resolved?

That's the info I'm after. :)

Tinfoil
05-27-2014, 04:32 PM
Gambit + War Machinist = 42 damage to opponent.



I got a bad feeling about this...

MatWith1T
05-27-2014, 05:50 PM
I got a bad feeling about this...

I can verify, after extensive testing for the last couple hours, that this is an incredibly satisfying way to win a game. :)

Xenavire
05-27-2014, 07:38 PM
Pfft, why did you go and tell even more people about my War Machinist and Gambit combo? :p

MatWith1T
05-27-2014, 08:07 PM
Pfft, why did you go and tell even more people about my War Machinist and Gambit combo? :p

No one reads the bug report forum but us nerds

zadies
05-27-2014, 11:19 PM
Given Rex pointed it out in game like 3 days ago it didn't matter it got posted on the forms.

Xenavire
05-28-2014, 04:02 AM
Guess the cats out of the bag haha. My favourite combo by far, could technically win on turn 2.

Incindium
05-28-2014, 07:22 AM
How is Gambit and War Machinist getting to 42 damage? Also how could you use that combo to win on turn 2?

Quasari
05-28-2014, 07:32 AM
How is Gambit and War Machinist getting to 42 damage? Also how could you use that combo to win on turn 2?

The replicas are artifacts, so you have 7 war machinists proc 6 times.

ossuary
05-28-2014, 07:36 AM
How is Gambit and War Machinist getting to 42 damage? Also how could you use that combo to win on turn 2?

Like Quasari said, you end up with 7 machinists in play, 6 of which are artifact troops, so it's 7x6 = 42 damage.

Turn 2 because turn 1, machinist, turn 2, gambit, if the gambit redraws the machinist, recast it for 42 damage turn 2. It's like a 0.00000001% chance of working out that way, but it's theoretically possible.

Tinfoil
05-28-2014, 08:00 AM
I discussed this combo with a friend, maybe a month ago, but we agreed it wasn't the way it was suppose to work. Then I guess we forgot about and I forgot to test. Guess we were wrong.

Why do I only have one copy of RG!!???

DionyzRex
05-28-2014, 08:56 AM
Sorry, I was just thinking of it in terms of the 6 individual copies vs all at once, I keep forgetting that Inspire is special compared to other triggers because it's "as" instead of "when."

Take my theoretical Backdraft card as an example of what I mean by multiple triggers.

Say you have a quick action that says:

"Deal 3 damage to each troop in play.
Deal 1 damage to yourself for each troop in play."

Assuming the system is built to treat these as 2 distinct actions instead of a single event done all at once, would the 2nd piece count all troops that were in play when it started? Or would it only count the troops that were still in play after the 1st piece resolved?

That's the info I'm after. :)

It would not work the way you want it to, as state-based effects wouldn't occur until the card has fully resolved.


Similarly if a card said "Lose 3 health, gain 10 health" you could use it at 1 life without dying.

ossuary
05-28-2014, 09:08 AM
Now I'll never get my cool card. :(

Xenavire
05-28-2014, 11:15 AM
Like Quasari said, you end up with 7 machinists in play, 6 of which are artifact troops, so it's 7x6 = 42 damage.

Turn 2 because turn 1, machinist, turn 2, gambit, if the gambit redraws the machinist, recast it for 42 damage turn 2. It's like a 0.00000001% chance of working out that way, but it's theoretically possible.

Thanks for explaining Oss :D This is exactly how it would be possible. I have come close a few times, but still no turn 2 wins.