Collectible Card Game Headquarters

sadlyblue wrote:Hi,
Time for a new update:
http://www.mediafire.com/?3u3jd1n2vrci8me

I added 3 more decks:
- Tempered Virtue (quite simple white artifact/token weenie)
- Modern Eminent Domain (a blue and red control deck)
- Land Crushing (a blue, red and green land deck)

Life from a Loam crashes the game at the end of the match. Couldn't find the error. If you have a working one, or know were the error is, pls let me know.

Thanks

I'm only downloading your pack now (70+MB, wow!), so I haven't seen the card yet, but theFireMind included Life from the Loam with his cards a while ago, here. I haven't tested it, but his stuff is usually pretty good. I'm sorry that I didn't think to mention it before when you mentioned your troubles.

Thanks. Somehow i didn't saw that post.
Will include it on my next release.

You've released a great pack, Blue! Thanks a lot. I haven't ironed out the bugs in my own decks, so I'm not sure I can help much finding them in yours, but... the end-of-match crashes in my decks almost always seem to be related to spawning tokens without first registering them. The few cards you spawn tokens with (splicers, lingering, call, gond, shrine) all seem to be registering their tokens in what seems to be the correct fashion, but the lands are a bit mixed up.

Avacyn's Pilgrim produces white mana but reserves a green token.
Blackcleave Cliff produces R/B mana but reserves B/W tokens.
Cascade Bluffs produces colorless mana but doesn't reserve a token.
Copperline Gorge produces R/G mana but reserves B/W tokens.
Darkslick Shores produces U/B mana but reserves B/W tokens.
Hinterland Harbor produces G/U mana but reserves W/U tokens.
Razorverge Thicket produces G/U mana but reserves B/W tokens.
Rootbound Crag produces G/R mana but reserves W/U tokens.

I may be wrong about the details, because I just did a few quick grep runs to see what's up, but I think that any of those mismatches could cause an end-of-game crash. They're really hard to debug, too, since it's possible that - for example - Cascade Bluffs probably won't cause a crash if one of your working colorless lands happens to hit the battlefield first. Either way, it's probably worth switching them around before banging your head about debugging loam.

That said, I checked out your loam card and it uses the thefiremind's code - you just happened to get it from a third party (me). I suspected as much once I cast thirst and had to discard before dredging. _DREDGE_FIREMIND_888262904 is thefiremind's dredge mechanic, I just renamed the card so that if he eventually (hopefully) releases some deck packs there wouldn't be a conflict between the two. If you use it, your wad will be dependent on mine. That's fine, but you might wanna' advise folks. If you'd rather copy it into your own wad, that's also fine (I can't speak for thefiremind, but I imagine it would please him for it to be well used) - but it would probably be wise to rename it so that it doesn't create name-clashes w/ other mods.

Your Seismic Assault deck is really much more fun to play than my Cheesy Swans. I look forward to seeing what else you can come up with! Keep up the great work, and thanks for all the help you've given me to date.

Regards,
Eglin

edit: where is the ColourTable you use in Cascading Bluffs defined?

Thanks for the reply.
I'll fix those problems.

The mana table is not my work. It's in the 7777_FUNC.lol by kevlahnota. He has done a lot of good work at moding this game.

Feel free to use my code wherever and whenever you need it, I'm happy if I can be helpful to other modders.

About the chance of a DLC from me, I could actually release it, but there's a "logistic" problem: it's bigger than the core! I would solve it if someone knew how to convert the card pictures to TDX in the same format used by the game. Gibbed tools make huge TDX files (probably uncompressed?), while Paint.NET makes TDX files with the right size, but they are readable by the game only when used as deck images or avatars, not when used as card pictures: in fact, by opening it with a hex editor I noticed that the header is a little different.

sadlyblue wrote:Thanks for the reply.
I'll fix those problems.

The mana table is not my work. It's in the 7777_FUNC.lol by kevlahnota. He has done a lot of good work at moding this game.

I agree - Kev is the man. My 7777_func file has a manaTable, but no ColourTable.

Its in the 1111.lol. Since i have all in one folder for easier search, sometimes i mix things up.
I took the example used in FIGURE_OF_DESTINY_ED.XML.

sadlyblue wrote:Its in the 1111.lol. Since i have all in one folder for easier search, sometimes i mix things up.
I took the example used in FIGURE_OF_DESTINY_ED.XML.

I believe that the 1111 wad is by Casper, not Kev. If you use his script, you need to make sure other people have it installed. I don't, for example, so your card will be broken if I try to use it.

thefiremind wrote:Feel free to use my code wherever and whenever you need it, I'm happy if I can be helpful to other modders. :wink:

About the chance of a DLC from me, I could actually release it, but there's a "logistic" problem: it's bigger than the core! I would solve it if someone knew how to convert the card pictures to TDX in the same format used by the game. Gibbed tools make huge TDX files (probably uncompressed?), while Paint.NET makes TDX files with the right size, but they are readable by the game only when used as deck images or avatars, not when used as card pictures: in fact, by opening it with a hex editor I noticed that the header is a little different.

