Collectible Card Game Headquarters

Chris H. wrote:Ran another test this morning using the newest branch build.

This time I am getting 10 pics that need to be downloaded after the import data. Nine of the pics will download:

Aretopolis.jpg
Chaotic AEther.jpg
Feeding Grounds.jpg
Haakon, Stromgald Scourge Avatar.full.jpg
Jaya Ballard Avatar.full.jpg
Mutual Epiphany.jpg
Planewide Disaster.jpg
Undercity Reaches.jpg

and one pic will not be download and is being skipped:

Horizon Boughs.jpg

For the ones that will download, are those the default pics or the set pics? Horizon Boughs has a broken link in the cardsfolder/h/horizon_boughs.txt file as reported here

myk wrote:For the ones that will download, are those the default pics or the set pics? Horizon Boughs has a broken link in the cardsfolder/h/horizon_boughs.txt file as reported here

 
Those pics were downloaded using the non-set button and are the default pics. There were no set pics involved in my data import tests as I am trying to keep things simple at this time.

The strange thing here is that my latest copy of the trunk snapshot build insists that all of the pics were downloaded and no new ones are available.

Yet when I import them into the branch snapshot version the branch Forge wants to download these 10 pics. I guess that the pic downloader code has seen a substantial re-write and this might explain what I am seeing.

It appears that some of the cards listed are in my trunk snapshot build pics folder and were not imported over to the branch snapshot version:

chaotic_aether.jpg
mutual_epiphany.jpg
planewide_disaster.jpg

gotcha -- I'm looking into it. In the meantime, I have a question. Should flippable cards like nezumi_graverobber_nighteyes_the_desecrator.txt have pictures for both "sides" downloaded? The card in question has pic urls for both "faces", but the picture is the same -- i.e. the second one is the same orientation as the first. Should nezumi_graverobber_nighteyes_the_desecrator.txt not have a second SVar:Picture defined, or are we just linking to the wrong picture?

edit: I see other flippable cards have flipped images for their second image. It looks like wizards.com just has the wrong image at that link.

ok, I looked into the cards that are newly downloaded. It looks like it was just a bug in the old code that they weren't getting downloaded, and now the bug is fixed. Try moving your set pics out of the trunk res/pics folder and starting forge, then viewing one of those cards in the deck editor. You can see that current trunk has no default picture downloaded for those cards (which is why they aren't getting imported).

The last three cards that weren't getting imported are all phenomenon cards. I probably just missed a condition check somewhere and was only checking for isPlane(). I'll get that fixed. edit: yup. found. fixed. I'll upload it as soon as I get the case insensitive comparisons in.

Ok, the case insensitive comparisons are in. This should get all the non-normalized-case names and normalize them on import as well. I double-checked that after import the only images missing are the ones that truly weren't there in the first place (though please tell me if this is still not the case on your system).

new version here

For those just looking at this now, here's the background for what's going on:

test procedure | Open

I'm gearing up to merge in the work I've been doing to separate the program data from user-writable data. I have taken care to make the data migration safe and as painless as possible, but I was hoping to get validation from a few additional users that (1) everything gets migrated correctly and (2) what is happening is clearly communicated. If anyone has a few minutes, I would really appreciate your help! The procedure is safe -- you aren't going to lose any data even if things go horribly wrong. Just follow the following steps:

1. Copy your entire forge installation to another location on your hard drive. Be sure to copy from the installation root so you include all your picture files, quest data, and decks.
2. Download the snapshot build of my branch from http://cardforge.org/releases/snapshots/forge/branches/myk-separate-writable-data/current/
3. Install it over the copy that you made
4. Run it! The prompts that automatically come up should guide you the rest of the way.

Once the migration is done, play with Forge a bit as you usually do. Make sure all your data is there, and please report back on your experiences! As I fix any bugs that come up and make further enhancements, I'll upload updated versions and write a notification here, but the link above will always get you to the most recent version.

I reran the test and this time these 3 cards were moved as part of the import data process:

chaotic_aether.jpg
mutual_epiphany.jpg
planewide_disaster.jpg

excellent. Ok, let's see if we can get verification from one or two more people, then I'll merge it into trunk. In the meantime, I'll get to work on the changes.txt blurb. How did you feel about the information and instructions on the migration dialog itself? Will it be clear enough what is happening for those who don't read the changes.txt file?

