Collectible Card Game Headquarters

Describe the Bug:
Manaforge Cinder taps when you activate it. fixed

Which card did behave improperly?
Manaforge Cinder

Which update are you using? (date, name)Which type? (duel, gauntlet, sealed deck)
Manalink 2016/08/27: Eldritch Moon v2, duel

What exactly should be the correct behavior/interaction?
Manaforge Cinder doesn't tap when you activate it.

Are any other cards possibly affected by this bug?
-

Fixed in commit 7992607 ("Manaforge Cinder fix taps when activated.", 2021-01-08).

I tried to improve EVENT_COUNT_MANA for this but I tried every possible method and didn't work for both colors of mana. Is there some conflict or there is a need for a new declare_mana_available_...()function?
I have commented out what I think should have worked but doesn't and instead declared only black mana available.
Current code:

Code: Select all

int card_manaforge_cinder(int player, int card, event_t event){
   /* CARD_ID_MANAFORGE_CINDER   9594
   Manaforge Cinder   |BR
   Creature - Elemental Shaman 1/1
   |1: Add |B or |R to your mana pool. Activate this ability no more than three times each turn. */

    hybrid(player, card, event);

   if( event == EVENT_CAN_ACTIVATE && has_mana(player, COLOR_COLORLESS, 1) && get_card_instance(player, card)->targets[1].player < 3 ){
      return can_produce_mana(player, card);
   }

   if(event == EVENT_ACTIVATE ){
      charge_mana(player, COLOR_COLORLESS, 1);
      if( spell_fizzled != 1 ){
         get_card_instance(player, card)->targets[1].player++;
         return produce_mana_any_combination_of_colors(player, COLOR_TEST_BLACK|COLOR_TEST_RED, 1, NULL);
      }
   }

   if( event == EVENT_COUNT_MANA && affect_me(player, card) ){
      if( has_mana(player, COLOR_ANY, 1) && can_produce_mana(player, card) &&
          get_card_instance(player, card)->targets[1].player < 3)
      {
         declare_mana_available(player, COLOR_BLACK, 1);
         //declare_mana_available_hex(player, COLOR_TEST_BLACK | COLOR_TEST_RED, 1*has_mana(player, COLOR_ANY, 1));
      }
   }
   if( event == EVENT_CLEANUP ){
      get_card_instance(player, card)->targets[1].player = 0;
   }

   return 0;
}

