Forge version 1.5.11
Post MTG Forge Related Programming Questions Here
Moderators: timmermac, Blacksmith, KrazyTheFox, Agetian, friarsol, CCGHQ Admins
Re: Forge version 1.5.11
by friarsol » 27 Jan 2014, 17:29
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?)
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Forge version 1.5.11
by Max mtg » 27 Jan 2014, 17:40
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.
Thanks for the bug reportMax 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
Fixed with r24531.
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Forge version 1.5.11
by Agetian » 27 Jan 2014, 17:50
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
- Agetian
- Agetian
- Programmer
- Posts: 3472
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 561 times
Re: Forge version 1.5.11
by Max mtg » 27 Jan 2014, 17:53
did it become better with r24532?
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Forge version 1.5.11
by Agetian » 27 Jan 2014, 18:05
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:
- Agetian
- 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);
}
- Agetian
- Agetian
- Programmer
- Posts: 3472
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 561 times
Re: Forge version 1.5.11
by Agetian » 27 Jan 2014, 18:07
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
- Agetian
- Agetian
- Programmer
- Posts: 3472
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 561 times
Re: Forge version 1.5.11
by Max mtg » 27 Jan 2014, 18:17
MyRandom.getRandom().nextInt(artCount + 1)
returns 0..artCount
you need 1 + MyRandom.getRandom().nextInt(artCount)
returns 0..artCount
you need 1 + MyRandom.getRandom().nextInt(artCount)
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Forge version 1.5.11
by Agetian » 27 Jan 2014, 18:20
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
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
- Agetian
- Programmer
- Posts: 3472
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 561 times
Re: Forge version 1.5.11
by Chris H. » 29 Jan 2014, 00:29
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.
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.
-
Chris H. - Forge Moderator
- Posts: 6320
- Joined: 04 Nov 2008, 12:11
- Location: Mac OS X Yosemite
- Has thanked: 644 times
- Been thanked: 643 times
Re: Forge version 1.5.11
by Agetian » 29 Jan 2014, 04:20
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
- Agetian
- Agetian
- Programmer
- Posts: 3472
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 561 times
Re: Forge version 1.5.11
by Max mtg » 29 Jan 2014, 08:12
There remains a minor issue with ordering of cards that differ only by artIndex.
Let's have a look at this deck of forests:
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:
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?
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
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;
}
}),
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?
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Forge version 1.5.11
by moomarc » 29 Jan 2014, 11:14
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?
Out of interest, has anyone tested this in a setup where they only have LQ images instead of set images?
-Marc
-
moomarc - Pixel Commander
- Posts: 2091
- Joined: 04 Jun 2010, 15:22
- Location: Johannesburg, South Africa
- Has thanked: 371 times
- Been thanked: 372 times
Who is online
Users browsing this forum: No registered users and 115 guests