[Fixed] Bug Archive

[Gargaroz]

Fixed.

[Gargaroz]

Fixed.

[Gargaroz]

A question : that values are resetted at what step ? After the EVENT_DEAL_DAMAGE ?
Should I insert that code in "add/remove_1_1_counter/conters" or it should be done only if it's happening in the damage step ?

[Gargaroz]

Bad values in "ct_all". Fixed.

[Gargaroz]

Fixed.

[Gargaroz]

Well, the "lose_the_game" function was recently improved thanx to Korath, and I've incorporated all the possible modifications, so this should be fixed now.

[Gargaroz]

Fixed.

[Gargaroz]

Prolly due to the "is_enchanted" function. It should be fixed now.

[Aswan jaguar]

There is a misunderstanding in some cases reported above as Abyssal Prosecutor can't let YOU win a game or opponents LOSE a game,so opponents can win a game through any card saying so or any other MTG way.

[Korath]

Whenever counter_power or counter_toughness change, but at minimum in the changes in counters.c (since they're called most frequently): true_add_1_1_counters(), remove_1_1_counter(), true_add_minus1_minus1_counters(), remove_minus1_minus1_counter(), and remove_all_counters().

[Gargaroz]

I'll do it.

[Korath]

I misread your first question, sorry.

Once 0x2000000 in card_instance_t::regen_status is set, the next call to get_abilities(player, card, EVENT_TOUGHNESS, anything) is called, it will do a full recalculation of that card's toughness.

After EVENT_DEAL_DAMAGE is sent, there's a TRIGGER_DEAL_DAMAGE; then all damage cards are removed; then each in-play creature card is checked to see whether damage_on_card is >= get_abilities(player, card, EVENT_TOUGHNESS, -1). That will be the first call to get_abilities after EVENT_DEAL_DAMAGE unless something responding to TRIGGER_DEAL_DAMAGE checks it.

Both the recalculate-power and recalculate-toughness bits are set (along with others; the bitfield used is 0x1F000000) after combat ends. The exact sequence is a TRIGGER_END_COMBAT to everything; STATE_ATTACKING/STATE_BLOCKING replaced with STATE_ATTACKED/STATE_BLOCKED on all cards; on all cards that have STATE_IN_PLAY set but not STATE_OUBLIETTED, regen_status |= 0x1F000000, then get_abilities(..., EVENT_SET_COLOR, -1) and get_abilities(..., EVENT_CHANGE_TYPE, -1); a whole lot of unknown globals are set; and then all in-play cards get a get_abilities(..., EVENT_TOUGHNESS, -1) and get_abilities(..., EVENT_POWER, -1) calls. The check to destroy cards with toughness <= 0 is also done within get_abilities(..., EVENT_TOUGHNESS, ...) if toughness is recalculated.

[HarlequinCasts]

Describe the Bug:
Reflecting Pool can not produce the correct mana with a vivid land in play. (Vivid Creek and Vivid Crag in example)

Also the screenshot shows it is not correctly showing mana that Exotic Orchard could produce.

Which card did behave improperly ?
Reflecting Pool

Which update are you using?(date,name)Which type(Duel,Gauntlet,Sealed Deck)
PWNMv2

What exactly should be the correct behavior/interaction ?
Reflecting Pool should be able to produce WUBRG with any vivid land in play, even a vivid land without any tokens.
Reflecting Pool should be able to produce any color mana that Exotic Orchard can currently produce.

Are any other cards possibly affected by this bug ?
Uncertain, but the vivid lands it should be aware of are:
Vivid Crag
Vivid Creek
Vivid Grove
Vivid Marsh
Vivid Meadow
and
Exotic Orchard

[Korath]

It'll also produce if you control no other lands. Last ruling here says it should be tappable but produce no mana. All the issues here affect Sylvok Explorer too.

(defective) diff | Open

Code: Select all

diff --git a/src/functions/functions.c b/src/functions/functions.c
index 7ffdc88..e8078a1 100644
--- a/src/functions/functions.c
+++ b/src/functions/functions.c
@@ -657,8 +657,8 @@ int get_color_of_mana_produced_by_id(int id, int hard_coded_color, int player){
         int color = 0;
         while(count < active_cards_count[player] && color < 62 ){
                                card_data_t* card_d = get_card_data(player, count);
-                               if((card_d->type & TYPE_LAND) && in_play(player, count)){
-                                       color |= card_d->color;
+                               if((card_d->type & TYPE_LAND) && in_play(player, count) && card_d->id != CARD_ID_REFLECTING_POOL){
+                                       color |= get_card_instance(player, count)->mana_color;
                                }
                                count++;
         }
@@ -737,8 +737,8 @@ int get_color_of_mana_produced_by_id2(int id, int hard_coded_color, int player){
         int color = 0;
         while(count < active_cards_count[player] && color < 62 ){
                                card_data_t* card_d = get_card_data(player, count);
-                               if((card_d->type & TYPE_LAND) && in_play(player, count)){
-                                       color |= card_d->color;
+                               if((card_d->type & TYPE_LAND) && in_play(player, count) && card_d->id != CARD_ID_REFLECTING_POOL){
+                                       color |= get_card_instance(player, count)->mana_color;
                                }
                                count++;
         }


almost fixes it. (The exe uses card_instance_t::mana_color, not card_data_t::color, to draw the mana stripes, and that's what I use here; and if reflecting pool's id isn't excluded, it'll still produce colorless without non-reflecting-pool lands present.)

I'm still seeing two bugs with this:

• Activating a Reflecting Pool that can't produce any mana types doesn't tap it.
• When the last counter is removed from a Vivid Crag, Reflecting Pools aren't updated to lose the extra colors until the end of the phase. Not just a display issue, either; I can still tap it for any color mana.

[HarlequinCasts]

It'll also produce if you control no other lands. Last ruling here says it should be tappable but produce no mana.

Good catch. I also am not certain how Reflecting Pool would work with Just a Mishra's Workshop in play...