(Deleted an earlier comment over an issue that came up, but I think I've resolved it)

Most cards that filter like this don't even bother with declaring the filtered colors. Try putting a Sol Ring in play with a Prophetic Prism, then a Lightning Bolt in your hand. Lightning Bolt will not show as castable. This is a novel solution that seems to work so far:

Code: Select all

int card_manaforge_cinder(int player, int card, event_t event){
   /* CARD_ID_MANAFORGE_CINDER   9594
   Manaforge Cinder   |BR
   Creature - Elemental Shaman 1/1
   |1: Add |B or |R to your mana pool. Activate this ability no more than three times each turn. */

   hybrid(player, card, event);

   if( event == EVENT_CAN_ACTIVATE && has_mana(player, COLOR_COLORLESS, 1) && get_card_instance(player, card)->targets[1].player < 3 ){
      return can_produce_mana(player, card);
   }

   if(event == EVENT_ACTIVATE ){
      card_instance_t* instance = get_card_instance(player, card);
      charge_mana(player, COLOR_COLORLESS, 1);
      if( spell_fizzled != 1 ){
         if( instance->targets[1].player < 0 )
            instance->targets[1].player = 0;
         get_card_instance(player, card)->targets[1].player++;
         return produce_mana_any_combination_of_colors(player, COLOR_TEST_BLACK|COLOR_TEST_RED, 1, NULL);
      }
   }

   if( event == EVENT_COUNT_MANA && affect_me(player, card) && has_mana(player, COLOR_ANY, 1) )
   {
      card_instance_t* instance = get_card_instance(player, card);
      if( instance->targets[1].player < 0 )
         instance->targets[1].player = 0;
      if( instance->targets[1].player < 3 ){
         int amount = MIN(has_mana(player, COLOR_ANY, 1), 3 - instance->targets[1].player);
         declare_mana_available_any_combination_of_colors(player, COLOR_TEST_BLACK | COLOR_TEST_RED | (has_mana(player, COLOR_COLORLESS, 1) ? COLOR_TEST_COLORLESS : COLOR_TEST_0), amount);
         declare_mana_available(player, COLOR_COLORLESS, -amount);
      }
   }

   if( event == EVENT_CLEANUP ){
      get_card_instance(player, card)->targets[1].player = 0;
   }

   return 0;
}

The novelty is in "undeclaring" the colorless mana for paying the activaton costs after declaring the colored mana. Definitely not perfect since it only undeclares colorless mana, but at least it gets the quantity of mana available right. It does seem to count correctly with only colored sources in play. I'm trying it out with all different casting costs to find cases that don't work correctly.

When I tried something similar in Shandalar, it broke with colorless-only mana costs like Endbringer's.

Seems to work with these as well. Manaforge Cinder + Sol Ring alone on the bf can cast Lightning Bolt, Demonic Tutor, Shatter, and Warping Wail, but not Gray Ogre or Matter Reshaper. Manaforge Cinder + two Forests can cast Lightning Bolt, Demonic Tutor and Shatter, but not Warping Wail. I'm pleasantly surprised that this combination cannot cast Gray Ogre, although I guess it makes sense considering how available colorless mana is calculated. I bet there is some combination of mana sources & costs that throws it off but I haven't found it yet.
It's done with the pass of COLOR_TEST_COLORLESS in declare_mana_available_any_combination_of_colors(), subject to checking for a colorless source. It breaks if you only had one colorless mana source & a spell that required two colorless, but right now that's Kozilek, the Great Distortion and nothing else. I think it changes the source of the mana - is that relevant?

It will be if cards like Imperiosaur ever happen. (And aren't there already approximations for some cards like Pyromancer's Goggles?)

The code above affects the source during EVENT_COUNT_MANA, rather than EVENT_ACTIVATE which is where Pyromancer's Goggles et al create their legacy effect. I'm not 100% solid on the whole thing since declare_mana_available/_hex() are in exe, and I'm not sure what the differences are, if any, in accessing raw_mana_available[] vs. raw_mana_available_hex[]. (speaking of which, do you still havethese files, and if so would you be ok with sharing privately? I understand if you'd rather not.) My concern is that with the above setup, you're potentially subtracting the values from raw_mana_available[], adding them to raw_mana_available_hex[] and ending with a negative value in raw_mana_available[]. Seems to handle it like a champ though. I'm surprised that declare_mana_available could even handle a negative value, but again its function is all conjecture as far as I'm concerned.

Unfortunately another issue of Manaforge Cinder that messes up our results and count_mana evaluation is that a mana producing card's in game id has to be bigger than the id of the mana source that you tap to pay for Manaforge Cinder ability to count mana correctly otherwise it doesn't count mana.

e.g. Play first and put in play Academy Ruins before you play anything else now it has id 8, if your Manaforge Cinder has id lower than 8 = Academy Ruins, lets say 5 it will not count mana. If Manaforge Cinder id is bigger than 8 = Academy Ruins then it will count mana. The same will happen of course if you put in play another mana source with id less than 5 = Manaforge Cinder one has.

Other than that it works great in my tests and of course it is not a big issue if it breaks in couple of cases.

EDIT: I have to mention that this happens also with my simpler code above using declare_mana_available(player, COLOR_BLACK, 1); and with removing all code that makes it only activateable for three times.

Got it. Do you mean with the code I posted above, or your code, or both?
A solution, if we want to implement it, could be to call EVENT_COUNT_MANA on mana filtering cards after everything else. This could be done with a simple tag (even just a cc[2] value reserved for this purpose). I'd be happy to implement it if we think it's a good idea. Aswan jaguar, wasn't there another bug like this recently, where the card id affected the outcome?

drool66 wrote:Do you mean with the code I posted above, or your code, or both?

Yes, it is for both which I tried to imply by also but as I didn't put both parts in my sentence, I understand it was not coherent.

drool66 wrote:Aswan jaguar, wasn't there another bug like this recently, where the card id affected the outcome?

There are around a dozen of these bugs in bugs forums and yes one of those was recently. I don't remember which one though, I will have to search for it.
They usually were a problem of tutoring cards or any kind of selection.

EDIT: I think this is the last we have met: viewtopic.php?f=110&t=19008&p=224425&hilit=game+id#p200852

Got it. I was thinking of this one, which wouldn't be affected by changing this: viewtopic.php?f=86&t=15288

Added drool66 code in f6a7b4d. I forgot to do it back then as I expected we would have found a solution for the in game id issue as well:


Anyway certainly a lot better than what we had before.