Collectible Card Game Headquarters

Describe the Bug:
Protection prevents unpreventable damage.

Which update are you using? (date, name)Which type? (duel, gauntlet, sealed deck)
dev 913cddcc6.

What exactly should be the correct behavior/interaction?
Reminder text currently on e.g. Black Knight ("Protection from white (This creature can't be blocked, targeted, dealt damage, or enchanted by anything white.)" in case it goes away, as it's wont to do) implies this behavior is correct. However, the comprehensive rules are explicit that protection is a damage prevention effect, not a separate kind of replacement effect:
702.16e Any damage that would be dealt by sources that have the stated quality to a permanent or player with protection is prevented.

Are any other cards possibly affected by this bug?
My base testcase was Silver Knight and Pyroclasm. I tested with Flaring Pain, Skullcrack, and Excruciator (and tried to with Whippoorwill), which should be fairly representative. (There isn't an untargeted "This deals [some] damage to each [something]. The damage can't be prevented." analogous to Pinpoint Avalanche to test with; getting a targeted one to deal its damage to a protected creature instead is certainly possible, but inconvenient enough that I didn't bother.) There's a bunch more individual damage-preventing cards listed in this bug, though that's pretty outdated by now.

I tested non-color protections even less thoroughly; only the single case of Baneslayer Angel, Skullcrack, and Scourge of Kher Ridges. Still no joy.

Fixed locally for the general case. Baneslayer will probably have to wait until misc. protection (which I think depends on card_instance_t->aux, right?)

Nope, you'd just need to track down two free bits somewhere, if you use something similar to the Shandalar implementation. (Though it can't handle things that copy protection like Rayami, First of the Fallen, and can break in rare cases combining grants of multiple types of protection and loss of abilities. So you may want to think about other ways of implenting it.)

The problem with arbitrary protection is that validate_target_impl(), when called from Magic.exe (via real_validate_target()), doesn't have parameters for the targeting source - it just merges in illegal keywords from get_protections_from(). The good news is that there's only a few calls left, from:
card_blaze_of_glory()
card_bronze_tablet()
card_detonate()
card_fireball()
card_spell_blast()
card_sword_dancer()
card_winter_blast()
damage_creature_or_player()

Everything but Bronze Tablet and Fireball look easy to reimplement, if not necessarily idiomatically. In particular, card_blaze_of_glory() is trivial; all the really complex hackery goes on in the effect card it creates.
Actually, no, there's a hack in it to retrieve the player/card pair given to get_protections_from(). So, really, there's nothing stopping you from going through each subrule of 702.16 programming them as written.

(Do I want to ask how come your sig looks like spam?)

Nope, you'd just need to track down two free bits somewhere, if you use something similar to the Shandalar implementation. (Though it can't handle things that copy protection like Rayami, First of the Fallen, and can break in rare cases combining grants of multiple types of protection and loss of abilities. So you may want to think about other ways of implenting it.)

Cool, I'll try to put it together after the can_autotap()/Bazaar of Baghdad bug. I've looked into doing misc protection a few times and haven't figured it out, so I might need your help.

(Do I want to ask how come your sig looks like spam?)

Ugh... looks like I was hacked. Site mods messaged & logs checked.

Fixed in 2ce322b and f900813