A
armybuilder at egroups.co
Guest
-------------------------- eGroups Sponsor -------------------------~-~>
eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9699/0/_/36190/_/976533841/
---------------------------------------------------------------------_->
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
------------------------------------------------------------------------
There are 4 messages in this issue.
Topics in this digest:
1. RE: Re: VDR datafile
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
2. RE: Problem with Dark Eldar in Gamma-III datafiles
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
3. RE: Re: VDR datafile
From: Scott Balfour <sbalfour@mindspring.com>
4. Re: Mirroring parent's attrib's, again
From: Rob Bowes <rob@wolflair.com>
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Sun, 10 Dec 2000 12:38:18 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: RE: Re: VDR datafile
At 23:24 09/12/00 -0800, you wrote:
>At 05:16 PM 12/9/00 -0800, you wrote:
> >http://www.freek-inc.com/skrills/abfiles/
> >
> >There ya go! From the ""master of datafile creation for no personal gain""
> >himself....Da Skrill!!!
>
>Who are you kidding? Mr. Skrill derives immense satisfaction from the
>glowing praise he receives and the constant adulations of his loyal
>followers. Both of them. :-> :->
hmm
>As for the other few thousand people
>dependent on his files.....
>
>It's a frequently thankless job that Colen has undertaken out of the
>goodness of his heart, and I am extremely grateful of his efforts. If it
>wasn't for Colen, the 40K files (among others) would never be as well done
>as they currently are. Plus, AB wouldn't have nearly the same number of
>cool features, since Colen keeps my todo list brimming all the time.
>Thanks Colen!!!! :->
It's something to do, you know
--
'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
________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Sun, 10 Dec 2000 12:39:28 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: RE: Problem with Dark Eldar in Gamma-III datafiles
At 02:09 10/12/00 -0700, you wrote:
>Colen,
>
>I think I found another minor error in Gamma-III Dark Eldar. Warp Beasts
>are listed as Other when they should be Elite.
No they shouldn't; they don't take up a composition slot.
HOWEVER! I can exclusively reveal to you that, with the first release of
datafiles for Army Builder 2.1, they will be in the Elites section due to
toy new attributes. Hoorah
>I should add a huge thank you for all your efforts on the 40K files. For
>the amount of data contained in these files I am amazed at how few errors
>there are.
Thanks! That's because I've been through so many versions of them. If I
was doing it "properly", we'd be on version... um... about 40 :O
--
'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
________________________________________________________________________
________________________________________________________________________
Message: 3
Date: Sun, 10 Dec 2000 14:44:12 -0700
From: Scott Balfour <sbalfour@mindspring.com>
Subject: RE: Re: VDR datafile
From: Rob Bowes [SMTP:rob@wolflair.com]
<snip>
Thanks Colen!!!! :->
<end snips>
Dare I "waste" bandwidth with a "here! Here!"
Cheers
Scott
sbalfour@mindspring.com
Colorado Springs 40K - http://www.egroups.com/group/cs40k/info.html
________________________________________________________________________
________________________________________________________________________
Message: 4
Date: Sun, 10 Dec 2000 19:17:08 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Mirroring parent's attrib's, again
The problem here is that you have introduced an extra wrinkle that was not
in the original set of suggestions you were given. You added the extra
stats and the use of "base:stat=(hstat)" on the child unit. That won't work
in V2.0.
Here's the problem. In V2.0, the "chld" attribute sets up the adjustments
for application to the child unit. Then the child unit is evaluated, with
ALL of its attached options being processed. AFTER they are all processed,
the child unit is checked for a type match. If it matches, the stat value
is assigned to the child. This means that the "base" attribute on the child
unit is being processed BEFORE the child unit is being assigned the stat
value by the parent. Why was it done this way? Because this ensures that
the child unit is fully processed and the FINAL set of types assigned to
teh child unit are compared against the type requirement in the "chld"
attribute.
Starting in V2.1, this problem will go away. First, you will be able to
have the "chld" attribute be applied BEFORE the child's other options are
processed if you want. Second, the "chld" attribute will allow you to
adjust the base value of the stat. Third, you can specify that a stat value
only ever show its adjusted value (never the base value). Any one of these
three new features will address the problem you're running into.
Please stay tuned, since V2.1 will be going into Beta testing any day now
and will be released in the near future.
Thanks, Rob
P.S. For all of you who will ask, V2.1 will be a free update for anyone
using V2.0 already.
At 04:29 PM 12/7/00 +0000, you wrote:
>All right, I have tried and retried to get this process to work, but
>I can't seem to swing it.
>
>To recap:
>
>I have a unit (Squad) that can take a number of specialists as child
>units. To facilitate decision making, I want the child units to
>always have the same stats as the parent unit, depending on the
>options the parent chooses. I originally had a bunch of "mirr"
>attrib's set up on the child, but it would be much streamlined if I
>used the table attrib on the parent, which would prevent "mirr" freom
>working any longer.
>
>So, here's what I have tried to do:
>
>redefined the datadef so that each unit has twice the normal stats:
>
>stat and holdstat, (qty & hqty, lead & hlead,etc.) with the 'h' stat
>unassigned. Then, I have the following options:
>
>set child stats - on the parent, auto, that sets the holder stat of
>the child equal to the parent's stat
>
>then
>
>mimic - on the child, auto, that says base:stat=(hstat)
>
>This doesn't work. I have put each option in every possible
>combination of priorities (at least I think I have):
>
>option then set child then mimic
>option then mimic then set child
>set child then mimic then option
>set child then option then mimic
>mimic then set child then option
>mimic then option then set child
>
>none of these work.
>
>HELP! Apparently there is some wya to do it, but I can't figure it
>out. If someone could just lay out the exact priorities (which goes
>first second, third, or if I'm missing a step) I think I could get
>the rest of it pretty easily.
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9699/0/_/36190/_/976533841/
---------------------------------------------------------------------_->
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
------------------------------------------------------------------------
There are 4 messages in this issue.
Topics in this digest:
1. RE: Re: VDR datafile
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
2. RE: Problem with Dark Eldar in Gamma-III datafiles
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
3. RE: Re: VDR datafile
From: Scott Balfour <sbalfour@mindspring.com>
4. Re: Mirroring parent's attrib's, again
From: Rob Bowes <rob@wolflair.com>
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Sun, 10 Dec 2000 12:38:18 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: RE: Re: VDR datafile
At 23:24 09/12/00 -0800, you wrote:
>At 05:16 PM 12/9/00 -0800, you wrote:
> >http://www.freek-inc.com/skrills/abfiles/
> >
> >There ya go! From the ""master of datafile creation for no personal gain""
> >himself....Da Skrill!!!
>
>Who are you kidding? Mr. Skrill derives immense satisfaction from the
>glowing praise he receives and the constant adulations of his loyal
>followers. Both of them. :-> :->
hmm
>As for the other few thousand people
>dependent on his files.....
>
>It's a frequently thankless job that Colen has undertaken out of the
>goodness of his heart, and I am extremely grateful of his efforts. If it
>wasn't for Colen, the 40K files (among others) would never be as well done
>as they currently are. Plus, AB wouldn't have nearly the same number of
>cool features, since Colen keeps my todo list brimming all the time.
>Thanks Colen!!!! :->
It's something to do, you know
--
'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
________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Sun, 10 Dec 2000 12:39:28 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: RE: Problem with Dark Eldar in Gamma-III datafiles
At 02:09 10/12/00 -0700, you wrote:
>Colen,
>
>I think I found another minor error in Gamma-III Dark Eldar. Warp Beasts
>are listed as Other when they should be Elite.
No they shouldn't; they don't take up a composition slot.
HOWEVER! I can exclusively reveal to you that, with the first release of
datafiles for Army Builder 2.1, they will be in the Elites section due to
toy new attributes. Hoorah
>I should add a huge thank you for all your efforts on the 40K files. For
>the amount of data contained in these files I am amazed at how few errors
>there are.
Thanks!
That's because I've been through so many versions of them. If I was doing it "properly", we'd be on version... um... about 40 :O
--
'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
________________________________________________________________________
________________________________________________________________________
Message: 3
Date: Sun, 10 Dec 2000 14:44:12 -0700
From: Scott Balfour <sbalfour@mindspring.com>
Subject: RE: Re: VDR datafile
From: Rob Bowes [SMTP:rob@wolflair.com]
<snip>
Thanks Colen!!!! :->
<end snips>
Dare I "waste" bandwidth with a "here! Here!"
Cheers
Scott
sbalfour@mindspring.com
Colorado Springs 40K - http://www.egroups.com/group/cs40k/info.html
________________________________________________________________________
________________________________________________________________________
Message: 4
Date: Sun, 10 Dec 2000 19:17:08 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Mirroring parent's attrib's, again
The problem here is that you have introduced an extra wrinkle that was not
in the original set of suggestions you were given. You added the extra
stats and the use of "base:stat=(hstat)" on the child unit. That won't work
in V2.0.
Here's the problem. In V2.0, the "chld" attribute sets up the adjustments
for application to the child unit. Then the child unit is evaluated, with
ALL of its attached options being processed. AFTER they are all processed,
the child unit is checked for a type match. If it matches, the stat value
is assigned to the child. This means that the "base" attribute on the child
unit is being processed BEFORE the child unit is being assigned the stat
value by the parent. Why was it done this way? Because this ensures that
the child unit is fully processed and the FINAL set of types assigned to
teh child unit are compared against the type requirement in the "chld"
attribute.
Starting in V2.1, this problem will go away. First, you will be able to
have the "chld" attribute be applied BEFORE the child's other options are
processed if you want. Second, the "chld" attribute will allow you to
adjust the base value of the stat. Third, you can specify that a stat value
only ever show its adjusted value (never the base value). Any one of these
three new features will address the problem you're running into.
Please stay tuned, since V2.1 will be going into Beta testing any day now
and will be released in the near future.
Thanks, Rob
P.S. For all of you who will ask, V2.1 will be a free update for anyone
using V2.0 already.
At 04:29 PM 12/7/00 +0000, you wrote:
>All right, I have tried and retried to get this process to work, but
>I can't seem to swing it.
>
>To recap:
>
>I have a unit (Squad) that can take a number of specialists as child
>units. To facilitate decision making, I want the child units to
>always have the same stats as the parent unit, depending on the
>options the parent chooses. I originally had a bunch of "mirr"
>attrib's set up on the child, but it would be much streamlined if I
>used the table attrib on the parent, which would prevent "mirr" freom
>working any longer.
>
>So, here's what I have tried to do:
>
>redefined the datadef so that each unit has twice the normal stats:
>
>stat and holdstat, (qty & hqty, lead & hlead,etc.) with the 'h' stat
>unassigned. Then, I have the following options:
>
>set child stats - on the parent, auto, that sets the holder stat of
>the child equal to the parent's stat
>
>then
>
>mimic - on the child, auto, that says base:stat=(hstat)
>
>This doesn't work. I have put each option in every possible
>combination of priorities (at least I think I have):
>
>option then set child then mimic
>option then mimic then set child
>set child then mimic then option
>set child then option then mimic
>mimic then set child then option
>mimic then option then set child
>
>none of these work.
>
>HELP! Apparently there is some wya to do it, but I can't figure it
>out. If someone could just lay out the exact priorities (which goes
>first second, third, or if I'm missing a step) I think I could get
>the rest of it pretty easily.
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________