Actually, reconciling this issue is nigh impossible without changing the
saved roster files so that they become more than a 1MB in size. :-( Here is
the explanation from the web-site....
The contents of the saved roster file are tightly coupled to the set of
data files that are in use when the roster is created. It does not matter
whether you go forward or backward in versions. If the data files are
different when you load a saved roster from when that roster was saved, it
is quite probable that the roster will not be able to be loaded. The only
solution is to revert back to the original set of data files that were in
use when the roster file was originally saved.
As an attempt at explaining this, consider the following. Data file set #1
uses an id of "xxx" for a particular unit. In data file set #2, a different
id of "yyy" is used for the same unit. Any roster saved with data set #1
will be unable to resolve the reference to id "xxx" when loaded with set
#2. Similarly, a roster saved with set #2 will have an unrecognized id
("yyy") when loaded by set #1.
This is a gross simplification of things, but it illustrates the problem
going on within the roster files vis-a-vis the data files. Suffice to say,
whether a roster remains readable is completely dependent on how the data
files are changed from one version to the next. It also depends on whether
your roster actually makes use of any of the things that are changed
between versions. If your roster is all Elves and the new release of the
files only changes stuff for Dwarves, then your roster will work fine
across the versions, but some else's (that uses Elves) will not work any
longer.
To continue....
Presently, the saved rosters reference the contents of the data files so
that the data file contents don't need to be repeated in the saved file. If
the saved files need to include all of those references, then the roster
files will grow to be nearly the size of all the data files. The argument
could be made to only save what is referenced. However, then the file could
be reloaded but NOT EDITED. That doesn't provide much value. :-(
You suggested that AB could automatically convert old rosters to new
rosters. Unfortunately, that would require that AB somehow knew what
changes from one set of data files to the next AND that AB knew WHY each
change was made. AB would have to know how to change X to Y, which means a
mapping must be either determined by AB automatically (impossible) or the
author must specify it (lots more work for the authors and major amounts of
work to support this ability within AB).
Your suggestion about AB building old files into the new files has some
merit. The only gotcha is that the files will progressively get huge in
size. This will have a few major impacts. First, download times will
steadily increase as the files bloat - even for people that don't need or
want any of the old stuff. Second, loading of data files AND roster files
will slow down significantly. Third, EVERY time a new roster is created
and/or old roster is loaded, all of the data files will need to be
RELOADED, since AB will need to reset itself properly. I don't think this
is a performance hit that the majority of users will accept.
At present, only the data file writers can control this issue. They have to
take extreme steps to ensure that the files don't change between releases.
That's often in direct conflict with the demands of users for more and more
capabilities within the files. In order to add new material to the files,
the authors need to modify existing material to integrate the new stuff.
Those changes break the old saved rosters. The only REAL solution I can
think of here is for the data files to achieve stability and stop evolving.
That works great for many games, but certainly not for the GW games, since
the GW business model relies on constantly changing and evolving the game
system on a monthly (weekly?) basis.
I'm open to ideas on this if anyone has them. It may be that I'm completely
missing a simple solution to all this. If so, please let me know!!!
Thanks, Rob
At 03:21 PM 12/5/00 +0000, you wrote:
>Hi List, hi Rob.
>I know this might be a bit into the future, but ...
>
>Would it be possible to change the way the Army Builder saves a
>roster, so that if the datafiles were changed, it could still be
>imported?
>
>I manage the system in my local club, and I'm having tons of trouble
>explaning to the other members why they can't import their old
>rosters ...
>
>Personally I see two solutions:
>
>1: Some kind of versioning in the ABCreator, that would build-in the
>old files into any new version of the datafiles, so that the
>ArmyBuílder would read the version of the datafiles from the save,
>then load up the correct version of the datafiles, or change the
>roster to comply with the newest files.
>
>2: A component in the ArmyBuilder itself, combined with changes in
>the Creator, so the user could parse through old files & update the
>contents. This could be done right after datafile update.
>
>Lars Gottlieb
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development
www.wolflair.com
-------------------------- eGroups Sponsor -------------------------~-~>
PLAY GAMES. WIN PRIZES. GUARANTEED.
Get $5.00 in FREE credits when you register at
http://click.egroups.com/1/10501/0/_/36190/_/976051659/
---------------------------------------------------------------------_->
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
