From ab38576a2665cf239d4c87ce05187b1cc5bc5e70 Mon Sep 17 00:00:00 2001 From: rubenpieters Date: Thu, 14 Sep 2023 19:35:57 +0200 Subject: [PATCH] prepare for next version --- data/input/00_changelog.yaml | 14 +------------- data/input/01_game_concepts.yaml | 3 --- data/input/02_parts_of_a_card.yaml | 10 +++++----- data/input/04_game_zones.yaml | 1 - data/input/05_turns.yaml | 1 - data/input/08_card_manipulation.yaml | 6 +----- data/input/09_abilities.yaml | 19 ++++--------------- data/input/10_additional_rules.yaml | 21 ++------------------- rules_doc_generator/__main__.py | 4 ++-- 9 files changed, 15 insertions(+), 64 deletions(-) diff --git a/data/input/00_changelog.yaml b/data/input/00_changelog.yaml index 9055b6f..35ccc89 100644 --- a/data/input/00_changelog.yaml +++ b/data/input/00_changelog.yaml @@ -1,14 +1,2 @@ changelog: -- text: Added {ref:rule_game_numbers} to clarify that by default, values can be negative numbers, but cannot be non-integer numbers. -- text: Added {ref:rule_threat_level} and {ref:rule_threat_flag} to define threat levels and the "threat N" ability flag. -- text: Updated list of subtypes ({ref:rule_subtypes_list}) to add {subtype:expendable} and expand {subtype:enforcer} and {subtype:clone} to new card types. -- text: Added {ref:rule_host_server} to clarify the meaning of "this server" on {subtype:trojans}. -- text: Added {ref:rule_finish_action_trigger_condition} to codify trigger conditions related to an action ending. -- text: Added {ref:rule_optional_drawing_simultaneously} to clarify the procedure for the card draw ability on {card:Umbrella}. -- text: Updated {ref:rule_swap_become_installed} to clarify the nature of installations performed as part of a swap, and added {ref:rule_swap_installed_cards_preserves_hosting} to clarify what happens to hosted objects when two already-installed cards are swapped. -- text: Added {ref:rule_instruction_link} to better highlight the importance of the concept of "instructions" and define "imminent" and "resolving" as statuses an instruction can have. -- text: Added {ref:rule_is_resolving} to clarify when an ability or event "is resolving". -- text: Added {ref:rule_references_to_trigger_conditions} to better codify the meaning of "'when encountered' abilities" and similar cases. -- text: Moved rules for Infinite Loops into {ref:sec_additional_general} pending future revisions. -- text: Added rules for bidding procedures in general ({ref:sec_bidding}) and the Psi Game keyword in particular ({ref:sec_psi_games}). -- text: Switched "yes" and "no" branches of the action windows to improve readability of the timing structure reference ({ref:sec_appendix_timing_structure_corps_turn,sec_appendix_timing_structure_runners_turn}). +- \ No newline at end of file diff --git a/data/input/01_game_concepts.yaml b/data/input/01_game_concepts.yaml index fc4103b..c9fb30a 100644 --- a/data/input/01_game_concepts.yaml +++ b/data/input/01_game_concepts.yaml @@ -13,7 +13,6 @@ sections: text: |- Each player needs a legal deck, an identity card for their role, and any extra cards used from outside their deck. They also need a supply of tokens as described in {ref:sec_counters_and_tokens}. The constraints that define the legality of a deck are defined in {ref:sec_deck_construction}, and the cases where cards outside the deck and identity can be used are defined in {ref:sec_extra_cards}. - rule: rule_game_numbers - new: text: All numbers used in the game are integers. Unless otherwise stated, a given value can be positive, negative, or zero. - section: sec_golden_rules text: Golden Rules @@ -726,10 +725,8 @@ sections: text: The sum of all agenda points on agendas in a player's score area is that player's {term:score}. rules: - rule: rule_threat_level - new: text: The {term:threat level} is equal to the greatest score of any player. The "Threat N" ability flag makes use of the threat level ({ref:rule_threat_flag}). examples: - - new: text: If the Runner's score is 4 agenda points, and the Corp's score is 3 agenda points, the threat level is 4. - rule: rule_game_win text: If at any time a player's score is greater than or equal to 7, they win the game at the next checkpoint. See {ref:sec_ending_the_game} regarding winning the game, and {ref:sec_checkpoints} for details about checkpoints. diff --git a/data/input/02_parts_of_a_card.yaml b/data/input/02_parts_of_a_card.yaml index 0549d9d..7f92de2 100644 --- a/data/input/02_parts_of_a_card.yaml +++ b/data/input/02_parts_of_a_card.yaml @@ -209,15 +209,15 @@ sections: - rule: rule_identity_subtypes text: The identity subtypes are Bioroid, Clone, Corp, Cyborg, Digital, Division, G-mod, Megacorp, Natural, Police Department, Stealth, and Subsidiary. - rule: rule_agenda_subtypes - text: The agenda subtypes are Ambush, Expansion, {n}Expendable,{/n} Initiative, NEXT, Psi, Public, Research, Security, Sensie, and Source. + text: The agenda subtypes are Ambush, Expansion, Expendable, Initiative, NEXT, Psi, Public, Research, Security, Sensie, and Source. - rule: rule_asset_subtypes - text: The asset subtypes are Academic, Advertisement, Alliance, Ambush, Beanstalk, Bioroid, Cast, Character, Clone, Corporation, {n}Enforcer,{/n} Executive, Facility, Government, Hostile, Illicit, Industrial, Political, Psi, Region, Research, Ritzy, Seedy, and Transaction. + text: The asset subtypes are Academic, Advertisement, Alliance, Ambush, Beanstalk, Bioroid, Cast, Character, Clone, Corporation, Enforcer, Executive, Facility, Government, Hostile, Illicit, Industrial, Political, Psi, Region, Research, Ritzy, Seedy, and Transaction. - rule: rule_ice_subtypes - text: The ice subtypes are AP, Advertisement, Ambush, Barrier, Bioroid, Code Gate, Deflector, Destroyer, {n}Expendable,{/n} Grail, Harmonic, Illicit, Morph, Mythic, NEXT, Observer, Psi, Sentry, Tracer, and Trap. + text: The ice subtypes are AP, Advertisement, Ambush, Barrier, Bioroid, Code Gate, Deflector, Destroyer, Expendable, Grail, Harmonic, Illicit, Morph, Mythic, NEXT, Observer, Psi, Sentry, Tracer, and Trap. - rule: rule_operation_subtypes text: The operation subtypes are Alliance, Black Ops, Condition, Current, Double, Gray Ops, Illicit, Lockdown, Psi, Reprisal, Terminal, Transaction, and Triple. - rule: rule_upgrade_subtypes - text: The upgrade subtypes are Advertisement, Alliance, Ambush, Beanstalk, Bioroid, Character, Clone, Enforcer, Executive, {n}Expendable,{/n} Facility, Hostile, Off-site, Orgcrime, Psi, Region, Ritzy, Seedy, Security Protocol, Sysop, and Unorthodox. + text: The upgrade subtypes are Advertisement, Alliance, Ambush, Beanstalk, Bioroid, Character, Clone, Enforcer, Executive, Expendable, Facility, Hostile, Off-site, Orgcrime, Psi, Region, Ritzy, Seedy, Security Protocol, Sysop, and Unorthodox. - rule: rule_event_subtypes text: The event subtypes are Condition, Current, Double, Job, Mod, Orgcrime, Priority, Run, Sabotage, Stealth, and Terminal. - rule: rule_hardware_subtypes @@ -225,7 +225,7 @@ sections: - rule: rule_program_subtypes text: The program subtypes are AI, Caïssa, Cloud, Daemon, Decoder, Deep Net, Deva, Fracter, Icebreaker, Killer, Stealth, Trojan, Virus, and Weapon. - rule: rule_resource_subtypes - text: The resource subtypes are Clan, {n}Clone,{/n} Companion, Connection, Directive, Genetics, Government, Job, Link, Location, Remote, Ritzy, Sabotage, Seedy, Source, Stealth, and Virtual. + text: The resource subtypes are Clan, Clone, Companion, Connection, Directive, Genetics, Government, Job, Link, Location, Remote, Ritzy, Sabotage, Seedy, Source, Stealth, and Virtual. - section: sec_text_box text: Text Box diff --git a/data/input/04_game_zones.yaml b/data/input/04_game_zones.yaml index 1d2bca7..550a4b1 100644 --- a/data/input/04_game_zones.yaml +++ b/data/input/04_game_zones.yaml @@ -241,7 +241,6 @@ sections: - rule: rule_another_server text: If an ability on a card currently or previously located in a server, its root, or protecting it refers to "another server", this means any server except "this server" as interpreted by {ref:rule_this_server}. If a card's abilities involve choosing a server, "another server" in a linked ability means any server except the chosen server. If neither of the previous cases apply and a run is in progress, "another server" means any server except the attacked server. - rule: rule_host_server - new: text: If an ability on an object uses the phrase "this server", and that object is hosted on another object (see {ref:sec_host}), the server referred to is the server of the host object. - subsection: subsec_central_servers diff --git a/data/input/05_turns.yaml b/data/input/05_turns.yaml index c6b17cf..e2c1216 100644 --- a/data/input/05_turns.yaml +++ b/data/input/05_turns.yaml @@ -48,7 +48,6 @@ sections: - rule: rule_action_conditional_ability_trigger text: A conditional ability that meets its trigger condition due to a player taking an action resolves after the action's trigger cost is paid, before the effects of the action itself. See {ref:rule_chain_reaction}. - rule: rule_finish_action_trigger_condition - new: text: Some conditional abilities meet their trigger conditions due to an action "ending", "finishing", or "completing". These abilities resolve in the reaction window following {ref:step_corp_turn_action} or {ref:step_runner_turn_action}, for actions taken by the Corp and Runner, respectively. - rule: rule_basic_actions text: Each player has several basic actions they can always perform. The Corp's basic actions are listed in {ref:rule_corp_actions}, and the Runner's basic actions are listed in {ref:rule_runner_actions}. diff --git a/data/input/08_card_manipulation.yaml b/data/input/08_card_manipulation.yaml index 46d8dc6..719d1b9 100644 --- a/data/input/08_card_manipulation.yaml +++ b/data/input/08_card_manipulation.yaml @@ -165,7 +165,6 @@ sections: text: 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. rules: - rule: rule_optional_drawing_simultaneously - new: text: If an ability gives multiple players the option to draw cards at the same time, first each player indicates whether or how many cards they will draw, starting with the active player. Then the indicated draws are performed simultaneously. - subsection: sec_steps_of_drawing_n_cards @@ -399,10 +398,8 @@ sections: text: 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. rules: - rule: rule_swap_installed_cards_preserves_hosting - new: text: When swapping installed cards, any cards or counters hosted on either of the swapped cards maintain their hosting relationships. examples: - - new: text: The Corp uses {card:Thimblerig}'s ability to swap it with a {card:Palisade} hosting {card:Botulus}. The {card:Botulus} remains hosted on the {card:Palisade} throughout this process. - subsection: rule_swap_simultaneous @@ -412,9 +409,8 @@ sections: text: 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. - rule: rule_swap_become_installed text: |- - 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). {n}The normal procedure for installing a card is not followed, so no install cost is paid and like cards cannot be trashed. At the next checkpoint after the swap takes place, trigger conditions related to uninstalling or installing the two cards are met, respectively.{/n} + 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). The normal procedure for installing a card is not followed, so no install cost is paid and like cards cannot be trashed. At the next checkpoint after the swap takes place, trigger conditions related to uninstalling or installing the two cards are met, respectively. examples: - - new: text: |- The Corp is playing {card:A Teia: IP Recovery} and has {card:Tatu-Bola} protecting a remote server. The Runner runs that server and passes {card:Tatu-Bola}. The Corp swaps it with a piece of ice from HQ. After the swap, the Corp can use {card:A Teia}'s ability to install a card in the root of another remote server. They then continue resolving the next instruction of {card:Tatu-Bola}'s ability, gaining 4[c]. - rule: rule_swap_score_areas diff --git a/data/input/09_abilities.yaml b/data/input/09_abilities.yaml index 226891d..f54c8ae 100644 --- a/data/input/09_abilities.yaml +++ b/data/input/09_abilities.yaml @@ -20,7 +20,6 @@ sections: - rule: rule_interrupt_link text: 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 {ref:sec_interrupts_replacements}. - rule: rule_instruction_link - new: text: Each non-static ability contains one or more {term:instructions} that make up the ability's component steps. {ref:Rule_instruction} describes the nature and function of instructions in an ability's text. An instruction that the game is presently concerned with can be either {term:imminent} or {term:resolving}. - subsection: rule_resolve_ability @@ -31,14 +30,11 @@ sections: examples: - text: The Runner's identity is {card:Armand "Geist" Walker}. They access a {card:Snare!} from R&D with only 2 cards in their grip. Before taking a tag or suffering any net damage, the Runner triggers {card:Decoy}'s ability in order to avoid the tag. Using the {card:Decoy} meets the trigger condition of {card:Geist}'s ability. As this is the most recent ability to meet its trigger condition, {card:Geist}'s ability must resolve first, before {card:Decoy} avoids the tag and before {card:Snare!} finishes resolving. The Runner draws a card from {card:Geist}, avoids the tag from {card:Snare!} with {card:Decoy}, and then finally suffers (and survives) the 3 net damage from {card:Snare!}. - rule: rule_is_resolving - new: text: An ability "is resolving" from when its first instruction becomes imminent until its last instruction has finished resolving. See also {ref:sec_interrupts_replacements}. An event or operation "is resolving" throughout {ref:rule_steps_playing_resolve_play_abilities} of playing that event or operation. examples: - - new: - text: |- + - text: |- The Corp resolves a subroutine on {card:Attini} while its first ability is active. The subroutine is resolving during the interrupt window for its instruction, so the Runner cannot spend credits during that window and will not be able to use {card:Caldera}'s ability to prevent net damage. - - new: - text: |- + - text: |- The Runner is playing {card:Zahya Sadeghi: Versatile Smuggler} and plays {card:Direct Access} to run HQ. The static ability on {card:Direct Access} removes {card:Zahya Sadeghi}'s ability whie it is resolving. Normally, that ability would meet its trigger condition and resolve immediately after the "Run any server." instruction. This reaction window is outside of the run, but it is still part of {card:Direct Access} resolving, so the ability is not present at the needed time and cannot be triggered or resolved. @@ -299,7 +295,7 @@ sections: rules: - rule: rule_ability_flag_types text: |- - There are {n}five{/n} ability flags: access, interface, [interrupt], persistent, {n}and threat N{/n}. + There are five ability flags: access, interface, [interrupt], persistent, and threat N. - rule: rule_access_flag text: 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 {ref:step_mid_access_ability} of accessing a card. See {ref:rule_mid_access_window}. - rule: rule_interface_flag @@ -309,7 +305,6 @@ sections: - rule: rule_persistent_flag text: 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 {ref:subsec_persistent}. - rule: rule_threat_flag - new: text: The "threat N" flag can appear on any type of ability. Abilities with this flag are only active if the threat level is greater than or equal to N, regardless of {ref:rule_ability_active_inactive_source_card}. See {ref:rule_threat_level}. - subsection: rule_ability_classification @@ -515,26 +510,20 @@ sections: {card:Joshua B}'s ability allows the Runner to gain [click]. If they do, it creates a delayed conditional ability that is independent of {card: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. - subsection: rule_references_to_trigger_conditions - new: text: |- Some cards refer to a class of conditional abilities according to their trigger condition. rules: - rule: rule_when_encountered - new: text: A "when encountered" ability is any ability that could meet its trigger condition at {ref:step_encounter_begins} of an encounter with its source. - rule: rule_when_installed - new: text: A "when installed" ability is any ability that could meet its trigger condition at {ref:rule_steps_installing_installed_condition} of the process of installing its source. - rule: rule_when_scored - new: text: A "when scored" ability is any ability on an agenda that could meet its trigger condition as a result of the Corp choosing the option to score that agenda during a paid ability window (see {ref:rule_paid_ability_window_corp_score}). - rule: rule_instructed_to_resolve_conditional_ability - new: text: |- If an effect attempts to resolve a conditional ability according to one of the classes identified in {ref:rule_references_to_trigger_conditions}, the ability is marked pending as though the stipulation of that class had occurred. Any additional requirements of the trigger condition in question must still be met by the game state. examples: - - new: - text: The Corp has scored {card:AstroScript Pilot Program} and {card:Market Research}. They forfeit one of those agendas to play {card:24/7 News Cycle} and resolve the "when scored" ability of the other agenda, even though neither agenda was actually scored at this time. The Corp can forfeit {card:Market Research} to resolve {card:AstroScript Pilot Program}'s ability and put an agenda counter on it, with no other stipulations. If the Runner is tagged, the Corp could instead forfeit {card:AstroScript Pilot Program} to put an agenda counter on {card:Market Research}. However, if the Runner is not tagged, the additional requirement of {card:Market Research}'s trigger condition will not be met, so its "when scored" ability cannot become pending or resolve. + - text: The Corp has scored {card:AstroScript Pilot Program} and {card:Market Research}. They forfeit one of those agendas to play {card:24/7 News Cycle} and resolve the "when scored" ability of the other agenda, even though neither agenda was actually scored at this time. The Corp can forfeit {card:Market Research} to resolve {card:AstroScript Pilot Program}'s ability and put an agenda counter on it, with no other stipulations. If the Runner is tagged, the Corp could instead forfeit {card:AstroScript Pilot Program} to put an agenda counter on {card:Market Research}. However, if the Runner is not tagged, the additional requirement of {card:Market Research}'s trigger condition will not be met, so its "when scored" ability cannot become pending or resolve. - subsection: sec_steps_of_triggering_and_resolving_a_conditional_ability text: Steps of Triggering and Resolving a Conditional Ability diff --git a/data/input/10_additional_rules.yaml b/data/input/10_additional_rules.yaml index cd0a523..7d611fe 100644 --- a/data/input/10_additional_rules.yaml +++ b/data/input/10_additional_rules.yaml @@ -28,7 +28,6 @@ sections: {card:Boomerang}'s text refers to "a copy of Boomerang". This is not self-referential language and refers to any card named {card:Boomerang}. - subsection: sec_infinite_loops - new: toc: text: Infinite Loops rules: @@ -339,54 +338,38 @@ sections: The Runner uses {card:Chastushka}'s ability to sabotage 4. The Corp has 2 cards in HQ and 1 card in R&D. The Corp must trash all cards from HQ and R&D. - section: sec_bidding - new: text: Bidding rules: - rule: rule_bidding - new: text: A {term:bid} is a number of credits that a player secretly chooses to spend as part of resolving an ability. Some effects instruct only a single player to bid, while other effects require both players to bid simultaneously. - rule: rule_bid_secret - new: text: Players select their bids in secret. This can be accomplished by writing down a number, by hiding a number of credit counters in a closed fist, or by any other unambiguous method. - rule: rule_bid_possible - new: text: A player cannot bid a number of credits they are unable to spend. Players can always bid 0[c]. examples: - - new: - text: The Runner has no credits in their credit pool and 1 credit hosted on {card:Fencer Fueno} when they make a successful run on a server with {card:Adrian Seis} rezzed in its root. When the ability on {card:Adrian Seis} resolves, the players play a Psi Game, which requires them both to bid 0, 1, or 2[c]. In this case, the Runner cannot bid 2[c], as they are not able to spend that number of credits. They can, however, bid 1[c], as they will be able to spend the credit from {card:Fencer Fueno} to pay for that bid. - - new: - text: The Runner encounters {card:RSVP} and its subroutine resolves. Later in that run, they are required to bid credits by another ability. Since the effect of {card:RSVP}'s subroutine prohibits the Runner from spending credits, they must bid 0[c]. + - text: The Runner has no credits in their credit pool and 1 credit hosted on {card:Fencer Fueno} when they make a successful run on a server with {card:Adrian Seis} rezzed in its root. When the ability on {card:Adrian Seis} resolves, the players play a Psi Game, which requires them both to bid 0, 1, or 2[c]. In this case, the Runner cannot bid 2[c], as they are not able to spend that number of credits. They can, however, bid 1[c], as they will be able to spend the credit from {card:Fencer Fueno} to pay for that bid. + - text: The Runner encounters {card:RSVP} and its subroutine resolves. Later in that run, they are required to bid credits by another ability. Since the effect of {card:RSVP}'s subroutine prohibits the Runner from spending credits, they must bid 0[c]. - subsection: rule_bid_reveal_spend - new: text: After all bids are selected, the ability that called for the bids continues resolving. Players will later be instructed to reveal their bids. Each player must spend a number of credits equal to their bid as soon as the bid is revealed. rules: - rule: rule_bid_spent_immediately - new: text: Spending credits for a revealed bid is not a conditional ability and does not wait for a checkpoint or priority window after revealing the number of credits bid. - rule: rule_bid_is_cost - new: text: Spending credits for a bid counts as paying a nested cost. See {ref:sec_costs}. - rule: rule_bid_payment_choices - new: text: If both players are bidding and a player has multiple sources of credits available from which to pay for their bid (see {ref:rule_spend_credits}), that player chooses how to pay after learning the number of credits their opponent bid. If both players have multiple ways to pay for their bids, first the active player chooses how to pay, then the inactive player chooses how to pay. In either circumstance, the credits are spent simultaneously. - rule: rule_bid_secretly_spend - new: text: Some older cards direct players to "secretly spend credits" without reference to bidding. These abilities still follow the rules for bidding. Trigger conditions based on players "secretly spending credits" or "revealing secretly spent credits" are met at the next checkpoint after bids are revealed and paid for. - subsection: sec_psi_games toc: - new: text: Psi Games rules: - rule: rule_psi_game - new: text: A {term:Psi Game} is a bidding contest in which the outcome depends on whether the number of credits each player bid was the same or different. The instruction "Play a Psi Game." encompasses both bidding and revealing bids. - rule: rule_psi_bid_options - new: text: When playing a Psi Game, each player can bid 0[c], 1[c], or 2[c]. - rule: rule_psi_bid_reveal - new: text: Playing a Psi Game is handled as a single instruction. After both players have selected a bid for a Psi Game, they immediately proceed to reveal and spend their bids. There are no checkpoints during this process until after both players have paid for their bids. - rule: rule_psi_outcome - new: text: In an ability that calls for a Psi Game, subsequent instructions will depend on the outcome of the Psi Game. The condition "if the bids match" is satisfied if the Corp and Runner bid the same number of credits. The condition "if the bids differ" is satisfied if the Corp and Runner did not bid the same number of credits. diff --git a/rules_doc_generator/__main__.py b/rules_doc_generator/__main__.py index af00c69..f3eb426 100644 --- a/rules_doc_generator/__main__.py +++ b/rules_doc_generator/__main__.py @@ -11,8 +11,8 @@ parser = ArgumentParser() parser.add_argument("-a", "--annotated", default=False, help="Also generate annotated version with highlights of new parts", action="store_true") parser.add_argument("-y", "--year", default="2023", help="Effective year", action="store") -parser.add_argument("-m", "--month", default="08", help="Effective month", action="store") -parser.add_argument("-d", "--day", default="07", help="Effective day", action="store") +parser.add_argument("-m", "--month", default="XX", help="Effective month", action="store") +parser.add_argument("-d", "--day", default="XX", help="Effective day", action="store") args = parser.parse_args() config = Config(args.annotated, args.year, args.month, args.day)