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
i hope to have a polished cleric Ai deck for release 14.1 within the next day or so. trying to include a couple decks that take adventage of all this great training.
hopefully i can get prevent working as good as equip does...the Ai deck i constructed called
"the kor" is almost an unbeatable white weenie deck.
ok here goes, first, fixed a crash that would happen when ever a player would gain more then 2000 life or take more then 2000 damage...the buffer was becoming corrupted i imagine because it was too small, increasing it to 10 slots allowed players to successfully take massive amounts of damage, highest i bothered checking was about 35k gained/lost, no crash...
2nd, removed the and refactored cantcaster rule, moved it to stateEffects() and renamed stateeffects to better reflect what it will be handling,
removed sneak attack rule and moved it into stateeffects
the following ints have been converted into bool,
all the cantcasters, canputlandsintoplay is becoming a bool, the amount of lands you can play is now handled by a new varible int landsPlayerCanStillPlay (this is for my ability additional lands increase in support on perminents coming after the release)
the changes to bools were for an obvious reason, they were all ints pretending to be bools, my varibles were confusing as you would often see code like this if(cantblahblah > 0)
which to another coder might not make any sense.
these varible ints were returning 0 as false and 1 as true...changed them all to bools, same goes for putlandsinplay int, in half the places it was being used as a bool, AND it was tracking the amount, when i was coding additional land ability, this made it impossible to maintain correct amounts without damaging the rest of the code.
as a bool, controlled by stateeffects, it can now be used correctly as a bool in all cases, and the stateEffects manages the switch on it to false if you no longer have any landsPlayerCanStillPlay left.
the refactor on cantcaster was also a bug fix, it was reported to me that cantcasters were not correctly working, sometimes ai or player would still be allowed to play a card with one in play, because of the old way i had it setup somecases of bothcantcaster were reseting the cantcast to 0, basically making the check do nothing.
it is now handled in stateeffects if you have one in play, then its true, if not then false...this returns very accurate tracking of the cards instantly instead of checking as cards enter or left play.
the "both" versions now have their own bools to avoid future conflicts with the single player cantcast...
added a case for the fancy moving text, some move to library effects were incorrectly returing fetch.
- computeActions would leak a ManaCost. This was fairly minor.
- AIPlayer::SelectAbility had a major leak. Basically, there's some code that pulls a random number for an efficiency check - if the action's efficiency value was below that random number, the action pointer was cleared, and none of the actions that were to be discarded would be deleted out of the rankings map. I've switched out the rankings container to not contain action pointers, but real action objects, so regardless what kind of logic is implemented, the map will properly clear out its objects upon destruction.
someone just forgot that both cases need to check if the interupt decision is 2 before changing it back to 0 (interupt) btw, once a stack is ready any NEW stack actions added, such as Ai interrupting your choice to not interrupt you will see the new stack actions to either cancel manuelly or "no to all"
sorry its not a bug fix for crashes! im really not skilled enough yet to fix the kinds of crashes were having.
-Attempt at fixing issue 538. This is a wild guess, but basically 1 000 000 bytes is NOT enough to decompress a 512*512*4 texture (32bits png). We need at least 1MB (1024*1024) AND some additional space for the decompression process. Based on that, bumped the 1 000 000 (minimum contiguous ram necessary to start decompressing a picture) to 1 500 000. I've had pretty good results so far but this needs confirmation
- GameObserver <- changes from Win to *nix carriage returns.
