Digest Number 557

To unsubscribe from this group, email

armybuilder-unsubscribe@egroups.com
------------------------------------------------------------------------

There are 9 messages in this issue.

Topics in this digest:

1. Re: AB File for D&D Chainmail
From: Rob Bowes <rob@wolflair.com>
2. Re: Tyranids - * instead of number for single creature units.
From: Rob Bowes <rob@wolflair.com>
3. Re: newest WHFB5 .ab version?
From: Rob Bowes <rob@wolflair.com>
4. Re: Upgrading Data Files
From: Rob Bowes <rob@wolflair.com>
5. Re: Inter Option Dependance
From: Rob Bowes <rob@wolflair.com>
6. Re: Inter Option Dependance
From: Rob Bowes <rob@wolflair.com>
7. Re: items and options and other Qs
From: Rob Bowes <rob@wolflair.com>
8. Re: (no subject)
From: Rob Bowes <rob@wolflair.com>
9. Re: Inter Option Dependance
From: cmanos@crt.xerox.com


__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 1
Date: Mon, 05 Nov 2001 18:20:02 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: AB File for D&D Chainmail

I haven't tried this, but I *THINK* that the issue is you are specifying a
value of "2" for the "signed" field in the definition file. A value of 2
forces a "+" to be prepended to the stat value if it is zero, which
overrides the mapping of a zero value to "-". If you switch to a value of
"1", I believe you will get the proper behavior. If not, it may be a bug
that I need to fix, in which case please send me the files and I'll look at
it myself.

Thanks, Rob


At 02:29 PM 10/31/2001 -0500, you wrote:
>I hacked together a file for D&D Chainmail. It's the first time I've
>created an AB file from scratch.
>
>I guess my first question is, is anyone else doing one? I'd hate to
>duplicate our efforts.
>
>Anyway, I have a question:
>
>Ranged Attack (RAtt) is a signed stat, but it does not apply to all
>models, so I set 0.0=-. Unfortunately, when there's a zero in the stat,
>it is displaying +0 instead of -.
>
>Here's the line from the data definition file:
>
> RAtt | 4 | 0 | 0.0=- | 99.0 | 0 | 2 | 0 | 0 | . | . | .
>
>Is there a workaround?
>
>Thanks,
>Rich


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



__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 2
Date: Mon, 05 Nov 2001 18:23:47 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Tyranids - * instead of number for single creature units.

AB can do it, but the Hive Tyrant would need to be handled a little bit
differently from the other units in order to display its net effects
differently. This is a choice by the data file author to simply the effort
involved in writing the data files. By having the Hive Tyrant use the same
set of options/items/tweaks as the other units, the data file author
doesn't require any additional effort to support. The downside is that the
visible behavior is the same as the other units. This is a decision
entirely at the discretion of the data file author.

Thanks, Rob


At 11:53 AM 11/1/2001 +1100, you wrote:
>Hi all,
>
>I would like to know if it is possible to remove the * for stats on Hive
>tyrant. I know this is fine to indicate that some of the unit has
>increased stats, but I'm talking about the Hive Tyrant. Only one so why
>the *. Is it posssible to apply the full number rule to single creature
>units, or can't the AB software do it?
>
>TIA, Brian


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



__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 3
Date: Mon, 05 Nov 2001 18:28:51 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: newest WHFB5 .ab version?

The latest data files for WFB 5th Edition use the filename
"warhammer_v2.ab". These files were updated to take advantage of some of
the V2.0 features last year. You can obtain these files by simply letting
Army Builder do all the work. Use the "Locate File" button on the "Select
Game System" dialog and AB will retrieve this file for you automatically.

Thanks, Rob


At 04:17 AM 11/1/2001 +0000, you wrote:
>Hey all...I'm one of those freaks who haven't rushed out to buy the
>6th edition of Warhammer Fantasy Battles yet and am still using WHFB
>5th edition. I've just recently checked out ArmyBuilder and am
>trying to track down the newest .ab file for WHFB5.
>
>The newest one I've found is the wfbv29.zip file - but it's
>specifically listed as being for version 1.4 of AB. The file doesn't
>give any links to any websites with newer versions....is v2.9 (or
>v29) the latest release or is there a newer one? If there's a better
>release (a couple of the characters crash AB2.2), where can I find
>it? Who is taking care of the updates for it?
>
>Thanks.
>
>-Bryan (aka BlkBuddah, aka Tha Meen Green Skreem, aka SpinningCharlie)


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



__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 4
Date: Mon, 05 Nov 2001 18:38:58 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Upgrading Data Files

The changes to the data files are entirely controlled by the data file
author. It is at the discretion of the author whether or not the data files
are changed in such a way that old files will or will not continue to work
correctly. Sometimes, the author has no choice in the matter, since adding
new functionality requires completely changing the way things are handled
(and breaking old files). However, the author always makes this determination.

