installed a horizontal text scroller for the deck selection screens in normal play
TODO:-> Need to make it smoother transition. It currently just replaces the text with the new text.
TODO:
change literals to use constants,
refactor the rendering code for the menu to have be leaner.
add text scroller to list all the tasks.
* 1st implementation will list all the tasks.dat
* 2nd round will try to get the scroller to only display relevant tasks to ai
Special thanks to wololo and MootPoint for helping me hammer this out. To abrasax, for the initial design of the layout.
this fixes a bug(?) that had high priority and maintains same effect as before. removed all traces of the "bugged(?) hint" from CardPrimitive.
Issue: 498
I've also added my current work on the zone navigation system (class Navigator) - it's currently turned off for now (the override for this is inside of CardSelectorSingleton's Instance() call, simply comment out the NEW CardSelector and uncomment out the NEW Navigator line.) It's functional, but I want to do more testing before considering wiring it into the game options or something similar. (Also, note that it currently doesn't support the mouse functionality added by DJardin.)
Lastly, there's a bug crash fix in ActionStack that I tripped across while testing - basically, an illegal index value would have us walk off the bounds of a vector.
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.
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!)
CODE: SELECT ALL
#if defined (WIN32) || defined (LINUX)
char buf[4096], *p = buf;
sprintf(buf, "Some debug message showing variables %i and %i\n", variableA, variableB);
OutputDebugString(buf);
#endif
new paradigm:
CODE: SELECT ALL
DebugTrace("Some debug message showing variables " << variableA <<" and " << variableB);
No more dealing with formatting sprintf crap, just stream out variables. Also, DebugTrace washes out in release automatically. (TODO, need to sweep through the rest of the app to apply the changes to all the cases where OutputDebugString() is being called)
2) added two traces to follow adding/resolving things on the stack;
3) changed the uninformative "stack object" string that was the default for base class interrupts to use typeinfo(*this).name() so that you can actually see the derived class in the trace output. Here's a sample of what my trace output looks like now:
Action added to stack: Devoted Hero
Resolving Action on stack: Devoted Hero
Action added to stack: class NextGamePhase
Resolving Action on stack: class NextGamePhase
Action added to stack: class NextGamePhase
Resolving Action on stack: class NextGamePhase
Action added to stack: class StackAbility
Resolving Action on stack: class StackAbility
Action added to stack: class DrawAction
Resolving Action on stack: class DrawAction
4) replaced some hardcoded 0 / -1 values with their proper enums.
