loading rosters

[drothman.dmth94 at gtalum]

First - let me say that I greatly (muchly) appreciate all the efforts
of the skrills staying on top of the rapidly evolving 40K rules.

However... something has got to be done about the roster loading bit
from file version to file version. This is getting to be an _awful_
drag. I've updated my GT army 5 times (from 40k3_v2p14.ab, through
several iterations to 40k3_v2p19.ab). Now I'm in a local campaign,
and I'm up to my third update on those files (which are actually more
critical to keep up-to-date..).

One trick that has worked for me is to save off units, and atttempt
to load them back individually, creating a new roster. Functional,
but time consuming and annoying.

so rob - can you automate this process? If the dreaded "old files"
state occurs (you've got it trapped - displaying the dialogue box
already), could the software attempt to load each unit individually
(perhaps with a "would you like to" for the user...), in the same
manner as the "load unit" option? There would probably have to be a
follow-on with a "failed for this unit", "failed for that unit" bit.

Another very nice feature would be an ability to import from the XML
output - i'd imagine this would have much the same effect as pulling
from individual units, and give us some hope of getting config-
version independent rosters.

other ideas, thoughts?

thanks,
daniel




------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://click.egroups.com/1/11231/0/_/36190/_/982693722/
---------------------------------------------------------------------_->

To unsubscribe from this group, email

armybuilder-unsubscribe@egroups.com

 

[demandred at skrill.org]

At 18:28 20/02/2001 +0000, you wrote:
>First - let me say that I greatly (muchly) appreciate all the efforts
>of the skrills staying on top of the rapidly evolving 40K rules.
>
>However... something has got to be done about the roster loading bit
>from file version to file version.

Yes.

>This is getting to be an _awful_
>drag. I've updated my GT army 5 times (from 40k3_v2p14.ab, through
>several iterations to 40k3_v2p19.ab). Now I'm in a local campaign,
>and I'm up to my third update on those files (which are actually more
>critical to keep up-to-date..).

Starting with (I think) this version, I've tried to be as 'lenient' as
possible in creating the files. They *should* work properly, although some
units may need to be deleted and re-added.

>One trick that has worked for me is to save off units, and atttempt
>to load them back individually, creating a new roster. Functional,
>but time consuming and annoying.

Yep. This will work, since only a few units will be causing all the problems.

>so rob - can you automate this process? If the dreaded "old files"
>state occurs (you've got it trapped - displaying the dialogue box
>already), could the software attempt to load each unit individually
>(perhaps with a "would you like to" for the user...), in the same
>manner as the "load unit" option? There would probably have to be a
>follow-on with a "failed for this unit", "failed for that unit" bit.

We had a large discussion on the ab beta-testing list about this, and IIRC
Rob said that putting in such a thing would take about a month of work.
I.e., it's unlikely to happen any time soon.

What is more likely is that previous versions of the files will be kept in
the system, and when a roster fails to load, it's just loaded with the
version that created it. IIRC this failed to make it into AB2.1 because of
time constraints.

>Another very nice feature would be an ability to import from the XML
>output - i'd imagine this would have much the same effect as pulling
>from individual units, and give us some hope of getting config-
>version independent rosters.

Yeesh. I'm no expert, but I suspect this would be a total nightmare to do


--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time


------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://click.egroups.com/1/11231/0/_/36190/_/982696896/
---------------------------------------------------------------------_->

To unsubscribe from this group, email

armybuilder-unsubscribe@egroups.com

 

[demandred at skrill.org]

At 19:39 20/02/2001 +0000, you wrote:

>hrmm.. my actual difficulty is not with "dropping" units, but with
>the displayable/uneditable character of the retrieved files. As far
>as I know, you haven't done much work with orks in the 14-19 version
>range, but none of my rosters come forward editably

Ah, I can see you haven't been paying attention to my emails

This is a bug in Army Builder. To fix it, make a change to your roster (for
example, add and remove a unit), save it, then load it again and it should
work fine.


--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time


------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://click.egroups.com/1/11231/0/_/36190/_/982699713/
---------------------------------------------------------------------_->

To unsubscribe from this group, email

armybuilder-unsubscribe@egroups.com

 

[drothman.dmth94 at gtalum]

--- In armybuilder@y..., Colen 'Skrillboy' McAlister <demandred@s...>
wrote:
> At 18:28 20/02/2001 +0000, you wrote:
<<SNIP>>
>
> Starting with (I think) this version, I've tried to be as 'lenient'
as
> possible in creating the files. They *should* work properly,
although some
> units may need to be deleted and re-added.

hrmm.. my actual difficulty is not with "dropping" units, but with
the displayable/uneditable character of the retrieved files. As far
as I know, you haven't done much work with orks in the 14-19 version
range, but none of my rosters come forward editably

<<SNIP>>
> >so rob - can you automate this process? If the dreaded "old files"
> >state occurs (you've got it trapped - displaying the dialogue box
> >already), could the software attempt to load each unit individually
> >(perhaps with a "would you like to" for the user...), in the same
> >manner as the "load unit" option? There would probably have to be a
> >follow-on with a "failed for this unit", "failed for that unit"
bit.
>
> We had a large discussion on the ab beta-testing list about this,
and IIRC
> Rob said that putting in such a thing would take about a month of
work.
> I.e., it's unlikely to happen any time soon.
>
> What is more likely is that previous versions of the files will be
kept in
> the system, and when a roster fails to load, it's just loaded with
the
> version that created it. IIRC this failed to make it into AB2.1
because of
> time constraints.