You mean that the WAD is too large to be loaded by the game? Try using WADPROGRAM to pack it instead of Gibbed's tools. It compresses the wads just fine, and it is also much less prone to crashing. For the Paint.NET stuff, I can't help you.

Eglin wrote:You mean that the WAD is too large to be loaded by the game? Try using WADPROGRAM to pack it instead of Gibbed's tools. It compresses the wads just fine, and it is also much less prone to crashing. For the Paint.NET stuff, I can't help you.

No, the game loads it fine, it's just that it would take a lot of time to upload the WAD with my connection, and I think there must be a way to obtain the same TDX format as the original TDX files, I just don't know how.

thefiremind wrote:

Eglin wrote:You mean that the WAD is too large to be loaded by the game? Try using WADPROGRAM to pack it instead of Gibbed's tools. It compresses the wads just fine, and it is also much less prone to crashing. For the Paint.NET stuff, I can't help you.

No, the game loads it fine, it's just that it would take a lot of time to upload the WAD with my connection, and I think there must be a way to obtain the same TDX format as the original TDX files, I just don't know how.

If your upload bandwidth is the problem, then I am completely unable to understand why compressing the images individually is advantageous to compressing the wad as a whole, but whatever. I'm not terribly comfortable uploading copyrighted pictures either, despite the project being strictly educational and the fact that they're already plastered all over the web elsewhere, so I won't push the matter.

ps, sorry for hijacking your thread, Blue.

thefiremind wrote:No, the game loads it fine, it's just that it would take a lot of time to upload the WAD with my connection, and I think there must be a way to obtain the same TDX format as the original TDX files, I just don't know how.

One thing i noticed is that even if your compress the PNG, the TDX will have the same size. So it really stores the TDX uncompressed, and decompresses the PNG.
Why don't you try uploading multipart. And if you want to put all together and and upload, just let me know. But multipart is easy to download with Jdownloader, and similar.

Eglin wrote:ps, sorry for hijacking your thread, Blue.

That's ok.

Eglin wrote:I am completely unable to understand why compressing the images individually is advantageous to compressing the wad as a whole

Maybe I explained it bad...
The TDX files produced by Gibbed Tools are big in size, probably because internally uncompressed, but the game recognizes them perfectly.
The TDX files produced by Paint.NET have the same size as the original TDX files you can find in the core, so they are smaller, but the header is slightly different, and the game doesn't recognize them when used as card pictures. Maybe they are internally compressed in a different way, I don't know the details.
If I could find a way to produce TDX files that can be read by the game and have the same size as the original TDX files, the resulting WAD file would be smaller, because every TDX file in it would be smaller. And yes, I would gladly reconvert every single picture for the sake of it.
Is it clear now?

P.S.: what's really bugging me out is that kev found a way to do this: if you look at the TDX files in his DLC 7777, they are all about 126 KB! I asked him via PM but never replied.

thefiremind wrote:

Eglin wrote:I am completely unable to understand why compressing the images individually is advantageous to compressing the wad as a whole

Maybe I explained it bad... #-o
The TDX files produced by Gibbed Tools are big in size, probably because internally uncompressed, but the game recognizes them perfectly.
The TDX files produced by Paint.NET have the same size as the original TDX files you can find in the core, so they are smaller, but the header is slightly different, and the game doesn't recognize them when used as card pictures. Maybe they are internally compressed in a different way, I don't know the details.
If I could find a way to produce TDX files that can be read by the game and have the same size as the original TDX files, the resulting WAD file would be smaller, because every TDX file in it would be smaller. And yes, I would gladly reconvert every single picture for the sake of it.
Is it clear now? :wink:

P.S.: what's really bugging me out is that kev found a way to do this: if you look at the TDX files in his DLC 7777, they are all about 126 KB! I asked him via PM but never replied.

OK, I owe you an apology. I believed, mistakenly, that compressing the wad using WADPROGRAM would reduce the net file-size to the same size as compressing the images individually. I guess my reasoning was that if the wad file can't be compressed with archiving software, like 7-Zip, that it didn't matter. What I failed to consider was that the compression method used for TDX files is a lossy compression.

I poked around the files a little bit today and wrote a small program that can convert uncompressed TDX files to compressed ones. The caveat is that the images must be exactly 512*376. With a little tinkering it is quite likely to make any image with dimensions in a multiple of four to work, but I'm unlikely to pursue it. IrfanView an other programs can batch resize pretty easily. My program does not convert from PNG or other formats, and it will probably crash out if you feed it something it doesn't expect. For me, it's not an issue - although the conversion to compressed TDX files is a lossy one, the conversion from it is not, and the compression is exactly repeatable. Thus, repeated compression/decompression cycles will not degrade the image. You can download my program, along with its C++ source here (57KB).

Cheers,
Eglin

pss sorry, again, for hijacking your thread, Blue.

I've tried your program, and worked like a charm.
It reduced the total size by at least 40% even when packed with wadprogram.
And what i tested so far there's no problem in game.
Next release will be smaller in size.
Great job.