In an effort to elucidate (for myself as much as anyone), is it known if you draw before damage is chosen with Synthetic Blood? IE: can the Synthetic Blood draw end up being hit with the incoming damage?
Literally no one plays the card so I don’t know the interaction, but if the SB draw can end up absorbing the damage, then PU almost certainly goes before IHW.
Strictly speaking, Chronos Protocol doesn’t mention “taking” damage. It’s also not worded like most conditionals – while “the first” does suggest a conditional ability, “For the first…” connotes a different structure than “Whenever the first…”
I agree with what you’re saying (it’s why I’m not 100% confident). But I’m also not sure it’s different. It’s why I wanted to try and attack it from a different level (bringing up SB).
But the fact is that almost all abilities in Netrunner react to an occurrence, and then perform something that affects from now forward. CP would need to be pre-empt an occurrence and modify it, if taking and trashing are the same time.
Maybe that’s what is happening, and what the “For the …” wording entails. But it is definitely a bit of a jump from the normal model.
“For the first” actually sounds like a (partial) replacement effect to me.
Also a fair assertion. Replacement effects are defined in the official FAQ as using “instead”, but I suppose there’s no reason it couldn’t be treated similarly.
Though, on point, even replacement effects do not pre-empt an event like CP would have to. They normally react to it happening and then redact it (which is why SDB shuts down ST). This is on another level.
That’s why I had the (partial) in parentheses. It clearly isn’t a replacement effect along the lines of, say, Tori Hanzo – a net damage still definitely happened here (if, say, CP chose to have you discard an IHW for some reason, you would still draw). But it also clearly modifies something as it happens, so it’s not working like a conditional trigger, either. I think it actually works as a constant ability and it just so happens that the thing it modifies includes the word “first,” which we usually associate with a conditional ability (side note: I believe cases like this are why @jakodrako 's primer includes the disclaimer that “the first time” is different than “the first ice, or the first program, etc.”).
But anyway, this is tangential from the original question – mostly what I’m trying to say here is that I don’t think CP is a solid case study to make an argument that “taking damage” and “discarding from damage” are discrete events.
ETA: On further reflection, I regret using the term “replacement” above – this is an inaccurate use of a reserved word.
Even constant abilities require the thing to happen though. Sneakdoor beta is a constant-ability, but it only happens after a successful run on archives is triggered (which is why ST on archives is then rendered inert for the remainder of the turn). This would have to be a special class of pre-emptive ability.
Anyway, I agree that it isn’t a solid case. But I am curious about how it works now.
If we want to get this back on track, I go back to SB draw vs. damage; do you draw then trash at random, or vica versa? The answer here will help.
On further consideration even SB doesn’t necessarily line up with PU + IHW. Could easily have the following:
Damage Flow 1
- X damage Incoming
- Suffer Damage; die if X > cards in hand. If not dead, choose X cards at random from grip to trash.
- Trash the chosen cards.
Under this model, PU would always go before IHW.
Alternatively:
Damage Flow 2
- X damage Incoming
- Suffer Damage; die if X > cards in hand. If not dead, trash X cards at random from grip.
Under this model, it’s based on turn-priority.
Key difference is the separation of choosing cards / taking damage and trashing them. CP leads me to suspect they are separate, but, again, this is not solid foundation. I see both models as plausible.
Stimhack is slightly different. "After the run is completed, suffer 1 brain damage…"
Seems like you resolve that brain damage after any triggers from run is completed triggers.
So I wouldn’t consider it similar to DB and Doppel triggers.
With respect to Stimhack, I definitely cannot see the DB + Doppel ruling extending to it. Even if I don’t understand the rationale around the DB + Doppel ruling, I know with certainty that letting Doppel prevent Stimhack triggers would break Netrunner.
Nobody would play anything outside of stimhack khantract Doppelganger criminal competitively. Not having to take the brain damage is one thing, but not having to return 9 credits is a complete game breaker.
I’m pretty sure that’s just coreset wording, before they started getting more meticulous with the phrasing. But even if true, reconciling this with the DB/Doppel ruling would mean that we have to conclude that “when this run ends” is a specific trigger which can be passed (akin to “when encountered” on ICE) if you move on to another run, and “After the run is completed” cannot be passed by other activities if there are pending triggers (akin to “when your turn begins”). Which, of course, means that while you are on the Doppel run, the DB run has “ended,” but it is not yet “completed,” which starts to feel like Schrodinger’s Cat territory from where I’m sitting.
I try not to call “bad ruling” very often, but this is actually what leads me to believe Damon didn’t think the DB/Doppel ruling through. He thought to himself “Letting DB hang out in the queue would be overly complicated and is a marginal advantage, so lets just say the trigger has passed” without considering that:
a) There were known rulings which contradict this reasoning.
b) There are plenty of times where a trigger can launch a nested series of triggers/interactions while other stuff hangs out in the queue – and even though some very complicated stuff can happen in the meantime with multiple action windows and timing steps (see any combination of: Chum/Kitsune/Archangel/Imp/Khan that you prefer), that doesn’t mean you have ‘passed’ the trigger. Bypassing a piece of ice is, I think, relatively unique in voiding pending triggers because it specifically moves you forward in a designated sequence with discrete and demarcated steps (the run chart for this specific run). Similarly, the “end your action phase” in HHN clearly indicates (at least in the UFAQ) that all pending triggers are invalidated. But these are special cases – that’s why they warrant FAQ clarification – and otherwise, the presumption should be that any simultaneously triggered abilities are waiting patiently for “cascades” to resolve themselves as outlined in the rules.
I agree with pretty much everything you just said, but am very apprehensive to say that Damon didn’t consider the interaction enough before posting a Twitter ruling.
He undoubtedly knows his words hold alot of weight within the community, and doesn’t seem to treat that lightly. While I can’t logically explain his choice, I can only assume there is some rationale here that I’m missing, and I’m going to go by it until there is time for an explanation (or he redacts it).
I don’t like the whole “blind trust” thing, or the ruling, but he is the designer, and hasn’t let me down before this.
I see it brought up a couple of times, but I don’t see it concisely stated…
If there’s a Runner Current in play and Corp Scores a Chronos Project, is the Runner’s Current in the Heap, or Removed from the Game?
(Question actually came up yesterday. At the time we determined that the Current would end up in the Heap by itself since triggers are resolved based on whose turn it is… But I think now the Current self-trash is a Constant ability so it always goes before Chronos Project/When Scored abilities?)
The blanket “current” effect is a constant effect (until); it races the conditional effect of Chronos Project (when).
Heap should be 100% empty.
Thanks. I knew I’d seen a ruling on it but we couldn’t find it. It didn’t end up mattering in that game, but it’s good to know for the future.
The ruling for Doppelganger/Dedicated Response Team is instructive.
The run ends triggers another conditional ability that is resolved after the second doppelganger run.
I think the only quibble is over the text on DB “when this run ends”. Does this somehow trigger but then fizzle if it’s no longer “this” run that has ended.
Does state of the trigger go on a stack when you nest the triggers?
Ah, I think I see. You’re saying that the more generic “Whenever a successful run ends” on DRT could be meeting its condition, then becomes temporarily invalid during the Doppel run (if it were to somehow magically come back to the front of the queue mid-run), but since it doesn’t resolve until the same time as another successful run is ending, the condition is then true again?
But that’s only if we presume two successful runs. Consider, though, that the runner could fail at the Doppel run. Then, we step back to the pending trigger of DRT. From Lukas’ ruling, we presumably still take 2 damage at that point (since he suggests 4 points is only a possibility). This means that, at least under the old ruling, we are still “waiting” in the queue at “a successful run ends” from the first time around – or, that we have not “passed” “Whenever a successful run ends” in the same way that we moved beyond an encounter phase.
I don’t see how it is any different in relation to the run in question (the initial run before Doppelganger fires).
Data Breach has the trigger written: “If successful, […] when this run ends”. Dedicated Response Team has the trigger written: “Whenever a successful run ends”. Each looks for exactly the same compound trigger, the run ending and the run having been successful. The fact that one references “a” run and one “this” run seems irrelevant as they both refer to the same initial run. The trigger is raised when the initial run ends. Then Doppelganger makes another run (with all the nested triggers that may entail, including more potential DRT-ing). Then we come back to the waiting trigger from the first run, Data Breach or DRT.
How can the Data Breach trigger now be deemed to be invalid (either run now isn’t successful or hasn’t ended, while they were both true when the trigger was initially queued), while the DRT trigger is seen to still be valid. Even if you want to say a “run ends” trigger must mean no other runs have happened in between to resolve, that the game shouldn’t have “moved on” past the end of the run, this ought to invalidate DRT as well.
I can’t see the difference myself. What’s sauce for the goose ought to be sauce for the gander.