their x position is the same in their "default" horizontal stack, so
when attacking it always start at left side, not in the middle. Please
report if you have bugs...
It seems when a zonechange event from inplay to inplay (player or
opponent), the card->view item values is recalculated... so it destroys
the GUI like missing card image, or moving it far off the screen... To
reproduce, cast Splinter Twin to Conquering Manticore and gain control
the same creature about 2 or 3 times...
blending of wood and/or gold texture on some resolutions(mobile,
tablets, etc) draws line which can be distracting. The backdrop is now
full size of PSP resolution (480x272, 2x res can be loaded like 960x544)
auraward -> an exception for protection from quality used for aura, like
flickering ward
added event for unattach
added state based check for protection from quality.
702.16c A permanent or player with protection can’t be enchanted by
Auras that have the stated
quality. Such Auras attached to the permanent or player with protection
will be put into their
owners’ graveyards as a state-based action.
702.16d A permanent with protection can’t be equipped by Equipment that
have the stated quality
or fortified by Fortifications that have the stated quality. Such
Equipment or Fortifications
become unattached from that permanent as a state-based action, but
remain on the battlefield.
In details:
- I removed my player swap idea, it caused tons of issues with randoms
- instead I simply keep both peer on the exact same game and added one single parameter allowing to configure the view on the game. So, each peer is rendering the same game (gameObserver class) from a different player point of view (DuelLayers and related classes).
- a lot of gui stuff are missing to prevent user forbidden interactions but it works fine on Windows
this can also be used for "equipped creature has unattach and blah" cards using
auto=teach(creature) {unattach}:blah
also corrected a long standing guiupdating issue. a long long time ago a replace was removed from GuiPlay::Update in hopes to increase performance no amount of performance increase is worth having cards not updating thier position after an event recieve happens. this means curse will finally go to the correctly choosen players battlefield, equipment will no longer just linger after its target dies, auras won't stay on battlefield after a card is exiled. ect. no preformance decrease noticed, if anyone else notices one let me know.
adjusted the calculation of x for enstack attackers to avoid drawing cards on top of the phase wheel out outside of the red box. adjusted the red box length for uniformity.
the previous calculation only drew cards to the middle of the screen and after about 15 attackers it pushed cards out of the red box, over on top of the phase wheel making it impossible to click or touch requiring alternative methods to advance to damage phase or reduction of the amount of attackers.
the new calculation draws attackers at the start of the red box keeping the enstack a cardwidth and a half from the edge of the screen on both sides instead instacking massive amounts of attackers tighter inside the red box, much how we handle battlefield enstack...attacking with more then 40 creatures no longer pushes attackers off screen.
- Modified the testsuite and gameobserver to be able to replay all the testcases based on the actions logged during the first pass. This allows to test the action logging and replay used during undo. It's only activated in multithreaded mode and it does not work on Momir tests.
- Modified choice logging and replay to use menuId instead of ability index, as, for some obscur reasons related to Lord, those ability indexes may change.
- Fixed bug in nextphase logging wrongly generating click actions
- Added a "stack" zone to the click ability logging to be able to replay properly interrupt
- Fixed a wonderful bug mixing card names with zone names in the actions execution engine
- Added a "combatok" action logging/execution
- Added a "clone" virtual method to MTGCardInstance and Token to be able to clone correctly the right object type. Used that in MTGGameZones::removeCard
- Reworked the testsuite to be able to work multithreaded. This is deactivated by default everywhere except in QT_CONFIG as one testcase still refuses to pass in multithreaded mode. On my 4 cores linux desktop, the 650 tests passes now in 4 seconds (1 fails).
- Replaced usage of CardSelectorSingleton by a card selector per game observer.
- Modified the resource manager to be optionnal and per game observer instance instead of being a singleton. Two reasons here : threading AND Open Gl access. I only updated the crashing parts called from the game observer, so most of the code is still using the single instance. Beware of copy-paste concerning resources ...
- Cleaned up the game observer constructors
- Fixed several problems in action logging code while testing proliferate decks
- Cleaned up Threading implementation based on QThread
- 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.
* pruned out unused local variables.
---- There's no need to define something if it isn't going to be referenced. It consumes extra memory temporarily and more than anything is a potential cause for confusion down the road.
- This is some Work in progress to make Wagic less "game" dependent.
This change especially is an attempt at moving away from some dangerous patents owned by some company.
It introduces "modrules.xml", a global configuration file describing dynamic settings for any given Wagic mod. It is very basic for now, but allows to customize a bit. In particular, it allows to remove the concept of shop and deck editor from the game, dynamically generate the main menu, and represent card activation with a mask rather than a rotation.
I have a sample in progress which I hope to submit in the days to come, a proof of concept (nothing fancy yet) for another type of game using these ideas, as well as a few other things I introduced recently.
In the future, I am hoping to extend modrules.xml so that it entirely describes the rules of a given card game. the other files in rules.txt will describe "extensions" to the core rules, just like they do right now, so this new file does not make them obsolete.
- Also fixed minor bugs I stumbled upon while developing
I've marked all the ones I found with the following TODO comment:
TODO: C6246: <blah blah>
a few in particular are the ones related to "oneShot" and "_target". These are local variables that are declared that
mask either a method parameter or a member variable.
reason for this change is that it becames WAY to hard to player decks which contained mostly artifacts to share the feild, give 9 cards half the screen to display just didnt seem like a good choice compared to the creatures horizontal stack which can display almost 200 cards in the same screen width.
2nd, started laying some ground work for planeswalkers.
added the planeswalker rule, as per mtg rules, if you have a type=planeswalker subtype=jace already on the battlefield, both are sent to the graveyard. so you can not have a jace mind scuptor and a jace beleren out at the same time. i choose to use subtype= and type= rather then adding another variable to MTGCard...
also, added GuiPlay positioning for planeswalker,
i think theres been a HUGE misunderstanding about planeswalkers which has most going "battlefield is too crowded where would be put them...easy...slap them at the end of the lands ..done...theyre not creatures or artifacts/enchantments..so i moved them to the colum with the lands and have guiplay slap them at the end of that colum...btw this is in no means final...if someone can think of a better solution be my guest, but looking at the planeswalker (workaround) thread, its pretty obvious that no one will care where we slap the planeswalkers, as long as theyre supported. planeswalkers have alot more ground to cover...
what this change does is this. if i have 20 enchantments on the battlefield Ai's creatures and lands no longer slide to the right. and vice versa. made no sense that if the other player had no artifacts/enchantments that HIS lands and creatures would slide simply because the OTHER player had artifacts/enchantments.
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
* Some cleaning after r1062 code review.
- Remove code that was never reached.
- Remove a useless function.
- Make GuiPlay treat cards that are both spells and creatures as
creatures and not spells.
