A
armybuilder at yahoogroup
Guest
------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://us.click.yahoo.com/kWP7PD/pYNCAA/4ihDAA/IfNVlB/TM
---------------------------------------------------------------------_->
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
------------------------------------------------------------------------
There are 3 messages in this issue.
Topics in this digest:
1. Re: Ravenwing Command squad problem
From: "Jimi" <james.tubman@blueyonder.co.uk>
2. Emperor's Children Problem and Tyranid Q&A
From: ckittle@fuse.net
3. Re: loading rosters
From: Rob Bowes <rob@wolflair.com>
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Sun, 25 Feb 2001 08:36:05 -0000
From: "Jimi" <james.tubman@blueyonder.co.uk>
Subject: Re: Ravenwing Command squad problem
> Hmm... fair enough. The reason I didn't originally give them the stuff
> was because I thought "What sort of things can they get? Well,
> Apothecaries can let one save in the squad be re=rolled every turn. That
> doesn't apply to Land Speeders. Fine, I'll not give any of them the
> equipment."
Dont forget that Ravenwing have a 6+ 'jink' save
Jimi
FREE 40k card scenery - http://www.crosswinds.net/~astronomican/
40k3 - http://groups.yahoo.com/group/40k3/
40k Fluff - http://groups.yahoo.com/group/40k_fluff/
Astartes - http://groups.yahoo.com/group/adeptus_astartes/
Grey Knights - http://groups.yahoo.com/group/greyknightchapter/
Imperial Guard - http://groups.yahoo.com/group/imperial-guard/
Sons Of Russ - http://groups.yahoo.com/group/sons-of-russ/
Unforgiven - http://groups.yahoo.com/group/unforgiven/
VDR - http://groups.yahoo.com/group/gw-vdr/
________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Sun, 25 Feb 2001 19:16:37 -0000
From: ckittle@fuse.net
Subject: Emperor's Children Problem and Tyranid Q&A
When creating an Emperor's Children army with a Daemon Prince, you
still get the error message "An Emperor's Children Army must be led
by a Chaos Lord or Daemon Prince with the Mark of Slaanesh." even
when the Mark of Slaanesh is selected in the Options list.
Also, GW has posted a Tyranid Q&A on the UK web site at
http://www.games-
workshop.com/40kuniverse/warhammer40k/tyranids/tyrqanda.htm
________________________________________________________________________
________________________________________________________________________
Message: 3
Date: Sun, 25 Feb 2001 18:08:31 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: loading rosters
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
________________________________________________________________________
________________________________________________________________________
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
eGroups is now Yahoo! Groups
Click here for more details
http://us.click.yahoo.com/kWP7PD/pYNCAA/4ihDAA/IfNVlB/TM
---------------------------------------------------------------------_->
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
------------------------------------------------------------------------
There are 3 messages in this issue.
Topics in this digest:
1. Re: Ravenwing Command squad problem
From: "Jimi" <james.tubman@blueyonder.co.uk>
2. Emperor's Children Problem and Tyranid Q&A
From: ckittle@fuse.net
3. Re: loading rosters
From: Rob Bowes <rob@wolflair.com>
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Sun, 25 Feb 2001 08:36:05 -0000
From: "Jimi" <james.tubman@blueyonder.co.uk>
Subject: Re: Ravenwing Command squad problem
> Hmm... fair enough. The reason I didn't originally give them the stuff
> was because I thought "What sort of things can they get? Well,
> Apothecaries can let one save in the squad be re=rolled every turn. That
> doesn't apply to Land Speeders. Fine, I'll not give any of them the
> equipment."
Dont forget that Ravenwing have a 6+ 'jink' save
Jimi
FREE 40k card scenery - http://www.crosswinds.net/~astronomican/
40k3 - http://groups.yahoo.com/group/40k3/
40k Fluff - http://groups.yahoo.com/group/40k_fluff/
Astartes - http://groups.yahoo.com/group/adeptus_astartes/
Grey Knights - http://groups.yahoo.com/group/greyknightchapter/
Imperial Guard - http://groups.yahoo.com/group/imperial-guard/
Sons Of Russ - http://groups.yahoo.com/group/sons-of-russ/
Unforgiven - http://groups.yahoo.com/group/unforgiven/
VDR - http://groups.yahoo.com/group/gw-vdr/
________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Sun, 25 Feb 2001 19:16:37 -0000
From: ckittle@fuse.net
Subject: Emperor's Children Problem and Tyranid Q&A
When creating an Emperor's Children army with a Daemon Prince, you
still get the error message "An Emperor's Children Army must be led
by a Chaos Lord or Daemon Prince with the Mark of Slaanesh." even
when the Mark of Slaanesh is selected in the Options list.
Also, GW has posted a Tyranid Q&A on the UK web site at
http://www.games-
workshop.com/40kuniverse/warhammer40k/tyranids/tyrqanda.htm
________________________________________________________________________
________________________________________________________________________
Message: 3
Date: Sun, 25 Feb 2001 18:08:31 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: loading rosters
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
________________________________________________________________________
________________________________________________________________________
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/