Collectible Card Game Headquarters

Mok wrote:I'm just saying that if you have for example a set of images for a specific expansion and these are 348x256 or something, there's really no good reason to resize them to 288x232 unless you want to cut down on the file sizes.

I understand, and totally agree on what you’re saying on the images. And yes, one of the main reasons I chose to standardize the image size was to reduce the file size - whilst trying to maintain a reasonable encoding quality. But I kid you not - the current 2000 Card Art folders total sizes we're nearly a third larger on what they are now.

Ah, with you now - on the "Sleighted Color" and "Hack Color" fields.
I was looking at my Oracle manalink sheet earlier, looking for potential pitfalls in a simple ‘Search and Replace’ approach to adding the codes – colors or lands mentioned in the card name and repeated in the rules text, being the most obvious.
But your timely intervention has saved me the trouble. And for that, kind sir – I thank you.

I seem to remember reading somewhere the coding of the abilities only recognize 'non-' (with the hyphen) in the earlier cards rules text, and not ‘non’ (without the hyphen) used in the later cards. Is that correct?

Unfortunately the deck editor made by Jatill if I am not wrong, mainly to make custom decks....doesn't open it was a good tool to search cards it gives this error probably due to a lot more cards than it was made to support.
I really hope it will get fixed.

EDIT* Sonic you mean all the 12000+ cardartwork?

Sonic wrote:
I've got all the HQ artwork pre-sized to 288x232

So, is the csv ready for some changes or are you still modifying it? I'm not going to do much to it initially, just updating some missing info and preparing for some additions.

No problems here - edit away!

0rion79 wrote:Well done Sonic! And thanks for the info about "Argo": it is always nice to learn something new

Ah, the file is working but the game is overall very slow to start, not to run. It is a shame that we are totally without arts now and that it is still showing the old, bad GIF arts.

to fix the old pics to new version pics of non card art you just take and move your original .pic files into another folder and rename your .bmp files to .pic and viola working with new non card art. On snackos dll mod i left cardartnew folder and created the new CardartManalink folder and put the new pics in there.everything is working great in the deck builder although i haven't played any new games with the new beta fix but that will change tonight. Gotta try that relentless assault that Garg made a while back. Yea im that far back. Im just excited to see everybody helping as much as they can to achieve this

Edit: As i just tried to do some things in your duel art you will have to keep most of your files bmp for them to show up which is cool. You will however need to have a full set of .pic files for shandalar. they can be the new ones changed from .bmp to .pic and they will work along with having a folder called CardArtShandalar for pics. just copy the whole folder from manalink and it will work.
Also playing with a few new cards in a deck but i noticed that the rules engine card that pops up says ambush? does it still work like the rules engine or is it messed up for the time being?

EDIT V2: also noticed since im using beta 2k1 when i press play first it automatically goes to opponent? dosent let me play first.. i knew the computer cheats but damn so blatant lol.

Sonic wrote:No problems here - edit away!

