Note this particular aspect of the "becomes" ability was not broken prior to the fix for 559. This is a sanity check as it has nothing to do with color change. but tests ability changes due to "becomes" ability.
Issue: 559
This one was a bit of a doozy to fix correctly, but the actual fix ended up being fairly simple - the upshot is that TargetAbility never checked for whether an extra cost needed setting prior doing a target selection. While at it, I discovered and fixed another bug: if you're in the middle of an extra cost choice (like sacrifice, for instance) and hit the next phase button, the game would let you proceed, and then hang in an endless loop.
While at it, did a little cleanup/refactoring around GameObserver's waitForExtraPayment - any time a bool has something that sounds like a verb, it probably deserves to be a function. Now it is. (I needed to refactor it anyway, as I reused that code for the next phase hang.)
Note that after this fix, I had to patch two test cases (siege_gang_commander.txt & seismic_assault.txt) - since I've change the selection order (ie a target ability with a sacrifice cost requires the cost to be paid up front before picking the target), this means that tests involving targeting & sacrifices need to switch the order of the cards to pass.
the tag "other " vs tag " other"
using "other " in target choosers will always work, however more often then not using " other" at the end of a line would produce weird effects, this was brought to my attention in a bug report by KF1, i moved all the " other" from outside target chooser into the actual target lines, as this always produces correct results in code, i imagine the tag at end of line was added before "other " was intruduced into targetchooser.
i will leave support for using " other" in code, however, i ask that we try not to use this code unless for some strange reason the targetchooser "other" doesnt take to the code.
stranger was that i noticed alot of mixed code, as in lord(other blahblah) 1/1 and this version with other tag at end, it was very inconsistent aside from causing weird weird results in game which i was actually able to confirm.
please update your primitive!!! this was ALOT of work.
correct syntax for "other "
lord(other blah)
all(other blah,blah,blah)
damage:1 target(other blah)
target(other *|somewhere)
notice its always first followed by a space. you only need one instence "other " in a targetchooser.
- fix for issue 539 . It is now possible to provide several possible paths in Res.txt, the game will use the first one that matches. If none of them works, it reverts to the oldschool "Res" folder
- Added AI Decks unlock system. Please update your graphics folder, and crossing fingers that Ilya B. is still around as I don't have the correct fonts.
Blitz Hellion
Deathcoil Wurm
Laccolith Grunt
Laccolith Titan
Laccolith Warrior
Laccolith Whelp
Line Wolf
Pride of Lions
Righteous Fury
Rhox
Thorn Elemental
Tornado Elemental
Wolf Pack
Removed Foosteps of the Goryo. It cannot work right now for the same reason as Miraculous Recovery cannot work.
* Add multilingual support for utf-8.
* Use japanese as a test case (removing the old tentative support).
* A number of shortcomings affect this code.
+ Bugs :
- This splits algorithms used to determine the length of a string
and to render it in two: either the string starts with an ascii
char and the monobyte, variable-space algorithm is used, or it
does not and a multibyte but fixed-space algorithm is used.
This shortcoming also exists in the code to support chinese.
- From the above comes the biggest limitation: any string that
starts with an ascii character but include non-ascii characters
will not be rendered correctly.
- This does not and cannot support chars outside the BMP. This
probably won't matter, ever.
+ Todos, fixmes, wishlist :
- Single-width characters with diacritics are reported as
double-space chars. It doesn't matter too much at the moment, but
should be fixed in the future.
- Font support currently only includes japanese.
+ Performance and compatibility notes :
- Chinese code has not been switched to utf-8, to maintain backward
compatibility. We should switch it at some point in the future,
but ponder the right way to do it first.
- Retaining the support for chinese with a non-international
charset hurts performance (by making some methods uselessly
virtual).
* Still, this generally works and is extensible (it can be used to
implement korean, traditional chinese, etc, without any more code).
Implementing languages with diacritics needs an improvement of the
bool doubleWidthChar() method.
