First version where I managed to finish a normal game while undoing several actions until the end. There are still some problems in direct damage spells and interruption management. I added several assert in the code to catch them.
-- I added an AbilityParser.cpp file, mid term goal is to move AbilityFactory there, so that MTGAbility.cpp becomes a bit less big.
-- I tried to add the file reference in Makefiles, but only tested windows compilation so far
- Fixed bugs related to "castRestriction" variables in MTGAbility. these variables were declared in both the parent and children classes, leading to bugs and duplicate code/content
The test suite passes
- Added an undo menu using this code (beware, it's still very very alpha).
- Removed various warning
- Cleaned up avatar loading
- Added full random lists load/save including the deck shuffling (not sure if I could not replace that with seed load/save)
- Moved momir and Co rules configuration out of GameStateDuel
- Create a GameType type to avoid mixing int everywhere
Included in a new modrules.xml tags.
<cardgui>
<background> Stores information concerning the colors </ background>
<renderbig> Stores information to draw the card </ renderbig>
<rendertinycrop> Stores information to draw the card </ rendertinycrop>
</ cardgui>
Change the variables array for vectors
- Added a "cachesize" option (not available from the menu, but can be manually edited in players/options.txt, for example cachesize=200 means 200MB of cache). The hardcoded cache on windows/linux is 20MB, which is not enough for Hi Res cards (60 is better, 200 is great)
this fixes 2 crashes I found, the first, 2 color random mode would crash on load.
2nd, ai vs ai testing would randomly crash, this should fix that also.
I noticed 2 color random mode is now trying to search for it's rules and sometimes flashes for a brief moment "error cant read file" or something like that....I could not find the source of that, it doesn't cause it to crash however it causes it to take a sec longer to load, this is before this commit btw, so the issue is still there.
it was trying to load the rules, flashed the error then crashes...i fixed the crash but not the rules error.
please review, i might have left in useless stuff...
I also did notice something, the way we are creating players is kind of all over the place. imo this is bad, it made this conversation extra hard becuase you create one player over here, another type over there, the human over in this direction, back track and create another somewhere else...this needs to be taken into account for a refactor, all player creation should happen in the same function, and at the same times...
the reason these 2 crashes existed was becuase players were being created before "gameobserver" in some modes, and in other modes, no player would exist at the time game was creating to set the player. but we then later call the same function when we actually load the player using the method specific to a mode.
this just leads to headaches, I mean no offense, just a general observation i made when converting this players array. unfortunately that kind of refactor is just a little beyond my coding ability.
- removed every references to the gameobserver singleton. This object can now be instantiated several times as it's needed for minmax. To be able to do that, I mostly added a reference to a gameobserver from any targetable object (cards, players, spells) and abilities.
- removed incorrect casts of MTGCardInstance into Spell objects.
- AI Test system now allows you to put decks in ai/bakaA and ai/bakaB instead of ai/baka. This allows to let AIPlayerBaka and AIPlayerBakaB play with specific decks
- Test suite speed improvement. Improved the card name cache. Test suite now runs in 850 seconds instead of 950 on my machine.
- minor code cleanup
- In order to clarify getEfficiency, started creating "getEfficiency" functions specific to each type of ability (see example with Damager). This won't reduce the file size but should make things bit clearer
- Minor cleanup of getEfficiency
- bug fixes in getEfficiency
- Minor fixes in AI code
- Attempt at preventing the AI from interrupting itself while it's selecting targets. I don't know why this happens, and my fix didn't work. I believe it shouldn't be possible to interrupt when there is an active targetChooser, please let me know if this is an incorrect assumption.
-- This is a copy/paste and shouldn't have any impact on the logic. I just moved some functions from AIPlayer to AIPlayerBaka
- Added back the possibility to select a different Resource folder with file Res.txt
- Fix a crash when a token id does not exist
what this does currently is remove a counter of the type counterstring and when the ability is destroyed it puts the counter back for us.
meant for weapons used as follows.
auto=teach(creature) countertrack(0/0,1,hand)
when the creature is equipped with this weapon it will remove a hand counter from the creature, when you remove the weapon, or the weapon is destroyed or whatever...it will put a hand counter back on the creature.
added dualwielding thisdescriptor...
auto=this(dualwielding) 2/2
auto=this(dualwielding) firststrike
enabled "restriction{" on phasebased triggers @next and @each...
i will work more on countertrack to extend it to domains if it currently isnt possible to use it in this case(haven't tested it on domains)....
ok this target chooser is set apart from the others becuase it focuses on relationship between cards instead of other forms of checking, also i made sure to add a method for deeper Targeting.
it is the same as any other target chooser when it comes to writeing the syntax and can be used in almost every way a normal one can.
here is what i mean by deeper targeting
this targetchooser allows you to denote a nested targetchooser.
target(children[targerchooser])
all(parents[targetchooser])
it is plural becuase i do allow maxtargeting to be denoted here. lets say you want to have a domain that lets you do the following
"2 of my target inhabitants get +1/+1 until end of turn"
you can do this...
auto={0}:target(<2>children) +1/+1 ueot
how about even more complex?
auto={0}:target(<2>children[elf[power=1]]) +1/+1
2 of my children that are elves with power equal to 1.
the same goes for parents, you can also lord( with this targetchooser.
if you want to say
"the inhabitants of this domain gain flying"
auto=lord(children) flying
here are some example coding that you can play around with.
[card]
name=Forest
text=G
auto=lord(children[elf]) +3/+3
auto={0}:target(<2>children) +12/+12
type=Basic Land
subtype=Forest
[/card]
[card]
name=Tidal Kraken
abilities=unblockable
target=land|mybattlefield
auto=connect
auto={0}:target(parents) destroy
text=Tidal Kraken is unblockable.
mana={0}
type=Creature
subtype=Kraken
power=6
toughness=6
[/card]
[card]
name=Arbor Elf
target=<upto:3>land|mybattlefield
auto=connect
auto=foreach(parents[forest]) 1/1
mana={0}
type=creature
subtype=elf
power=1
toughness=1
[/card]
*above, arbor elf can target upto 3 domains...for each one you choose to connect him to that is a forest, arbor elf would gain 1/1..
so as you can see it is pretty indepth.
note: all test pass.
target=*|mybattlefield
auto={0}:equip
auto=connect
notice i declare the equip before the connect, this is becuase connect will use the equip ability of the card to handle it.
target= can be used for connecting them now as the first time equip. please remember to use teach( or autoskill= to avoid giving abilities forever to a target...this makes equipments hybrid auras.
also, moved parentchildrule init from original init to rules.txt...
in yourrules.txt
should look like this:
include mtg.txt
name=Classic
[INIT]
mode=mtg
auto=connectrule
[PLAYERS]
auto=shuffle
auto=draw:7
i did this becuase i want to reuse the parentchild associations for mtgabilities...and if parents will always kill thier children, i won't be able to use it :P
changed connect into an instant ability, i don't want this ability to be done by menu choice.
added parentchildrule which currently only handles the removel of children if a parent dies, but will be extended to handle other actions based on event receiving that deal with child and parent association.
add keyword targetable ability "connect"
connect means "the source adds the target to it's parent vector, the target adds the source to it's children vector"
this can be multitargeted, so it is possible that
"Big Bad Dragon" can live it 2 different domains.
not sure if this was even asked for, but i thought it would be cool to be able to say
"to play big bad creature you need to give it 2 homes"
or
"big bad creature can live in upto 4 homes"
this adds a level of stratigy, becuase now big bad creature can have "all creatures which share a domain with big bad creature gain +2/+2"...or "all domains that city planner live in gain 1 capacity"
but also add the possibility of faster removel from a card like
"destroy all creatures on target domain".
i thought it would be a nice add to kai rules.
connect clears a target= on a card after connecting...this is to avoid abilities transfering to the target, unless you want it to effect the target like
"tap target domain as this becomes a inhabatant"
target=domain
auto=tap
auto=connect
auto=<==this line on will not be targeting the domain
small add with big impact:
added the useage of castrestriction on triggers and activated abilities.
this can be used to create such cards as library of alexandria.
{t}:draw:1 restriction{type(*|myhand)~equalto~7}
and replace instances were we were putting false triggers on the stack from abilities which contained nested aslongas...
meaning cards like epic struggle, won't need to be triggered every turn even if you have no creatures...
for epic struggle here is an example of how to replace it
@each myupkeep restriction{type(creature|mybattlefield)~morethan~19}:wingame controller
any of the current cast and other restrictions can be used. this includes turn:1 <===and various others such as phase based checking.
syntax is
restriction{ whatever casting/other restriction you want }
a nice quality of life fix for false triggers (which don't mean theyre incorrect, just annoying when they trigger when they will do nothing)
another example would be the triggers on cards like
skullcage.
auto=@each opponent upkeep:aslongas(*|opponenthand) damage:2 opponent >4
auto=@each opponent upkeep:aslongas(*|opponenthand) damage:2 opponent <3
becomes
auto=@each opponent upkeep restriction{type(*|opponenthand)~morethan~4}:damage:2 opponent
auto=@each opponent upkeep restriction{type(*|opponenthand)~lessthan~3}:damage:2 opponent
now instead of triggering every opponent upkeep even without a resolve...it will only triggers when the restriction requirement is met.
enjoy :)
note:all test pass.
wagic.the.homebrew
Xawotihs
techdragon.nguyen@gmail.com
rodrigodemoura@gmail.com
omegablast2002@yahoo.com