There is no way to load files from any format other than a saved ".rst"
file into AB. If your rosters have gone out-of-date to the point where they
are no longer loadable by AB, you will unfortunately need to re-enter them
from a printout. Another option is to save each new import file when you
download it. The Mordheim files all have different filenames for each new
version, so you can easily keep all versions around.

You can determine what version of data files were used for a given ".rst"
file by looking at the contents of the file. Near the top of the file, you
will see a XML tag named "t15". The attributes for this tag named "p4" and
"p5" represent the major and minor version numbers of the data files. So if
p4 is "2" and p5 is "3", the data files used by that roster were version 2.3.

Hope this helps,
Rob


At 09:39 AM 11/2/2001 -0800, you wrote:
>Maybe I'm missing it, but is there a way to avoid having to manually
>recreate all your army rosters each time a new data file comes out? Can you
>save the rosters in text or XML & then copy them back in? I primarily use
>AB for Mordheim & maintain about 10 rosters. I now have rosters that I
>haven't kept up to date (recreating them with each new data file) & their
>old enough that I can't find the data files that allow them to be loaded
>without an error.
>Thanks,
>Nils


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



__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 5
Date: Mon, 05 Nov 2001 18:41:43 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Inter Option Dependance

At 11:29 PM 11/2/2001 +0000, you wrote:
>One fine day in the middle of the night, cmanos@crt.xerox.com got up to
>write:
>
> >Alrighty
> >
> >A unit has 3 weapon choices, A B and C. each of them can be chosen
> >as a range, but you can't have weapon A and weapon B in the same
> >unit. You can have A and C or B and C, all A, or all B, but not A
> >and B.
> >
> >Is there a function that will send up a flag if the user chooses some
> >of A and some of B?
>
>Why not give A the attribute over:B=deselect and B the attribute
>over:A=deselect?

Excellent idea. If you don't like that method and prefer using a validation
rule, simply have option A assign "typeA" to the unit and option B assign
"typeB". You can then use a "trat" attribute to verify that the presence of
typeA precludes the presence of typeB.

Thanks, Rob

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



__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 6
Date: Mon, 05 Nov 2001 18:51:30 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Inter Option Dependance

I believe this should work, as long as you have the ranges start at zero.
If the ranges start at non-zero values, this will definitely NOT work. It's
also possible that I'm very rusty at the nuances of the "over" attribute
and that I'm forgetting an important reason why this doesn't work. But
Colen uses the "over" attribute extensively, so I'm inclined to trust his
recommendation on this one. :-)

Thanks, Rob


At 12:28 PM 11/5/2001 +0000, you wrote:
>doesn't seem to work with the rang function. I'll try it again
>
>
> > Why not give A the attribute over:B=deselect and B the attribute
> > over:A=deselect?


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



__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 7
Date: Mon, 05 Nov 2001 19:11:10 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: items and options and other Qs

There is not a FAQ on ABC yet. I've been recently accumulating a bunch of
support questions and their answers for use as a starting point for a FAQ,
but I haven't done it yet.

There are two methods that leap to mind for having options and items work
together. The first technique is to use conflict groups, and this method
can be seen in use in the tutorial game system data files. With this
method, you have the weapon options visible to the user all the time. You
assign the weapon options to belong to the conflict group and you also
assign the weapon items to the same conflict group. If the user picks a
weapon item, the weapon options are disabled. If the user picks a weapon
option, the weapon items are disabled.

The second technique is to use types. Each weapon item needs to assign a
type "weapitem" to the unit via the "type" attribute and each option
assigns the type "weapoption" to the unit via the "type" attribute. Each
item then uses the "itst" attribute to verify that the type "weapoption" is
not assigned to the unit. And each option uses the "utyp" attribute to
verify that the type "weapitem" is not assigned to the unit.

To impose the limit of five on the options, you can also use a separate
conflict group. Just set the maximum count on the group to five and assign
all of the options to that conflict group. It's perfectly legal to assign
an option/item to belong to multiple conflict groups. Simply hold down the
<control> key when clicking on the conflict groups within ABC. The rules
for all of the assigned groups will be applied.

To answer your last question, the simplest solution is to use the "must"
attribute. Assign all of the options to a conflict group with a maximum
limit of 3. Then use the "must" attribute to require the unit to have at
least 3 selections. Alternately, you could skip the conflict group and just
use a pair of "must" attributes - one to impose the minimum and another to
impose the maximum.

Hope this helps,
Rob


At 10:15 PM 11/4/2001 +0000, you wrote:
>is there a techinal faq for abc? like "how do i do this..." etc?
>the registration faq doesnt help me much on that side of things .
>
>now my main question.
>being the beginner i am with abc i'd like to know how i can link
>options and items. heres what i mean. troopA can choose any item they
>want, however if its not a weapon then i need optionA, optionB, and
>optionC to appear. also, they can choose upto five things from A+B+C
>if the options are there for them. i know how to set range and ocat
>(for troops that have the same a+b+c validation). but how do i make
>this all work together for troopA?
>
>acutally while i'm here lemme bug you guys with this too ...
>troopB has only 1 model in it but needs to have 3 option choices. how
>do i get ocat to force exatcly 3 choices? do i use something else?
>right now i have 2 lines of ocat with the ratio of 0:3 and 3:0.
>
>thanks guys and i hope this was clear :P


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



