“cannot initiate a run on” certain servers under certain conditions. These effects refer to
the announcement of the attacked server in the Initiation
Phase.
Example: Off the Grid states in part, “The Runner cannot initiate a run on
this server.” This only prohibits the Runner from announcing this particular remote server as the attacked server at the beginning of the run. If an ability
changes the attacked server while a run is in progress, Off the Grid does not interfere with that
ability.
- Some abilities impose an additional cost to run, either generally or on a
particular server. Any costs to run a server must be paid at the time that server is
announced as the attacked server.
- After the attacked server is announced, the
Runner receives credits equal to the number of bad publicity the Corp has. See section 10.6 for an
explanation of bad publicity.
- Credits from bad publicity cannot be spent to pay costs to make the run, as
they are received after the attacked server is announced.
- Once they are received, credits from bad publicity are in the
Runner’s credit pool and behave just as any other credits. They can be spent, lost, placed on
cards, and so on as normally allowed.
- During the Run Ends Phase, any credits from bad publicity remaining
in the Runner’s credit pool are lost.
- Some abilities look for particular conditions occurring
“during a run” or are restricted to being used “during a run.” For purposes of
abilities, the run formally begins only after the attacked server is announced and any costs are
paid.
Example: The Runner initiates a run against a server
with a rezzed Heinlein Grid while the Corp has Enhanced Login Protocol in play. They do not lose any credits
to Heinlein Grid’s ability, as the additional click Enhanced Login Protocol requires them to spend is
spent to initiate the run, and is not spent during the run.
- When the Initiation Phase completes, the run moves either to the Approach
Ice Phase (section 6.4) or
the Movement Phase (section
6.6). If there is ice protecting the attacked server, the Runner’s
position becomes the outermost piece of ice, and the run proceeds to the Approach Ice Phase. If there is
no ice protecting the server, then the run moves directly to the Movement Phase.
-
Approach Ice
- The APPROACH ICE
PHASE gives the Corp the opportunity to rez the ice in the Runner’s current
position.
- For purposes of meeting trigger conditions, the Runner approaching a piece
of ice is equivalent to the Approach Ice Phase beginning at that ice’s position. Abilities with
this trigger condition are subject to rule 9.2.8f.
- The paid ability window in step 6.9.2b of the Approach Ice Phase is
the only time the Corp can normally rez ice. In this window, the Corp only gains the ability to rez the
piece of ice being approached, not any other ice.
- When the Approach Ice Phase completes, the run moves
either to the Encounter Ice Phase (section
6.5) or the Movement Phase (section 6.6). If the approached
piece of ice is rezzed, the Runner encounters it next. If
the approached piece of ice is unrezzed or if there is no longer ice installed in that position, then
the run moves directly to the Movement Phase.
-
Encounter Ice
- The ENCOUNTER ICE PHASE gives the Runner the opportunity to interact with the ice in their current position,
then requires the Corp to resolve unbroken subroutines on that ice.
- For purposes of meeting trigger conditions, the Runner encountering a
piece of ice is equivalent to the Encounter Ice Phase beginning at that ice’s position. Abilities
with this trigger condition are subject to rule 9.2.8f.
- As each encounter begins, each subroutine on the encountered ice gains an
“unbroken” status associated with that encounter. See section 9.8 for details.
- During the paid ability window in the Encounter Ice Phase (step 6.9.3b), the Runner can break
subroutines on the ice. See rule
9.8.6.
- After the paid ability window in the Encounter Ice Phase closes, unbroken
subroutines on the encountered ice resolve. See section 9.8.8.
- At the end of the Encounter Ice Phase, the run continues to the Movement
Phase, section 6.6.
-
Fully Break
- During each encounter, the Runner FULLY
BREAKS the encountered ice the first time all subroutines on that ice are
broken.
- Whenever the Runner fully breaks a piece of ice, if all its subroutines were
broken using abilities on a single object, that object also FULLY
BREAKS the ice.
- If an encountered piece of ice has no subroutines, the Runner fully breaks it
when step 6.9.3b of the encounter begins. No objects fully break the ice in this case.
- If the encountered piece of ice gains subroutines after the Runner
fully breaks it, the Runner’s status of having fully broken the ice remains in place. Conditions
that check whether the Runner fully broke the ice will still be met as normal. Breaking the new
subroutines will not fully break the ice or meet related conditions again.
-
Bypass
-
When an effect allows the Runner to
BYPASS a piece of ice, the Encounter Ice Phase
is aborted and the Runner immediately proceeds to pass that ice.
-
Most bypass effects occur at the
beginning of an encounter and result in steps 6.9.3b and 6.9.3c never
occurring, meaning that subroutines on the encountered ice are neither broken nor resolved.
-
A few bypass effects can be triggered
later. If ice is bypassed in step
6.9.3b, subroutines may or may not have been broken, but
step 6.9.3c never occurs so no subroutines resolve. Note that for ice with zero
subroutines, the Runner has “broken all subroutines” if and only if step 6.9.3b was reached. See rule 9.12.2c.
Example: The Runner plays Forked and encounters a Troll that they can bypass with
Femme Fatale. The Runner pays 0[c] to bypass the Troll with Femme Fatale. Forked does not meet its trigger
condition, and Troll is not trashed, because the opportunity to break subroutines was never reached.
-
Forced Encounters
- If an ability directs the Runner to encounter a piece of ice
without first changing their position, resolve an Encounter Ice Phase but do not
change the Runner’s position, if any. After the encounter, return to the effect that caused the
encounter and proceed from there. This type of encounter outside the normal progression of
a run is referred to as a FORCED ENCOUNTER.
Example: If Shiro causes Chrysalis to be accessed, resolve the encounter with
Chrysalis and then return to resolving subroutines on Shiro.
- If a forced encounter occurs during a run, an instruction to end the run during
that encounter is applied to both the Encounter Ice Phase being resolved and the phase from which the
additional encounter was initiated. If a forced encounter occurs outside of a run, an instruction to end
the run simply closes the Encounter Ice Phase and returns the
game to the effect that called for the encounter.
Example: The Corp uses The
Twins to force the Runner to encounter a piece of ice
again when they pass it. If a subroutine directs the Corp
to end the run during the extra encounter, both that encounter and the original Movement Phase are aborted, and the game proceeds to the Run
Ends phase.
- An instruction that creates a forced encounter is not finished resolving until
the encounter is complete.
- During a forced encounter, if an ability moves the Runner or directs
the Runner to approach a piece of ice, that movement resolves and changes the parameters of the
underlying run normally, but does not end or interfere with the forced encounter.
-
Movement
- The MOVEMENT PHASE handles the
progression of the run between pieces of ice and after the innermost piece of ice, up to the point when
the Runner approaches the attacked server.
- If the Movement Phase was reached from the Approach Ice Phase or the Encounter Ice Phase, the Runner passes the
ice in their position.
- During each Movement Phase, the Runner has the opportunity to jack out.
See section 6.1.5.
- If the Runner declines to jack out, their position moves to the
next inward position if there is one.
- If the Runner moves to a new position, the run continues from the Movement
Phase to the Approach Ice Phase, section
6.4. The Runner will approach the piece of ice in their new
position.
- If the Runner does not jack out or return to the Movement Phase, they
approach the server. This has no inherent effects, but is referred to by some card abilities. After the
Runner approaches the server, the run continues to
the Success Phase, section 6.7.
-
Success
- The SUCCESS PHASE declares
the run successful and allows the Runner to breach the attacked server.
- A run during which the runner breaks through the Corp’s defenses and
reaches the server itself is declared a SUCCESSFUL
RUN. This label is frequently referred to by card abilities.
- Declaring a run to be successful is not the same as the Success Phase
beginning. Accordingly, abilities that have trigger conditions related to a successful run are not
subject to rule
9.2.8f.
- Many abilities that initiate a run contain a conditional ability with the
trigger condition “If successful”. This means, “After the run created this way becomes
successful”.
- If an effect that initiates a run specifies that that run must be
made against a specific server or servers, any “If successful” abilities associated with
that effect are tied to that server or servers. If the attacked server has changed since the run was
initiated, and no longer is a server that could have been chosen for this run, the “If
successful” abilities do not meet their trigger conditions.
Example: The Runner plays Because I Can, which directs them to make a run on a
remote server. If an effect moves the run to a central server, the “If successful” effect on
Because I Can will not apply. However, if the run is moved instead to another remote server, the “If
successful” effect is still applied, since Because I Can would have allowed a run on the second remote
server to begin with.
- “If successful” abilities frequently create lingering effects (see
section 9.10) that modify the
procedure for accessing cards or replace breaching the attacked server with another effect entirely.
These effects apply to the breach permitted by the rules for this run (see section 6.7.5), and they expire when the run is
complete.
- If an “If successful” effect gives the Runner an effect they can
optionally carry out instead of breaching, that decision is made at the time
the breach would begin, in step 6.9.5b.
Example: The Runner plays Account Siphon while Ash 2X3ZB9CY is installed in the
root of HQ, and the run is successful. The Runner can wait until after the trace from Ash 2X3ZB9CY completes
before deciding to access cards normally or force the Corp to lose credits.
- When the Runner breaches the server, they follow the
procedures detailed in section
7.
-
Run Ends
- The RUN ENDS PHASE formalizes the end of the run and prepares the game to return to the timing structure
from which the run was initiated.
- At the beginning of the Run Ends Phase, the game processes each
priority window that was open when the run was ended. This is done according to the following
procedure:
- If a paid ability window was open when the run was ended, the
window closes. No player can trigger further paid abilities or resolve other options the window would
normally allow (such as rezzing cards).
Example: The Corp spends a counter from a scored Nisei Mk II to end the run.
Once this happens, the Runner does not have an opportunity to use their bad publicity credits from this run
to pay for using Self-Modifying Code.
- If the run was ended during a reaction window opened due to a phase beginning,
the reaction window closes, as per rule
9.2.8f. No other pending abilities are resolved.
Example: The Runner uses the ability on Security Nexus during a reaction window at
the beginning of the Encounter Ice Phase. The trace is successful, so the ability ends the run. If
Tollbooth’s ability is also pending in this reaction window, it will not be resolved, since the
encounter has ended.
- Any other open priority window is completed normally. If more than one
priority window needs to be completed this way, they are resolved in the usual order described in
rule 9.1.2a.
Example: The Corp resolves the ability on Giordano Memorial Field during a reaction
window in the Success Phase. This ability ends the run, but first the priority window is completed. If
Embolus’s second ability is pending in the same reaction window (as it usually will be if both cards
are rezzed), the Corp must remove a power counter from Embolus.
- During the Run Ends Phase, if the Runner has any credits from bad
publicity remaining in their credit pool, the Runner loses those credits.
- As part of the Run Ends Phase, the game determines whether the run should be
declared an UNSUCCESSFUL RUN. This is a label applied to
runs in which the Runner failed to reach the server they attacked, and is referred to by card abilities.
The run is declared unsuccessful if neither of the following conditions have been met:
- If the run reached step 6.9.5, the Success Phase, it is not declared
unsuccessful. This is the case regardless of whether the run was actually declared successful.
Example: The Runner reaches a server with Crisium Grid rezzed. Crisium
Grid’s ability stops the run from being declared successful, but the run is not declared unsuccessful
either.
- If the attacked server has ceased to exist, the run is not declared
unsuccessful. See rule
8.5.8.
- Conditions related to a run ending are not met as soon as an “end the
run” effect resolves or at the beginning of the Run Ends Phase. Instead, these conditions are met
at step 6.9.6d, when the
entire run timing structure is complete. Similarly, static abilities that apply during a run and
durations that apply until the end of a run expire at step 6.9.6d.
Example: The Runner plays The Noble Path to make a run in which they prevent all
damage. During the run, the subroutine on Chum resolves, and then the Runner encounters Wall of Static and
does not break its subroutine. When the “end the run” ability resolves, the encounter also ends,
so the trigger condition on Chum’s delayed conditional ability is met. The ability will resolve and
fail to damage the Runner during the Run Ends Phase, because The Noble Path’s effect still applies.
Similarly, Georgia Emelyov’s first ability meets its trigger condition at step 6.9.6c, which is
still before the run is over, so the damage will be prevented.
Example: The Runner plays The Noble Path to make a run in which they prevent
all damage. The run is successful but the Runner takes a tag during the run. When the run ends, Dedicated
Response Team’s ability meets its trigger condition at the same time that The Noble Path’s
effect expires, so the Runner will suffer 2 meat damage.
-
Steps of a Run
-
Initiation Phase
- The Runner announces the attacked
server.
- The Runner gains 1[c] to spend during the run for each bad publicity
the Corp has.
- The run formally begins. Conditions related to the run beginning
or initiating are met.
- The Initiation Phase is complete. If the attacked server has at least one piece
of ice protecting it, proceed to step 6.9.2, Approach Ice Phase,
approaching the outermost piece of ice protecting the attacked server. If the attacked
server is not protected by ice, proceed to step 6.9.4, Movement Phase.
-
Approach Ice Phase
- The approach begins. Conditions related to the Runner approaching
this ice are met.
- A paid ability window occurs, in which players may use paid abilities and the
Corp may rez non-ice cards. Additionally, the Corp can rez the
approached piece of ice. (P) (R)
- The Approach Ice Phase is complete. If the approached piece of ice
is rezzed, continue to step
6.9.3, Encounter Ice Phase.
Otherwise, proceed to
step 6.9.4,
Movement Phase.
-
Encounter Ice Phase
- The encounter begins. Conditions related to the Runner encountering
this ice are met.
- A paid ability window occurs, in which players may only use paid
abilities. Subroutines on the encountered ice can be broken during this window. (P)
- If there are unbroken subroutines that have not yet resolved this
encounter, the Corp resolves the next such subroutine in order. Otherwise, skip to (e).
- Return to (c).
- The Encounter Ice Phase is
complete. Continue to step
6.9.4, Movement Phase.
-
Movement Phase
- If the Runner’s position corresponds to a piece of ice, the
Runner passes that ice. Conditions related to passing ice are met. If there are no positions more inward
than the ice just passed, conditions related to passing all of the ice protecting a server are also
met.
- A paid ability window occurs, in which players may only use paid
abilities. (P)
- The Runner may choose to jack out, proceeding to step 6.9.6, Run Ends Phase.
If the Runner does not, continue to (d).
- The Runner’s position moves to the next position inward, if
any.
- A paid ability window occurs, in which players may use paid
abilities and the Corp may rez non-ice cards. (P) (R)
- If the Runner moved to a new position, return to step 6.9.2, Approach Ice
Phase, approaching the piece of ice in their new position. If not, continue to (g).
- The Runner approaches the attacked server. Conditions related to the
Runner approaching a server are met.
- The Movement Phase is complete. Continue to step 6.9.5, Success Phase.
-
Success Phase
- The run is declared successful. Conditions related to a successful run are met.
- The Runner breaches the attacked
server.
- The Success Phase is complete. Continue to
step 6.9.6, Run Ends
Phase.
-
Run Ends Phase
- Any priority windows that were open when the run moved to this phase are
completed or closed as described in section 6.8.2.
- The Runner loses any unspent bad publicity credits.
- If the Success Phase was not reached during this run and the
attacked server still exists, the run becomes unsuccessful.
- The Run Ends Phase and the run as a whole are both complete.
-
Accessing Cards and Breaching Servers
-
Accessing Cards
- ACCESSING is the process of the Corp
showing one of their cards to the Runner for potential interaction.
- While the Runner is accessing a card, the Runner is allowed to look
at that card, even if it would normally not be visible to them. While the Runner is accessing a card,
the Corp is allowed to look at it as well, except when the card is being accessed from R&D.
- An ability that meets its trigger condition when its source card is accessed is
active even if the source card is inactive. See section 9.1.8.
- During each access, the Runner has 1 opportunity to use a mid-access
ability. This occurs after the reaction window at the beginning of the access, and before the Runner
steals an accessed agenda.
- The Runner always has the ability "Access → Pay the trash cost of the
accessed card: Trash it." This is the BASIC TRASH ABILITY.
- All assets and upgrades have trash costs, as do some ice and
operations. If a card does not have a trash cost, the Runner cannot pay its trash cost, and therefore
the Runner cannot use the basic trash ability during that access.
- The Runner cannot trash or pay the trash cost of a card in the
Corp’s discard pile, either with the basic trash ability or with other mid-access
abilities.
- One card, Mumbad Virtual Tour, has the
ability "If the Runner accesses this upgrade while it is installed, they must trash it, if
able." When this ability applies, the Runner can use any mid-access ability they have available
that trashes the card, but they cannot decline to use a
mid-access ability or use one that would not trash the accessed card unless they are unable to pay the
cost of any ability that would trash it.
- One card, Neutralize All Threats, has
the ability "The first time each turn you access a card with a trash cost, reveal it. You must
trash that card by paying its trash cost, if able." When this
ability applies, the Runner can only use the basic trash ability. They cannot decline to use a
mid-access ability or use a mid-access ability available from a card unless they cannot pay the cost of
the basic trash ability.
- If, after resolving mid-access abilities, the Runner is still
accessing an agenda, they must steal it.
- Some abilities can create additional costs to steal an agenda. The Runner can
decline to pay such costs and not steal the agenda. See section 1.16.9.
- If a card moves to another location while it is being accessed, the
access ends immediately.
- If a run is in progress, an instruction to end the run ends any
access taking place. If an access is occurring outside of a run, an instruction to end the run has no
effect on that access.
- One card, Information Sifting, uses a
method other than a breach to establish a set of cards for the Runner to access. The Runner accesses
those cards one at a time in the order of their choice. Each access is performed as a separate
instruction. See rule
9.11.4b. Accessing cards in this way is an exception to rule
9.12.2a.
- One card, Counter Surveillance, instructs the Runner to access a certain number of cards from a server without mentioning a
breach. The procedure for these accesses follows the normal rules for breaching that server except:
there is no random access limit if the server is HQ or R&D; and the procedure ends once the
designated number of cards have been chosen for access.
-
Steps of Accessing a Card
- The card is accessed. Conditions related to accessing this card are
met.
- The Runner may use a single mid-access ability, such as the basic
trash ability.
- If the accessed card is an agenda, the Runner must steal it.
- The access is complete. Conditions related to an access ending are met.
-
Breaching Servers
- BREACHING a server is the process of the Runner
accessing a particular set of cards associated with that server. Most accesses occur during a breach.
Step 6.9.5b of a run calls for the Runner to breach the attacked server, but card abilities can
also directly instruct the Runner to breach a server.
- When the Runner breaches Archives, all the facedown cards in the
Corp’s discard pile are turned faceup before the Runner accesses any cards.
- If a card is added to Archives facedown after this step, that card remains
facedown for the remainder of the breach, even after it is
accessed. The Runner can only look at a facedown card in Archives while accessing it.
- The cards associated with a breached server that the Runner could potentially
access are called CANDIDATES. The set of candidates is compiled
from the cards in the root of the breached server and, for central servers, the cards in the zone that
corresponds to that server (see rule
4.6.7a). Section
7.4 defines which of these cards are candidates.
- During a breach, the Runner is presented with the current
candidates. They choose 1 of those cards and access it. This process repeats until there are no longer
any candidates.
- When presented with candidates during a breach of HQ, the Runner
chooses either a specific candidate that is not in the Corp's hand or to access a random candidate
from among the ones in the Corp's hand. A card randomly chosen this way is treated as though the
Runner had chosen it.
- One card, Dedicated Neural Net,
instructs the Corp to choose which cards the Runner accesses from HQ. While this effect applies, the
Runner still chooses candidates that are not in the Corp’s hand as normal. Whenever the Runner
chooses to access a candidate from the Corp’s hand, instead of a candidate being chosen at random,
the Corp chooses 1 of those candidates for the Runner to access. The chosen card is still treated as
though the Runner had chosen it.
- The Runner can only choose candidates from the Corp’s hand or deck a
limited number of times during a breach of HQ or R&D, respectively. This number is called the
RANDOM ACCESS LIMIT. Before the Runner begins accessing
cards during a breach of HQ or R&D, the random access limit for that breach is determined, after
which it will not change for the remainder of that breach.
- By default, the random access limit is 1.
- If an ability allows the Runner to "access additional
cards" during a breach of HQ or R&D, the effect of that ability is to increase the random
access limit. Such an ability can only be applied at the beginning of the breach, before the value of
the random access limit is set.
- Cards are counted against the random access limit in the manner described in
rule 7.3.6a.
- Some rules and abilities refer to the number of cards the Runner
accesses or the number of times the Runner accesses a card.
- If such a reference applies while a breach is in progress, it
counts the number of times a candidate has been chosen so far during that breach, regardless of how many
of those candidates have actually been accessed.
Example: The Runner plays Immolation Script, and the subroutine on Hudson 1.0
resolves before Archives is breached. The Runner will only be able to choose 1 candidate during the breach,
regardless of whether they choose to access that card or apply Immolation Script’s replacement
effect.
- If such a reference applies after a breach is complete, it counts only the
number of times the Runner actually resolved an access during that breach.
Example: The Runner plays Rip Deal while they have Obelus installed. If they
use Rip Deal’s ability to replace accesses of cards in HQ with adding cards from the heap to the grip,
the cards those replacement effects applied to were not accessed. When Obelus’s ability resolves after
the breach ends, it will only cause the Runner to draw cards for upgrades they accessed in the root of
HQ.
- If a run is in progress, an instruction to end the run ends any
breach taking place. If there is no run in progress, an instruction to end the run has no effect on a
breach.
- If a server would be breached while a breach is already in progress, instead
the new breach takes place when the current breach ends. The effect
creating the delayed breach is treated as a conditional ability controlled by the Runner.
Example: The Runner steals Clone Retirement during a breach of HQ, causing the
Corp to take bad publicity. The Runner must complete the current breach before beginning the breach granted
from Raymond Flint’s first ability.
-
Determining Candidates
- The candidates at the beginning of a breach are as follows:
- Each card in the root of the breached server is a candidate.
- If the breached server is HQ, each card in the Corp’s hand is
a candidate.
- If the breached server is R&D, the top card of the Corp’s
deck is a candidate.
- If the breached server is Archives, each card in the Corp’s
discard pile is a candidate.
- If at any time the Runner is prohibited from accessing an object,
that object ceases to be a candidate and cannot become a candidate.
Example: The Corp performs a successful trace with the ability on Ash 2X3ZB9CY,
prohibiting the Runner from accessing any card other than Ash for the remainder of the current run. When the
server is breached, Ash will be the only candidate for the Runner's first selection, and then there will
be no candidates remaining, so the breach will end.
- One card, Hudson 1.0, creates an effect
that prohibits the Runner from accessing more than 1 card during a run. This effect always considers
whether the Runner has actually accessed a card during that run, even when rule 7.3.6a would normally
apply. If the Runner has accessed any cards, this effect prohibits all accesses, and therefore there
will be no candidates.
- Once the Runner chooses a candidate for access, it ceases to be a
candidate for the remainder of that breach. It does not matter whether the chosen candidate is actually
accessed. As long as the card is chosen, it ceases to be a candidate.
Example: The Runner is breaching Archives during a run made with Immolation Script.
They choose a piece of ice from the set of candidates, and apply Immolation Script's replacement effect
to trash another card instead of accessing the chosen ice. After resolving this, the chosen ice is no longer
a candidate and cannot be accessed again this
breach. (The newly-trashed card, however, could be a candidate.)
Example: The Corp is playing Gagarin Deep Space: Expanding the Horizon, and the
Runner breaches a remote server. When the Runner chooses a candidate from the root of that server, an
additional cost to access is imposed. The Runner declines to pay the cost and therefore does not perform the
access. That card still ceases to be a candidate.
- When the random access limit is reached during a breach of HQ or R&D, all
candidates in the zone corresponding to the breached server cease to be
candidates, and no cards in that zone can become candidates for the remainder of that breach. See
section 7.3.5.
- If a candidate leaves the breached server, it ceases to be a
candidate. Note that the moved card could be a new object, which could be eligible to become a new
candidate if appropriate.
Example: The Runner trashes an installed upgrade during a breach of Archives. That
card moves to the Corp’s discard pile. The new object for the upgrade’s existence in the
Corp’s discard pile becomes a candidate, so the Runner will access the same physical card twice during
this breach.
- Cards entering a server while a breach is in progress can become
candidates.
- If a card enters the root of a server during a breach of that
server, it becomes a candidate.
- If a card enters the Corp’s hand during a breach of HQ while the random
access limit has not yet been reached, that card becomes a candidate.
- If a card enters the Corp’s deck during a breach of R&D, that card
could become a candidate (either at that time or later in the breach), depending on the random access
limit and its position within the deck. See section 7.4.7.
- If a card enters the Corp’s discard pile during a breach of Archives,
that card becomes a candidate. See also rule 7.3.2a.
- During a breach of R&D, the Runner is presented
with 1 candidate from the Corp’s deck at a time in turn, working down from the top of the deck.
Cards are made candidates 1 at a time until the access limit is reached.
- After the Runner chooses a candidate from the Corp’s deck and
whenever any cards enter, leave, or are reordered within the Corp’s deck, all cards in the
Corp’s deck cease to be candidates. Then, if the random access limit has not been reached, the
topmost eligible card in the deck becomes a candidate. A card is eligible for this purpose if the Runner
has not already chosen to access that object and is not prohibited from accessing that object in this
breach.
Example: The Runner plays The Maker’s Eye and breaches R&D, accessing
2 additional cards. They access Celebrity Gift and then access and steal Bacterial Programming. The Corp
uses Bacterial Programming’s ability to rearrange cards in R&D, but they leave Celebrity Gift as
the top card of R&D. The cards returned to the top of R&D are new objects, so the Runner must
continue the breach from the top of R&D and will access Celebrity Gift again.
Example: The Corp is playing Seidr Laboratories and has Strongbox rezzed in the
root of R&D. The Runner breaches R&D with a random access limit of 4. They first access the top card
of the Corp’s deck and leave it in place. The 2nd card from the top now becomes a candidate, and turns
out to be an agenda, which the Runner steals by spending [click] to pay the additional cost imposed by
Strongbox. The Corp then uses Seidr Laboratories to add 1 card from Archives to the top of R&D. The 3rd
candidate presented to the Runner is the card newly added to the top of R&D. After accessing that card,
the next card down is still the object that was accessed first, so the card below that (currently 3rd from
the top) becomes the 4th and final candidate.
- One card, Showing Off, allows the Runner
to access cards from the bottom of R&D. While this effect applies, candidates in the Corp’s
deck are presented working up from the bottom: treat rule 7.4.1c as if it said “bottom” instead
of “top” and rule
7.4.7a as if it said “bottommost” instead of
“topmost”.
-
Steps of Breaching a Server
- Breaching the server formally begins. Conditions related to
breaching this server are met.
- If the breached server is Archives, turn all cards in the Corp's
discard pile faceup.
- If the breached server is HQ or R&D, determine the limit to how
many times the Runner can choose a candidate from the Corp's hand or deck.
- The Runner chooses a candidate. If they cannot, skip to step 7.5.7.
- The Runner accesses the chosen card.
- Return to step
7.5.4.
- The breach is complete. Conditions related to the breach ending are
met.
-
Card Manipulation
-
Faceup and Facedown Status
-
An agenda, asset, upgrade, or piece of ice
is UNREZZED if it is installed and facedown.
An asset, upgrade, or piece of ice is REZZED if
it is installed and faceup. Runner cards, faceup agendas, operations, events, and counters are
neither rezzed nor unrezzed.
-
To REZ an unrezzed card is to turn it faceup.
-
Some paid ability windows allow the Corp
to rez assets and upgrades. See section 9.2.8. The paid ability window at
step 6.9.2b of a run allows the Corp to rez ice.
-
Card abilities can direct or allow the
Corp to rez cards at other times.
-
Agendas cannot be rezzed.
-
Before rezzing a card, the Corp must pay
that card’s rez cost. This includes both rezzing in a paid ability window and rezzing through
a card ability. Card abilities can modify or ignore rez costs, but must state this
explicitly.
-
To resolve rezzing a card, the Corp pays
its rez cost (accounting for any modifiers or additional costs), a checkpoint occurs (as required by
rule 10.3.4), then the Corp turns the card faceup. For purposes of meeting trigger conditions, the
card is considered to be rezzed at the conclusion of this process.
-
To DEREZ a rezzed card is to turn it facedown.
-
Cards are only derezzed by card
effects.
-
There is no inherent cost associated with
derezzing a card.
-
Derezzing a card is instantaneous and has
no component steps.
- Some abilities can install Runner cards facedown
or turn already-installed Runner cards facedown.
-
Runner cards that are installed or turned
facedown do not have a name, type, or subtypes, and their abilities are not active.
-
The Runner can look at their facedown
cards at any time.
-
After a facedown Runner card enters the
heap, it is turned faceup.
-
A Runner card turned facedown is not
considered to be uninstalled and simply remains in the play area.
-
If an installed facedown Runner card is
turned faceup, the card gains its name, type, and subtypes, and it becomes active. Turning an
installed facedown Runner card faceup does not meet the trigger conditions of “when
installed” abilities.
-
Runner cards are never considered rezzed or
unrezzed.
-
Card Movements
- A MOVEMENT is a way that
cards change their zone or location following special rules. The movements are: arrange, draw, forfeit,
install, play, search, score, steal, swap, and trash.
- Other terms that change the locations of cards are not movements.
If an ability directs a player to “add” or “move” cards to 1 or more locations,
simply put those cards in the indicated locations. If an ability or game rule directs a player to
“discard”, “set aside”, or “remove from the game” 1 or more cards,
simply put those cards in their owner’s discard pile, the set-aside zone, or the removed-from-game
zone, respectively.
- If a replacement effect modifies the effects of a movement, but does
not replace the entire movement by name, the modified effect is still an occurence of that movement and
can still meet trigger conditions relating to that type of movement.
Example: Harbinger’s ability modifies the effects of trashing it by
replacing adding Harbinger to the heap with turning it
facedown. Harbinger is still trashed when the modified effect resolves. If this is the first time this turn
that the Runner trashed one of their installed cards, they will be able to resolve Wasteland’s
ability.
- If a movement is replaced or prevented entirely or otherwise cannot
be carried out, that movement does not take place and conditions related to that type of movement are
not met.
Example: The Corp is resolving the first subroutine on Rototurret to trash an
installed program. The Runner uses Sacrificial Construct to prevent the program from being trashed. Since
trashing did not occur, the Runner does not place a power counter on District 99, and District 99 can still
meet its trigger condition if a program or piece of hardware is successfully trashed later in the
turn.
- To ARRANGE a set of cards is to reposition
them among their current locations. The full rules for arranging are detailed in section 8.3.
- To DRAW a given number of cards is to
move that many cards from the top of a player’s deck to their hand. The full rules for drawing
cards are detailed in section
8.4.
- To FORFEIT an agenda is to
move it from a player’s score area to the removed-from-game zone. When a player forfeits an
agenda, its agenda points no longer contribute to that player’s score, and any objects hosted on
it are trashed.
- To INSTALL a card is to move it from
its current zone to the play area. The full rules for installing cards are detailed in section 8.5.
- To PLAY an event or operation is to move
it from its current zone to the play area, resolve its play abilities, and then trash it. The full rules
for playing events and operations are detailed in section 8.6.
- To SEARCH is to look at a specified
zone and potentially set aside cards from that zone. The full rules for searching are detailed in section 8.7.
- To SCORE an agenda is to move it from its
current zone to the Corp’s score area. The full rules for scoring are detailed in section 1.17.
- To STEAL an agenda is to move it from its
current zone to the Runner’s score area. The full rules for stealing are detailed in section 1.17.
- To SWAP a pair of cards
is to move each card to the other’s location simultaneously. The full rules for swapping are
detailed in section 8.8.
- To TRASH a card is to move it from its
current zone to its owner’s discard pile. The full rules for trashing are detailed in section 1.19.
-
Arranging and Rearranging Cards
- To ARRANGE or REARRANGE an ordered set of 2 or more cards is to reposition
them among their current locations. The words “arrange” and “rearrange” are
synonymous.
- If a player is instructed to arrange 1 or fewer cards, instead that
player does nothing.
- When a player arranges a set of installed ice, that player carries out the
arrangement by repeatedly choosing and swapping 2 pieces of ice. Each swap follows all the usual rules
for swapping cards in section
8.8.
- No checkpoints occur during the sequence of swaps. An ability that
meets its condition while ice is being arranged will become pending at the end of resolving the
instruction in which arranging ice is taking place.
- When a player arranges cards from the top of their deck or
their opponent’s deck, that player sets those cards aside facedown, secretly puts them in the
order of their choice, and returns them to the top of that deck. They do not declare which cards moved
to which positions. All of the arranged cards become new objects after they are arranged, even cards
that remain in the same location in the deck.
-
Drawing Cards
- DRAWING cards is a process that moves
cards from a player’s deck to their hand.
- To draw 1 or more cards, a player sets aside that many cards from
the top of their deck facedown. The cards are then considered drawn, and abilities with trigger
conditions related to cards being drawn can act on them. When resolving any such abilities is complete,
the set aside cards are added to their owner’s hand.
- Abilities with a trigger condition that refers to cards being drawn can see
the drawn cards in the set-aside zone. This is an exception to rule 4.8.3.
- Abilities that do not refer specifically to cards a player has drawn are
subject to rule 4.8.3, and only see the drawn cards move directly from the player’s deck to their
hand.
- Abilities that resolve while drawn cards are set aside can move
those cards or add new cards to that set.
- If a drawn card leaves the set-aside zone, it is no longer
considered “drawn” and remains in its new location when the drawn cards are added to the
hand.
- If a drawn card is swapped with another card, the card swapped into
the set-aside zone is now considered “drawn”, can be manipulated by other abilities, and
will be added to the hand with the other drawn cards.
Example: The Corp takes their mandatory draw while they have Daily Business
Show and Raman Rai rezzed. They set aside Wraparound and Enigma from the top of R&D. After looking at
those cards and the cards in Archives, the Corp uses Raman Rai to reveal the Enigma and a Tollbooth from
Archives and swap them. Then, the corp uses Daily Business Show to add Tollbooth to the bottom of the deck.
Finally, the Corp adds Wraparound to HQ.
- If an ability directs multiple players to draw cards at the same
time, those players follow the procedure for drawing cards together. Abilities relating to all of those
draws will become pending in the same reaction window.
-
Steps of Drawing N Cards
- Set aside N cards from the top of the drawing player’s deck.
The cards are now considered drawn and can be looked at by their controller.
- A checkpoint occurs.
- Add the set-aside cards to the player’s hand.
-
Installing and Uninstalling
Cards
- INSTALLING an agenda, asset, ice,
upgrade, hardware, program, or resource card is the act of placing that card into the play area. Events,
operations, and identities are never installed.
- Cards and counters can also be installed onto other cards if either the card
being installed onto or the card or counter being installed has an ability allowing this. The
relationship created this way is called HOSTING and is
discussed in section 1.13. Some abilities also host cards without installing them.
- A card or counter is UNINSTALLED when it stops being installed for any reason.
- Corp cards are installed facedown,
unrezzed, and remain inactive until rezzed. Corp cards are installed into
specific locations. See section
4.6.6 for more information on servers and the locations of
installed Corp cards.
- As part of installing a card, the Corp chooses which server will be the
destination for that card. The Corp can either choose an already existing server as the destination or
announces that the card will create a new remote server.
- The Corp always installs an agenda or asset into the root
of a remote server.
- The Corp always installs an upgrade into the root of a central or
remote server.
- Unless otherwise indicated, the Corp always installs ice into the
outermost position protecting the destination server.
- Cards in servers cannot be rearranged unless instructed by a
card ability. To organize this hidden information for both players, it is important that the Corp
observes the following rules for card orientation:
- Agendas, assets, and upgrades are always installed in a vertical orientation.
An upgrade in the root of a remote server is
installed in the same position as an agenda or asset. The Runner should not be able to
tell what type of card is installed in the root of a remote
server by its position.
- Ice is always installed in a horizontal orientation.
- Runner cards are normally installed
faceup, active. Runner cards are generally installed without designated locations.
- Installing cards is an exception to rule 9.12.2a. If an effect would install more than one
card, then those cards are chosen and installed one at a time, following all of the steps of the
installation process (section
8.5.13) for each card before choosing and installing the
next. Each such installation is performed as a separate instruction. See
rule 9.11.4b.
Example: The Runner uses Mass Install to install three programs. The Runner can
install Dhegdheer first, and then host one of the other two programs on Dhegdheer in order to reduce the
install cost.
- As part of the installation process, a player installing an
agenda, asset, upgrade, ice, or program has the opportunity to trash like cards.
- When installing an agenda or asset in the root of a remote server,
or an upgrade in the root of any server, the Corp may first trash any other cards already installed in
the root of that server. If the card to be installed is an asset or agenda, the Corp must trash any
other asset or agenda from that server. If the card to be installed is a region, the Corp must trash any
other region from that server.
- When installing ice protecting a server, the Corp may first trash
any other ice already installed protecting that server. Ice trashed in this way will not be counted when
determining the install cost of the new ice.
- When installing a program, the Runner may first trash any number of programs
already installed. They must do so if installing the new program would exceed their memory limit.
- If the Corp trashes any cards during the installation process, the trashed cards are placed in Archives with the same faceup or
facedown status they had while installed.
- If the last card protecting a remote server or in the root of
that server is uninstalled outside of the process of installing another
card, then the server ceases to exist during
the next checkpoint. See section
10.3.
- The Corp cannot destroy a server by installing cards. While the Corp is
installing a card with a remote server as its destination, that server does
not cease to exist during any checkpoints that occur before the install effect is complete. Even if the
last card installed in the root of or protecting a remote server is
trashed during the installation process, it is still considered the same server after the new card has
been installed.
- If a piece of ice is uninstalled while being approached or encountered,
any open paid ability window is completed. Then the approach or encounter ends without completing any
further steps of that timing structure. The Runner passes the position the uninstalled ice had occupied,
and the run continues. See section 6.2 for rules about
positions during a run.
- Some types of cards have an install cost, which must be paid
before the card can become installed, unless an ability indicates that this cost should be
ignored.
- The install cost of a piece of ice is 1 credit for each piece of ice already
installed protecting the destination server at the time the cost is to be paid. The install cost of a
piece of hardware, program, or resource is indicated on the card. Assets, agendas, upgrades, and
facedown Runner cards have no install cost. See also section 1.16.5.
- If a card has an install cost of X, the value for X is chosen by the
player at the time the cost would normally be paid, according to any stipulations indicated in the
card’s text box. This value of X is maintained until the install effect is complete.
- After the install cost is paid, a checkpoint occurs, as required by
rule 10.3.4.
- Some upgrades have an ability that specifies 1 or more central servers or
“remote server” followed by the word “only”. This is a restriction on the
locations an upgrade can occupy that applies at all times, even if the upgrade is inactive. The Corp
cannot choose the root of a non-specified server as the installation destination for such an upgrade,
and such an upgrade cannot be swapped into the root of a non-specified server.
-
Steps of Installing a Card
- Place the card into the play area with the same faceup or facedown
status it will have when the installation is complete. It is not yet installed or active.
- Choose and declare the install destination appropriate to the card
that will be installed, including any host relationships, if applicable.
- Trash like cards as described in section 8.5.6.
- Pay the appropriate install cost. (The cost-paid
checkpoint then occurs.)
- If the card is to be the first card in the root
of or protecting a new remote server, that server is created. Move the card
to the chosen install location. It becomes installed. If the card is faceup, it becomes active.
- Any “When installed...” abilities that apply to the installation
meet their trigger conditions, including those on the installed card, and the install
effect is complete.
-
Playing Events and Operations
- PLAYING an event or operation is
the act of placing that card into the play area. Agendas, assets, ice,
upgrades, hardware, programs, and resources, and identities are never played.
- Normally, playing an operation or event requires paying its
play cost. Abilities that initiate playing a card may ignore the play cost or require it to be
paid.
- If a card has a play cost of X, the value for X is chosen by the player at the
time the play cost is paid, according to any stipulations written on the
card. This value of X is maintained while resolving the event or operation.
- After the play cost is paid, a checkpoint occurs, as required by rule 10.3.4.
- Playing cards is an exception
to rule
9.12.2a. If an effect would play more than one card, then
those cards are chosen and played one at a time, following all of the steps of the play process
(section 8.6.6) for each
card before choosing and playing the next. Each such card is played as a
separate instruction. See rule
9.11.4b.
Example: The Corp uses Subcontract to play Hedge Fund and
another operation. The Corp can use the credits gained from Hedge Fund to pay for the second
operation.
- Operations and events can create
lingering effects. Once those effects exist, they become independent of the
source operation or event and the card is considered fully resolved and ready to be trashed.
See section 9.10.
Example: Test Run creates a delayed conditional ability that will resolve at
the end of the turn, but Test Run itself is considered fully resolved and is trashed once it finishes
installing a program.
- An operation or event that initiates a timing structure remains active in
the play area for the duration of that timing structure. It is not considered fully resolved until the
timing structure is completed and any abilities on the card that meet their trigger
conditions when the timing structure ends are resolved.
-
Steps of Playing an Event or
Operation
- Place the card faceup into the play
area. It is not installed and not yet active.
- Pay the play cost. (The cost-paid checkpoint then
occurs.)
- The card becomes active.
- Any “When played...” abilities that apply meet their
trigger conditions.
- A checkpoint occurs.
- Resolve the play abilities of the
card.
- Trash the card if it is still in the play
area.
- Any “After you resolve...” abilities that apply meet their trigger
conditions.
- The play effect is complete.
-
Searching for Cards
- If a player is instructed to SEARCH a zone for one or more cards,
they look at all the cards in that zone for cards matching the criteria of the search.
- If a player is instructed to search a hidden or secret zone, they are temporarily allowed to look at those cards until the search is complete,
so long as they maintain that zone as hidden or secret as necessary to the other player.
- While a player is searching, they may FIND an appropriate number of cards matching any criteria of the search by
taking them from the zone being searched and setting them aside facedown.
- A card cannot be found for a search unless it both matches the
specified criteria of the search and can be acted upon by any other effects referencing the found card
in the ability that initiated the search.
Example: The Runner uses Artist Colony to search for a card and install it.
They cannot find an event with the search because events can never be installed. They also cannot find a
program, hardware, or resource that they cannot afford to install.
- The searching player is not required to reveal any found cards
unless instructed to do so by the ability that initiated the search. Found cards are not revealed until
resolution of the ability that initiated the search resumes, pending any necessary shuffling.
- If a player is searching for a set number of cards without any
specified criteria, they must find that many cards from that zone or all the cards in that zone if there
are not enough.
- If a player is searching a deck for
one or more cards with specified criteria, they may choose to fail to find anything, even if one or more
cards matching the criteria exist in that deck.
- If a player is directed to search a zone for cards “with different
names,” each card that player finds must have a different English name from every other card found
for that search.
- Once a search through a deck is complete, whether or not any
cards are found, the deck must be immediately reshuffled before continuing to resolve any remaining
effects from the ability that initiated the search. The shuffling takes precedence over anything that
would be done with the found card(s), as well as any chain reactions that occur as a result of the
search, finding, or remaining abilities.
Example: The Corp is playing Near-Earth Hub and uses the ability on Tech
Startup to search their deck for an asset and install it. After finding the asset, R&D must be
immediately shuffled before the Corp installs the asset or triggers Near-Earth Hub’s ability.
- Once the search is complete, and any shuffling necessary has
occurred, resolution of the ability that initiated the search resumes. If no cards were found during the
search, any effects referencing found cards fail to resolve, but as much of the remaining effects
resolve as possible.
- If the trigger condition of a conditional ability involves a search, that
ability becomes pending after the search is completed and any shuffling is performed, but before the
found cards are acted on.
-
Swapping Cards
- To SWAP two cards is
to exchange their locations.
- A card can only ever be swapped into a location it is normally allowed to
occupy. When a player resolves a swap effect, they must observe any applicable game rules or card
abilities that would affect that card in its final destination. If a swap effect would resolve while
there are no legal exchanges possible, then that effect does nothing.
Example: When the subroutine on Metamorph resolves, the Corp cannot choose to swap
an agenda and an upgrade such that the agenda would end up in the same remote server as an asset.
- If two installed cards are swapped, each card moves to the other’s
location simultaneously. The two cards remain installed throughout the process of swapping, and do not
otherwise affect any other part of the game state.
- If two cards are swapped between zones, each card moves to the zone the
other is in simultaneously.
- Each of the swapped cards enters its destination zone in the same
state that a card would normally enter that zone. A card swapped into Archives enters Archives facedown
unless it was visible to the Runner at the time of the swap, a Corp card swapped into the play area
enters unrezzed, etc.
- If only one of the cards to be swapped is installed, then it becomes
uninstalled as it moves to the destination zone. Any cards or counters hosted on it are trashed. The
other card becomes installed in the exact position the first card occupied, maintaining any specific
location (such as server, ice position, or host).
- If two agendas are swapped between the players’ score areas, any hosted
cards or counters remain hosted on their respective host agendas.
-
Abilities
-
General
- An ABILITY is an
independent unit of text on a card or counter, a basic action, or the basic trash ability.
- All rules text on a card or counter is part of an ability.
- The basic actions are defined in section 5.2.7 and section 5.2.8.
- The basic trash ability is defined in section 7.1.5.
- An ability’s text can include other abilities that it could grant to
cards or counters or introduce directly to the game state. See also section 9.10.
- Each ability is categorized as either a static ability (section 9.4), a paid ability
(section 9.5), a
conditional ability (section
9.6), a play ability (section 9.7), or a subroutine (section 9.8).
- Abilities marked with [interrupt] or that include the words
“prevent” or “avoid” in their instructions have special timing rules that differ
from other abilities. See section
9.9.
- To RESOLVE AN ABILITY means to
resolve each of that ability’s instructions in the order they appear. If an ability contains more
than one instruction, a checkpoint occurs between each consecutive instruction. To RESOLVE AN INSTRUCTION means to carry out that
instruction.
- While resolving an ability, other abilities can meet their
conditions. When this happens, a “chain reaction” is created. The current instruction
finishes resolving, then more recent abilities fully resolve before the next instruction of the original
ability. If any other abilities meet their conditions while resolving the “chained”
abilities, then another “chain” is created before continuing to resolve the previous chained
abilities. Resolve each set of chained abilities one at a time, from the most recently met condition to
the oldest, before continuing with the original ability that started the chain reaction.
Example: The Runner’s identity is Armand “Geist” Walker. They
access a Snare! from R&D with only 2 cards in their grip. Before taking a tag or suffering any net
damage, the Runner triggers Decoy’s ability in order to avoid the tag. Using the Decoy meets the
trigger condition of Geist’s ability. As this is the most recent ability to meet its trigger
condition, Geist’s ability must resolve first, before Decoy avoids the tag and before Snare! finishes
resolving. The Runner draws a card from Geist, avoids the tag from Snare! with Decoy, and then finally
suffers (and survives) the 3 net damage from Snare!.
- The SOURCE of an
ability is the card, counter, or game rule that originated it.
- Each card is the source of its own printed abilities.
- If something grants an ability to an object, the source of the
granted ability is that object, not whatever granted the ability.
Example: Dedicated Processor is hosted on Corroder, granting it the ability
“2[c]: +4 strength.” The source of this ability is Corroder, not Dedicated Processor.
- The source of an ability that is being maintained by a lingering effect is the
object that created that lingering effect. See section 9.10.
- Each paid ability, conditional ability, and subroutine becomes independent
of its source at a certain point before it resolves, as described in rule 9.5.4, rule 9.6.12, and rule 9.8.9,
respectively. If the source changes zones after that point, the ability cannot act on the
source.
Example: The runner plays Compile, uses it to install Mayfly during the
resulting run, and breaks subroutines with Mayfly during that run. When the run ends, delayed conditional
abilities from both Mayfly and Compile become pending. The Runner decides to resolve Compile first, adding
Mayfly to the bottom of their stack. The Runner then resolves the ability from Mayfly, which instructs them
to trash its source program. Because Mayfly has changed zones, the copy of it on the bottom of the stack is
a new object. With nothing to trash, the ability from Mayfly does nothing.
- Whereas an ability, instruction, or declaration is made up of text, an
EFFECT is what happens in the game because of that
text.
- Any of a non-static ability’s effects that apply beyond the duration of
that ability’s resolution become independent of that ability and its source. The game engine takes
responsibility for managing these LINGERING EFFECTS directly,
and deletes them from the game state as their durations expire. See section 9.10.
- When determining whether a certain ability has the potential to change the game
state, look only at the expected effects of the ability. Do not consider its costs or restrictions, and
do not consider other abilities that could become pending or relevant because of triggering or resolving
the ability. See rule
1.2.5 of the Golden Rules.
- Any time a player chooses to resolve an optional ability or an optional
part of an ability, the player is considered to be USING that ability and the source card of that ability. Players do not “use”
abilities that are entirely mandatory.
- A paid ability is considered used once the trigger cost has been paid. See
section 9.5.6 for the steps of using a paid ability.
- A conditional ability is considered used once the relevant optional effects of
the ability have been resolved by the controller of the ability. See section 9.6.14 for the steps of
triggering and resolving conditional abilities.
- If an ability allows a player to spend or move counters, that ability’s
source card is considered used at the time the
player pays a cost by spending or moving those counters, even if the counters are spent or moved from
cards other than the card that is the source of that ability.
Example: The Runner spends the credit hosted on Cyberfeeder to pay the trigger
cost of Mimic’s ability. Because the Runner triggered Mimic’s paid ability and
Cyberfeeder’s ability allowed the credit to be spent, both Mimic and Cyberfeeder have been
used.
- A player can only use an ability if its effect has the potential to change the
game state. See rule 1.2.5.
- Abilities are ACTIVE if they are
eligible to be resolved or apply to the current game state, and INACTIVE otherwise. By default, a card’s abilities are active if and
only if that card is active (see section
1.8.3). Abilities of counters are active for as long as the counter
exists.
- Some types of abilities are active even while their source card
is inactive.
- Conditional abilities that meet their conditions when their source
card is accessed are active even while that card is inactive.
- Abilities stating that they are active in a particular zone are
active in that zone. Abilities that can only ever meet their conditions in a particular zone are active
in that zone. Abilities that can only affect the game state from a particular zone are active in that
zone. When determining whether these stipulations apply, refer only to the game rules, not to any other
effects that may be changing how cards move between zones.
Example: I’ve Had Worse has an ability that meets its trigger condition
when it is trashed due to damage. Normally, this can only occur by moving I’ve Had Worse from the grip
to the heap. Therefore, this ability is active in the heap. However, if I’ve Had Worse is trashed, but
the Corp uses Skorpios Defense Systems to remove it from the game instead of adding it to the heap, the
ability is not active.
- Abilities that modify when or if their source card can be played,
installed, or rezzed are active even while that card is inactive.
- Abilities that modify the cost to install, rez, or play their source
card are active even while that card is inactive.
- Abilities that modify the advancement requirement of their source
card or create an additional cost to steal their source card are active even while that card is
inactive.
- Abilities allowing a card to be advanced are active even while that
card is unrezzed.
- If an active card is trashed, an ability of that card with a trigger condition
that is met by this trashing remains active in its owner’s discard pile until any corresponding
instances of the ability resolve. See rule
9.6.2 for information about instances of conditional
abilities.
Example: The Runner uses Singularity to simultaneously trash a rezzed Hostile
Infrastructure and 2 upgrades. Those cards are moved to Archives and become inactive, but Hostile
Infrastructure’s ability remains active, and 3 instances will become pending, each doing 1 net damage
when it resolves. Once all those instances are resolved, Hostile Infrastructure’s ability stops being
active.
- If a piece of ice is encountered while it is not installed, its
subroutines are active during that encounter.
Example: The Runner accesses Archangel from HQ, and the Corp uses its ability
to force the Runner to encounter it. Archangel’s subroutine is active and can resolve during that
encounter.
- Persistent abilities can sometimes remain active after their source card is
trashed. See section 9.12.5.
-
Timing and Priority
- The ACTIVE PLAYER is the player
whose turn it is. The other player is the INACTIVE PLAYER.
- A TIMING STRUCTURE is
a unit of the game in which a prescribed sequence of steps progress the game forward.
- The Corp’s turn and the Runner’s turn are timing structures, as are
each of the 3 phases of the turns. See section 5.
- A run is a timing structure, as are each of the 6 phases of a run. See
section 6.
- Breaching a server is a timing structure. See section
7.3 and section 7.5.
- Accessing a card is a timing structure. See section
7.1 and section 7.2.
- Other procedures with prescribed steps, such as installing a card or
resolving a trace attempt, are not timing structures.
- PRIORITY is a player’s
opportunity to act and make certain game choices. No more than one player can have priority at any given
time.
- A PRIORITY WINDOW is a general
term for a timing step in which one or both players receive priority. Priority windows OPEN for different purposes throughout the game. When a priority window
CLOSES, the game continues to the next timing step.
- All priority windows give the player with priority the option to choose a
relevant ability they control (if there are any) as the next ability for the game to resolve. This is
often referred to as TRIGGERING the chosen ability.
Some priority windows also give players other options.
- Except during action windows, the player with priority has the option to
PASS in addition to the available options defined by
that priority window. When a player passes, the game progresses to the next step, either by giving
priority to the other player or by closing the priority window. Each type of priority window defines the
method and resolution of passing.
- Unless otherwise noted, the player with priority receives priority
again after resolving one of their available options. That player will continue to receive priority
until they pass.
- While a priority window is open, another nested priority window can open as
well. This nesting allows the game to resolve “chain reactions,” as discussed in
rule 9.1.2a. The
most recently opened priority window is always resolved before returning to an earlier priority
window.
- Whenever a player receives priority during a priority window, a checkpoint
occurs immediately before that player may act. See section 10.3.
- The types of priority windows are action windows, paid ability
windows, reaction windows, interrupt windows, and mid-access ability windows.
- An ACTION WINDOW is a
priority window that opens during a player’s action phase if they have unspent clicks.
- An action window gives only the active player priority.
- During an action window, the active player must take an action. Section 5.2 discusses actions. This type of window does not give the
option to pass.
- After the active player takes an action, the action window closes
and the game moves to the next timing step. The player does not receive priority again.
- There are two timing steps during which an action window may open. The Corp has
an action window in step
5.6.2b of their action phase. The Runner has an action window in step 5.7.1f of their
action phase.
- A PAID ABILITY WINDOW is a priority window that opens throughout the game’s timing structures to allow
players to trigger paid abilities, rez cards, or score agendas.
- Paid ability windows give both players priority, starting with the
active player. When a player passes, the other player receives priority. Players continue to exchange
priority until a player who receives priority from their opponent passes without resolving any other
option available to them. Once this happens, the paid ability window closes.
- During every paid ability window, the player with priority has the option to
trigger an active paid ability they control. Players cannot trigger actions, interrupts, or mid-access
abilities in a paid ability window. See section 9.5. Within this document, paid ability
windows are marked with the symbol (P) to denote the option to trigger a regular paid ability.
- During some paid ability windows, the Corp has the option to rez an asset or
upgrade while they have priority. Within this document, the symbol (R) denotes a paid ability window in
which cards can be rezzed. See section
8.1.
- During some paid ability windows, the Corp has the option to score an agenda
while they have priority. Within this document, the symbol (S) denotes a paid ability window in which
agendas can be scored. See section
1.17.
- During the paid ability window at step 6.9.2b of the Approach Ice Phase of a
run, the Corp has the option to rez the piece of ice the Runner is approaching while they have
priority.
- The player with priority during a paid ability window may use any of
the options available to them any number of times in any combination and order until they decide to
pass, so long as they are allowed and the player pays any and all costs to use each option. Each option
must be fully resolved before another is chosen. A player is not obligated to resolve any of the options
available to them, except they must pass.
- Paid ability windows occur throughout the timing steps of turns and runs.
Section 5.6, section 5.7, and section 6.9 detail those steps and
indicate which options are available in which windows. Section 11 also contains a summarized
version of these steps.
- A REACTION WINDOW is a priority
window that opens whenever one or more active conditional abilities become pending by meeting their
conditions. Section 9.6 discusses conditional abilities.
- Each reaction window is associated with the fixed set of conditional abilities
that met their conditions just before the window opened. If other abilities become pending during a
reaction window, a separate reaction window opens to handle the new abilities. See rule 9.1.2a.
- Reaction windows give both players priority, starting with the
active player. When the active player passes, the inactive player receives priority. When the inactive
player passes, the reaction window closes.
- During a reaction window, the player with priority has the option to
trigger a pending conditional ability they control that is associated with that window.
- The player with priority during a reaction window may trigger their
pending abilities in any order until they decide to pass; they do not need to trigger mandatory
abilities before optional ones. Each ability they trigger must be fully resolved before another is
chosen.
- The player with priority cannot pass if they control any pending mandatory
abilities. They may pass with optional conditional abilities still pending, in which case those
abilities lose their pending status without being triggered. Section 9.6.9 describes the differences
between mandatory and optional conditional abilities.
- If a reaction window opens due to a timing structure beginning, and
during that reaction window the timing structure ends (e.g. by an effect moving the game to another
timing point past the end of the structure), then the reaction window immediately closes. All remaining
abilities associated with the window lose their pending status without being triggered, even if they are
mandatory abilities.
Example: The Runner has a Femme Fatale installed and chose a Tollbooth with its
“when installed” ability. When the Runner encounters the Tollbooth, they pay 1[c] to bypass the
Tollbooth with Femme Fatale. Because the resolution of Femme Fatale’s ability causes the encounter to
end, the pending ability from Tollbooth cannot be triggered. The Runner does not pay 3[c], and the run does
not end.
- An INTERRUPT WINDOW is a
priority window that opens just before an instruction would resolve when one or more players have
abilities that could modify that imminent instruction. See section 9.9 for rules about interrupt
abilities.
- Each interrupt window is associated with the single imminent
instruction being modified by the abilities triggered during the window, and with a fixed set of
conditional ability interrupts determined as the window opens.
- As an interrupt window opens, before players receive priority, the expected
effects of the imminent instruction are determined, any applicable replacement effects are applied, and
then relevant conditional abilities become pending. See section 9.9.4.
- Interrupt windows give both players priority, starting with the
active player. When a player passes, the other player receives priority. Players continue to exchange
priority until a player who receives priority from their opponent passes without resolving any other
option available to them. Once this happens, the interrupt window closes.
- During an interrupt window, the player with priority has the option to trigger
an interrupt ability they control that is relevant to the imminent effect. See section 9.9.3.
- The player with priority during an interrupt window may trigger
their abilities in any order until they decide to pass. They do not need to trigger mandatory abilities
before optional abilities or trigger conditional abilities before paid abilities. Each ability they
trigger must be fully resolved before another is chosen.
- The player with priority cannot pass if they control any pending mandatory
abilities that are still relevant to the imminent effect. They may pass with optional conditional
abilities still pending. (Section
9.6.9 describes the differences between mandatory and optional conditional
abilities.) Once a player has passed, if they receive priority again, they may
continue to trigger paid abilities and pending conditional abilities that are relevant. As the interrupt
window closes, any remaining pending conditional abilities lose their pending status.
- A MID-ACCESS ABILITY WINDOW is a priority window that opens while the Runner is accessing a card.
- A mid-access ability window gives only the Runner priority.
- During a mid-access ability window, the Runner may use a mid-access ability or
may pass. In addition to any mid-access abilities available from cards, the Runner may use the basic
trash ability (see section
7.1.5).
- After the Runner uses a mid-access ability or passes, the mid-access
ability window closes and the game moves to the next timing step. The Runner does not receive priority
again.
- The only point at which a mid-access ability window occurs is at step 7.2.2 of accessing a
card.
-
Interpreting Card Text
- Text is classified into conditions, restrictions, instructions,
declarations, and ability flags. The rules text of an ability can contain text in any combination of
these classes, except that no ability contains both instructions and declarations.
- A CONDITION is a unit
of text that stipulates a requirement for when an ability’s effects are allowed to apply.
- A COST CONDITION describes a cost
(either a nested cost or a trigger cost) that a player must pay to apply an effect. Costs are discussed
in detail in section 1.16.
- A TRIGGER CONDITION describes a change in game state that must occur for an effect to apply. Trigger
conditions often begin with words such as “if”, “when”, “whenever”,
or “after”, or with ordinal phrases such as “the first time”.
- A STATIC CONDITION describes a property of the game state that must be true for an effect to apply. Static
conditions often begin with words such as “if”, “during”, or
“while”.
- A RESTRICTION is a unit of text
that applies one of a specific set of constraints for a card to be played or an ability to be used. If a
restriction appears in an ability, it applies to the entire ability regardless of whether it is written
before, after, or in the middle of the ability’s other text. Many restrictions fall under
section 9.1.8,
meaning they are active even while their source is inactive.
- Text modifying the cost to play, install, rez, or steal the card it
appears on is a restriction, including text that adds an additional cost.
- Constraints on when or where a card can be installed, rezzed,
played, or scored are restrictions.
- Limits on when, where, or how often an ability can be used are
restrictions.
- Constraints on how a cost can be paid are restrictions.
- If a card’s text limits what cards it can host, the text describing that
limit is a restriction. See also rule
1.13.5b.
- Definitions for or constraints on a variable are
restrictions.
Example: Some abilities dictate a value for X, such as “X is the number
of rezzed NEXT ice.” Some abilities with X in their cost constrain the value that can be chosen for X,
such as “X must be equal to or less than the number of tags the Runner has.” These statements
are restrictions.
- Stipulations that an effect or part of an effect cannot be prevented
are restrictions.
- Any text not falling under one of the above categories is not a
restriction.
- An INSTRUCTION is a statement or
command that is resolved at a specific time and applies immediate effects to the game state. (This can
include creating new lingering abilities or effects that will continue to apply over time; see
section 9.10.)
- Instructions can originate from a game rule or from the text of an ability. An
instruction in an ability resolves when that ability resolves (see rule 9.1.2). An instruction in the game rules resolves
during the timing step(s) when it appears. Section 9.11 explains how to determine the boundaries between consecutive instructions.
- If an instruction requires any targets, players announce those targets before
that instruction becomes imminent. See section 1.15.
- Each instruction is carried out as an atomic unit and cannot be interrupted
once it begins to resolve. The procedure for carrying out an instruction can be altered by other effects
such as interrupts, but only before the instruction begins to resolve. See section 9.9.
- Other than choosing targets, carry out the steps of a single
instruction in the order they are written.
- Instructions in an ability can create effects that last beyond the resolution
of the ability. See section
9.10.
- A DECLARATION is a
statement describing an effect on components or game rules that is applied continuously. A declaration
applies its effects as long as it is active.
- An ABILITY FLAG is a keyword or
symbol that appears at the beginning of an ability. Ability flags are separated from the
main text of the ability by an arrow (→). Each ability flag changes the rules for how the flagged
ability functions.
- There are four ability flags: access, interface, [interrupt], and
persistent.
- The “access” flag appears on Runner card paid abilities and affects
the timing for triggering those abilities. The Runner can use abilities with this flag only during the
mid-access ability window at step
7.2.2 of accessing a card. See section 9.2.10.
- The “interface” flag appears on icebreaker paid abilities and
affects the timing for triggering those abilities. The Runner can use abilities with this flag only
during an encounter, and only if the ability’s source is an icebreaker with strength that equals
or exceeds the strength of the encountered ice. See section 3.9.5.
- The interrupt flag ([interrupt]) appears on paid and conditional abilities and
affects the timing for triggering those abilities. Players can use abilities with this flag only during
interrupt windows, and only if the ability is relevant to the imminent instruction. See section 9.9.
- The “persistent” flag appears on Corp card abilities and changes
the rules about when those abilities are active. An ability with this flag can persist until the end of
the run after its source card is trashed. See section 9.12.5.
- The five types of abilities can be identified by the types of
text they are made of.
- Static abilities (section 9.4) can contain declarations,
restrictions, and conditions, but never instructions. Static abilities are the only ability type that
can contain declarations.
- Paid abilities (section 9.5) can always be identified by their
formatting: a cost condition in bold text, a colon (:), then the remainder of the ability. The text
after the colon can contain conditions, restrictions, and/or instructions.
- Conditional abilities (section 9.6) always contain a trigger condition
or static condition and at least one instruction. They can also contain restrictions, other
instructions, or nested conditions. The primary condition is often written with a timing-related word or
phrase like "when", "after", "the first time", and so on, and is usually
the first part of the ability’s text. Some older cards write the condition at the end of the
ability or use "if" to indicate the condition.
- Play abilities (section 9.7) are the abilities on events and
operations that are not paid, conditional, or static abilities. They can contain conditions,
restrictions, and/or instructions.
- Subroutines (section 9.8) always begin with the [sub] symbol,
and can contain conditions, restrictions, and/or instructions.
-
Static Abilities
- A STATIC ABILITY is
an ability that continuously affects the game as long as it is active. Static abilities are the only
type of ability that can contain declarations, and they do not resolve or have associated priority
windows.
- If a static ability contains a static condition, then the
constrained parts of the ability apply to the game state only if that condition is met.
- Static abilities can include restrictions that apply to their source card.
These restrictions are often active even while the card is inactive. See section 9.1.8.
- The effects of static abilities do not have durations and cannot directly
create lingering effects (see section
9.10).
Example: The runner controls Puffer with a hosted Gebrselassie. Gebrselassie
changes the durations of abilities affecting its host’s strength, so if the Runner uses Puffer’s
paid ability to give it +1 strength, that increase will last for the remainder of the turn. Gebrselassie
does not affect Puffer’s static ability that increases its strength for each hosted power counter, so
if the Runner spends [click] to remove a power counter, then the increase in strength from Puffer’s
static ability will immediately be lost.
- Static abilities that modify a value maintain the same
restrictions and specifications that were present on the original value.
Example: The Cleaners has a static ability that gives every instance of meat
damage done by the Corp +1 to the amount of the damage. Part of Flare’s effect does 2 meat damage that
can’t be prevented. If this effect resolves while The Cleaners is active, then all 3 points of meat
damage are unpreventable.
-
Paid Abilities
- A PAID ABILITY is an ability
players trigger at-will, during appropriate priority windows. In order to use a paid ability, the
controller of that ability must pay its TRIGGER COST.
Paid abilities are always written with the trigger cost first, followed by a colon (:), followed by the
remainder of the ability’s text.
- A player can trigger paid abilities they control while they
have priority in an appropriate priority window.
- If the trigger cost of a paid ability begins with a [click] symbol, the ability
is an ACTION. A player can use one action paid ability during each
action window on their turn. See section
9.2.6 and section
5.2.
- If the [interrupt] flag appears before a paid ability’s trigger cost,
that ability is an interrupt. A player can use interrupt paid abilities during appropriate interrupt
windows. Each such ability can be used as many times as its effects could apply to the imminent
instruction. See section
9.9.
- If the “access” flag appears before a paid ability's trigger
cost, that ability is a mid-access ability. The Runner can use up to 1 mid-access ability during the
mid-access ability window at step
7.2.2 of accessing a card.
- If the “interface” flag appears before a paid ability’s
trigger cost, that ability is an Interface ability and is subject to the restrictions of icebreakers
discussed in section 3.9.5. Interface abilities do not have a special priority window type.
- A paid ability that is not an action, interrupt, or mid-access
ability can be used during a paid ability window. Each such ability can be used an unlimited number of
times as long as its cost is paid each time and any restrictions specified by its effect are
observed.
- Paid abilities are always optional. A paid ability and its
source are considered used when the ability’s trigger cost is paid.
- Mid-access abilities the Runner is forced to trigger still count as optional
abilities. See also rule
7.1.5c and rule 7.1.5d.
Example: The Corp resolves the subroutine on Wendigo, prohibiting the Runner from
using their installed Imp for the remainder of the run. Later, the Runner accesses an installed Mumbad
Virtual Tour. Even though Mumbad Virtual Tour forces the Runner to trash it if able, Imp's ability is
still optional for purposes of Wendigo's prohibition. Since Imp's ability cannot be used at all this
run, Mumbad Virtual Tour cannot compel the Runner to spend one of its hosted virus counters. If the Runner
can pay the cost of another mid-access ability, such as the basic trash ability, the Runner must use that
ability. If not, the Runner will not be able to trash Mumbad Virtual Tour at all.
- Once a player pays the trigger cost of a paid ability, that ability
becomes independent of its source and rule
9.1.4 applies to it.
- If the trigger cost of a paid ability uninstalls or forfeits
the source of that paid ability, and the effects of that paid ability refer to or act on cards or
counters hosted on that source, set aside any hosted cards and
counters as the trigger cost is paid. The set-aside
cards or counters are still considered “hosted” for purposes of this ability, but they are
not trashed due to not having a host for as long as the ability is resolving. When the ability finishes
resolving, if any of those cards or counters are still set aside, they are trashed during step 10.3.1f or step 10.3.1g of the next
checkpoint, as appropriate. Other abilities cannot interact with these cards or counters while they are
set aside (see rule 4.8.3).
Example: The Runner has Fermenter installed with 4 hosted virus counters. They use
its paid ability, which has a cost that includes trashing Fermenter. As the
Runner pays this cost, they set aside the 4 counters. When the ability resolves and refers to the number of
hosted virus counters, it includes the counters that were set aside, so the Runner gains 8 credits. When the
ability is finished resolving, the counters are returned to the bank.
Example: The Runner uses the [trash] ability on Street Peddler. They pay the
trigger cost and set the 3 hosted cards aside. When the ability resolves, the Runner installs one of the
set-aside cards. Since the other two cards are still set aside, the next checkpoint trashes them just as in
any other case of cards that were hosted on a card that is no longer installed. No other abilities are able
to tell that the cards were set aside: they are treated as having been installed or trashed from their
previous location in the play area.
Example: This example describes a situation similar to the previous examples,
but covers the sequence of steps the game carries out in a higher level of detail. The Corp has priority in
a paid ability window, and chooses to trigger the [trash] ability on Reconstruction Contract. As they pay
the trigger cost, moving Reconstruction Contract to Archives, they set aside the advancement counters hosted
on Reconstruction Contract. Next, a checkpoint occurs following the cost having been paid. After that
checkpoint and any corresponding reaction window, the [trash] ability’s instruction is ready to become
imminent. The Corp chooses a card they can advance to be the instruction’s target, and an interrupt
window opens. After the interrupt window (assuming the effects of the instruction are not prevented), the
Corp moves the set-aside counters to the target card.
-
Steps of Using a Paid Ability
- Announce the intent to trigger the paid ability.
- Pay the trigger cost. The ability and its source are considered
used. “When used” abilities meet their trigger conditions. (The cost-paid checkpoint then
occurs.)
- Announce any targets for the ability’s first instruction. That
instruction then becomes imminent.
- An interrupt window occurs, during which abilities can modify,
prevent, or avoid the imminent effects.
- Resolve the instruction, applying any changes to its effects from
interrupts that were resolved.
- A checkpoint occurs.
- If there are more instructions to resolve, announce any targets for
the next instruction. That instruction then becomes imminent. Return to (d).
- Resolution of the paid ability is complete.
-
Conditional Abilities
- A CONDITIONAL ABILITY is an ability that a player can or must trigger at a specific point in the game.
Conditional abilities always include a primary condition and one or more instructions, but they have no
special syntax requirements.
- The primary condition of a conditional ability is usually a trigger
condition, but can also be a static condition.
- The primary condition of a conditional ability is often, but not always,
written at the front of the ability. See rule 9.3.7c for details about conditional
ability syntax.
- When a conditional ability has met its condition, one or more INSTANCES of that conditional ability is created PENDING in the next reaction window that opens. Each instance of
a conditional ability is a separate copy of that ability that resolves independently of the others. An
instance of an ability with the pending status is waiting for its controller to trigger it.
- A conditional ability with a static condition can only have one
instance at a time.
- A conditional ability with a trigger condition can have
multiple instances.
- If a trigger condition is met again while an instance of the
corresponding ability is already pending, imminent, or resolving, a new instance can still become
pending in the next reaction window.
- If the trigger condition of an ability is met more than once between
consecutive checkpoints, multiple instances of that ability become pending in the next reaction
window.
Example: The Runner plays Singularity, trashing 3 Corp cards simultaneously.
Since Hostile Infrastructure’s trigger condition is met separately for each card trashed, the next
checkpoint handles all of those occurrences, and 3 instances of the ability become pending in the same
reaction window.
Example: The Runner controls Blackguard and plays Satellite Uplink, exposing 2
cards in a single instruction. In the next checkpoint, two instances of Blackguard’s ability become
pending, one corresponding to each card that was exposed.
- The trigger condition of most conditional abilities describes an
occurrence that allows it to become pending. These rules about trigger conditions also apply to
conditional abilities with static conditions, except as described in section 9.6.7.
- During each checkpoint, the game checks whether any conditional abilities have
met their trigger conditions. If any have, a reaction window opens to resolve those abilities (See
section 10.3). This
reaction window is fully resolved and closed before the game proceeds to the next instruction of the
original effect or game rule.
- A conditional ability can only recognize its trigger condition
occurring if the ability is active at the time the trigger condition resolves. If a conditional ability
becomes active after the point when its trigger condition was met, that ability does not become pending,
even if other abilities sharing that trigger condition are still pending.
- A conditional ability can only recognize its trigger condition
occurring if all the stipulations and requirements listed in the trigger condition are met at the moment
that the trigger condition would occur.
Example: The entire trigger condition on Quantum Predictive Model is “If
the Runner is tagged when Quantum Predictive Model is accessed”. Quantum Predictive Model can only
meet its trigger condition if the Runner is tagged at the time the access occurs. Even if Casting Call is
hosted on Quantum Predictive Model, the tag will be given after the access begins, and no ordering of the
abilities will allow Quantum Predictive Model to meet its trigger condition.
- Additional stipulations and requirements listed in the instructions
of a conditional ability are checked as part of the ability’s effects and are not part of the
ability’s trigger condition. For the effects under the scope of this kind of condition to resolve,
the condition only needs to be met when the relevant instructions resolve. This can occur even if some
or all of those conditions were not met at the time the ability met its trigger condition.
Example: If a Runner with 1 link has both Underworld Contact installed and The
Supplier installed hosting a Dyson Mem Chip, both Underworld Contact and The Supplier meet their trigger
conditions at the same time. The Runner can trigger The Supplier first, installing the Dyson Mem Chip, thus
allowing Underworld Contact to recognize that the Runner has 2 link and give them 1 credit, even though the
Runner did not have 2 link at the time the Underworld Contact became pending.
- The phrase “If successful” in reference to a run is a trigger
condition with specific rules. See section 6.7.4. The phrases “If successful” and “If
unsuccessful” are also frequently used as trigger conditions relating to the results of a trace.
See section 10.8.
- Trigger conditions look for an instantaneous change in the game
state. The next checkpoint after that change takes place marks an instance of the ability as pending for
each occurrence of the change that was looked for.
- Conditional abilities with a static condition instead of a
trigger condition describe an effect that must be performed repeatedly, if possible, while the condition
is true. Such abilities usually attempt to end their own repetition by uninstalling their source.
- During each checkpoint, the game checks whether any conditional
abilities with static conditions should become pending, alongside conditional abilities with trigger
conditions. However, there are further requirements for this kind of ability to be marked
pending.
- A conditional ability with a static condition can only be marked
pending during a checkpoint if the condition is true at the beginning of that checkpoint.
- A conditional ability with a static condition can only be marked
pending if no other instance of the same ability from the same source is already pending, imminent, or
resolving.
- A conditional ability with a static condition can only be marked
pending if the instructions in the ability have the potential to change the game state.
Example: Parasite is hosted on a piece of ice with 0 strength. Parasite’s
ability tries to trash that ice. If the effect of an interrupt ability prevents the ice from being trashed
without increasing its strength, the condition is still true, so the ability will become pending again. But
this does not occur while the previous instance of the ability is still pending or resolving. Conversely, if
a static ability (such as the one on Architect) prohibits Parasite from trashing the ice, Parasite’s
ability does not have the potential to change the game state, and therefore it does not become
pending.
- A player can trigger a conditional ability while they have
priority in a reaction window in which the ability is pending.
- Once a player triggers a conditional ability, that instance of the
ability loses its pending status. Other pending instances of the ability are unaffected and can still be
triggered later, regardless of whether those instances are associated with the same reaction
window.
- If the [interrupt] symbol appears before a conditional ability’s text,
that ability is an interrupt. These abilities will become pending in interrupt windows rather than
reaction windows, but are otherwise resolved in the same way as non-interrupt conditional abilities. See
section 9.9.
- If a conditional ability gives its controller a choice of whether to apply
its effects, such that the ability could potentially have no effects at all, it is considered an
OPTIONAL CONDITIONAL ABILITY. These abilities can usually be recognized
by the presence of permissive words such as “may” or “allows”, or by a
restriction such as “Use this ability only once per turn.” If the ability is not optional,
then it is a MANDATORY CONDITIONAL ABILITY.
- Instances of optional conditional abilities can still be pending
when their controller passes in the corresponding priority window. Players are not required to trigger
optional conditional abilities.
- Players must trigger all instances of pending mandatory conditional abilities
they control in a given priority window before they can pass in that window. See section 9.2.8.
- Both optional and mandatory conditional abilities may have optional
parts to their effects. Even if triggering the ability is mandatory, its controller may still decline
any optional constituent effects that arise during its resolution.
- A conditional ability and its source are considered used when any
optional component of the ability’s effects is carried out.
- If any instances of a conditional ability are pending and the conditional
ability itself becomes inactive, those instances lose their pending status and will not
resolve.
Example: The Runner has both Aesop’s Pawnshop and Drug Dealer installed.
Both cards have abilities that meet their trigger conditions when the Runner’s turn begins. If the
Runner chooses to trigger Aesop’s Pawnshop first, and then uses it to trash Drug Dealer, Drug
Dealer’s pending ability can never be triggered, so the Runner does not lose a credit.
- If a priority window closes while any abilities still have pending
instances associated with that window, the remaining instances lose their pending status and cannot be
triggered or resolved. See rule
9.2.8f.
- Once a player triggers a conditional ability and its instructions become
imminent, the ability becomes independent of its source and rule 9.1.4 applies to it.
- A DELAYED CONDITIONAL ABILITY is
a conditional ability maintained by a lingering effect (see section 9.10). Unlike other lingering effects,
some delayed conditional abilities are created without an explicitly stated duration.
- If an “if successful” ability contains a nested delayed conditional
ability referring to breaching the attacked server, that ability applies to the breach at step 6.9.5b of the run the
“if successful” ability is associated with. Its duration expires at the end of the run. See
rule 6.7.4b.
- If an instruction creates a delayed conditional ability and
specifies a duration, the delayed conditional ability is active until that duration expires.
Example: In the Groove creates a delayed conditional
ability that specifies a duration of “this turn”. Since a duration is specified, it is not
limited to only being triggered once. The ability becomes pending and can resolve every time its trigger
condition is met, and its existence only expires at the end of the turn.
- Any other delayed conditional ability exists until the next time it
resolves, after which it expires.
Example: Joshua B’s ability allows the Runner to gain [click]. If they
do, it creates a delayed conditional ability that is independent of Joshua B itself, which will meet its
trigger condition only once, when that turn ends. After that ability resolves, the game no longer maintains
the lingering effect creating the ability.
-
Steps of Triggering and Resolving a
Conditional Ability
- Announce that you will trigger one of the pending abilities
associated with the reaction window that gave you priority.
- Announce any targets for the ability’s first instruction. That
instruction then becomes imminent.
- An interrupt window occurs, during which abilities can modify,
prevent, or avoid the imminent effects.
- Resolve the instruction, applying any changes to its effects from
interrupts that were resolved. If the controller of the ability chooses to resolve an optional effect
contained in this instruction, and this is the first instruction for which that player has done so,
“when used” conditionals meet their trigger conditions.
- A checkpoint occurs.
- If there are more instructions to resolve, announce any targets for
the next instruction. That instruction then becomes imminent. Return to (c).
- Resolution of the conditional ability is complete.
-
Play Abilities
- Any ability on an event or operation that is not a paid, conditional, or
static ability is a PLAY ABILITY. Play abilities are the abilities
that resolve as part of playing that event or operation during step 8.6.6f.
Example: The operation card Hyoubu Precog Manifold has several abilities of
different types. The first sentence reads “Play only if there is no active lockdown.” This is a static ability that contains a
restriction and no declarations. The second sentence (“This operation is not trashed until your next
turn begins.”) is a play ability that has no immediate impact on the game state but creates a
lingering effect that alters how the operation will leave the play area after resolving. The second
paragraph reads simply, “Choose a server.” This play ability instruction is the main part of the
card that actively affects the game state while the operation resolves. Finally, the third paragraph is a
single conditional ability with multiple instructions that is active as long as the operation remains in the
play area.
-
Steps of Resolving a Play Ability
- Announce any targets for the ability’s first instruction. That
instruction then becomes imminent.
- An interrupt window occurs, during which abilities can modify,
prevent, or avoid the imminent effects.
- Resolve the instruction, applying any changes to its effects from
interrupts that were resolved.
- A checkpoint occurs.
- If there are more instructions to resolve, announce any targets for
the next instruction. That instruction then becomes imminent. Return to (b).
- Resolution of the play ability is complete.
-
Subroutines
- A SUBROUTINE is an ability
beginning with the [sub] symbol. Only ice can have subroutines.
- Subroutines are the only abilities that are ordered.
- The order of the subroutines printed on a piece of ice is the order in which
they appear on that ice.
- Unless otherwise stated, subroutines a piece of ice gains from an
ability are added after all other subroutines the ice has at that time.
Example: The Runner encounters Marker, and its subroutine resolves. The next ice the Runner encounters is Brainstorm. When the
encounter begins, the lingering effect from Marker gives Brainstorm an “[sub] End the run.”
subroutine. Then, Brainstorm’s conditional ability resolves, giving it the appropriate number of
“[sub] Do 1 brain damage.” subroutines. The “[sub] Do 1 brain damage.” subroutines
are all ordered after the “[sub] End the run.” subroutine.
- If multiple subroutines are added to a piece of ice at the same time in an
unspecified order, the Corp declares the relative order of those subroutines at the time the ice gains
them.
- Some ice have static abilities that grant that piece of ice a
variable number of subroutines. Subroutines from such an ability are always ordered before any other
subroutines on that ice.
- If the number of subroutines granted to a piece of ice by its own
static ability increases, the additional subroutines are added immediately after the previously-existing
subroutines from the same ability.
Example: The Corp has no bad publicity and controls a rezzed copy of Ireress
hosting a condition counter from Sub Boost. If the Corp takes bad publicity, the corresponding subroutines
from Ireress’s ability are added before the “[sub] End the run.” from the condition
counter.
Example: The Corp has 3 cards in HQ while the Runner is encountering Ashigaru.
After the Runner breaks Ashigaru’s 3 subroutines, the Corp uses Panic Button to draw another card. The
new subroutine is added after the previous 3, so the Runner can use Gbahali to break it.
- If the number of subroutines granted to a piece of ice by its own
static ability decreases, subroutines are lost beginning with the last subroutine the ice previously had
from the same ability and working backwards.
Example: The Corp has 3 cards in HQ while the Runner is encountering Ashigaru. The
Runner breaks the first subroutine, then uses Utopia Shard to force the Corp to discard 2 cards. Ashigaru
correspondingly loses its last 2 subroutines, leaving behind the subroutine that was already broken.
- One card, Hive, has a static ability
that removes its own printed subroutines. Subroutines are lost to this ability beginning with the last
printed subroutine and working backwards.
- For each encounter, the subroutines on the encountered ice have a status
of BROKEN or UNBROKEN with respect to that encounter.
- When an encounter begins, each of its subroutines becomes unbroken
with respect to that encounter.
- When a piece of ice gains 1 or more new subroutines during an
encounter with it, those subroutines come into existence unbroken with respect to that encounter.
- When an encounter ends, card abilities can still check whether subroutines were
broken or unbroken during that encounter.
- To BREAK a subroutine is to
change its status with respect to the active encounter from unbroken to broken. Many cards that can
allow a player to break subroutines are icebreakers (see section 3.9.5). If the Runner breaks all the subroutines on
the encountered ice, they fully break that ice (see section 6.5.7).
- Only unbroken subroutines can be chosen as targets for
abilities that would break them.
- An ability that breaks “all subroutines” does not target
any subroutines, and can be used as long as the encountered ice has at least 1 unbroken
subroutine.
- One card, Grappling Hook, has
the ability to break “all but 1 subroutine” on the encountered ice. To trigger this ability,
its controller chooses as its target the 1 subroutine that will not be broken. When the ability
resolves, it breaks all unbroken subroutines except the chosen subroutine.
Example: The Runner uses two copies of Grappling Hook to break all of the
subroutines on Heimdall 1.0. For the first Grappling Hook, the Runner chooses the unbroken “[sub] Do 1
brain damage.” subroutine as the target, and Grappling Hook breaks both “[sub] End the
run.” subroutines. For the second Grappling Hook, the Runner chooses one of the already-broken
“[sub] End the run.” subroutines as the target. They can choose the broken subroutine as
Grappling Hook’s target because Grappling Hook will not attempt to break the chosen subroutine. When
the ability resolves, Grappling Hook breaks the “[sub] Do 1 brain damage.” subroutine, but does
nothing to the other “[sub] End the run.” subroutine, because it is already broken.
- At step 6.9.3c of an encounter,
the Corp resolves subroutines that are unbroken with respect to that encounter.
- Resolving subroutines is mandatory and does not open a priority
window.
- The Corp resolves the unbroken subroutines 1 at a time in order. The order of
subroutines is discussed in section 9.8.2.
- If the encounter ends during this process, no more subroutines are
resolved.
Example: The Runner encounters Little Engine and does not break any
subroutines. Little Engine’s first subroutine resolves and ends the run. Since the run and therefore
the encounter have ended, no more subroutines resolve. The Runner will not gain 5[c].
- One card, Street Magic, allows the Runner
to set the order in which subroutines are resolved. If this ability is active
when step
6.9.3c is reached for the first time in an encounter, the Runner declares an order for the unbroken subroutines, and the Corp must resolve them
in this order instead of their normal order. The new order is determined before any subroutines are
resolved.
- Once a subroutine’s first instruction becomes imminent, the
subroutine becomes independent of its source and rule 9.1.4 applies to it.
-
Steps of Resolving a Subroutine
- The subroutine itself becomes imminent.
- An interrupt window occurs, during which abilities can prevent the
subroutine from resolving. If this happens, the remaining steps are not carried out.
- Announce any targets for the subroutine’s first instruction.
That instruction then becomes imminent.
- An interrupt window occurs, during which abilities can modify,
prevent, or avoid the imminent effects.
- Resolve the instruction, applying any changes to its effects from
interrupts that were resolved.
- A checkpoint occurs.
- If there are more instructions to resolve, announce any targets for
the next instruction. That instruction then becomes imminent. Return to (d).
- Resolution of the subroutine is complete.
-
Interrupts and Replacement Effects
- An INTERRUPT is an ability
that modifies either the effects of another instruction or the context in which that instruction will be
resolved. Interrupts can be written in the form of a paid ability or a conditional ability.
- Interrupt abilities are denoted by the [interrupt] symbol appearing
at the beginning of the ability, or by certain keywords in the ability’s text.
- Any paid or conditional ability that uses the word
“prevent”, “avoid”, or “would” is an interrupt ability.
- The EXPECTED EFFECTS of an imminent instruction are the effects described by the instruction’s text,
modified by any static abilities that affect it and any replacement effects or interrupt effects that
have been applied. The expected effects of an instruction are continually updated throughout the
interrupt window.
Example: The Runner plays Process Automation and the instruction “Gain
2[c] and draw 1 card.” becomes imminent. The expected effects of this instruction are that the Runner
will gain 2[c] and draw 1 card.
Example: The Runner plays Process Automation after Lockdown’s subroutine
resolves. The instruction “Gain 2[c] and draw 1 card.” becomes imminent, but the Runner cannot
draw cards. The expected effect of this instruction is that the Runner will gain 2[c].
- When an instruction resolves, its expected effects correspond to the effects
that occur, except for situations where rule 9.9.7d applies.
- In order to trigger an interrupt, it must be RELEVANT to an imminent instruction. An interrupt is relevant to an
instruction if at least one of the following is true:
- Its effects could prevent or avoid part or all of the imminent
instruction’s expected effects. See section 9.9.5.
- Its effects could modify a value associated with the imminent
instruction’s expected effects. See section 9.9.6 and section 9.9.7.
- Its effects could create a replacement effect that applies to the imminent
instruction’s expected effects. See rule 9.9.10.
- It has a trigger condition using the word “would” that
is met by the imminent instruction’s expected effects.
Example: The trigger condition on The Class Act’s second ability is
“The first time each turn you would draw any number of cards”. Even though this ability’s
effects do not directly modify the imminent instruction’s effects, the ability is relevant to an
instruction that is expected to draw cards.
- Whenever an instruction becomes imminent, an interrupt window opens to
allow players to modify the effects of that instruction. Section 9.2.9 contains the rules for
handling priority during interrupt windows.
- As the window opens, the initial expected effects of the instruction are
determined, then any active replacement effects that replace all or part of the expected effects are
applied. If multiple replacement effects could apply, the order in which they are applied follows the
rules in section 9.9.11.
- After replacement effects have been applied, but before players
receive priority, active conditional ability interrupts that are relevant to the imminent instruction
are marked pending and are associated with the window. If a conditional ability interrupt becomes active
after the interrupt window opens, it does not become pending.
- While a player has priority in an interrupt window, they can trigger
a conditional ability interrupt they control only if it is pending in that window and still relevant to
the imminent instruction.
Example: An instruction is imminent that would trash an installed copy of
Harbinger. The Runner uses Sacrificial Construct to prevent Harbinger from being trashed. The Runner
can no longer trigger Harbinger’s interrupt ability, even though it is still pending, because the
expected effects of the instruction no longer include Harbinger being trashed and therefore the ability is
no longer relevant.
Example: An instruction is imminent that would give the Runner 2 tags. The Runner
trashes Decoy to use its ability to avoid 1 of the tags, which meets the trigger condition for Thunder Art
Gallery’s ability. The latter resolves as a chain reaction (see rule 9.1.2a) while the interrupt
window is still open, allowing the Runner to install No One Home, which has a conditional ability interrupt
that is relevant since the instruction is still expected to give the Runner 1 tag. However, No One Home was
not active when the interrupt window opened, so its ability is not pending and cannot be triggered.
- While a player has priority in an interrupt window, they can use a paid ability
interrupt that is relevant to the imminent instruction. The ability does not have to have been active
when the interrupt window opened, nor does a paid ability window need to be open at this time.
Example: An instruction is imminent that would give the Runner 2 tags. The Runner
trashes Decoy to use its ability to avoid 1 of the tags, which meets the trigger condition for Thunder Art
Gallery’s ability. The latter resolves as a chain reaction (see rule 9.1.2a) while the interrupt window
is still open, allowing the Runner to install another copy of Decoy. The Runner receives priority again in
the original interrupt window and uses the second Decoy’s ability to avoid the other imminent
tag.
- To PREVENT or AVOID an effect is to stop that effect from happening. The terms
“prevent” and “avoid” are synonymous.
- Some abilities look for an ordinal instance of an effect that
“would” take place within a specified time period. These abilities look for the appropriate
number of times that effect becomes imminent, not whether the effect actually resolves. Preventing or
replacing an effect does not allow these abilities to meet their trigger conditions again in the same
time period.
Example: Tori Hanzō’s interrupt can only be used “the first
time you would do net damage” during a run. If the first net damage that becomes imminent is prevented
by the Runner using Feedback Filter, Tori Hanzō cannot be used on any other instances of net damage for
the remainder of the run, as the next imminent net damage is the second time the Corp “would”
deal net damage, not the first time.
- Abilities that do not use “would” do not see effects that are
prevented, as those effects did not occur.
- A static ability can stipulate that a particular effect is always
prevented. This kind of prevention effect does not require a player to explicitly trigger it.
Example: Paparazzi reads in part, “Prevent all meat damage.” This
is a static ability that applies automatically to any instruction that would deal meat damage.
- Some instructions make use of an associated value. These values
can be changed by interrupts and replacement effects.
- A number of tags the Runner would take from an effect is a value.
Avoiding a number of those tags decreases that value. The value for a number of tags the Runner takes
must be greater than 0 for the effect giving tags to occur.
- An amount of damage the Runner would take from an effect is a value.
Preventing an amount of that damage decreases that value. The value for an amount of damage the Runner
takes must be greater than 0 for the damage effect to occur.
- A cost that would be paid while resolving an effect is a value. Rule 1.16.1c applies to the final value at the time the
cost is paid. See also rule
1.16.1d.
Example: Patchwork’s interrupt modifies a play cost or install cost, so it is relevant to any instruction where a card
will be played or installed and the corresponding cost paid.
- The base trace strength of a trace attempt is a value. See section 10.8 for rules about trace
attempts. A base trace strength value does not need to be greater than 0 for the trace attempt to
occur.
- Values associated with an imminent instruction are calculated
continuously as part of the instruction’s expected effects.
- While an instruction is imminent, values associated with that
instruction can be reduced below 0. Values 0 or lower can still be modified by other interrupt abilities
while the instruction remains imminent.
Example: The Runner takes a tag on their turn, allowing the Corp to trigger Mr.
Stone. While the 1 meat damage from Mr. Stone’s ability is imminent, both players can trigger
interrupts to modify the damage effect. Since it is the Runner’s turn, they receive priority first and
use Biometric Spoofing to prevent 2 damage. The imminent effect is now expected to do -1 damage. When the
Corp receives priority, they trigger two copies of The Cleaners that each add 1 to the expected damage,
increasing the total to 0 and then to 1. The ability will resolve with 1 damage even though the amount of
damage was temporarily 0 or less while the effect was imminent.
- If an effect prevents “all damage” or “any amount
of damage” while an instruction is imminent, the damage is removed from the expected effects
entirely, and there is no longer a value to be modified. If an effect avoids “all tags” or
“any number of tags” while an instruction is imminent, taking tags is removed from the
expected effects entirely, and there is no longer a value to be modified.
- One card, Bio-Modeled Network,
has an instruction that prevents “all but 1 net damage.” This ability is relevant when the
imminent instruction’s expected effects include doing net damage and the amount of the damage is 2
or more. The effect of this ability is to set the value for the amount of damage to 1.
Previously-applied modifiers to the value are ignored. The value can still be modified by other
interrupts after being set to 1 this way.
- Some types of values must be greater than 0 for the associated effect to occur.
See section 9.9.6. At the
time an instruction resolves, if any value of one of those types is 0 or less, as much of that ability
resolves as possible without applying the part of the effect making use of
that value, following rules 1.2.3 and 1.2.4 of the Golden Rules.
Example: The Runner accesses Breached Dome. While the instruction from its
“when accessed” ability is imminent, the Runner uses Biometric Spoofing to prevent 2 damage.
When the ability resolves, the value for the amount of damage is -1, which is less than or equal to 0, so
the damage effect cannot occur and the Corp only trashes the top card of the stack.
- Any effects making use of modified values maintain their
restrictions and specifications with the new values.
Example: While the result of a successful trace from Flare is imminent, the Corp
triggers The Cleaners to increase the imminent meat damage by 1. Even though the damage from Flare has been
increased from 2 to 3, none of that meat damage can be prevented.
- A REPLACEMENT EFFECT modifies another effect by replacing some or all of the original effect’s
behavior with different behavior. Replacement effects are indicated by the word “instead” in
their text. Once created, replacement effects apply automatically and do not require players to
explicitly trigger them.
- Interrupts can introduce replacement effects that apply to the currently
imminent instruction. See rule 9.9.10.
- Static abilities can stipulate replacement effects that apply
whenever appropriate while the static ability is active.
- Other abilities can create replacement effects ahead of time, which apply to
effects that could happen later. This is a type of lingering effect (see section 9.10).
- Replacement effects most commonly apply to the effects of an
instruction, but some apply to static abilities or alter the durations of lingering effects.
- If a replacement effect modifies the effects of a static ability or
the duration of a lingering effect, this modification applies continuously for as long as the
replacement effect itself is active, and no longer applies once the replacement effect or the original
effect being modified becomes inactive.
Example: Gebrselassie’s static ability replaces the durations of certain
lingering effects affecting its host with a duration of “for the remainder of the turn.” If
Gebrselassie is uninstalled or moved to a different host, its replacement effect no longer applies to those
lingering effects, so they revert to their normal durations. If any of those durations have already expired,
the corresponding effects will end at the next checkpoint.
- If an active replacement effect can apply to the expected effects of an
imminent instruction, it is applied as the interrupt window opens, and the expected effects of the
instruction are updated accordingly. This happens before the expected effects are checked for relevant
active abilities that could become pending. Replacement effects created by interrupts will not yet be
active at this time and are applied according to rule 9.9.10 instead.
- Each replacement effect can only apply once to any single effect.
Once a replacement effect has been applied, even if the new effect it creates (or a new effect created
by a later replacement effect) still includes an occurrence of the effect that gets replaced, the same
replacement effect cannot be applied to that effect again.
Example: The Runner accesses Project Vacheron and its interrupt ability
resolves. The interrupt creates a replacement effect that will override adding the agenda to the
Runner’s score area. The Runner will still steal Project Vacheron, but they will do so by adding it to
their score area with hosted agenda counters. Even though the modified effect still includes adding Project
Vacheron to the Runner’s score area, there is no way for the replacement effect to apply again to its
own results.
- Some interrupts create replacement effects to modify an
instruction that is already imminent. When the interrupt resolves, if the replacement effect can apply
to the expected effects of the imminent instruction, it is applied immediately.
Example: An instruction is imminent with an expected effect of the Corp doing
net damage to the Runner. The Corp uses Tori Hanzō’s ability, creating a replacement effect
replacing net damage with brain damage. The replacement effect applies immediately, so after Tori
Hanzō’s ability resolves, the expected effect is now to do 1 brain damage. When players get
priority again, their interrupts are relevant or not based on the new expected effects.
- If multiple replacement effects would apply to an effect acting
on a targeted card, that card’s controller chooses the order in which the replacement effects
apply. If multiple replacement effects would apply to any other effect, the controller of the base
effect chooses the order in which the replacement effects apply.
- After applying one replacement effect, a subsequent replacement
effect can only be applied if the effect it was to replace is still expected. A replacement effect
cannot apply without something to replace.
Example: The Runner chooses HQ with Security Testing when their turn begins, then
plays Account Siphon. When the run becomes successful, both Security Testing and Account Siphon create replacement effects. When step 6.9.5b of the run becomes
imminent, the Runner must choose to apply either the replacement effect from Security Testing or the one
from Account Siphon. Since neither effect creates a new instance of accessing cards, the effect not chosen
to apply first has nothing to replace and does not apply.
Example: The Runner chooses R&D with Security Testing when their turn begins,
then plays Showing Off. When a run on R&D becomes successful, both Security Testing and Showing Off
create replacement effects. When step
6.9.5b of the run becomes imminent, the Runner must choose to apply
either the replacement effect from Security Testing or the one from Showing Off. If they choose to apply
Security Testing first, Showing Off’s effect has nothing to replace and does not apply. If they choose to apply Showing Off first, the expected effects still include accessing cards
from R&D, albeit not in the usual way. Security Testing can still replace this access, so it
applies next. Either way, the Runner will gain 2[c] and will not access any
cards.
-
Lingering Effects
- Instructions can create LINGERING
EFFECTS that exist beyond their resolution. Once a lingering effect is created, it
exists independently of its source even if the source becomes inactive. Lingering effects remain active
only for the duration specified in the instruction that created them. Lingering effects with durations
that have expired are removed from the game state at step 10.3.1b of each checkpoint.
- Some lingering effects exist only to maintain the existence of another
ability. Delayed conditional abilities are maintained this way and may have an implicit duration. See
section 9.6.13.
- Some lingering effects maintain a choice that a player made while
resolving an ability in order for another ability or effect with the same source object to make use of
that choice.
- If the choice is only referred to by another lingering effect, the
lingering effect maintaining the choice has the same duration as the other lingering effect.
Example: The Runner resolves Pelangi’s paid ability and chooses an ice
subtype. The ability then creates a lingering effect adding the chosen subtype to the encountered ice. Both
the choice of subtype and the effect adding it to the ice expire at the end of the encounter.
- If the abilities linked in this way use the word “this”
in reference to a timing structure, then the reference applies only to the occurrence of that timing
structure in which the choice was made. In this case, the duration of the lingering effect maintaining
the choice expires when that timing structure ends or the source object becomes inactive.
Example: Security Testing’s first ability allows the Runner to choose a
server. Its second ability has the trigger condition, “the first time this turn you make a successful
run on the chosen server”. The reference to “this turn” in this condition indicates that
the choice should be maintained only until the timing structure of the Runner’s turn ends. On future
turns, the previous choice of server will not affect when or whether Security Testing’s second ability
meets its trigger condition, even if a new server is not chosen.
- If the previous cases do not apply, the duration of the lingering
effect expires only when the source object becomes inactive.
Example: Femme Fatale’s first conditional ability directs the Runner to
choose an installed piece of ice. Which ice was chosen is maintained as a lingering effect for as long as
Femme Fatale remains active, and its last ability refers to the object that is being remembered by that
lingering effect.
- If a lingering effect is created with a duration based on a
timing structure that is not in progress at the time the lingering effect is created, the duration
expires immediately, and the lingering effect persists only until the next checkpoint after it is
created.
- Abilities on an icebreaker that
modify their source’s strength have an implicit duration of “for the remainder of the
current encounter”. See rule
3.9.5b.
- Only lingering effects have durations. An ability that modifies