Unified picture resource handling in MA and Forge
Moderators: timmermac, Agetian, friarsol, Blacksmith, KrazyTheFox, CCGHQ Admins
21 posts
• Page 2 of 2 • 1, 2
Re: Unified picture resource handling in MA and Forge
by myk » 13 Feb 2013, 01:12
I'd suggest finding out how the filenames are being used. Who is calling buildFilename and how are they using the string? Trace it back from the point where the image should be displayed but isn't
- myk
- Posts: 439
- Joined: 17 Jan 2013, 02:39
- Location: California
- Has thanked: 38 times
- Been thanked: 57 times
Re: Unified picture resource handling in MA and Forge
by Chris H. » 13 Feb 2013, 04:15
I have a several year old iMac with a 3.06 GHz Intel Core 2 Duo, 6 GB RAM and a 7200 RPM hard drive. I have a copy of Forge using the HQ pics and have not noticed any problems. My computer is unlikely to get bogged down with page ins and page outs while playing Forge and it should not cause too much of a slow down when it does.
A lot of work was done last year reducing the memory requirements and we may be at a point where only the low end netbooks are likely to notice a slow down. The old Java Heap Space crash reports should no longer occur.
The general feeling is that we should not encourage people to only use the HQ pics as this could cause a problem with the low end netbooks. As we add in additional UI elements and sounds and so forth the memory requirements could increase. HQ pics is an option but we do not limit people to just the HQ pics.
The /res/pics_link dir and its contents should probably be removed. We do tend to have old material left in the project that no longer serves a useful purpose. At times someone will remove some of this old cruft. But the devs typically would rather spend their limited free time working on new material.
A lot of work was done last year reducing the memory requirements and we may be at a point where only the low end netbooks are likely to notice a slow down. The old Java Heap Space crash reports should no longer occur.
The general feeling is that we should not encourage people to only use the HQ pics as this could cause a problem with the low end netbooks. As we add in additional UI elements and sounds and so forth the memory requirements could increase. HQ pics is an option but we do not limit people to just the HQ pics.
The /res/pics_link dir and its contents should probably be removed. We do tend to have old material left in the project that no longer serves a useful purpose. At times someone will remove some of this old cruft. But the devs typically would rather spend their limited free time working on new material.
-
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: Unified picture resource handling in MA and Forge
by Max mtg » 13 Feb 2013, 07:22
out of pic_links only tokens file seems to contain correct data - links to magiccards.info
As for that code chunk - I object against modifications to setdata.txt. The very file now contains only essential data related to the set (I would even throw away the index column and rely on lines ordering in file). The how some other apps store their pictures is not a property of any set, that's product a of imagination of developers of that program - I mean that data MUST NOT be stored in setinfo.txt. That would be like adding a column with chineese name of a set. But wait, chineese translation is to be found in a vocabulary - and that's correct!
So if anyone wants some custom locations of per-set images - let them be kept in a separate dictionary file that gets read into a java.util.Map. Forge starts, loads that dictionary (if it's present) and if it is, uses that paths to serve picures
As for that code chunk - I object against modifications to setdata.txt. The very file now contains only essential data related to the set (I would even throw away the index column and rely on lines ordering in file). The how some other apps store their pictures is not a property of any set, that's product a of imagination of developers of that program - I mean that data MUST NOT be stored in setinfo.txt. That would be like adding a column with chineese name of a set. But wait, chineese translation is to be found in a vocabulary - and that's correct!
So if anyone wants some custom locations of per-set images - let them be kept in a separate dictionary file that gets read into a java.util.Map. Forge starts, loads that dictionary (if it's present) and if it is, uses that paths to serve picures
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: Unified picture resource handling in MA and Forge
by Max mtg » 17 Mar 2013, 12:46
We have some progress in this branch - viewtopic.php?p=112767#p112767 - The next release is expected to feature profile migration and provide more flexible settings for custom image collections.
I think that the new option will enable you to use that MA collection with Forge.
I think that the new option will enable you to use that MA collection with Forge.
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: Unified picture resource handling in MA and Forge
by LordHelmchen » 08 Apr 2013, 22:36
The new resource directory handling of forge >= 1.3.11 made this look a lot more doable than before. My changes so far had the downloader report only 476 missing pictures, 233 of which were tokens. Those were downloaded without problems and, though they're technically duplicates as well, are probably best left as duplicates for now.
What I did so far:
What I did so far:
- forge.profile.properties | Open
- readMApictures-v2.patch | Open
- still to be solved | Open
- LordHelmchen
- Posts: 125
- Joined: 21 Aug 2012, 16:06
- Has thanked: 21 times
- Been thanked: 32 times
Re: Unified picture resource handling in MA and Forge
by LordHelmchen » 09 Jun 2013, 21:53
Some small progress on this:
- Include Dragon's Maze in cardPicsSubDirs within forge.profile.properties:
- cardPicsSubDirs | Open
- Goblin Hero changed some filenames within the zips, as Magic Album is case agnostic whereas Forge apparently isn't.
I think there are three more cards (Alpha and Revised: Will-o'-the-Wisp; Dragon's Maze: Bred for the Hunt) with just upper/lower case mismatch. - Updated the patch to find split cards' images in the MA zips.
- readMApictures-v2.1.patch | Open
- LordHelmchen
- Posts: 125
- Joined: 21 Aug 2012, 16:06
- Has thanked: 21 times
- Been thanked: 32 times
21 posts
• Page 2 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 97 guests