Also fixed the project includes so that we don't need to always use the indirect include path, ie:
#include "../include/foo.h" -> #include "foo.h"
I'm don't know much about make files - if I busted the linux build, mea culpa, but I think we're okay on that front too. For future reference, here's the most straightforward link on the topic of adding pch support to make files:
http://www.mercs-eng.com/~hulud/index.php?2008/06/13/6-writing-a-good-makefile-for-a-c-project
this is by no means absolutely perfect, i like it tho, and makes for some real good times with level up deck built with equips.
you will notice i added a level=number...to the level up creatures, this has no effect on players, this is just a small hint to the Ai as to when it should stop investing mana in that creature. the chances are a little over half that ai will want to level a creature, increased ever so slightly with each level up.
for equipment, the Ai will now want to equip its best Creature(determined by power+toughness+convertedcost+how many abilities it has) and will want to equip these "better" cards atleast 2 times before it is reduced. same system for prevent damage, it will want to save its "better creature" more then a 1/1 token.
for both tho i added slight bonuses...
to equip, there is a higher chance that the ai will want to target a white creature, with an extra bonus if the creature is a 1/1 and nontoken. this is to encourage Ai to equip in white weenie decks
in prevent, there is a slight bonus if the creature is a 1/1 and the blocker/blockee has a power of 1.
currently prevent damage treated this way is not coded for direct damage spell, sorry ! but for combat you will notice ai taking a stand and fighting back hard.
No option to delete or edit the AI deck once it has been created.
The deck gets saved as the canonical form of the deck to match other AI deck formats.
(I did a cursory check to make sure chinese still displays correctly - at a glance, I'm seeing what looks correct to someone who doesn't read the language :) )
I'm also noticing that the GetQuad(int) variant never seems to get hit, so I suspect that the ID lookup map is redundant. I left it alone as the JResourceManager base class forces the need for the function; I need to spend more time looking at just how much of JResourceManager we actually use at this point.
- adding tests for issue 489 and issue 491
- check for null pointers in Credits.cpp
- Test suite can now select tokens by their name
- Fixed Dragon Broodmothere's token name
Also moved some static value definitions used in the drawing code from the class header to a private namespace in the cpp file, as they don't need to be seen by any clients of the class.
( ie task list was being updated, set information being evaluated, etc )
put a guard around the endgame stat update process to only update when non-testsuite games are played.
Issue: 488
Some of the things refactored to the base class:
- isPaymentSet()
- canPay()
- Render()
- setSource()
- setPayment()
- the target instance
- duplicated constructor initialization crap
I'm not interested in pointing fingers as to how the code got this way, but I'll ask that everyone who's altered this code in one fashion or another to carefully diff this change and understand what I refactored. This code is a poster child for neglect & what happens when people start blindly copy & pasting code instead of paying attention to the commonality between code paths. If you see the same lines of code happening over & over, and you're about to make yet another copy, please stop yourself & think about how you can refactor the code to be in a single shared function (or, more explicitly, a shared base member function when possible).
If you don't understand what I mean by a shared base member function, then I would suggest at the very least reading up on this topic:
http://www.cplusplus.com/doc/tutorial/inheritance/
(And, after all that, if you're still unsure how to proceed, ping someone else for advice!)
"It's currently unclear for me why several instances of the same hgeparticlesystem with the same .psi file are created..."
The GameApp::Create() call was initializing an array of particles, but it wasn't actually stashing them in the psi cache. The MenuItems also create the particles, but these are stashed correctly in the cache at that point. So, I simply removed the unused particle array loading code since it wasn't actually caching anything correctly & therefore simply adding redundant reading of the same particle files.
