deck number convention creates issues when we add new decks to ship

[GoogleCodeExporter]

currently when we(the devs) add new decks to wagic, they are added to ai/baka 
folder incremented from whatever the highest was.
this creates an issue where we make it difficult for none power users to update 
their game, without causing conflicts with any new deck we might add.

the issue started with ai deck saving, which saves a player created deck as an 
ai deck. lets say we add a new deck to ship with wagic, deck106, and the player 
had already created an ai deck that took the slot for 106...heres where the 
issue araises, they now have a conflict, one could argue that the player can 
rename the deck(however not all users are power-users) but thats not the only 
issue, the stats file is saved for the player created deck106 and is now going 
to be loaded as the stats for the new deck106. in some cases i've had crashes 
relating to this that i have not been able to reproduce constantly, as if the 
stats are looking for something that the new deck does not have.

my suggestion:
create a new directory in ai folder..."playercreated"(or whatever) where 
players can drop the forum deck builder decks into, as well as have the game 
save the player created decks to this folder.
this way we can have the menu
load baka folder...
load playercreated decks..finished...
and have both folder independent of each other, but display thier contents in 
deck selection. this way we can increase the deck count of shipped decks 
without worry that we are going to put a massive headache on our users.

i do foresee a difficulty in stats file with this tho, as stats are recorded by 
deck number, maybe have a fresh stats file for the player created decks?

Original issue reported on code.google.com by omegabla...@gmail.com on 4 Jul 2011 at 3:55

[GoogleCodeExporter]

We've had a discussion a while ago that read-only data should go into 
Res/system, and user data could go in Res/user. This does not solve the issue 
as we want files to overrides those in Res/system, but I want to point this out 
so that whoever works on a solution for this issue takes this into account.

I think your suggested solution makes sense, in a similar way to what we have 
for the player ("premade" vs "actual" decks).

Another solution would be to get rid of the naming convention and let people 
create their own deck names (but that would make the deck unlocking mechanism a 
bit more difficult to put in place)

So for now I think your suggestion is the best one.

Original comment by wagic.the.homebrew@gmail.com on 5 Jul 2011 at 12:03

[GoogleCodeExporter]

we do need to keep a heavy eye on the stats, remember that deck meta data is 
saved by deck number, so deck101 of player created and deck101 of shipped decks 
might cause issues if we forget about how the stats are saved.

Original comment by omegabla...@gmail.com on 5 Jul 2011 at 2:17

[GoogleCodeExporter]

also i disagree with allowing any names as we have discussed in the past that 
comparing  decks by number vs comparing the string name of the deck would cause 
the deck menus to load even slower then they currently do when trying to fetch 
the stats. unless you think it would be about the same as we currently do.

Original comment by omegabla...@gmail.com on 5 Jul 2011 at 2:25

[GoogleCodeExporter]

One thing we should think about is not using the deck number or name to save 
stats.  rather we should generate a unique id for every deck.  That id can be 
stored in the deck file when it is initially saved.  Moving to this model will 
do a number of good things for the game. 

1) ensures that we can name the files whatever we want and still be able to map 
stats correctly to the decks.
2) breaks the dependance the code has on deckid.  (ie. deck menus are populated 
using deckid, stats, etc)

However this also requires more time to implement and will most likely break a 
few things initially.  point being, it won't be  an hour job.  more like a few 
days to a week.

Original comment by techdragon.nguyen@gmail.com on 24 Aug 2011 at 6:06