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.
another issue i fixed, when last trigger would be resolving in "trigger" substep, the game was moving to next combatstep before you could finish it, NOW the game correctly finishes resolving any triggers that might have fired off in "Triggers" substep, THEN it adds combatdamage step to the stack. this also fixes an issue where if you were multiblocked and combattriggers fired off, then your trigger would be UNDER the "ordering window" and unresolvable.
added waitingforanwsers return to userRequestNextGamePhase
when youre "waiting for anwsers" that means you have a menu box open and the game is waiting for you to decide....this was one of the causes of the rush to combat damage while youre still selecting something on a menu.
moved Trigger step call to requestnextgamephase into stateEffects() and out of updates, works MUCH better this way. i wonder why this isnt handling more of the automated functions, i suggest we consider moving the autopassphase into stateEffects() also as it will most likely be handled much better in there then in the update function.
also,
adjust Ailessons on Adrawer, it was still getting a little too excited about drawing cards.
moved around the eff setting on grantingability lessons.
having it set to 0 BEFORE actually giving it a value was conter productive.
added a peice of commented out code in "isintop" function that if you uncomment will allow you to have Ai ALWAYS multiblock you.
im pushing this in as i feel comfortable with the positives and havent really come across an adverse effect yet.
however i am just one person and testing something like this is much easier with alot more then 1 person on it.
exsample, 3 unresolved stack actions. with interrupt set to 5 secs, will allot you 15 secs to decide the first action, then 10 secs to decide the 2nd action, then 5 secs to decide the last action.
note: its multiplicative, this does not make each stack action into 15 sec interrupt.
as they resolve "extraTime" gets recalculated.
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.
fixed the bug where the ai "attacks/blocks" its own attackers during the combat phase.
Strangely, creatures only die in this bug when there are two or more suffering from
summoning sickness.
If somebody can double check this code change to make sure that it is appropriate.
My playtesting indicates a success but I don't have the variety of player decks others have.
with this change, currentmana is now what it could make and if anything is in the pool then add whats in the pool as potential mana., if it could potentially make mana then THIS is its currentpool. as getpotentialMana already handles the rest.
i originally added the manapool at the end of potential as my first attempt to stop this behavior, but this either/or if statement really got in the way of producing the result i wanted, which is, if
Ai has a 3 swamps, and a dark ritual, and it cast darkritual.
in hand Ai has a 5 black drop.
in OLD set up Ai would see it has 3 mana, then it would see it had 2 mana from the untapped swamps. it would pass the phase thinking that it could not cast the creature.
NOW ai looks for how much it has in mana, it see 3 swamps, it cast dark ritual, it now see what it can create on the next call to findcards, it see 2 swamps + 3 mana in pool, it cast the 5 drop creature.
mind you that this does not fix Ai mindlessly casting dark ritual as we have no current system to tell AI "hey dont cast that card now its useless to do so" like the fancy system to tell it what abilities it should use on cards :) *maybe someday*
2nd bug fix,
commented out a peice of code that compared if power and toughness would be cancelled out by a new counter. exsample:
1/1 is cancelled by -1/-1...this is actually extremely incorrect,
if you "put a 1/1 on a creature"
then you "put a -1/-1" on the same one. it does NOT remove the 1/1 as per MTG rules. the counters all all treated as NEW objects on a card. so a creature that had both those abilities used on it should have BOTH a 1/1 and a -1/-1 counter.
commenting out the section of code corrected this probelm.
modular creature, phantom creatures,sunburst and many many more will now correctly be able to use their counters even if they recieved "cancelling" Counters
last was just an improvement, as i got overly frustraited tonight while fighting with a deck that slaps many different types of counters on cards, i was having a very hard time telling what exactly i was about to put on a creature.
so what i did to correct this is create a much better menuText return on aacounter class.
PLEASE let me know if i missed a case where a counter is not showing correct text.
