Welcome back to Rules Talk with your friendly Assistant Rules Manager, Jamie! Today we have for you the long-awaited Comprehensive Rules version 1.3 update. This update corrects a couple of problems with CR1.2. The changes shouldn’t significantly impact your games if you’ve been playing as we recommended on Twitter when the problems were first discovered.
You can always find the latest version of the Comprehensive Rules at the Comprehensive Rules Hub here.
Here’s a rundown of the update in terms that will hopefully make sense to most players. If I get too far into Rules-speak, please forgive me! This update is all about fixing subtle, technical problems, so I’m going to have to use some amount of jargon to explain it. On the other hand, if you’re the sort of player who wants to see all the technical details, definitely check out the Summary of Changes on the first page of the CR document itself. The changelog includes hyperlinks to all of the updated content, so you won’t have to crawl through the whole thing looking for hidden bits of orange text.
Terminal Iteration
Our first couple of items involve MirrorMorph: first of all, we spelled out a definition for what it means for actions to be different from each other (and, for that matter, what Jeeves Model Bioroids means about actions being the same as each other). This should be right in line with how you’ve already been playing those cards.
Secondly, we fixed the loophole where you could play a Terminal operation with your third action and then use MirrorMorph to take an action in your discard phase. The rules now clearly state that you can’t take actions outside your action phase, period. For example, if you spend your turn drawing a card, taking credits with Nanoetching Matrix, and playing Preemptive Action, you still trigger MirrorMorph, but you will only be able to use its “Gain 1” option.
You Need to Walk Before You (End the) Run
In CR1.2, we tried to tighten up rules about Deflectors and other effects that could move the game to a different point in the run timing chart. However, we made the mistake of including “end the run” in these rules, when ending the run really needs to be handled separately. In particular, this introduced a problem where paid ability windows would finish up normally instead of cutting off if the run ended while they were open. So by a strict reading of the CR1.2 rules, the Runner could still spend credits from Stimhack or bad publicity after the Corp used a Nisei Mk II counter or trashed a Border Control. That’s not supposed to be allowed!
Rather than just writing a narrow fix for that specific problem, we decided to take a more thorough look at the rules about ending the run. We made a few changes to make the procedure more clear: we revised the definition of “end the run” at the beginning of section 6 (Runs), and we added two new subsections to section 6.8 (The Run Ends Phase).
The first new section is where we actually solve the problem above: it gives explicit instructions about how to handle each type of priority window that might be open when the run ends. It pretty much says what you expect, but now it’s written down clearly. For example, if the run ends during the reaction window for resolving subroutines, you close that reaction window, and no more subroutines resolve. Similarly, if a run ends during a paid ability window, that window closes right away.
The second new section talks about unsuccessful runs, and establishes clear criteria for whether a run should be declared unsuccessful or not. Which leads me to the last major topic for this update…
What Is Success Anyway?
There’s a particular card that seems to keep finding ways to cause confusion, and we realized we had an opportunity to do something about that. That card is Crisium Grid.
The way the rules handle Crisium has always been weird. The game normally keeps a log of all the events that happen, and cards can implicitly refer back to that event log when they need to. For example, that’s how Security Testing knows whether it should trigger or if you already made a successful run on that server this turn. Until now, Crisium Grid essentially forced the game to keep a separate log “for purposes of card abilities”, which would make it look like runs on the Crisium Grid server were not successful. But this gets really confusing later on. What if Crisium is trashed? Does the game have to keep covering for the lie, or does it start telling the truth about those runs?
To make matters worse, there have been a bunch of confusing rulings about Crisium’s interaction with other cards, including ones that directly reversed previous rulings. It came to our attention that for at least one interaction, the older ruling was more widely known than the one that overturned it!
To fix Crisium once and for all, we took a look at what “successful run” and “unsuccessful run” actually mean. Ultimately, they are just labels that abilities can check for. Fundamentally, the game doesn’t care what happens at step 6.9.5e (the “successful run” step). Whether the run is successful or not, the next steps in the timing of the run are the same. If you get to step 6.9.5g (the “access cards” step) without the run ending, you access cards, whether the run is supposedly “successful” or not.
So instead of having Crisium make its own separate game log, we realized it could just apply its effect to the real game log. We updated some rules to make it more clear that “successful run” and “unsuccessful run” are just labels, not inherent to how you execute a run. We also made sure the rules don’t mistakenly declare a run unsuccessful just because Crisium stopped it from being declared successful.
The upshot of this is that Crisium Grid does nearly exactly what it always did, but the under-the-hood explanation of how it does that is greatly simplified. Here’s the new text:
Runs against this server cannot be declared successful. (This effect does not cause runs to become unsuccessful.)
Let’s quickly look at some examples:
- The Runner chooses a server with Security Testing that turns out to have a Crisium Grid in it. They run and trash the Crisium Grid. Since that run wasn’t successful, it doesn’t count against Security Testing’s trigger condition of “the first time you make a successful run on that server this turn.” The Runner can get credits with their next run.
- The Runner trashes a rezzed Crisium Grid during a run against Tennin Institute, but doesn’t make any other runs on their turn. Crisium stopped that run from becoming successful, so Tennin’s ability triggers when the Corp’s next turn begins.
- The Runner uses Sneakdoor Beta while Crisium Grid is rezzed in the root of Archives. The run isn’t successful, so Sneakdoor Beta can’t change its results, and the Runner accesses cards from Archives.
- The Runner uses Sneakdoor Beta while Crisium Grid is rezzed in the root of HQ. The run becomes successful, so Sneakdoor Beta has the game treat it as a successful run on HQ. Since the run is declared successful while the attacked server isn’t HQ, Crisium Grid can’t affect it. The Runner will access cards from HQ, and can also then play Emergency Shutdown. (This interaction is the only meaningful change to how Crisium works: a past ruling about Omar Keung: Conspiracy Theorist suggested that it should work differently, but did not give an explanation for how it reached its conclusion. Now the rationale is much easier to understand!)
That’s about it for CR1.3! You can expect the next Comprehensive Rules update alongside the release of Uprising later this year. If you have questions, you can always reach the NISEI Rules Team on Twitter at @NISEI_Rules or by e-mail at rules@nullsignal.games.
Until next time, keep running!
