A
armybuilder at egroups.co
Guest
-------------------------- eGroups Sponsor -------------------------~-~>
eGroups eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9698/0/_/36190/_/978172969/
---------------------------------------------------------------------_->
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
------------------------------------------------------------------------
There are 2 messages in this issue.
Topics in this digest:
1. Re: Re: foll:race-must and leader attributes?
From: Eric Landes <eric@landesfamily.com>
2. Re: foll:race-must and leader attributes?
From: acummings@lucent.com
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Thu, 28 Dec 2000 20:11:22 -0800
From: Eric Landes <eric@landesfamily.com>
Subject: Re: Re: foll:race-must and leader attributes?
Andy, you may be reinventing the wheel, here. I've done quite a bit of
work updating the DBM files, though real life got in the way and kept me
from finishing the job.
Rob's got copies of the latest stuff I have.
Eric
At 04:46 PM 12/28/2000, acummings@lucent.com wrote:
>Rob,
>
>Thanks for clearing up the parent/child and leader/follower scenario -
> it will in itself save me time.
>
>The problem (s):
>
>Within DBM it is possible to have up to 4 commands, each command is
>lead by a general (CinC, Sub or Ally). Each of these commands is
>assigned a break point (1/3 its Equivalent Elements(EE)) Currently in
>the original DBM file only the army break point is calculated (1/2
>total EE) and displayed on the printout roster using the Record Type
>Race xx accu attribute in the Core data file, I would also like to
>display the Break Points of each command in the same way.
>
>I can achieve all of the above BUT... not in an automatic way with
>suitable rule validation.
>
>The easiest way for me to show you is to upload the datadef.dbm and
>core.dbm and example army file to the files section (dbm.zip)
>
>Basically the follower EE is accumulated through the external
>attribute Lead into stat "Cmd" (this shows the number of EE available
>to the entire command led by this general. This works fine.
>
>The CinC is automatically given Command 1 and the Record Type Race xx
>within the Core.dbm file produces the correct Command 1 break point
>(1/3 ee for that comamnd (ie just the cinc
).
>
>When a Sub general is added then Command 1 is not an option but
>Command 2, 3 and 4 are, first problem how do I stop Command 2 (0r 3
>or 4) being taken by two seperate (but in the same list) sub generals
>(two seperate entries in unit list would achieve this but is not
>elegant and raises other problems with army of more than 4 generals
>available for selection!).
>
>The only way I can then get the correct Command Break points to work
>is to provide an option for Command selection for EACH unit (this
>then sets the right stats to enable the Core.dbm race attribute to
>accu the stat.
>
>The problem with this is that a follower can be allocated to a Sub
>general that sub general has been allocated command 2! but the unit
>could be allocated to command 3! so we have a unit whos general is
>Command 2 but the units EE is calculated for command 3!
>
>The ideal solution (hence my question about Foll:race-must and
>leaders) and derived stats is how can I enforce the following yet
>still use the Record Race attribute accu to display the command break
>points:
>
>1. "Followers" of a leader automatically assigned same Command (1
>from 4) as leader
>2. Sub/Ally Generals same as above but can only be allocated a
>command that is not currently selected by another general (ie command
>2 3 or 4).
>3. A unit should only be allowed to select a command that is
>currently allocated to a general (eg in example army file only 3
>generals are valid so comamnd 4 should never be displayed as an
>option!)
>
>Sorry for the length - but I have spent quite a few hours (ok days)
>trying to resolve this one!) and you expertise would be greatly
>appareciated in resolving this.
>
>Note: I have changed both the datadef.dbm and core.dbm files from
>the original that are available from your website!
>
>Regards
>Andy
>
>
>
>
>--- In armybuilder@egroups.com, Rob Bowes <rob@w...> wrote:
> > The relationship between leaders and followers is a loose
>association, so
> > there is no hard link between the two. The leader can accumulate
> > characteristics of the children, but there is no way to formally
>establish
> > dependencies between leaders and followers, so leader can't
>directly obtain
> > stat values from children (unless there is only ever a single
>child - a
> > degenerate case) and children can't derive information from the
>parent.
> >
> > If you outline what game mechanic you are trying to solve, I will
>see if I
> > can think of something to recommend to you, but there is no way to
> > accomplish what you specifically are trying.
> >
> > Thanks, Rob
> >
> >
> > At 08:42 PM 12/28/00 +0000, you wrote:
> > >Hi all,
> > >
> > >A quick question that has me stumped!
> > >
> > >If a unit has the "foll:race-must" external attribute, when a
>leader
> > >is chosen is there any way that a followers specific stat can be
>made
> > >the same as it leaders? (AB2.1).
> > >
> > >The follower is not a Child of the Leader - or does it become a
>child
> > >when assigned a leader?
> > >
> > >regards
> > >Andy
> >
> >
> > --------------------------------------------------------------------
>-------
> > Rob Bowes (rob@w...) (650) 726-9689
> > Lone Wolf Development
>www.wolflair.com
>
>
>
>To unsubscribe from this group, email
>
>armybuilder-unsubscribe@egroups.com
Eric Landes
eric@landesfamily.com
http://www.landesfamily.com
"A mathematician is a device that turns coffee into theorems."
- Paul Erdes
________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Fri, 29 Dec 2000 20:08:19 -0000
From: acummings@lucent.com
Subject: Re: foll:race-must and leader attributes?
Eric,
Good to hear from you again - much like you real life got in the way
(to the extent work took me and the family to your fair country
(south Carolina) for what was to be an extended stay of two years
only to be cut short after three months (change in business) now I
find myself back in the UK and with a few days accrued holiday-
hence some AB data file writing....
Never wanting to reinvent the wheel - can you send me the latest
datadef, core files you have - and any new army files please... I
will then take a look and hopefully I can help with the DBM Ab file
process - work permitting...
Regards
Andy
BTW; I have uploaded my datadef, core and example army file to the
files section of this egroup (DBM.ZIP) - have a browse and see what
you think.
--- In armybuilder@egroups.com, Eric Landes <eric@l...> wrote:
> Andy, you may be reinventing the wheel, here. I've done quite a
bit of
> work updating the DBM files, though real life got in the way and
kept me
> from finishing the job.
>
> Rob's got copies of the latest stuff I have.
>
> Eric
>
>
> At 04:46 PM 12/28/2000, acummings@l... wrote:
> >Rob,
> >
> >Thanks for clearing up the parent/child and leader/follower
scenario -
> > it will in itself save me time.
> >
> >The problem (s):
> >
> >Within DBM it is possible to have up to 4 commands, each command is
> >lead by a general (CinC, Sub or Ally). Each of these commands is
> >assigned a break point (1/3 its Equivalent Elements(EE)) Currently
in
> >the original DBM file only the army break point is calculated (1/2
> >total EE) and displayed on the printout roster using the Record
Type
> >Race xx accu attribute in the Core data file, I would also like to
> >display the Break Points of each command in the same way.
> >
> >I can achieve all of the above BUT... not in an automatic way with
> >suitable rule validation.
> >
> >The easiest way for me to show you is to upload the datadef.dbm and
> >core.dbm and example army file to the files section (dbm.zip)
> >
> >Basically the follower EE is accumulated through the external
> >attribute Lead into stat "Cmd" (this shows the number of EE
available
> >to the entire command led by this general. This works fine.
> >
> >The CinC is automatically given Command 1 and the Record Type Race
xx
> >within the Core.dbm file produces the correct Command 1 break point
> >(1/3 ee for that comamnd (ie just the cinc ).
> >
> >When a Sub general is added then Command 1 is not an option but
> >Command 2, 3 and 4 are, first problem how do I stop Command 2 (0r 3
> >or 4) being taken by two seperate (but in the same list) sub
generals
> >(two seperate entries in unit list would achieve this but is not
> >elegant and raises other problems with army of more than 4 generals
> >available for selection!).
> >
> >The only way I can then get the correct Command Break points to
work
> >is to provide an option for Command selection for EACH unit (this
> >then sets the right stats to enable the Core.dbm race attribute to
> >accu the stat.
> >
> >The problem with this is that a follower can be allocated to a Sub
> >general that sub general has been allocated command 2! but the unit
> >could be allocated to command 3! so we have a unit whos general is
> >Command 2 but the units EE is calculated for command 3!
> >
> >The ideal solution (hence my question about Foll:race-must and
> >leaders) and derived stats is how can I enforce the following yet
> >still use the Record Race attribute accu to display the command
break
> >points:
> >
> >1. "Followers" of a leader automatically assigned same Command (1
> >from 4) as leader
> >2. Sub/Ally Generals same as above but can only be allocated a
> >command that is not currently selected by another general (ie
command
> >2 3 or 4).
> >3. A unit should only be allowed to select a command that is
> >currently allocated to a general (eg in example army file only 3
> >generals are valid so comamnd 4 should never be displayed as an
> >option!)
> >
> >Sorry for the length - but I have spent quite a few hours (ok days)
> >trying to resolve this one!) and you expertise would be greatly
> >appareciated in resolving this.
> >
> >Note: I have changed both the datadef.dbm and core.dbm files from
> >the original that are available from your website!
> >
> >Regards
> >Andy
> >
> >
> >
> >
> >--- In armybuilder@egroups.com, Rob Bowes <rob@w...> wrote:
> > > The relationship between leaders and followers is a loose
> >association, so
> > > there is no hard link between the two. The leader can accumulate
> > > characteristics of the children, but there is no way to formally
> >establish
> > > dependencies between leaders and followers, so leader can't
> >directly obtain
> > > stat values from children (unless there is only ever a single
> >child - a
> > > degenerate case) and children can't derive information from the
> >parent.
> > >
> > > If you outline what game mechanic you are trying to solve, I
will
> >see if I
> > > can think of something to recommend to you, but there is no way
to
> > > accomplish what you specifically are trying.
> > >
> > > Thanks, Rob
> > >
> > >
> > > At 08:42 PM 12/28/00 +0000, you wrote:
> > > >Hi all,
> > > >
> > > >A quick question that has me stumped!
> > > >
> > > >If a unit has the "foll:race-must" external attribute, when a
> >leader
> > > >is chosen is there any way that a followers specific stat can
be
> >made
> > > >the same as it leaders? (AB2.1).
> > > >
> > > >The follower is not a Child of the Leader - or does it become a
> >child
> > > >when assigned a leader?
> > > >
> > > >regards
> > > >Andy
> > >
> > >
> > > ----------------------------------------------------------------
----
> >-------
> > > Rob Bowes (rob@w...) (650) 726-
9689
> > > Lone Wolf Development
> >www.wolflair.com
> >
> >
> >
> >To unsubscribe from this group, email
> >
> >armybuilder-unsubscribe@egroups.com
>
>
> Eric Landes
> eric@l...
> http://www.landesfamily.com
>
> "A mathematician is a device that turns coffee into theorems."
> - Paul Erdes
________________________________________________________________________
________________________________________________________________________
eGroups eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9698/0/_/36190/_/978172969/
---------------------------------------------------------------------_->
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
------------------------------------------------------------------------
There are 2 messages in this issue.
Topics in this digest:
1. Re: Re: foll:race-must and leader attributes?
From: Eric Landes <eric@landesfamily.com>
2. Re: foll:race-must and leader attributes?
From: acummings@lucent.com
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Thu, 28 Dec 2000 20:11:22 -0800
From: Eric Landes <eric@landesfamily.com>
Subject: Re: Re: foll:race-must and leader attributes?
Andy, you may be reinventing the wheel, here. I've done quite a bit of
work updating the DBM files, though real life got in the way and kept me
from finishing the job.
Rob's got copies of the latest stuff I have.
Eric
At 04:46 PM 12/28/2000, acummings@lucent.com wrote:
>Rob,
>
>Thanks for clearing up the parent/child and leader/follower scenario -
> it will in itself save me time.
>
>The problem (s):
>
>Within DBM it is possible to have up to 4 commands, each command is
>lead by a general (CinC, Sub or Ally). Each of these commands is
>assigned a break point (1/3 its Equivalent Elements(EE)) Currently in
>the original DBM file only the army break point is calculated (1/2
>total EE) and displayed on the printout roster using the Record Type
>Race xx accu attribute in the Core data file, I would also like to
>display the Break Points of each command in the same way.
>
>I can achieve all of the above BUT... not in an automatic way with
>suitable rule validation.
>
>The easiest way for me to show you is to upload the datadef.dbm and
>core.dbm and example army file to the files section (dbm.zip)
>
>Basically the follower EE is accumulated through the external
>attribute Lead into stat "Cmd" (this shows the number of EE available
>to the entire command led by this general. This works fine.
>
>The CinC is automatically given Command 1 and the Record Type Race xx
>within the Core.dbm file produces the correct Command 1 break point
>(1/3 ee for that comamnd (ie just the cinc
).>
>When a Sub general is added then Command 1 is not an option but
>Command 2, 3 and 4 are, first problem how do I stop Command 2 (0r 3
>or 4) being taken by two seperate (but in the same list) sub generals
>(two seperate entries in unit list would achieve this but is not
>elegant and raises other problems with army of more than 4 generals
>available for selection!).
>
>The only way I can then get the correct Command Break points to work
>is to provide an option for Command selection for EACH unit (this
>then sets the right stats to enable the Core.dbm race attribute to
>accu the stat.
>
>The problem with this is that a follower can be allocated to a Sub
>general that sub general has been allocated command 2! but the unit
>could be allocated to command 3! so we have a unit whos general is
>Command 2 but the units EE is calculated for command 3!
>
>The ideal solution (hence my question about Foll:race-must and
>leaders) and derived stats is how can I enforce the following yet
>still use the Record Race attribute accu to display the command break
>points:
>
>1. "Followers" of a leader automatically assigned same Command (1
>from 4) as leader
>2. Sub/Ally Generals same as above but can only be allocated a
>command that is not currently selected by another general (ie command
>2 3 or 4).
>3. A unit should only be allowed to select a command that is
>currently allocated to a general (eg in example army file only 3
>generals are valid so comamnd 4 should never be displayed as an
>option!)
>
>Sorry for the length - but I have spent quite a few hours (ok days)
>trying to resolve this one!) and you expertise would be greatly
>appareciated in resolving this.
>
>Note: I have changed both the datadef.dbm and core.dbm files from
>the original that are available from your website!
>
>Regards
>Andy
>
>
>
>
>--- In armybuilder@egroups.com, Rob Bowes <rob@w...> wrote:
> > The relationship between leaders and followers is a loose
>association, so
> > there is no hard link between the two. The leader can accumulate
> > characteristics of the children, but there is no way to formally
>establish
> > dependencies between leaders and followers, so leader can't
>directly obtain
> > stat values from children (unless there is only ever a single
>child - a
> > degenerate case) and children can't derive information from the
>parent.
> >
> > If you outline what game mechanic you are trying to solve, I will
>see if I
> > can think of something to recommend to you, but there is no way to
> > accomplish what you specifically are trying.
> >
> > Thanks, Rob
> >
> >
> > At 08:42 PM 12/28/00 +0000, you wrote:
> > >Hi all,
> > >
> > >A quick question that has me stumped!
> > >
> > >If a unit has the "foll:race-must" external attribute, when a
>leader
> > >is chosen is there any way that a followers specific stat can be
>made
> > >the same as it leaders? (AB2.1).
> > >
> > >The follower is not a Child of the Leader - or does it become a
>child
> > >when assigned a leader?
> > >
> > >regards
> > >Andy
> >
> >
> > --------------------------------------------------------------------
>-------
> > Rob Bowes (rob@w...) (650) 726-9689
> > Lone Wolf Development
>www.wolflair.com
>
>
>
>To unsubscribe from this group, email
>
>armybuilder-unsubscribe@egroups.com
Eric Landes
eric@landesfamily.com
http://www.landesfamily.com
"A mathematician is a device that turns coffee into theorems."
- Paul Erdes
________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Fri, 29 Dec 2000 20:08:19 -0000
From: acummings@lucent.com
Subject: Re: foll:race-must and leader attributes?
Eric,
Good to hear from you again - much like you real life got in the way
(to the extent work took me and the family to your fair country
(south Carolina) for what was to be an extended stay of two years
only to be cut short after three months (change in business) now I
find myself back in the UK and with a few days accrued holiday
- hence some AB data file writing....
Never wanting to reinvent the wheel - can you send me the latest
datadef, core files you have - and any new army files please... I
will then take a look and hopefully I can help with the DBM Ab file
process - work permitting...
Regards
Andy
BTW; I have uploaded my datadef, core and example army file to the
files section of this egroup (DBM.ZIP) - have a browse and see what
you think.
--- In armybuilder@egroups.com, Eric Landes <eric@l...> wrote:
> Andy, you may be reinventing the wheel, here. I've done quite a
bit of
> work updating the DBM files, though real life got in the way and
kept me
> from finishing the job.
>
> Rob's got copies of the latest stuff I have.
>
> Eric
>
>
> At 04:46 PM 12/28/2000, acummings@l... wrote:
> >Rob,
> >
> >Thanks for clearing up the parent/child and leader/follower
scenario -
> > it will in itself save me time.
> >
> >The problem (s):
> >
> >Within DBM it is possible to have up to 4 commands, each command is
> >lead by a general (CinC, Sub or Ally). Each of these commands is
> >assigned a break point (1/3 its Equivalent Elements(EE)) Currently
in
> >the original DBM file only the army break point is calculated (1/2
> >total EE) and displayed on the printout roster using the Record
Type
> >Race xx accu attribute in the Core data file, I would also like to
> >display the Break Points of each command in the same way.
> >
> >I can achieve all of the above BUT... not in an automatic way with
> >suitable rule validation.
> >
> >The easiest way for me to show you is to upload the datadef.dbm and
> >core.dbm and example army file to the files section (dbm.zip)
> >
> >Basically the follower EE is accumulated through the external
> >attribute Lead into stat "Cmd" (this shows the number of EE
available
> >to the entire command led by this general. This works fine.
> >
> >The CinC is automatically given Command 1 and the Record Type Race
xx
> >within the Core.dbm file produces the correct Command 1 break point
> >(1/3 ee for that comamnd (ie just the cinc
).> >
> >When a Sub general is added then Command 1 is not an option but
> >Command 2, 3 and 4 are, first problem how do I stop Command 2 (0r 3
> >or 4) being taken by two seperate (but in the same list) sub
generals
> >(two seperate entries in unit list would achieve this but is not
> >elegant and raises other problems with army of more than 4 generals
> >available for selection!).
> >
> >The only way I can then get the correct Command Break points to
work
> >is to provide an option for Command selection for EACH unit (this
> >then sets the right stats to enable the Core.dbm race attribute to
> >accu the stat.
> >
> >The problem with this is that a follower can be allocated to a Sub
> >general that sub general has been allocated command 2! but the unit
> >could be allocated to command 3! so we have a unit whos general is
> >Command 2 but the units EE is calculated for command 3!
> >
> >The ideal solution (hence my question about Foll:race-must and
> >leaders) and derived stats is how can I enforce the following yet
> >still use the Record Race attribute accu to display the command
break
> >points:
> >
> >1. "Followers" of a leader automatically assigned same Command (1
> >from 4) as leader
> >2. Sub/Ally Generals same as above but can only be allocated a
> >command that is not currently selected by another general (ie
command
> >2 3 or 4).
> >3. A unit should only be allowed to select a command that is
> >currently allocated to a general (eg in example army file only 3
> >generals are valid so comamnd 4 should never be displayed as an
> >option!)
> >
> >Sorry for the length - but I have spent quite a few hours (ok days)
> >trying to resolve this one!) and you expertise would be greatly
> >appareciated in resolving this.
> >
> >Note: I have changed both the datadef.dbm and core.dbm files from
> >the original that are available from your website!
> >
> >Regards
> >Andy
> >
> >
> >
> >
> >--- In armybuilder@egroups.com, Rob Bowes <rob@w...> wrote:
> > > The relationship between leaders and followers is a loose
> >association, so
> > > there is no hard link between the two. The leader can accumulate
> > > characteristics of the children, but there is no way to formally
> >establish
> > > dependencies between leaders and followers, so leader can't
> >directly obtain
> > > stat values from children (unless there is only ever a single
> >child - a
> > > degenerate case) and children can't derive information from the
> >parent.
> > >
> > > If you outline what game mechanic you are trying to solve, I
will
> >see if I
> > > can think of something to recommend to you, but there is no way
to
> > > accomplish what you specifically are trying.
> > >
> > > Thanks, Rob
> > >
> > >
> > > At 08:42 PM 12/28/00 +0000, you wrote:
> > > >Hi all,
> > > >
> > > >A quick question that has me stumped!
> > > >
> > > >If a unit has the "foll:race-must" external attribute, when a
> >leader
> > > >is chosen is there any way that a followers specific stat can
be
> >made
> > > >the same as it leaders? (AB2.1).
> > > >
> > > >The follower is not a Child of the Leader - or does it become a
> >child
> > > >when assigned a leader?
> > > >
> > > >regards
> > > >Andy
> > >
> > >
> > > ----------------------------------------------------------------
----
> >-------
> > > Rob Bowes (rob@w...) (650) 726-
9689
> > > Lone Wolf Development
> >www.wolflair.com
> >
> >
> >
> >To unsubscribe from this group, email
> >
> >armybuilder-unsubscribe@egroups.com
>
>
> Eric Landes
> eric@l...
> http://www.landesfamily.com
>
> "A mathematician is a device that turns coffee into theorems."
> - Paul Erdes
________________________________________________________________________
________________________________________________________________________