myk wrote:excellent. Ok, let's see if we can get verification from one or two more people, then I'll merge it into trunk. In the meantime, I'll get to work on the changes.txt blurb. How did you feel about the information and instructions on the migration dialog itself? Will it be clear enough what is happening for those who don't read the changes.txt file?

 
I thought that the instructions were fairly clear but I may have more experience in this project than other people. We should be prepared to hold a few hands and help people adjust.

Oh:

I spent a few minutes trying to edit the new properties file. I created a folder named " Forge Snapshot" in my documents folder and moved the files from the /Application Support/Forge/ and the /Caches/Forge/ folders into this " Forge Snapshot" folder in my documents folder. Note the leading space in the folder name.

I edited the pathnames in the new properties file. Launched Forge and found it creating a folder named "$HOME" in my Forge folder and it set up a new set of data folders within it. Hmmm. The files that I moved to the /Documents/ Forge Snapshot/ folder were ignored.

Is the properties pathname code "trimming" the dirs in the path and since it can not find a folder named "Forge Snapshot" in the documents folder it is instead creating a new dir structure in the Forge folder?


EDIT:

I renamed the folder and removed the leading space but I am still getting a folder named "$HOME" in my Forge folder and it set up a new set of data folders within it.

environment variables aren't expanded when read in from the properties file -- I had referred to $HOME in the comments to indicate where the default directories would be, but I didn't mean to imply that they would be valid literal values for the variables. It's interpreting the string as a relative path from the forge program directory. This is documented in the forge.profile.properties file, but I'll see if I can make it clearer.

I was starting to suspect as much, I found that using:

/Users/my user name/path to folder containing the data files

did the trick and it is working.

Running a few more tests this weekend and it appears that the branch snapshot build wants to download 23 quest images. I will go ahead and download and try to determine what files are new. The terminal app shows files being downloads without any useful messages.

OK, the 23 new pics are appearing inside of the Boosters folder:

| Open

2ED.png
3ED.png
4ED.png
5ED.png
6ED.png
ALL.png
ARN.png
ATQ.png
CHR.png
DRK.png
FEM.png
HML.png
ICE.png
LEA.png
LEB.png
LEG.png
MMQ.png
NMS.png
PCY.png
PO2.png
POR.png
PTK.png
S99.png

 
I seem to remember a downloading bug where a number of booster pics were downloaded into the pics_product folder rather than the pics_product/booster folder. I guess that your recent work will fix this old time bug.

Yeah, the pics_product dir has been removed from the distributable, and booster pics are now downloaded. The ones you see above were just added by moomarc to the server and are not in the trunk pics_product/booster dir (and hence were not imported and must be downloaded). There is a commented-out System.out.println that reports the URL being downloaded and the file being written to. I left it commented since I wasn't sure whether we were trying to be discreet about hosting card pics. I can 'half-uncomment' it so it reports the list of files it will download.

I have something I need to do today, but unless something comes up, I will be able to do the merge in about 12 hours from now.

I've been merging for the past few hours, but it might take a few more. The branch spanned the cardsfolder updates, so it has to touch each one of the files in there.

merged -- please tell me if anybody has any issues! @max: decks are no longer deleted on update, thanks for the heads up!

edit: there are currently a number of tree conflicts. I'm figuring out the best way to deal with them.

edit2: Bah, this will be annoying. When I originally deleted the directories that will become unused after the migration, I expected subversion to leave the non-versioned files (like .dck files) alone. It turns out that subversion just deletes all files in those directories. To avoid this, I added the directories back into svn. However, since I deleted the directory, then re-added it, svn will complain about tree conflicts when everyone svn up's to the current revision : / Normal users who install releases or snapshots won't have any issues, but devs who check out from svn will have to follow this procedure to get back on track:

1. update from svn
2. run forge at least once to complete the data migration
3. revert "local" changes in the source tree to clear up the tree conflicts. save any work you have in progress but have not yet checked in before doing this
   • do it from eclipse or from the commandline
   • svn revert --depth=infinity .

sometime in the near future, I'll remove the leftover directories (such as res/decks) for good and clean up, but if I do it now, svn will delete the user data in those directories before it can be migrated : (

I think we can close issue 634 on Mantis.

Chris H. wrote:I seem to remember a downloading bug where a number of booster pics were downloaded into the pics_product folder rather than the pics_product/booster folder. I guess that your recent work will fix this old time bug. :D

I realized I didn't really answer your question -- yes, the bug has been fixed. There were .png booster pic files released with the distributable in the pics_product/booster folder. Additional .jpg booster pic copies were downloaded to pics_product/ directory. The booster files are now all .png and are downloaded to the proper location. The .jpg versions are no longer downloaded at all.