A
armybuilder at yahoogroup
Guest
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
------------------------------------------------------------------------
There are 12 messages in this issue.
Topics in this digest:
1. RE: More validation questions
From: Jerry Anderson <jerrya@wellspringsolutions.com>
2. RE: More validation questions
From: Jerry Anderson <jerrya@wellspringsolutions.com>
3. RE: More validation questions
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
4. Back From a Long Absence
From: Rob Bowes <rob@wolflair.com>
5. Re: Gear Krieg Files
From: Rob Bowes <rob@wolflair.com>
6. Re: impossible action?
From: Rob Bowes <rob@wolflair.com>
7. Re: Inter Option Dependance
From: Rob Bowes <rob@wolflair.com>
8. Re: Warmaster Battle Honors (Longish)
From: Rob Bowes <rob@wolflair.com>
9. Re: Sack Armies?
From: Rob Bowes <rob@wolflair.com>
10. Re: enab Special Attribute
From: Rob Bowes <rob@wolflair.com>
11. Re: ABCreator - Validating by Unit Category
From: Rob Bowes <rob@wolflair.com>
12. RE: More validation questions
From: Rob Bowes <rob@wolflair.com>
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Thu, 29 Nov 2001 10:18:27 -0800
From: Jerry Anderson <jerrya@wellspringsolutions.com>
Subject: RE: More validation questions
Unfortunately, neither of these solve my problem. The way my roster works is
that the users add a unit and then select unit options to add other units as
children. They only select the unit option once and then increase the "model
count" of the unit with the "+". No matter how many models there are there
is always only one "option" for the child unit unit that was added. The
solutions below only work if more than one option is being used.
Is there a way to set the stat of a parent unit from a child unit and vice
versa? "Unit Options" have "stat" but I can't find anything like that for
"units". I've tried "calc" but that only allows me to change the stat of the
current unit not a parent or a child.
> -----Original Message-----
> From: Colen 'Skrillboy' McAlister [SMTP:demandred@skrill.org]
> Sent: Wednesday, November 28, 2001 12:42 PM
> To: armybuilder@yahoogroups.com
> Subject: Re: [AB] More validation questions
>
> At 09:59 28/11/2001 -0800, you wrote:
> >Ok all you AB wizards out there - here are some more questions. I'll use
> >Warhammer 40k as my reference again.
> >
> >I need to limit the number of units that can have a specific option to
> three
> >regardless of composition group.
>
> Have you tried the olmt: race attribute?
>
> >Also, I need to restrict the total number of models that a unit has to no
> >more than 20. Again this is by using "unit options" which use "hidden
> >units". In the case above Unit 5 has two options selected, Infantry and
> HMG,
> >for a total of 10 models. A user could only add 10 more models. Again I
> have
> >tried using the obvious "unit" validation rules but they don't seem to
> work
> >for units created via a "unit option".
>
> Why not use a hidden stat? Give every child unit an option that adds # to
> a
> 'USize' stat of it's parent, then use lcmp to limit the stat to <= 20.
>
>
> --
> Colen 'Skrillboy' McAlister, demandred@skrill.org
> <http://www.skrill.org/,> <http://www.incompetence-central.co.uk/>
> 1 = 2, for large values of 1.
>
>
>
> Yahoo! Groups Sponsor
> ADVERTISEMENT
>
> <http://rd.yahoo.com/M=214322.1753821.3271459.1261774/D=egroupweb/S=170505
> 9080:HM/A=860488/R=0/*http://registrar.godaddy.com/default.asp?isc=yaho350
> >
>
> <http://us.adserver.yahoo.com/l?M=214322.1753821.3271459.1261774/D=egroupm
> ail/S=1705059080:HM/A=860488/rand=363039964>
>
> To unsubscribe from this group, email
>
> armybuilder-unsubscribe@egroups.com
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> <http://docs.yahoo.com/info/terms/>.
________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Thu, 29 Nov 2001 10:58:03 -0800
From: Jerry Anderson <jerrya@wellspringsolutions.com>
Subject: RE: More validation questions
Hi all,
Let me re-phrase my questions.
The main problem that I am having with AB though is trying to figure out how
to manage general organizational concepts for the game I am modeling. For
example, the system that I am creating has 5 composition groups and 5 units
within each composition group. The 5 units are simply placeholders and don't
represent models themselves - rather they have unit options which add child
units to the top-level unit. Starting at "race" this is how a roster would
look for my game system:
Relgious Faction (race)
Unit 1 - Professional (unit)
Infantry w/ Small Arms * 8 (unit added via a unit option)
Tank * 2
Unit 2 - Regular
Infantry w/ Small Arms * 6
Tank * 2
Unit 3 - Militia
Infantry w/ Small Arms * 4
Infantry w/ RPG * 2
Unit 4 - Militia
Infantry w/ Small Arms * 8
Unit 5 - Militia
Infantry w/ Small Arms * 8
In each case above where there is a multiplier at the end of the unit that
was arrived at by using the "+" in the AB editor. The unit option when
selected will add one unit of the type indicated and the user has to
increase the model count with the "+". For each model type there is only one
"unit option".
There are certain things that I am trying to do that I am finding
impossible. Here are the validations that I am trying to enforce that I
can't find a solution to.
1. Each top-level "unit" i.e. Unit 1, Unit 2, Unit 3, etc. cannot have more
than 20 child models. How do I calculate the number of child units within a
unit? For example, in the roster above Unit 1 has 10 models in it (8 + 2 =
10).
2. Only two top-level units are allowed to have "tanks" regardless of the
quantity in the specific unit. In the roster above Unit 1 and Unit 2 have
tanks, if I added a tank to Unit 3 the roster would be invalid.
3. If a top-level unit contains an RPG or HMG unit (model count is
unimportant) then there must be at least 4 models of type "Infantry w/ Small
Arms". I think that I can do this one with inter-unit dependency
validations, but I haven't tried it yet.
Things I have tried:
olmt - each unit only has one option of each type so things like
determing model count don't work.
stat attribute - unit option
tlmt - doesn't work on units added as a unit option/child of another
unit
calc - can't affect stats of child/parent unit
coun - unit attribute - I tried setting the top-level size to 20 and
then use "coun" in the child units but I can't prevent the user from
increasing the size of the top-level unit which must remain at 1.
Thanks
Jerry
________________________________________________________________________
________________________________________________________________________
Message: 3
Date: Thu, 29 Nov 2001 23:41:06 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: RE: More validation questions
At 10:18 29/11/2001 -0800, you wrote:
>Unfortunately, neither of these solve my problem. The way my roster works is
>that the users add a unit and then select unit options to add other units as
>children. They only select the unit option once and then increase the "model
>count" of the unit with the "+". No matter how many models there are there
>is always only one "option" for the child unit unit that was added. The
>solutions below only work if more than one option is being used.
>
>Is there a way to set the stat of a parent unit from a child unit and vice
>versa? "Unit Options" have "stat" but I can't find anything like that for
>"units". I've tried "calc" but that only allows me to change the stat of the
>current unit not a parent or a child.
prnt: allows you to set the stat of a parent unit, chld: that of a child.
What I meant was that every child unit would have an attribute like:
prnt:USize+(#)
That would add the size of the child unit to the parent's USize stat.
--
Colen 'Skrillboy' McAlister, demandred@skrill.org
http://www.skrill.org/, http://www.incompetence-central.co.uk/
1 = 2, for large values of 1.
________________________________________________________________________
________________________________________________________________________
Message: 4
Date: Thu, 29 Nov 2001 21:40:09 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Back From a Long Absence
Hi Folks,
I've been incommunicado with this list for a full 3 weeks now. Sorry about
that. I hope I wasn't too badly missed.
After a bout with the flu,
going the first few rounds with newly discovered termites in the house, and
a week-plus visit from the in-laws, I'm finally back. So I'll try to get
caught up on outstanding questions that have been in need of an answer
since I went offline.
Sorry again if anyone felt their questions were ignored. My guess is that
most questions were answered by all the other experts on this forum. So
I'll now start addressing the few that received silence.
Thanks, Rob
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 5
Date: Thu, 29 Nov 2001 21:47:16 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Gear Krieg Files
The release date for GK files is currently unknown. Since GenCon, I got the
remaining kinks out of the demo files that I had put together. Those files
only included a handful of units, but all the mechanics were fully
operational. One of the free-lancers that does a lot of the GK writing and
development was going to take the framework I'd put together and then
convert all of the raw electronic data for vehicles (which he has) into AB
data files. I sent the last stuff off to him right around the time of the
September 11th tragedy. Since he lives in Jersey, my guess is that his life
has been significantly altered by that event (although I have heard that
he's personally OK). I haven't heard from him since sending the files and I
don't know their status. It's been on my todo list to get ahold of him, but
I've not yet done so. Hence the unknown status of those files.
Wish I had better news on this....
- Rob
At 07:23 PM 11/7/2001 -0600, you wrote:
>Hello All:
>
> At this year's GenCon, I saw a demo of the Gear Krieg AB file at Lone
>Wolf's booth. I was curious when these were going to be released?
>
>Later,
>Mark A. Siefert
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 6
Date: Thu, 29 Nov 2001 21:49:26 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: impossible action?
AB has no provisions for "random" events. The assumption is that random
determinations are made while other players are present or via private
rolled subject to the honor system. In either case, once the random
detmerinations are made, AB can be used to select the results into a
roster. But AB will not actually perform the random determination itself.
Sorry,
Rob
At 03:58 AM 11/9/2001 +0000, you wrote:
>when a player chooses unitA 4 other units must be attached randomly
>from 5 possible choices. 1 can only be given once, and another has
>twice as likely a chance to be chosen. is there any way in hell to do
>this complexe madness?
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 7
Date: Thu, 29 Nov 2001 21:53:48 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Inter Option Dependance
You can use "trat" on the same unit if you want. You can also use "tlmt"
and "olmt" with the "istype" qualifier to implement intra-unit constraints.
Another option is to use types for each of the options and use "utyp"
attributes to eliminate options that aren't valid due to the presence of
other options. This might actually be the best solution given my
understanding of what you're trying to accomplish.
Hope this helps,
Rob
At 01:37 PM 11/9/2001 +0000, you wrote:
>OK
>
>I set OptionA to rang:0-8 and over:OptionB=deselect, and OptionB to
>rang:0-8 and over:OptionA=deselect.
>
>When I run AB, Both options start at zero, which is correct, but then
>you start adding one option the other option does not deselect, and
>you are still able to take that option.
>
>I looked into using the typeA, typeB, trat method but I don't believe
>this will work as this is used between two units...whan I need is to
>prevent the same unit from taking the two different options.
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 8
Date: Thu, 29 Nov 2001 23:51:33 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Warmaster Battle Honors (Longish)
If a unit can only have a single Honor attached to it, then it ought to be
straightforward to allow Honors for units. You could also implement this
yourself via a separate augmentation file. Create an option for each of the
Honors, with all Honors in the same option category. Create another option
that chains to all of the Honors via "more" attributes. Then attach this
one option to all units. You could also assign the "glob" attribute to the
option and then use "utyp" or some other filtering mechanism so that the
Honors only appears for the appropriate set of units.
If various units can have varying numbers of Honors, then this solution
becomes a bit more work and is problematic to implement as an augmentation
unless there are easy ways already in place to filter units based upon
(e.g. types).
Hope this helps,
Rob
At 09:49 AM 11/12/2001 -0500, you wrote:
>I was perusing the Warmaster manual last night and was looking at the
>Battle Honors in the, you guessed it, Battle Honors Section...LOL.
>
>How hard would it be to add that small blip of a chart to the files? Would
>you have to add it to each Army section or could you make a generic file
>that can pop up for each unit in each army by using some type of option in
>the main menu?
>
>There is no limit to the number of Honors an army can have, but Infantry
>and Cavalry can only have a maximum of one (1) per unit. The Battle Honor
>is considered LOST if the unit is destroyed.
>
>Also, these are Optional rules, but used many times in campaigns or in
>groups that play against each other regularly
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 9
Date: Thu, 29 Nov 2001 23:55:48 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Sack Armies?
I put together prototype files for GenCon, received approval from the
creators of SA, and then haven't had the time to get the files completed.
If anyone is interested in taking on the project, most of the hard work is
done. All that's required is for someone to revise the existing data file
structure slightly to address a few misconceptions I had about the game
(should be easy) and then actually enter the data into that structure.
Alternately, the raw token data is available electronically and can be
converted to an AB data file via a program - if someone wants to write the
program. Again, it shouldn't be very difficult, but this method DOES
require some programming skill. Option #1 simply requires the hours to
enter the appropriate data into ABCreator.
Any takers??????
Thanks, Rob
At 03:54 PM 11/16/2001 +0000, you wrote:
>Is there a datafile for Sack Armies?
>
>---Steven
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 10
Date: Thu, 29 Nov 2001 23:59:40 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: enab Special Attribute
The "enab" attribute only works within the context of a specific unit. It
does NOT work across multiple units. The only way to track this (that I can
think of right now) is by using a validation rule. You can't directly
impose the restriction - only a validation can check for it. The method I
would use is to assign a unique type to UnitA, then assign another unique
type to the Option. You can then use a "trat" attribute to ensure that the
existence of type "Option" in the roster requires the presence of type "UnitA".
Hope this helps,
Rob
At 02:09 PM 11/21/2001 +0000, you wrote:
>Hi Folks
>
>I am having problems getting the enab special attribute to work.
>
>I have Unit A and Unit B. When unit A is chosen it allows unit B to
>take an option, but without Unit A, Unit B cannot take the option.
>
>What I have attemted to do is add the Attribute dsab to the option
>and adding the option to Unit B. It shows up as disabled and
>unchangeable.
>
>Then I created an item with the 'enab:UnitB-Option' Attribute and
>Included it with Unit A, in hopes that by choosing Unit A, you would
>make the Option available to Unit B. Unfortunately, Unit B still
>cannot choose the option, even when Unit A has been chosen.
>
>Any help?
>
>Chris
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 11
Date: Fri, 30 Nov 2001 00:03:57 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: ABCreator - Validating by Unit Category
Shawn had good suggestions - types are by far the most flexible and capable
mechanism within AB. However, you CAN limit units based on category via the
"ulmt" attribute. Check the documentation for "ulmt" within ABCreator and
you'll see how it works.
Thanks, Rob
At 09:46 AM 11/27/2001 -0800, you wrote:
>Hi all,
>
>I'm new to creating AB files so bear with me on this one. I'm putting
>together AB files for a game called AK47 Republic. The organization of the
>game somewhat maps to how AB is designed but there are some gaps. One of the
>gaps that I am trying to close involves restricting the number of units
>present in a roster. This is how things are organized - I will use Warhammer
>40k as a reference.
>
>Roster type: Religious, Popular Front = Imperial Guard, Orks, etc.
>
>Composition groups: Professional, Regular, Militia = HQ, Elites, Troops,
>etc.
>
>Units: Unit 1, 2, 3, 4, 5 = Armored Fist Squad, Basilisk, etc.
>
>The problem that I am trying to solve is for an army roster to be valid
>there can be only 5 units, filled out with other options of course, but
>nonetheless the roster can only have 5 units and the units can be any one of
>the composition groups i.e. Professional, Regular or Militia. I've created
>specific Units for each Composition Group e.g. there is a Professional Unit
>1, Regular Unit 1 and a Militia Unit 1. The user is only allowed to have one
>Unit 1 - either Professional, Regular or Militia. How do I setup the
>validation rules so that I can look at the entire roster and only allow a
>single unit to be created regardless of its composition group? I would like
>to use the Unit Category field but I can't figure out how to validate using
>it. The reason I would like to use that field is because I've used it to
>uniquely identify each unit regardless of its composition group. BTW - I
>have been able to figure out how to restrict the users from creating more
>than one unit of each type by limiting the size to a max of one.
>
>Thanks
>Jerry
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 12
Date: Fri, 30 Nov 2001 00:18:54 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: RE: More validation questions
Answers interspersed below in response to each specific question....
At 10:58 AM 11/29/2001 -0800, you wrote:
>Hi all,
>
>Let me re-phrase my questions.
>
>The main problem that I am having with AB though is trying to figure out how
>to manage general organizational concepts for the game I am modeling. For
>example, the system that I am creating has 5 composition groups and 5 units
>within each composition group. The 5 units are simply placeholders and don't
>represent models themselves - rather they have unit options which add child
>units to the top-level unit. Starting at "race" this is how a roster would
>look for my game system:
>
>Relgious Faction (race)
> Unit 1 - Professional (unit)
> Infantry w/ Small Arms * 8 (unit added via a unit option)
> Tank * 2
> Unit 2 - Regular
> Infantry w/ Small Arms * 6
> Tank * 2
> Unit 3 - Militia
> Infantry w/ Small Arms * 4
> Infantry w/ RPG * 2
> Unit 4 - Militia
> Infantry w/ Small Arms * 8
> Unit 5 - Militia
> Infantry w/ Small Arms * 8
>
>In each case above where there is a multiplier at the end of the unit that
>was arrived at by using the "+" in the AB editor. The unit option when
>selected will add one unit of the type indicated and the user has to
>increase the model count with the "+". For each model type there is only one
>"unit option".
>
>There are certain things that I am trying to do that I am finding
>impossible. Here are the validations that I am trying to enforce that I
>can't find a solution to.
>
>1. Each top-level "unit" i.e. Unit 1, Unit 2, Unit 3, etc. cannot have more
>than 20 child models. How do I calculate the number of child units within a
>unit? For example, in the roster above Unit 1 has 10 models in it (8 + 2 =
>10).
Colen offered the ideal solution. Create a hidden stat, which we'll call
"model". Create an option called "AddModels" that is hidden and uses the
"prnt:model+(#)". For each child unit, attach the "AddModels" option. The
net result is that each parent unit will have the total number of models in
the "model" stat. You can then use an "lcmp" attriubte to verify the limit
is satisfied.
>2. Only two top-level units are allowed to have "tanks" regardless of the
>quantity in the specific unit. In the roster above Unit 1 and Unit 2 have
>tanks, if I added a tank to Unit 3 the roster would be invalid.
Assign the type "Tank" to the tank units. Also assign the attribute "forc"
to tank units. Then use "tlmt" to enforce the maximum limit of two tank
units in the roster.
>3. If a top-level unit contains an RPG or HMG unit (model count is
>unimportant) then there must be at least 4 models of type "Infantry w/ Small
>Arms". I think that I can do this one with inter-unit dependency
>validations, but I haven't tried it yet.
If you assign the RPG/HMG as an option to the unit, use the "ocat" unit
attribute to impose a minimum relationship. If the RPG/HMG is a separate
child unit, use "tcon" within the parent unit to verify the model count
relationship.
>Things I have tried:
>
> tlmt - doesn't work on units added as a unit option/child of another
>unit
If you use the "forc" attribute on the child units, it will work on the
children.
This list of suggestions ought to help get you over the current road blocks
you've encountered.
Thanks, 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/
armybuilder-unsubscribe@egroups.com
------------------------------------------------------------------------
There are 12 messages in this issue.
Topics in this digest:
1. RE: More validation questions
From: Jerry Anderson <jerrya@wellspringsolutions.com>
2. RE: More validation questions
From: Jerry Anderson <jerrya@wellspringsolutions.com>
3. RE: More validation questions
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
4. Back From a Long Absence
From: Rob Bowes <rob@wolflair.com>
5. Re: Gear Krieg Files
From: Rob Bowes <rob@wolflair.com>
6. Re: impossible action?
From: Rob Bowes <rob@wolflair.com>
7. Re: Inter Option Dependance
From: Rob Bowes <rob@wolflair.com>
8. Re: Warmaster Battle Honors (Longish)
From: Rob Bowes <rob@wolflair.com>
9. Re: Sack Armies?
From: Rob Bowes <rob@wolflair.com>
10. Re: enab Special Attribute
From: Rob Bowes <rob@wolflair.com>
11. Re: ABCreator - Validating by Unit Category
From: Rob Bowes <rob@wolflair.com>
12. RE: More validation questions
From: Rob Bowes <rob@wolflair.com>
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Thu, 29 Nov 2001 10:18:27 -0800
From: Jerry Anderson <jerrya@wellspringsolutions.com>
Subject: RE: More validation questions
Unfortunately, neither of these solve my problem. The way my roster works is
that the users add a unit and then select unit options to add other units as
children. They only select the unit option once and then increase the "model
count" of the unit with the "+". No matter how many models there are there
is always only one "option" for the child unit unit that was added. The
solutions below only work if more than one option is being used.
Is there a way to set the stat of a parent unit from a child unit and vice
versa? "Unit Options" have "stat" but I can't find anything like that for
"units". I've tried "calc" but that only allows me to change the stat of the
current unit not a parent or a child.
> -----Original Message-----
> From: Colen 'Skrillboy' McAlister [SMTP:demandred@skrill.org]
> Sent: Wednesday, November 28, 2001 12:42 PM
> To: armybuilder@yahoogroups.com
> Subject: Re: [AB] More validation questions
>
> At 09:59 28/11/2001 -0800, you wrote:
> >Ok all you AB wizards out there - here are some more questions. I'll use
> >Warhammer 40k as my reference again.
> >
> >I need to limit the number of units that can have a specific option to
> three
> >regardless of composition group.
>
> Have you tried the olmt: race attribute?
>
> >Also, I need to restrict the total number of models that a unit has to no
> >more than 20. Again this is by using "unit options" which use "hidden
> >units". In the case above Unit 5 has two options selected, Infantry and
> HMG,
> >for a total of 10 models. A user could only add 10 more models. Again I
> have
> >tried using the obvious "unit" validation rules but they don't seem to
> work
> >for units created via a "unit option".
>
> Why not use a hidden stat? Give every child unit an option that adds # to
> a
> 'USize' stat of it's parent, then use lcmp to limit the stat to <= 20.
>
>
> --
> Colen 'Skrillboy' McAlister, demandred@skrill.org
> <http://www.skrill.org/,> <http://www.incompetence-central.co.uk/>
> 1 = 2, for large values of 1.
>
>
>
> Yahoo! Groups Sponsor
> ADVERTISEMENT
>
> <http://rd.yahoo.com/M=214322.1753821.3271459.1261774/D=egroupweb/S=170505
> 9080:HM/A=860488/R=0/*http://registrar.godaddy.com/default.asp?isc=yaho350
> >
>
> <http://us.adserver.yahoo.com/l?M=214322.1753821.3271459.1261774/D=egroupm
> ail/S=1705059080:HM/A=860488/rand=363039964>
>
> To unsubscribe from this group, email
>
> armybuilder-unsubscribe@egroups.com
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> <http://docs.yahoo.com/info/terms/>.
________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Thu, 29 Nov 2001 10:58:03 -0800
From: Jerry Anderson <jerrya@wellspringsolutions.com>
Subject: RE: More validation questions
Hi all,
Let me re-phrase my questions.
The main problem that I am having with AB though is trying to figure out how
to manage general organizational concepts for the game I am modeling. For
example, the system that I am creating has 5 composition groups and 5 units
within each composition group. The 5 units are simply placeholders and don't
represent models themselves - rather they have unit options which add child
units to the top-level unit. Starting at "race" this is how a roster would
look for my game system:
Relgious Faction (race)
Unit 1 - Professional (unit)
Infantry w/ Small Arms * 8 (unit added via a unit option)
Tank * 2
Unit 2 - Regular
Infantry w/ Small Arms * 6
Tank * 2
Unit 3 - Militia
Infantry w/ Small Arms * 4
Infantry w/ RPG * 2
Unit 4 - Militia
Infantry w/ Small Arms * 8
Unit 5 - Militia
Infantry w/ Small Arms * 8
In each case above where there is a multiplier at the end of the unit that
was arrived at by using the "+" in the AB editor. The unit option when
selected will add one unit of the type indicated and the user has to
increase the model count with the "+". For each model type there is only one
"unit option".
There are certain things that I am trying to do that I am finding
impossible. Here are the validations that I am trying to enforce that I
can't find a solution to.
1. Each top-level "unit" i.e. Unit 1, Unit 2, Unit 3, etc. cannot have more
than 20 child models. How do I calculate the number of child units within a
unit? For example, in the roster above Unit 1 has 10 models in it (8 + 2 =
10).
2. Only two top-level units are allowed to have "tanks" regardless of the
quantity in the specific unit. In the roster above Unit 1 and Unit 2 have
tanks, if I added a tank to Unit 3 the roster would be invalid.
3. If a top-level unit contains an RPG or HMG unit (model count is
unimportant) then there must be at least 4 models of type "Infantry w/ Small
Arms". I think that I can do this one with inter-unit dependency
validations, but I haven't tried it yet.
Things I have tried:
olmt - each unit only has one option of each type so things like
determing model count don't work.
stat attribute - unit option
tlmt - doesn't work on units added as a unit option/child of another
unit
calc - can't affect stats of child/parent unit
coun - unit attribute - I tried setting the top-level size to 20 and
then use "coun" in the child units but I can't prevent the user from
increasing the size of the top-level unit which must remain at 1.
Thanks
Jerry
________________________________________________________________________
________________________________________________________________________
Message: 3
Date: Thu, 29 Nov 2001 23:41:06 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: RE: More validation questions
At 10:18 29/11/2001 -0800, you wrote:
>Unfortunately, neither of these solve my problem. The way my roster works is
>that the users add a unit and then select unit options to add other units as
>children. They only select the unit option once and then increase the "model
>count" of the unit with the "+". No matter how many models there are there
>is always only one "option" for the child unit unit that was added. The
>solutions below only work if more than one option is being used.
>
>Is there a way to set the stat of a parent unit from a child unit and vice
>versa? "Unit Options" have "stat" but I can't find anything like that for
>"units". I've tried "calc" but that only allows me to change the stat of the
>current unit not a parent or a child.
prnt: allows you to set the stat of a parent unit, chld: that of a child.
What I meant was that every child unit would have an attribute like:
prnt:USize+(#)
That would add the size of the child unit to the parent's USize stat.
--
Colen 'Skrillboy' McAlister, demandred@skrill.org
http://www.skrill.org/, http://www.incompetence-central.co.uk/
1 = 2, for large values of 1.
________________________________________________________________________
________________________________________________________________________
Message: 4
Date: Thu, 29 Nov 2001 21:40:09 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Back From a Long Absence
Hi Folks,
I've been incommunicado with this list for a full 3 weeks now. Sorry about
that. I hope I wasn't too badly missed.
After a bout with the flu, going the first few rounds with newly discovered termites in the house, and
a week-plus visit from the in-laws, I'm finally back. So I'll try to get
caught up on outstanding questions that have been in need of an answer
since I went offline.
Sorry again if anyone felt their questions were ignored. My guess is that
most questions were answered by all the other experts on this forum. So
I'll now start addressing the few that received silence.
Thanks, Rob
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 5
Date: Thu, 29 Nov 2001 21:47:16 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Gear Krieg Files
The release date for GK files is currently unknown. Since GenCon, I got the
remaining kinks out of the demo files that I had put together. Those files
only included a handful of units, but all the mechanics were fully
operational. One of the free-lancers that does a lot of the GK writing and
development was going to take the framework I'd put together and then
convert all of the raw electronic data for vehicles (which he has) into AB
data files. I sent the last stuff off to him right around the time of the
September 11th tragedy. Since he lives in Jersey, my guess is that his life
has been significantly altered by that event (although I have heard that
he's personally OK). I haven't heard from him since sending the files and I
don't know their status. It's been on my todo list to get ahold of him, but
I've not yet done so. Hence the unknown status of those files.
Wish I had better news on this....
- Rob
At 07:23 PM 11/7/2001 -0600, you wrote:
>Hello All:
>
> At this year's GenCon, I saw a demo of the Gear Krieg AB file at Lone
>Wolf's booth. I was curious when these were going to be released?
>
>Later,
>Mark A. Siefert
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 6
Date: Thu, 29 Nov 2001 21:49:26 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: impossible action?
AB has no provisions for "random" events. The assumption is that random
determinations are made while other players are present or via private
rolled subject to the honor system. In either case, once the random
detmerinations are made, AB can be used to select the results into a
roster. But AB will not actually perform the random determination itself.
Sorry,
Rob
At 03:58 AM 11/9/2001 +0000, you wrote:
>when a player chooses unitA 4 other units must be attached randomly
>from 5 possible choices. 1 can only be given once, and another has
>twice as likely a chance to be chosen. is there any way in hell to do
>this complexe madness?
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 7
Date: Thu, 29 Nov 2001 21:53:48 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Inter Option Dependance
You can use "trat" on the same unit if you want. You can also use "tlmt"
and "olmt" with the "istype" qualifier to implement intra-unit constraints.
Another option is to use types for each of the options and use "utyp"
attributes to eliminate options that aren't valid due to the presence of
other options. This might actually be the best solution given my
understanding of what you're trying to accomplish.
Hope this helps,
Rob
At 01:37 PM 11/9/2001 +0000, you wrote:
>OK
>
>I set OptionA to rang:0-8 and over:OptionB=deselect, and OptionB to
>rang:0-8 and over:OptionA=deselect.
>
>When I run AB, Both options start at zero, which is correct, but then
>you start adding one option the other option does not deselect, and
>you are still able to take that option.
>
>I looked into using the typeA, typeB, trat method but I don't believe
>this will work as this is used between two units...whan I need is to
>prevent the same unit from taking the two different options.
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 8
Date: Thu, 29 Nov 2001 23:51:33 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Warmaster Battle Honors (Longish)
If a unit can only have a single Honor attached to it, then it ought to be
straightforward to allow Honors for units. You could also implement this
yourself via a separate augmentation file. Create an option for each of the
Honors, with all Honors in the same option category. Create another option
that chains to all of the Honors via "more" attributes. Then attach this
one option to all units. You could also assign the "glob" attribute to the
option and then use "utyp" or some other filtering mechanism so that the
Honors only appears for the appropriate set of units.
If various units can have varying numbers of Honors, then this solution
becomes a bit more work and is problematic to implement as an augmentation
unless there are easy ways already in place to filter units based upon
(e.g. types).
Hope this helps,
Rob
At 09:49 AM 11/12/2001 -0500, you wrote:
>I was perusing the Warmaster manual last night and was looking at the
>Battle Honors in the, you guessed it, Battle Honors Section...LOL.
>
>How hard would it be to add that small blip of a chart to the files? Would
>you have to add it to each Army section or could you make a generic file
>that can pop up for each unit in each army by using some type of option in
>the main menu?
>
>There is no limit to the number of Honors an army can have, but Infantry
>and Cavalry can only have a maximum of one (1) per unit. The Battle Honor
>is considered LOST if the unit is destroyed.
>
>Also, these are Optional rules, but used many times in campaigns or in
>groups that play against each other regularly
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 9
Date: Thu, 29 Nov 2001 23:55:48 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Sack Armies?
I put together prototype files for GenCon, received approval from the
creators of SA, and then haven't had the time to get the files completed.
If anyone is interested in taking on the project, most of the hard work is
done. All that's required is for someone to revise the existing data file
structure slightly to address a few misconceptions I had about the game
(should be easy) and then actually enter the data into that structure.
Alternately, the raw token data is available electronically and can be
converted to an AB data file via a program - if someone wants to write the
program. Again, it shouldn't be very difficult, but this method DOES
require some programming skill. Option #1 simply requires the hours to
enter the appropriate data into ABCreator.
Any takers??????
Thanks, Rob
At 03:54 PM 11/16/2001 +0000, you wrote:
>Is there a datafile for Sack Armies?
>
>---Steven
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 10
Date: Thu, 29 Nov 2001 23:59:40 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: enab Special Attribute
The "enab" attribute only works within the context of a specific unit. It
does NOT work across multiple units. The only way to track this (that I can
think of right now) is by using a validation rule. You can't directly
impose the restriction - only a validation can check for it. The method I
would use is to assign a unique type to UnitA, then assign another unique
type to the Option. You can then use a "trat" attribute to ensure that the
existence of type "Option" in the roster requires the presence of type "UnitA".
Hope this helps,
Rob
At 02:09 PM 11/21/2001 +0000, you wrote:
>Hi Folks
>
>I am having problems getting the enab special attribute to work.
>
>I have Unit A and Unit B. When unit A is chosen it allows unit B to
>take an option, but without Unit A, Unit B cannot take the option.
>
>What I have attemted to do is add the Attribute dsab to the option
>and adding the option to Unit B. It shows up as disabled and
>unchangeable.
>
>Then I created an item with the 'enab:UnitB-Option' Attribute and
>Included it with Unit A, in hopes that by choosing Unit A, you would
>make the Option available to Unit B. Unfortunately, Unit B still
>cannot choose the option, even when Unit A has been chosen.
>
>Any help?
>
>Chris
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 11
Date: Fri, 30 Nov 2001 00:03:57 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: ABCreator - Validating by Unit Category
Shawn had good suggestions - types are by far the most flexible and capable
mechanism within AB. However, you CAN limit units based on category via the
"ulmt" attribute. Check the documentation for "ulmt" within ABCreator and
you'll see how it works.
Thanks, Rob
At 09:46 AM 11/27/2001 -0800, you wrote:
>Hi all,
>
>I'm new to creating AB files so bear with me on this one. I'm putting
>together AB files for a game called AK47 Republic. The organization of the
>game somewhat maps to how AB is designed but there are some gaps. One of the
>gaps that I am trying to close involves restricting the number of units
>present in a roster. This is how things are organized - I will use Warhammer
>40k as a reference.
>
>Roster type: Religious, Popular Front = Imperial Guard, Orks, etc.
>
>Composition groups: Professional, Regular, Militia = HQ, Elites, Troops,
>etc.
>
>Units: Unit 1, 2, 3, 4, 5 = Armored Fist Squad, Basilisk, etc.
>
>The problem that I am trying to solve is for an army roster to be valid
>there can be only 5 units, filled out with other options of course, but
>nonetheless the roster can only have 5 units and the units can be any one of
>the composition groups i.e. Professional, Regular or Militia. I've created
>specific Units for each Composition Group e.g. there is a Professional Unit
>1, Regular Unit 1 and a Militia Unit 1. The user is only allowed to have one
>Unit 1 - either Professional, Regular or Militia. How do I setup the
>validation rules so that I can look at the entire roster and only allow a
>single unit to be created regardless of its composition group? I would like
>to use the Unit Category field but I can't figure out how to validate using
>it. The reason I would like to use that field is because I've used it to
>uniquely identify each unit regardless of its composition group. BTW - I
>have been able to figure out how to restrict the users from creating more
>than one unit of each type by limiting the size to a max of one.
>
>Thanks
>Jerry
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 12
Date: Fri, 30 Nov 2001 00:18:54 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: RE: More validation questions
Answers interspersed below in response to each specific question....
At 10:58 AM 11/29/2001 -0800, you wrote:
>Hi all,
>
>Let me re-phrase my questions.
>
>The main problem that I am having with AB though is trying to figure out how
>to manage general organizational concepts for the game I am modeling. For
>example, the system that I am creating has 5 composition groups and 5 units
>within each composition group. The 5 units are simply placeholders and don't
>represent models themselves - rather they have unit options which add child
>units to the top-level unit. Starting at "race" this is how a roster would
>look for my game system:
>
>Relgious Faction (race)
> Unit 1 - Professional (unit)
> Infantry w/ Small Arms * 8 (unit added via a unit option)
> Tank * 2
> Unit 2 - Regular
> Infantry w/ Small Arms * 6
> Tank * 2
> Unit 3 - Militia
> Infantry w/ Small Arms * 4
> Infantry w/ RPG * 2
> Unit 4 - Militia
> Infantry w/ Small Arms * 8
> Unit 5 - Militia
> Infantry w/ Small Arms * 8
>
>In each case above where there is a multiplier at the end of the unit that
>was arrived at by using the "+" in the AB editor. The unit option when
>selected will add one unit of the type indicated and the user has to
>increase the model count with the "+". For each model type there is only one
>"unit option".
>
>There are certain things that I am trying to do that I am finding
>impossible. Here are the validations that I am trying to enforce that I
>can't find a solution to.
>
>1. Each top-level "unit" i.e. Unit 1, Unit 2, Unit 3, etc. cannot have more
>than 20 child models. How do I calculate the number of child units within a
>unit? For example, in the roster above Unit 1 has 10 models in it (8 + 2 =
>10).
Colen offered the ideal solution. Create a hidden stat, which we'll call
"model". Create an option called "AddModels" that is hidden and uses the
"prnt:model+(#)". For each child unit, attach the "AddModels" option. The
net result is that each parent unit will have the total number of models in
the "model" stat. You can then use an "lcmp" attriubte to verify the limit
is satisfied.
>2. Only two top-level units are allowed to have "tanks" regardless of the
>quantity in the specific unit. In the roster above Unit 1 and Unit 2 have
>tanks, if I added a tank to Unit 3 the roster would be invalid.
Assign the type "Tank" to the tank units. Also assign the attribute "forc"
to tank units. Then use "tlmt" to enforce the maximum limit of two tank
units in the roster.
>3. If a top-level unit contains an RPG or HMG unit (model count is
>unimportant) then there must be at least 4 models of type "Infantry w/ Small
>Arms". I think that I can do this one with inter-unit dependency
>validations, but I haven't tried it yet.
If you assign the RPG/HMG as an option to the unit, use the "ocat" unit
attribute to impose a minimum relationship. If the RPG/HMG is a separate
child unit, use "tcon" within the parent unit to verify the model count
relationship.
>Things I have tried:
>
> tlmt - doesn't work on units added as a unit option/child of another
>unit
If you use the "forc" attribute on the child units, it will work on the
children.
This list of suggestions ought to help get you over the current road blocks
you've encountered.
Thanks, 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/