Oops, it's going to take a while with all the extras. Some things are questionable (excuse me if you discussed it before and I haven't paid much attention to csv up until now, shame on me) - like tokens (and animated versions) mixed with the normal cards, "flipped" versions of cards that probably should be treated as tokens too (so they don't show up in deck builder) and kept together with the rest (at the end), some cards that are unlikely to be coded in any near future but are legal (planes, schemes) are missing while stuff like unglued(!) cards are in... Oh well, back to copy/paste tomorrow

@Sonic, thanks but I prefer to wait for the first pack with Alpha version to test.
@Mok, why questionable? I mean only for tokens and "animated" versions. Shouldn't it be more comfortable for us to have animated versions of cards close to their originals?

Hi,
I was checking the draft.c and didn't do much
but checked the latest csv that sonic posted and the expansions field values are still limited, at least from what I understood, so I think no major change in the logic can be made yet.
One thing, if the expansions field is expanded the exp rarity must be expanded also, but it would be far better to enum the expansion sets in order to avoid unecessary fors and scanning tables.
In this case the enum should also be relevant to the bit showing the exp rarity, if the same logic is adopted.

0rion79 wrote:@Mok, why questionable? I mean only for tokens and "animated" versions. Shouldn't it be more comfortable for us to have animated versions of cards close to their originals?

In theory yes, in practice it's not so hard to look for all tokens/effects/not real cards at the end of the file instead of in the middle of normal cards and mixing them makes it harder to change large number of card at once in cases where you cannot do it automatically. But it doesn't matter tbh, it was my observation not a call for any changes, I won't touch the order.

foolosopher wrote:Hi,
I was checking the draft.c and didn't do much
but checked the latest csv that sonic posted and the expansions field values are still limited, at least from what I understood, so I think no major change in the logic can be made yet.
One thing, if the expansions field is expanded the exp rarity must be expanded also, but it would be far better to enum the expansion sets in order to avoid unecessary fors and scanning tables.
In this case the enum should also be relevant to the bit showing the exp rarity, if the same logic is adopted.

This was to be expected. The original coded cards, compiled from previous csv files, had different expansion codes in different versions of the game (Con, Lim, GY, NL). And having 90+ card sets listed in the Oracle, there was no way to determine which sets should constitute being grouped under which code value. So after compiling all the separate the files into a single csv - the easiest way to standardize the codes was to cut and paste the 'expansion column' from Orion79's 'finalized' card order file - as this file also contained the 'Token' expansion code (1000h) in the correct placement. Which at present is probably more important to testing.

As I've mentioned - I've got oracle set up as a manalink csv - the rarity of the cards and the sets they appeared in is included (but needs to be extracted). But without knowing the form of the new 'exp rarity' code, as in, how will the 90+ sets be grouped to fit into the code - there was little point of compiling the data from the Oracle file at this stage.

Simply - the brief we got from the coders, was just give us a csv to get the game up and running for testing at the moment. All this specific rarity stuff will come later I presume.

0rion79 wrote:@Sonic, thanks but I prefer to wait for the first pack with Alpha version to test.

I think Mok's 20 steps ahead of us csv monkeys.
Whilst we'd be happy expanding on what we've already got - he's planing a rival to challenge 'Dual of the Planeswalkers'.
I'd suggest we let him run with it. We can ride in on his coat tails - if his brain slows down and we can catch up.

Hey, I posted it here for all to see and take into account, so that we might make a decision on this.
We have
uint32_t rarity;
uint32_t expansion
in card_ptr_t. That is 32 bits, if we could reserve 2-4bits for rarity, the rest 28bits correspond to 268435456 numbers. Even if some values are reserved, I believe that they are enough. For the draft this approach can be done separately. The questions are if it is necessary to do it in the exe and if it can be done.
The combination of the values can be done with bitwise operators and it's fairly easy in c.
if we follow this approach, whichever field we choose, the expansion enum can be defined arbitrarily, including reserved values and still have no problem.

As for the "order" of the cards, as I already said that the "animated" versions of some permanents needs to stay "close" to their counterparts for coding purposes : it's juts more easy to call ID+1 or ID-1 that making an endless series of calls to specific IDS.

Gargaroz wrote:As for the "order" of the cards, as I already said that the "animated" versions of some permanents needs to stay "close" to their counterparts for coding purposes : it's juts more easy to call ID+1 or ID-1 that making an endless series of calls to specific IDS.

This is asking for trouble, really. What's so bad about calling the animated version by their CARD_ID instead of some vague +1 stuff.

Sonic wrote:

0rion79 wrote:@Sonic, thanks but I prefer to wait for the first pack with Alpha version to test.

I think Mok's 20 steps ahead of us csv monkeys.
Whilst we'd be happy expanding on what we've already got - he's planing a rival to challenge 'Dual of the Planeswalkers'.
I'd suggest we let him run with it. We can ride in on his coat tails - if his brain slows down and we can catch up.

Nah, I just think that making "first" csv as clean and readable as possible will only benefit us in the future (when adding new cards, when a new programmer wants to help but have no experience with the project etc.). I also plan to remove as many direct CARD_ID uses in the exe as possible, so the order that has to be preserved is limited to the original cards (pre ML 2.0 even). Hardcoding stuff is bad, period. Unfortunately with exe in precompiled form it'd take ages to remove the need for specific order of the original cards