Collectible Card Game Headquarters

Hmmm... apparently the image code does not play well with the HQ full card scans. I tried Sprouting Thrinax in a test deck and it did not scale down to the size that Incantus normally uses. The image was far too large and causes usability issues when you try to zoom in and read the text of the card at full size.

If you want to reproduce I used the card image for Sprouting Thrinax that can be found here.

As I'm thinking about this... trying to use the HQ scans in Incantus is probably not worth the effort. So to anyone who reads this I suggest you don't spend time trying it. Their directory structure is different, their file naming convention is different, and the real nail in the coffin (for me at least) is the size of the images. HQ scans are HUGE compared to current Incantus implementation. Card_images.db was about 23MB for the old 6000+ cardlist, but HQ scans are over 45MB for Shards of Alara alone (!)

True, each HQ set will be 40-50 MB, this is hardly a problem for the tens of thousands of happy HQ collection owners.
That aside, Incantus should be able to seamlessly scale images of any size. That it doesn't is an issue to be addressed at some point.

<edit> spelling

Been a long time follower of this site and Incantus. But this is my first post. I'm loving the new version and have played a few games, with the cards included. Being a programmer myself i would love to begin creating my own cards, but i seem to remember that we should wait for another release since you were moving a few things around. Is still something to take into account?

Hello Xana,

Good to see another Incantus enthusiast. Especially one with programming experience.

There is nothing to stop you from programming cards, however, MK has said it's possible some things may change that would make all cards break again in a future release. The engine changes in v0.7.0 caused thousands of cards to be unusable in their current form so don't go on any missions to implement all Type 2 cards or something crazy like that.

That said - if you have some cards you want to implement you could probably load your decklist and cut/paste the relevant card code in this new release. For example it might be possible to code all of the cards for Jund now.

There's nothing to stop you from implementing cards (in fact, in the NEW VERSION (cue fanfare) it reads multiple cards from a single file instead of each card being read from its own file (cluttering up your cards folder)). Just don't expect them to work with future versions. In other words, don't get too attached.



For those of you who missed it, there's a new version!

I dunno... having each card in a separate file makes it easy to find the one you want. *shrug*

Two releases in the same week, huzzah! Will let you know if I can break anything.

I am posting in this topic since it's not really a bug. However, I've noticed that this release does not make use of set names in the card headers. This would prevent implementation of Apocalypse Chime or City in a Bottle. Is there a reason to keep set name out of the card headers?

juzamjedi wrote:I am posting in this topic since it's not really a bug. However, I've noticed that this release does not make use of set names in the card headers. This would prevent implementation of Apocalypse Chime or City in a Bottle. Is there a reason to keep set name out of the card headers?

Um... because.

Seriously, they were mostly unused in older versions (I certainly didn't see anyone code City in a Bottle, and most cards were just left with a blank string for their set), and the current auto-code-generator doesn't even bother including them. Given that it's just those two cards, you could simply only define a set for Arabian Nights and Homelands cards. Nothing should stop you from specifying the attribute even though it's not a default for the template (same goes with types, supertypes, and subtypes... just because some cards don't define them doesn't mean no cards can).

And Golgothian Sylex, don't forget about that

Plus there is the problem of some cards being in multiple sets. Although that could probably be handled the same as other characteristics. But I agree with MageKing17, it's probably just easier to hardcode the valid cards for those sets. Although if you copy an Antiquities creature with Clone, is it affected by Golgothian Sylex?

Yes.

Huggybaby wrote:Incantus should be able to seamlessly scale images of any size. That it doesn't is an issue to be addressed at some point.

I just noticed this, and it got me thinking.

I know I've said (repeatedly) that I don't understand the UI code, but I do think that some way to deal with wrong-sized images should be included, regardless of whether or not I have the skill to seamlessly integrate it with the UI. It occurs to me that there is a script in the source folder that was meant to resize HQ images; it uses a Mac-only library, but some sort of adaption using another library should be possible. Granted, having to run the images through a converter isn't a whole lot better than resizing them yourself... but at least it would be automated (I spent far too much time cropping custom card images in Photoshop). I could probably whip something together in Pygame, if nothing else... it has image-transformation code.

Of course, we should just fix the UI to not choke on card images that aren't 200x285 pixels.

Forge in the last couple of weeks implemented the lanczos algorithm and Snacko could probably throw some code your way, he seems to know something about every language used on this board.

Feature request: choosing a card by name.

I would like to be able to play Cabal Therapy. Can we add in the functionality that allows typing in a name or selecting from a list?

juzamjedi wrote:Feature request: choosing a card by name.

I would like to be able to play Cabal Therapy. Can we add in the functionality that allows typing in a name or selecting from a list?

As that requires a UI change... not easily. It's been on the to-do list for some time (as well as a method of selecting a creature type that's a little less hackish than the current method).