The engine always handled it as "REGENERATE" and thus had to be renamed. Its new name is "CANTREGEN". It has been tested excessively by me and Zethfox. Now all cards with the former "cantregenerate" work as they should.
- I also added a test for "CANTREGEN" (Incinerate).
- Added the new keyword "FOG" (by Zethfox).
This is an equivalent for "PREVENTALLCOMBATDAMAGE", which only worked for instants and sorceries. "Fog" works only for permanents and is used in combination with the newly introduced parameter "ONESHOT"!
- I also added 2 tests for "FOG" (Maze of Ith, Spore Frog).
Both additions lead to several issue fixes:
Fixed issue286.
Fixed issue328.
Fixed issue332.
Fixed issue416.
- Removed Demonic Torment, Gaseous Form, General's Kabuto, Sandskin. Those cards never worked and could even not be fixed with "FOG".
- Optimized the code of the dragon-lair land-cycle from PLS and added 2 tests for them.
- Added 8 successfully tested cards. Card list -> first comment.
- updated pt translation (thanks to almosthumane)
- Added/updated some Themes by Ilya B
- Added a random wallpaper loading at loading screen (see wallpapers.txt in Res/graphics)
- Saving decks and collection should now be a bit more secure (attempt at minimizing issue 393)
- IMPORTANT: Legendary is not an ability anymore, creating cards with super types should be much more natural. You can now say "type=Snow Land", and stuff like that. No backward compatibility!!!
Notes to programmers:
1. This feature uses an awful lot of copy-pasta, using "protetcion from()" as a base. While I'm learning the architecture, it's easier for me to have a dedicated single-purpose piece of code to work with, than trying to create multi-purpose code. I'm aware that this isn't a very elegant approach though, and I hope to be able to refactor additions like this into multi-purpose code once I have a better understanding of the architecture as a whole.
2. Please check the questions I'll add in my next code comments, specifically about AI integration and activated abilities / instants / sorceries.
3. I did have a crash (with the debugger complaining about stack corruption around the cd variable) during testing. I wasn't able to reproduce it though. I did have to clean the solution in-between when I updated to the primitives system, so perhaps there was this cleaning solved whatever corruption was in my files. I'm mentioning the issue in case someone has an idea on where my code might be risky (I'm still probne to making beginners mistakes).
- Card Primitives system. Check Royal Assassin in RV, 10E, M10
- Please review, is sets/primitives a good directory? Should we rename MTGCard into "CardPrint"?
- Unfortunately for now it is not possible to "override" a Primitive. A card that links to a primitive but also defines new "values" will create its own data and ignore the data in the "linked" primitive for the time being. I hope to solve that at some point...
- Code cleanup
- fix issue 142 . This will lead to other issues for some cards. These issues can be fixed by using targetcontroller/controller...etc
- Added a few cards
- removed some unused code. Please review!
- Added protection from() auto keyword. It is still possible to use protection from [color] in abilities, but when it is not possible, please use protection from([target]) in auto=
* The horsemanship ability literally required only one line of code, and could add an additional ~36 cards to Dr. Solomat's PT3 set. It seems functional, but someone please double check it anyways, as I've not worked with much of the actual game code yet.
- some performance improvements
- "daily build". The daily build was compiled in "profile" mode. If you have problems running the exe, or problems with Visual Studio please let me know
-Issue 31 fixed. Land and tokens don't use the stack anymore. Taking control of a card in opponent's battlefield doesn't trigger "spell cast" triggers either
* Numerous cache fixes, reduced filesystem access.
* Cache fails very gracefully.
* Cache is now a templated class, with individual caches per data-type.
* Much easier to extend.
* Extensively debugged. Try compiling with -DDEBUG_CACHE.
* Caches limits can be set on a per-item basis.
* hgeParticleSystemInfo are now cached, mana particles now fall back to defaults.
* Samples are not cached, but track filesystem misses using the cache backbone.
* Avatars are cached. Default baka avatar is now baka.jpg, to prevent collision with player.
A note on the retrieval types:
RETRIEVE_MANAGE puts a resource into a seperate, managed resource list.
Managed resources are guarenteed valid for the lifetime of the program.
Retrieving a managed quad promotes the associated texture to managed. Don't do that by mistake.
Calls to Resources.Refresh() will attempt to reload managed resources in place.
RETRIVE_LOCK (and by extension, RETRIEVE_VRAM), returns a resource after locking it.
A resource may have many locks, and remains in cache until they are all released.
If the resource is managed, it returns it unmodified.
A note on quads:
Unlike all other RetrieveWhatever() functions, the default behavior for RetrieveQuad is RETRIEVE_LOCK. Worse, Release(JQuad*) is slow, and will /always/ release one lock from the associated texture.
There's a long and complicated explanation for this, involving support for live relinking of textures to existing quads, but basically what it means is that we only use RetrieveQuad for quads we intend to store and later Release(). If a temporary quad is needed, the preferred method is to use NEW JQuad* and SAFE_DELETE with RetrieveTexture(). RetrieveTempQuad is also provided, but is only guaranteed until the next call to the cache.
Note that RetrieveCard has none of these problems.
This is pretty major, so there'll probably be something wrong with it... even though I did spend a few hours looking.
NOTES:
* If you've Retrieved it, don't delete it--- Use resources.Release(Whatever).
Textures automatically release subordinate quads.
* Most of the time, use resources.RetrieveQuad to grab a quad. Should handle everything for you.
RetrieveQuad will load the required texture, if needed.
Only managed resources have a resource name ("back", "simon", etc).
Managed resources can be retrieved with GetTexture/GetQuad/GetWhatever.
Non managed quads lookup by position/dimensions, defaulting to the whole texture.
* Use resources.RetrieveTexture only when you need to do something special to it.
Calling retrieve texture with RETRIEVE_MANAGE will permanently add a texture to the manager
RETRIEVE_LOCK and RETRIEVE_VRAM will lock a texture. It will not leave the cache until
Release(JTexture*) is called, or as a last resort during cache overflow.
* Try to only store (as a class member) pointers to textures retrieved with RETRIEVE_MANAGE.
All others may become invalid, although locked textures do have a high degree of stability. It's
pretty safe to store a locked texture if you're not going to load much between uses.
There's a lot going on here, so I might have missed something... but it runs through the test suite alright.
TODO:
* When called without any arguments, RetrieveQuad sometimes leaves a thin border around the image.
This can be bypassed by specifying a quad one or two pixels less than the image size. Why?
* I've had a crash while runing the Demo mode, something to do with receiveEventMinus?
This hasn't exactly reproduced on a clean SVN copy, (being a hang, rather than a crash) so
I've probably done something to worsen the problem somehow? I'll look into it tomorrow.
* Clean up lock/unlock system, memory usage. Streamline interface, consider phasing out calls using GetWhatever() format.
