Salsette/CtM Discussion Thread

Rules Questions
41

The way I see it working now (after ditching my flawed understanding), it’s like a boolean flags for “first” effects. When you make the first successful run on archives, that flag gets set false after all effects relying upon it occur. Replacement effects will not reset the flag; sneakdoor won’t retroactively turn on the “first archives success” flag, despite that there was no successful archives run after sneakdoor fires.

So pretty much what Kesterer said, except instead of “was there a first successful run on archives”, I’d say “is the first archives flag set”. Difference being the later doesn’t make it sound like archives was successfully run (first or ever).

And that’s admittedly a pretty pedantic difference given the current card pool, but I feel like if there was a card that said “Play only after your first successful archives run”, you wouldn’t/shouldn’t be able to install it after a sneakdoor run (but that’s more design level than rules-querying level, and is moot for the current pool anyway).

So archives would be my answer for the apocalypse question (which lines up with the accepted answer). But this is also after hastily re-evaluating my position after proving myself wrong. Maybe that isn’t correct (WRT my reasoning; archives is definitely the answer to the question).

42

What I have gleaned from all of this discussion and previous rulings: Having a “First successful run on Archives” is different than having a “Successful run on Archives”.

Wat?

So, Sneakdoor replaces the successful run on Archives. But, in order to replace it, there must have first been a successful run on archives, which means subsequent runs are now the second, third, etc… successful runs on Archives. That means there is no longer a “successful run on Archives” in the game state (it has been switched to be a successful run on HQ), but there has been a first successful run on Archives, because if there wasn’t then Sneakdoor wouldn’t have anything to replace!

Therefore, using your example with Apoc, you would have to run Archives because, while there has been a first “successful run on Archives”, there has not been an actual recorded “successful run on Archives” for cards to see, since it was replaced with a “successful run on HQ”.

To put in another way, there was a successful run on Archives that turn, but it was replaced with a successful run on HQ. The game state after that says there hasn’t been a successful run on Archives, but a subsequent run won’t be the first since the first one still existed, it was just replaced.

2 Likes
43

Ok, the full version of the (“new thing”, deeply sorry about this) that bothers me resides there :

I don’t understand what Sneakdoor’s "instead treat it as a successful run on HQ. " means now.
The wording is old, and the admitted meaning is “succesfull run (archive)” totally got replaced by “succesfull run (archive)”.

