It is currently 07 Jul 2021, 11:57
   
Text Size

Shandalar - Program Bugs

Shrine of Piercing Vision effect doesn't work (fix completed)

 

It doesn't see like Shrine of Piercing Vision 's tap effect works. It does gain counters at your upkeep and when you cast a blue spell from what I can tell, but no matter how many counters it has, it just goes straight to the graveyard without showing me the top X cards in my library, let alone let me pick one.
Attachments
bug.png

Comments

Posted by Korath » 16 Mar 2016, 00:43

count_counters() returns 0 if the card it's counting counters on isn't on the battlefield anymore. So Shrine of Piercing Vision - which sacrifices itself as a cost to activate - always "has 0" when it resolves.

The general rule for this is to look at the information for the card as it was last on the battlefield (except during target validation and static abilities):
relevant comprehensive rules | Open
112.7a Once activated or triggered, an ability exists on the stack independently of its source. Destruction or removal of the source after that time won't affect the ability. Note that some abilities cause a source to do something (for example, "Prodigal Pyromancer deals 1 damage to target creature or player") rather than the ability doing anything directly. In these cases, any activated or triggered ability that references information about the source because the effect needs to be divided checks that information when the ability is put onto the stack. Otherwise, it will check that information when it resolves. In both instances, if the source is no longer in the zone it's expected to be in at that time, its last known information is used. The source can still perform the action even though it no longer exists.

114.8b An object that looks for a "[spell or ability] that targets [something]" checks the current state of that spell or ability's targets. If an object it targets is still in the zone it's expected to be in or a player it targets is still in the game, that target's current information is used, even if it's not currently legal for that spell or ability. If an object it targets is no longer in the zone it's expected to be in or a player it targets is no longer in the game, that target is ignored; its last known information is not used.

604.7. Unlike spells and other kinds of abilities, static abilities can't use an object's last known information for purposes of determining how their effects are applied.

608.2b If the spell or ability specifies targets, it checks whether the targets are still legal. A target that's no longer in the zone it was in when it was targeted is illegal. Other changes to the game state may cause a target to no longer be legal; for example, its characteristics may have changed or an effect may have changed the text of the spell. If the source of an ability has left the zone it was in, its last known information is used during this process. The spell or ability is countered if all its targets, for every instance of the word "target," are now illegal. If the spell or ability is not countered, it will resolve normally. Illegal targets, if any, won't be affected by parts of a resolving spell's effect for which they're illegal. Other parts of the effect for which those targets are not illegal may still affect them. If the spell or ability creates any continuous effects that affect game rules (see rule 613.10), those effects don't apply to illegal targets. If part of the effect requires information about an illegal target, it fails to determine any such information. Any part of the effect that requires that information won't happen.

608.2g If an effect requires information from the game (such as the number of creatures on the battlefield), the answer is determined only once, when the effect is applied. If the effect requires information from a specific object, including the source of the ability itself or a target that's become illegal, the effect uses the current information of that object if it's in the public zone it was expected to be in; if it's no longer in that zone, or if the effect has moved it from a public zone to a hidden zone, the effect uses the object's last known information. See rule 112.7a. If an ability states that an object does something, it's the object as it exists - or as it most recently existed - that does it, not the ability.


Why I made it so counting counters for cards no-longer-in-play fail, I don't remember. It was deliberate, since there's a separate had_count_counters() function that gives the right number anyway. I'd really rather figure that out, then just make count_counters() do the right thing, than either kick the can down the road by making this call had_count_counters() or just make count_counters() do what had_count_counters() currently does without checking.

Posted by Korath » 16 Mar 2016, 01:01

OK, had_count_counters() was introduced at a later point, since I'd found a card that was failing similarly to this one and presumably just trusted - as I did above - that count_counters() was checking if a card had left the battlefield for good reason.

The bug here was introduced in commit 4bb2eb20, which is intended to find the proper card to count counters for if it was given a {player,card} pair for a card that had changed control. (Internally, change of control obliterates a card, then creates a new identical one for the other player; this causes numerous problems, like making cards' artwork variation change when control does, or making most activated effects in Manalink affect the card's underlying controller as "you" rather than the controller of the ability when an instant-speed change-of-control effect resolves while an ability is on the stack.)

Tracking {player,card} references across a change-of-control like that had previously only been possible if the ref was stored in an active card or effect's targets[] array, damage source, attachment field, or effect source. The initial version of making this possible for arbitrary player/card pairs could track them, but couldn't tell whether it needed to except by checking to see if the player/card it's checking was still in play or not; and apparently some of its early uses - including in the counter functions - didn't get updated.

Posted by Korath » 20 Mar 2016, 06:23

commit a2dd056b203de0f57ceb54925c66908ac4697c77
Author: Korath <dgk@Dirge.none>
Date: Sun Mar 20 02:22:48 2016 -0400

[AS] FIX #1044: counter-counting functions don't check in_play()

This was an artifact of the first version of card_aux_t::became_player and
became_card introduced in commit 4bb2eb20e30af86a294ca0a991fcdaa736cc8214,
imperfectly removed in commit 343da3ccd0bf1af8c1c6bfc089cc1d584e4f9dd5 with the
follow_control() interface, and then worsened when I didn't remember why it was
there in commits 3daaad32949e44aa390eb8dc2d5f78882a9d86fa (when I made when-
this-dies effect cards exempt) and 489f29bb92753cd4a7c07b520e83bc025660bc13
(when I added had_count_counters() for cards that I'd noticed were breaking).

Adding, removing, or moving counters still has no effect on cards no longer on
the battlefield.

Ticket details

  • Ticket ID: 1044
  • Project: Shandalar
  • Status: Fix completed
  • Component: Individual Card
  • Project version: Abandoned Shrine 1
  • Priority: Normal
  • Severity: Normal
  • Assigned to: Korath
  • Reported by: TheKillerNacho
  • Reporter's tickets: List all tickets
  • Reported on: 09 Mar 2016, 16:55
  • Last visited by Korath » 20 Mar 2016, 08:17.
 

Login Form