Doesn't sound much less icky - it means you'd have to fiddle with the
import/load functions...

I am glad to see that there was debate on it though...

>
> >Another very nice feature would be an ability to import from the
XML
> >output - i'd imagine this would have much the same effect as
pulling
> >from individual units, and give us some hope of getting config-
> >version independent rosters.
>
> Yeesh. I'm no expert, but I suspect this would be a total nightmare
to do
>

It's a _batch_ of new code, but does keep you from having to revisit
existing code. There's always an interesting trade-off between
building v. updating. The difficulty of this thing really, entirely,
depends on the internal structure of the code (which i'm not privy
to

daniel


------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://click.egroups.com/1/11231/0/_/36190/_/982697989/
---------------------------------------------------------------------_->

To unsubscribe from this group, email

armybuilder-unsubscribe@egroups.com

 

[rob]

Sorry for the long lag of responding on this stuff. I'm just spread way too
thin right now. :-(


At 07:39 PM 2/20/01 +0000, you wrote:
> > >so rob - can you automate this process? If the dreaded "old files"
> > >state occurs (you've got it trapped - displaying the dialogue box
> > >already), could the software attempt to load each unit individually
> > >(perhaps with a "would you like to" for the user...), in the same
> > >manner as the "load unit" option? There would probably have to be a
> > >follow-on with a "failed for this unit", "failed for that unit"
>bit.

This specific idea of loading units individually was not suggested on the
AB Beta forum, but it has merit. It's actually not as much work as the
ideas we DID discuss, and it would likely prove useful. Perhaps I just have
AB flag units that loaded with problems so that the user knows where the
trouble points likely are. I'll add this on the todo list.

> > We had a large discussion on the ab beta-testing list about this,
>and IIRC
> > Rob said that putting in such a thing would take about a month of
>work.
> > I.e., it's unlikely to happen any time soon.
> >
> > What is more likely is that previous versions of the files will be
>kept in
> > the system, and when a roster fails to load, it's just loaded with
>the
> > version that created it. IIRC this failed to make it into AB2.1
>because of
> > time constraints.
>
>Doesn't sound much less icky - it means you'd have to fiddle with the
>import/load functions...
>
>I am glad to see that there was debate on it though...

Actually, Colen is misremembering things slightly here. The major
undertaking would be in having AB track multiple versions of data files on
a user's system and automatically switch back and forth between old
versions when older rosters are loaded. Then what about the user who
downloads the latest files with unit X in them, loads an old roster from an
earlier set of data files, and then is confused because unit X isn't listed
anymore as an available unit. Also, if I automatically switch between
versions of data files, most users will wonder why I can just translate an
old roster to the new set of data files, even though doing so would be nigh
impossible on a technical level. This gets extremely ugly from a usability
standpoint and would probably create more support problems than it would
solve. Coupled with the amount of time involved to implement it, and it
just wasn't viable for V2.1.

The suggestion above to load units one at a time is a much more viable
option to implement and still retains a reasonable amount of usefulness.

Another useful thing would be for me to work more closely with some of the
data file authors to help ensure that new versions of data files remain
compatible with older versions. This would mitigate the problem to a large
extent. I just have been spread way too thin for this to be possible. I'm
hoping that I'll have more time for this sort of stuff in the upcoming months.

> > >Another very nice feature would be an ability to import from the
>XML
> > >output - i'd imagine this would have much the same effect as
>pulling
> > >from individual units, and give us some hope of getting config-
> > >version independent rosters.
> >
> > Yeesh. I'm no expert, but I suspect this would be a total nightmare
>to do
> >
>
>It's a _batch_ of new code, but does keep you from having to revisit
>existing code. There's always an interesting trade-off between
>building v. updating. The difficulty of this thing really, entirely,
>depends on the internal structure of the code (which i'm not privy
>to

Actually, importing from the public XML output would be flat-out
impossible. A large portion of the necessary information needed by AB is
thrown out when the XML file is generated. AB saved rosters contain
references to information wihtin the data files, but public XML roster
files contain the information extracted FROM the data files instead. This
way, the public XML file contains all the info necessary without need for
the data files. The drawback with this is that the public XML file cannot
ever be read back in by AB and used for anything.

The normal saved roster files also use XML for their structure, although
the contents are in a propriety format. These files contain all of the
proper references back to the data files so that AB can load the roster in
and figure out all of the inter-relationships. The problem with new data
files being unusable with old rosters is due to the data file writer
changing the data files so that a given unit no longer is structured the
same as it was in the old data files. When this happens, the references to
the data files become broken (e.g. option "xyz" no longer exists because
its unique id was changed). At that point, AB can't resolve the reference
and has to throw up its hands in failure. This is something that can be
controlled by the data file author, although adding new capabilities to the
files can sometimes force changes like this. It's a nasty tradeoff that the
data file author has to make. Usually, this will be limited to only a few
units, so the idea above about loading all the units individually and only
throwing out those that fail is a good one (since most units will be able
to be reloaded without any problems).

Hope this helps,
Rob

---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com


------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://us.click.yahoo.com/kWP7PD/pYNCAA/4ihDAA/AANVlB/TM
---------------------------------------------------------------------_->