But that log memorizing archives run for archives sectest confuse me.
If it remember for archives sectest (so normal archive run #2 make sectest not working), then why it doesn’t remember for Apoc ?

And if it don’t remember for sectest, why an archive sectest doesn’t trigger run #2 after sneakdoor ?

How is it related to that Slum/CTM ruling now :
Well, Slum’s triggered perma ab, as in the @jakodrako’s point-by-point shema shows that Slum doesn’t “hide” the trash.
I dislikes this but it’s like this.
I’m not disliking this because it’s changing the result, sincerly, it is that way today and I don’t care.

Reason #1, #0, #-1 or #minus infinite I’m disliking it, is because I totally, utterly, fail to understand it.

Sneakdoor “hide” the archive successful run. Slum doesn’t “hide” the trash. Both things, run & trash, get replaced by a perma ab.
I totally don’t understand this.

I (surely wrongly) understand Slum acting there like there was a ‘,’ between trash & RTFG. To me the effect is direct, once prereq met, if no simultaneous trigger then effect take place immediatly. That’s how Sneakdoor works. Not Slum.

Sorry. Sorry and sorry again if this brings new spaghetti elements. i’m so confused now :confused:

44

The point is that, the “first” of “something” is two distinct (but related) elements; the if you replace “something” with “something else”, the “first” still happened in the context of “something” (despite the fact that “something”, itself, has been replaced and is not considered to have occurred).

Don’t look at it like “the first successful archives run”, or “the first trash” has occurred, because this is confusing; how could the first of either of those things occur if they themselves didn’t occur? Look at it instead like the “first” flag for these events has been set, and cannot be set again.

From a programming point of view, imagine you have an event dispatcher for events. They each track their own “first” flags, and fire off the value of those flags each time they send an event. These flags don’t get updated based on consumers actions on the events; they are only tracked by the dispatcher.

The first time the dispatchers sends out an event, it sends it with the flag “first” = true. It then sets the flag to false, and every subsequent time sends out the event with “first” = false.

That’s my view. If someone feels that’s inadequate feel free to LMK.

2 Likes
45

I do get the “first”, the point for me “now” (sorry) is hiding or not hiding the signals :confused:

46

The game doesn’t remember a successful run for Security Testing. It remembers that the first successful run happened. It’s different.

To gauge whether a run is the first successful run or not you don’t look for previous successful runs. You look to see whether the first successful run “flag” has been “set” in the game log. It’s perfectly possible to have that flag set but have no instances of successful runs in the game log.

Apocalypse and Security Testing are looking for different things. Security Testing is looking for the “first successful run” flag. Apocalypse is looking for instances of successful runs in the game log.

1 Like
47

So I can better understand, what do you mean by this?

Sneakdoor “hide” the archive successful run

Sneakdoor does replace the successful run, but it doesn’t hide the fact that the first one happened. If you later run archives with ST, you won’t get money (because the “first” event sent out, which sneakdoor ate, has already come and gone).

Similarly, the first trash event that got sent out was eaten by slums, so CtM can’t fire off the future ones.

48

@popeye09 @ironcache ok, I have to rethink about the first in all those situations. I’m slow there.

So to be crystal clear, if I want to clic 4 apoc, I must run r&d, sneakdoor, normal archive run, all successfully, rigth ?

1 Like
49

Yeah that’s right.

1 Like
50

Warning, I did not understood this yet so turn on your BS detector full power.

But what can I say is this :

Step #2 is not hided by Slum there.

For Sneak/Sectest, the first run on archives get replaced by a first run on HQ. Sneak totally “hides” the prereq of Sectest, since, say it’s clic 1, it’s your first run on any server anyway.
If First Archive Succes was true half a millisecond, Sectest would have chain reaction in Sneak, because there is no concurent effect with the perma ab of sneakdoor (FAQ p.4, chain reaction ruling).

So you would “trade HQ access for credits”, and I know that situation is super wrong.

So I’m thinking Sneakdoor hides the event “succesfull run on archives” in a way that I don’t understand since now Slum don’t hide its trash.

Here, it’s not really a matter of “first” for sneakdoor, I’m still thinking of it for Slum but since first is a restriction, I don’t really understand why Slum should open and sneakdoor close the event signal. More restriction would mean things are more closed, not more opened.

51

I don’t think this is true, if I understand correctly. Both Sneakdoor and ST are informed that the first successful run has happened. However, Sneakdoor’s run ability is a constant effect, and takes precedence over ST. When it fires, the run is no longer on archives, so after the Sneakdoor ability procs, ST attempts to proc and fails (because it’s no longer a successful run on the chosen server).

52

Ok, ST’s signal hiden is a direct consequence of the chain reaction ruling :
“If during the resolution of an ability another ability meets its trigger condition, then a “chain reaction” is created. The ability that just met its trigger condition resolves immediately following the active effect on the current ability.”

So Sneak resolves first, then ST but it can’t, ok I get it.

-edit- arg. Now this is The Foundry ABT that is haunting me. I don’t remember why The Foundry is not waiting full ABT resolution, but I can find this alone I think.

Things gets clearer anyway.

53

I don’t think this ruling is relevant here; there’s no chain reaction. Sneakdoor isn’t causing ST to proc. Rather, Sneakdoor and ST are both signalled due to the fact that a successful run on archives happens. However, sneakdoor is forced to happen first due to the constant nature of it, and it changes it from a successful archives run to HQ run before ST ever gets a chance to fire. When ST does get a chance to fire, sneakdoor has already done its job and the run is changed to a new server, so it has to fail (like the Slums/CtM effect).

2 Likes
54

Arg almost liked. It’s not “like the Slum / CTM”, they don’t signal at the same time in jako’s list.

55

Let me try to give an example of (my interpretation) how the game-log works in this instance, step by step.

Imagine a board state where there are no ICE installed, an Sneakdoor is in play at the beginning of the Runner’s turn, Security Testing is on Archives, and the runner has made a successful run on R&D.

Game log

  • Runner’s turn has begun
  • …general logs relating to making runs
  • Successful run on R&D #1

The Runner now uses Sneakdoor to make a run on Archives. There is no ice covering Archives, and so the run is successful.

Game log

  • Runner’s turn has begun
  • …general logs relating to making runs
  • Successful run on R&D #1
  • Successful run on Archives #1

Sneakdoor’s constant effect and Security Testing’s triggered effect enter the queue. Sneakdoor must go first because constant > triggered. The Sneakdoor effect now replaces the successful run on Archives with a successful run on HQ. This alters the game log.

Game log

  • Runner’s turn has begun
  • …general logs relating to making runs
  • Successful run on R&D #1
  • XXX Successful run on Archives #1 XXX (struck out)
  • Successful run on HQ #1

Security Testing is next in the queue. It double checks for “Successful run on Archives #1”. This has been struck from the log, so it is no longer valid, so Security Testing fizzles.

Then you perform your Successful run on HQ #1 triggers.

If you tried to play Apocalypse here, after the HQ triggers, you would not read a successful run on Archives because it has been STRUCK from the record.

Now the runner runs Archives again.

Game log

  • Runner’s turn has begun
  • …general logs relating to making runs
  • Successful run on R&D #1
  • XXX Successful run on Archives #1 XXX (struck out)
  • Successful run on HQ #1
  • Successful run on Archives #2

Now you can use Apocalypse, because it sees the successful run on Archives, and can trigger off of a successful run on Archives of any number. But Security Testing wouldn’t fire, because Security Testing needs to trigger off “Successful run on Archives #1”, and cannot trigger off “Successful run on Archives #2”.

Successful run on Archives #1 exists, but was struck and replaced by Successful run on HQ #1. Because Successful run on Archives #1 already exists, the second run on Archives must be Successful run on Archives #2.

Slums/CtM works the same way: Strike out “Installed Card Trashed #1” and replace with “Installed Card Removed from Game #1”, CtM fizzles, and the next trashed card becomes “Installed Card Trashed #2” so CtM doesn’t fire.

3 Likes
56

Actually, outside of the fact that one is on successful archives run, and one is on trashing cards, the actual ability timing of ST and Sneakdoor is the exact same as CtM and Slums

3 Likes
57

Ok guys, you convinced me.
Time to try raises at work or ask bowling stuff to your girl, you’re all awesome.

2 Likes
58

If it’s the case, why Security Testing can trigger on the second successful run on a server with Crisium Grid installed (The grid was trashed during the first successful run) ?

59

Because it was never a successful run for card abilities, due to Crisium. (It’s only successful in that they can access cards.)

60

Yes, but it’s still a successful run (the first) and the game keeps track of that.