Collectible Card Game Headquarters

If we want to do January 31st, are we merging Born of the Gods cards back in before that? (Since that's the day before prerelease?)

Agetian wrote:Does anyone have any idea why this might be happening?.. I don't think it used to happen before, at least I've just noticed this recently.

Max mtg wrote:I've changed a lot in CardDb internals, so if anything went wrong with sets assignment in decks being read or deck recognition, please let me know

Thanks for the bug report
Fixed with r24531.

Thanks for the fix, Max! Definitely works in Constructed. Something is still off with the Quest Mode art indices though - they are still randomized and it looks like they're possibly generated with the art index 0 in mind or something (sadly, can't check the code base at the moment to be sure). For instance, upon first generation the quest card pool will only contain cards with three art indexes (even for editions that have four). Upon reloading Forge many of them will get "consolidated" into groups with two different art indices or one art index.

- Agetian

did it become better with r24532?

Yes, the quest indices are definitely preserved now, but there's still something odd going on. It looks like the card pool is not generated with the proper art index (1-based) in mind. I looked at QuestUtilCards.java:130 and found a piece of code that, indeed, generated art indexes with 0 in mind. I tried changing that code into this:

Code: Select all

            if (Singletons.getModel().getPreferences().getPrefBoolean(FPref.UI_RANDOM_ART_IN_POOLS)) {
                int[] artGroups = MyRandom.splitIntoRandomGroups(nBasic, artCount);

                for (int i = 0; i < artGroups.length; i++) {
                    pool.add(db.getCard(landName, landCode, i + 1), artGroups[i]);
                }
            } else {
                pool.add(db.getCard(landName, landCode, artCount > 1 ? MyRandom.getRandom().nextInt(artCount + 1) : 1), nBasic);
            }


However, that introduced a really weird effect - sometimes, a card would be generated in the card pool that would have its art randomized every time I clicked on it (e.g. there would be five basic lands and the fifth one would change its art every time I click on it). Not sure why - with the previous (0-based) code, it used to "under-generate" the lands as far as art indices went. But with the change to 1-based it's "overgenerating" them or something, potentially putting a card in it which has a non-existent art index or something?..

- Agetian

By the way, the "art change on click" disease is affecting other modes too, so it looks it's something bigger than just the quest mode art index generation being off... For instance, try generating a sealed deck and then enter the sealed deck editor. Try clicking on all four lands. Usually the last land will change its art on clicking (if it doesn't, try choosing it again - select another land and then this land again, chances are it's just changed it to the same art index as before).

- Agetian

MyRandom.getRandom().nextInt(artCount + 1)
returns 0..artCount

you need 1 + MyRandom.getRandom().nextInt(artCount)

Oh, yep, got that fixed! Sadly, that's not the reason those random-art-on-click lands are appearing (since this particular code only fires when the fixed art option is chosen), that's got to be something else... :\

P.S. Constructed is affected too, so it's a generic issue of some kind. It looks like art indices 1,2,3,4 are being loaded or processed somewhere as 0,1,2,3, thus causing the land with art index 0 to always change their art on every click. Sadly, not sure where this might happen exactly.

- Agetian

It looks like I finally figured out how to fix the problem on my end. I had to create a whole new workspace and then import the project into this new workspace.

I just ran a snapshot build and deploy maven command that is now pointed to the new workspace. This time there is no error reporting that my workspace and or project directories were created while using Subversion 1.6.

I should be able to do the beta release this Friday.

Max and I have figured out and fixed the remaining issues with card images related to multiple art support yesterday, so this feature appears to be in good order (I'm running some last minute tests, but there's likely to be nothing major). So, as far as this feature goes, it's good for the public release on 31st.

- Agetian

There remains a minor issue with ordering of cards that differ only by artIndex.
Let's have a look at this deck of forests:

Code: Select all

[metadata]
Name=forests
[Main]
1 Forest|9ED|1
2 Forest|9ED|2
3 Forest|9ED|3
4 Forest|9ED|4


When loaded into deck editor it appears randomly ordered, not 1-2-3-4 as one could expect. Moreover, there are no means to distinguish different arts without looking at the picture, and there's no column to order cards by art indices.

I do not have a solid soultion, just a couple of ideas.
1. Add collector's number to PaperCard and a column into ItemManager to show it. Then it'll be possible to order by name then collectors number. There are res/edition/*.txt files, so the collector's number for a card will be the seqential number of a line declaring the very card. The problem is: Only "Dragon's Maze" and newer sets list cards in accordance with their collector's number, so the earlier editions' files have to be rearranged somehow (with a Python script or something like that).

2. Have names of cards with artIndex >=2 become different than names of cards with index = 1 for the purpose of comparison. There's a hack I am talking about:

Code: Select all

    NAME("Name", "Name", 180, -1, -1, SortState.ASC, new ItemCellRenderer(),
            new Function<Entry<InventoryItem, Integer>, Comparable<?>>() {
                @Override
                public Comparable<?> apply(final Entry<InventoryItem, Integer> from) {
                    String name =  from.getKey().getName();
                    int ai = from.getKey() instanceof IPaperCard ? ((IPaperCard)from.getKey()).getArtIndex() : 1;
                    if ( ai > 1 ) {
                        StringBuilder sb = new StringBuilder(name);
                        for(int i = ai; i > 1; i--)
                            sb.append(' ');
                        return sb.toString();
                    }
                    else
                        return name;
                }
            },
            new Function<Entry<? extends InventoryItem, Integer>, Object>() {
                @Override
                public Object apply(final Entry<? extends InventoryItem, Integer> from) {
                    String name = from.getKey().getName();
                    return name.contains("AE") ? AE_FINDER.matcher(name).replaceAll("\u00C6") : name;
                }
            }),


Unfortunatelly, this will show cards ordered by name then set different from what was expected (ie:Forest|M12|1, ie:Forest|M13|1, Forest|M14|1, ie:Forest|M12|2, Forest|M13|2, Forest|M14|2, ie:Forest|M12|3, ...)

So I see no easy solution for that problem.
The first option I've found involves some edition files processing that definitely needs automation,
The second one will bring odd ordering... not much better than what we originally have.

What do you think of that? Are there any other solutions?

Max, I don't think it is really an issue that the art indices aren't sorted. The purpose of the feature is to be able to stipulate a specific art for the card and it does that perfectly. Can you think of any reason where somebody would want to sort by art index? I think the only time someone would even notice is when manually editing a deck created in the editor in which case I assume the ordering would be out. That's not really a problem unless the deck editor has OCD. That's my personal opinion anyway.

Out of interest, has anyone tested this in a setup where they only have LQ images instead of set images?