[confirmed]Cabal Coffers
Report wrong Card behavior to get it fixed.
PLEASE ADD SAVEGAMES TO YOUR TOPIC !
PLEASE ADD SAVEGAMES TO YOUR TOPIC !
Moderators: BAgate, drool66, Aswan jaguar, gmzombie, stassy, CCGHQ Admins
[confirmed]Cabal Coffers
by Nexhro » 01 Feb 2014, 02:20
Describe the Bug:
Cabal Coffers ' activated ability costs 2 to activate, but can't be activated unless its controller can theoretically produce 3 (tested with random Mox and Ancient Tomb, so it's not about the land count.)
Which card did behave improperly ?
Cabal Coffers
Which update are you using?(date,name)Which type(Duel,Gauntlet,Sealed Deck)
CIA v2, Duel
What exactly should be the correct behavior/interaction ?
Cabal Coffers can be activated as soon as its controller can produce 2.
Are any other cards possibly affected by this bug ?
-
Cabal Coffers ' activated ability costs 2 to activate, but can't be activated unless its controller can theoretically produce 3 (tested with random Mox and Ancient Tomb, so it's not about the land count.)
Which card did behave improperly ?
Cabal Coffers
Which update are you using?(date,name)Which type(Duel,Gauntlet,Sealed Deck)
CIA v2, Duel
What exactly should be the correct behavior/interaction ?
Cabal Coffers can be activated as soon as its controller can produce 2.
Are any other cards possibly affected by this bug ?
-
- Attachments
-
- CabCoff1.zip
- (3.44 KiB) Downloaded 195 times
Last edited by Aswan jaguar on 26 Apr 2016, 17:19, edited 2 times in total.
Reason: reconfirmed bug
Reason: reconfirmed bug
-
Nexhro - Posts: 1613
- Joined: 23 Jan 2014, 18:08
- Location: HRO, UTC +1
- Has thanked: 78 times
- Been thanked: 103 times
Re: [confirmed]Cabal Coffers
by Gargaroz » 01 Feb 2014, 16:08
I'm not sure this can be fixed, this one of the cards that tend to mess AI up, let's wait for Korath.
----
- Current / medium term task: adjusting the code for making Misdirection and such usable
- Long term task: inserting all the good stuff I left out from the "Golden Years" mod
- Current / medium term task: adjusting the code for making Misdirection and such usable
- Long term task: inserting all the good stuff I left out from the "Golden Years" mod
- Gargaroz
- Programmer
- Posts: 7097
- Joined: 06 Nov 2009, 11:11
- Has thanked: 82 times
- Been thanked: 595 times
Re: [confirmed]Cabal Coffers
by Korath » 01 Feb 2014, 17:53
What we're eventually going to have to do here, and with everything that can both produce mana and do something else that costs mana, is make a variant of has_mana() that doesn't consider the mana the permanent itself can produce.
Right now, for, say, Balduvian Trading Post, we check to see if the second ability (costing ) is activateable by seeing if we have available (since the land's own produceable is counted). That falls apart when the amount of mana it can produce is variable; and for lands, it always will be if there's a Mana Flare or Contamination on the battlefield, or if it's enchanted by some aura that has "Whenever enchanted land is tapped for mana, add [some mana] to your mana pool". With a Mana Flare, Balduvian Trading Post declares and the Mana Flare declares either or , so the Post will think it can activate to deal damage even if there are no other mana sources. With a Contamination on the battlefield, Balduvian Trading Post will only declare available, so you'd need two mana available besides it in order to activate to deal damage. Not being able to activate when you should be able to is more harmful than vice-versa, which is one of the reasons why we have Mana Flare enabled and not Contamination.
Cabal Coffers declares variable mana all by itself, so it's going to be inaccurate in edge cases. It could be fixed, hackily, by replacing its calls to has_mana() with setting a flag on the land so it won't do anything in response to EVENT_COUNT_MANA, calling count_mana(), checking has_mana(player, COLOR_COLORLESS, 2), unsetting the flag, and then calling count_mana() again. I suspect that's going to be too slow for the general case, though; count_mana() is slow, and EVENT_CAN_ACTIVATE on mana-producing cards is likely called relatively often.
A better way, tentatively, would be to rewrite declare_mana_available() and declare_mana_available_hex() so that, if some global flag is set,
they remove the mana instead of adding it (using undeclare_mana_available() and undeclare_mana_available_hex()); then write a has_mana_excluding_this_card function that looks something like:
(For that matter, we could use a similar function for charging mana for these abilities, instead of doing it in every single affected card's function and in a slightly different way for each one. This would probably be as simple as disabling mana abilities on the card if they weren't already disabled, charging the mana, and restoring mana abilities if we'd disabled them earlier.)
Right now, for, say, Balduvian Trading Post, we check to see if the second ability (costing ) is activateable by seeing if we have available (since the land's own produceable is counted). That falls apart when the amount of mana it can produce is variable; and for lands, it always will be if there's a Mana Flare or Contamination on the battlefield, or if it's enchanted by some aura that has "Whenever enchanted land is tapped for mana, add [some mana] to your mana pool". With a Mana Flare, Balduvian Trading Post declares and the Mana Flare declares either or , so the Post will think it can activate to deal damage even if there are no other mana sources. With a Contamination on the battlefield, Balduvian Trading Post will only declare available, so you'd need two mana available besides it in order to activate to deal damage. Not being able to activate when you should be able to is more harmful than vice-versa, which is one of the reasons why we have Mana Flare enabled and not Contamination.
Cabal Coffers declares variable mana all by itself, so it's going to be inaccurate in edge cases. It could be fixed, hackily, by replacing its calls to has_mana() with setting a flag on the land so it won't do anything in response to EVENT_COUNT_MANA, calling count_mana(), checking has_mana(player, COLOR_COLORLESS, 2), unsetting the flag, and then calling count_mana() again. I suspect that's going to be too slow for the general case, though; count_mana() is slow, and EVENT_CAN_ACTIVATE on mana-producing cards is likely called relatively often.
A better way, tentatively, would be to rewrite declare_mana_available() and declare_mana_available_hex() so that, if some global flag is set,
they remove the mana instead of adding it (using undeclare_mana_available() and undeclare_mana_available_hex()); then write a has_mana_excluding_this_card function that looks something like:
- Code: Select all
int has_mana_exluding_this_card(int player, int card, color_t color, int amount)
{
hack_declare_mana_actually_undeclares_it = 1;
dispatch_event(player, card, EVENT_COUNT_MANA);
hack_declare_mana_actually_undeclares_it = 0;
int result = has_mana(player, color, amount);
dispatch_event(player, card, EVENT_COUNT_MANA); // put the removed mana back
return result;
}
(For that matter, we could use a similar function for charging mana for these abilities, instead of doing it in every single affected card's function and in a slightly different way for each one. This would probably be as simple as disabling mana abilities on the card if they weren't already disabled, charging the mana, and restoring mana abilities if we'd disabled them earlier.)
-
Korath - DEVELOPER
- Posts: 3707
- Joined: 02 Jun 2013, 05:57
- Has thanked: 496 times
- Been thanked: 1106 times
3 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 11 guests