Page 1 of 1

Fixing current known issues

PostPosted: 09 Aug 2016, 15:39
by Agetian
I'm opening this thread to unload the "Card Development Questions" and "Bug Reports" threads a little and also create a more systematic thread for the discussion of the currently ongoing efforts to fix some of the long-standing rule and rule interaction issues.

Thanks to Hanmac's efforts it was possible to fix some issues in how Forge interprets and applies rules.

The progress of further fixes and modifications can be discussed and reported in this thread.

For the sake of completeness here's a breakdown of the currently listed Known Issues in CHANGES.txt - this is by no means a complete list of known issues, it's just some of the more "major" and "long-standing" issues that haven't been fixed for a very long time. Any issues that are fixed will be crossed off the list to indicate progress.

"ISSUES LIST (LISTED IN CHANGES.TXT)" | Open
There is a known issue with Kodama of the Center Tree: its Soulshift X ability used to crash Forge, and until a proper fix can be implemented, a temporary fix was introduced which prevents the crash but makes the Soulshift X ability work incorrectly in certain cases (in particular, it doesn't work correctly with mass removal, and it may have issues when Kodama of the Center Tree is controlled by someone else other than its owner). In the basic cases (such as Kodama of the Center Tree being destroyed in combat or with a direct damage spell) should work correctly. Hopefully one of the developers will be able to implement a better and proper fix for this card soon. - FIXED in r31924.

There is a known issue with the cost reduction for cards that have color-locked X in their mana cost (e.g. Drain Life, Soul Burn). Cost reduction will not apply correctly to these cards if the amount by which the cost is reduced is greater than the amount of colorless mana in the mana cost specified on the card (e.g. 1 for Drain Life, 2 for Soul Burn). Fixing this issue likely requires rewriting the way announced color-locked X is interpreted and paid (most likely it has to be represented with colorless mana shards but still locked to the colors required by the card).

Several people have noticed that the cards displayed on the battlefield will fail to be displayed when the number of cards on the battlefield increases. Maximizing the human panel can help to re-display the cards.

Some time was spent turning the static ETB triggers into the proper ETB replacement effects they should be, mainly to interact correctly with each other. This work is not yet finished. As a result there is currently some inconsistencies with "Enters the battlefield with counters" (Not incredibly noticeable).

A recent contribution to the code base should fix some of the bugs that people noticed with cloning type abilities. At this time there is one remaining issue that we hope will be addressed in the near future: Copies of cards that setup Zone Change triggers via addComesIntoPlayCommand and addLeavesPlayCommand will not function correctly.


In addition to the list above, I'd like to mention a currently known major visual issue that is currently relevant and that hasn't been fixed yet: certain cards, in particular, certain auras (a good example: Wind Zendikon) and enchantment God creatures (e.g.: Thassa, God of the Sea) flicker very heavily during phase changes, change their places on the battlefield (in particular, which row they are drawn in), and can sometimes even temporarily disappear from the battlefield (e.g. Wind Zendikon randomly disappearing and reappearing upon phase change - happens rather rarely).

- Agetian

Re: Fixing current known issues

PostPosted: 09 Aug 2016, 20:07
by Hanmac
it might not be a big problem, but it exists a few months back (since the release of SOI) ;P

Altered Ego cloning a creature which already enters the battlefield with counters depending on X. for example Apocalypse Hydra (xPaid)

currently Altered Ego gains both counters. (but should only gain its own one)

my current idea how to fix that:
using OriginalHost on them, Intrinsic might not be the right thing.
then when "Count$xPaid" is checked, have it check some things

(i probably need to check a few things for replacementAbility=true, mapParams.containsKey("ETB"), OriginalHost != null, ...)
but if that is the case, then i have xPaid return 0.

Edit: should be fixed in r31929.
Feel free to check that.
===

for the stuff with XColor, i already did take a look, i probably need to rewrite a big chunk of ManaCostPaid and CostAdjustment (and something for the ai)
might take a while bit i think its doable.

my idea for that:
  • have ManaCostPaid first treat the X as "X" and have the xValue and the xColor be stored (because see below)
  • now have CostAdjustment be able to reduce that X part like it normally would. (but generic first?)
  • then after CostAdjustment is done, have ManaCostPaid replace the "X" with xColor times xValue.