__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 8
Date: Tue, 06 Nov 2001 01:49:25 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: (no subject)

Unfortunately, the current version of AB doesn't provide an optimal way to
handle the command point structure within Chainmail. Even though we
received a verbal OK to do data files for Chainmail, the folks at WotC have
been very secretive until something was inked in writing, and that still
hasn't been accomplished yet. :-( Needless to say, I didn't know about the
special command point rules on warband construction until I got my starter
set. :-)

That being said, there IS a reasonable way of solving this problem. It's
just a little bit clunky. Since there is no way to compare accumulated
stats in AB, totalling up the in-faction and out-of-faction command points
(plus those for Wild Troops) provides numbers that you then can't use. :-(
I promise to address this in the next release of AB, so keep those stats in
place for the future. Until then, however, you will need to utilize types.

The key will be to assign a type to each model, as appropriate to its
command value and/or command cost. You can then use the "trat" attribute to
impose appropriate validation constraints on the roster. The difficulty
that arises with this approach is that there is no way to track models that
cost more than one command point or have a command value greater than one.
So how do you solve that? Well, the clunky solution is to use dummy child
units. When a unit has more than one command point, you need to attach to
that unit a dummy child unit that also has the proper type and has a number
of models equal to the extra command value/cost. You then must use the
model-based comparisons of the "trat" attribute. To help mitigate the
clunkiness factor of this approach, name the dummy child units something
clearly to be ignored and assign them a stat-set that consists of a single
attribute that is obviously to be ignored. Another thing to do is designate
the unit as display-only via use of the "disp:noprint" attribute. You must
also assign the "forc" attribute to these units in order to assure that the
types assigned to these units are included in the "trat" comparisons. Once
you have the child units and types implemented, it should be easy to write
the necessary "trat" attributes to verify all the correct relationships as
in place within the roster.

Like I said, it's a clunky solution, but it's not a horribly ugly one. :-)
I'll make sure to implement the necessary functionality for a clean
solution in the next release of AB.

If you have questions about the above solution, don't hesitate to ask. I'm
not certain how familiar you are with writing AB data files, so I may have
glossed over some important details in my description. If so, I'll be happy
to clarify.

Thanks, Rob


At 01:17 PM 11/3/2001 -0500, you wrote:
>Hello all.
>
>I'm almost finished with the D&D Chainmail ab files, but I'm stumped on how
>to implement the command limits for unit selection.
>
>First, some background:
>A warband (army) comes from one of six factions (races).
>Certain models are Commanders, and they have a command rating (from 1 to 5).
>
>When you build a warband you have to have:
>- one point of command for each in-faction Wild Troop.
>- one point of command for every out-of-faction Model.
>- two points of command for every out-of-faction Difficult or Wild Troop.
>
>Things get a little more tricky when you recruit an out-of-faction Commander.
>You can't have more out-of-faction command points than in-faction command
>points. Also, you can't use out-of-faction command points for the limits
>specified above.
>
>I've implemented several hidden stats to help me: Command Points, In-Faction
>Command Cost, and Out-of-Faction Command Cost. Wild Troop and Difficult
>Troop are also defined as Options.
>
>But, I can't figure out how to calculate and compare these stats for
>validation purposes.
>
>Any help would be appreciated.
>
>Thanks,
>Rich


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



__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 9
Date: Tue, 06 Nov 2001 11:43:02 -0000
From: cmanos@crt.xerox.com
Subject: Re: Inter Option Dependance

tried it with the over finction and couldn't get it to work. I'll
try it with the trat...that I believe is exactly what I was looking
for. I'm just dense that I didn't think of it.

Chris

--- In armybuilder@y..., Rob Bowes <rob@w...> wrote:
> I believe this should work, as long as you have the ranges start at
zero.
> If the ranges start at non-zero values, this will definitely NOT
work. It's
> also possible that I'm very rusty at the nuances of the "over"
attribute
> and that I'm forgetting an important reason why this doesn't work.
But
> Colen uses the "over" attribute extensively, so I'm inclined to
trust his
> recommendation on this one. :-)
>
> Thanks, Rob
>
>
> At 12:28 PM 11/5/2001 +0000, you wrote:
> >doesn't seem to work with the rang function. I'll try it again
> >
> >
> > > Why not give A the attribute over:B=deselect and B the attribute
> > > over:A=deselect?
>
>
> --------------------------------------------------------------------
-------
> Rob Bowes (rob@w...) (650) 726-9689
> Lone Wolf Development
www.wolflair.com



__________________________________________________ ______________________
__________________________________________________ ______________________



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/