• Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.

    If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.

    - The Lone Wolf Development Team

Digest Number 487

  • Thread starter Thread starter armybuilder at yahoogroup
  • Start date Start date
A

armybuilder at yahoogroup

Guest
------------------------ Yahoo! Groups Sponsor ---------------------~-->
FREE COLLEGE MONEY
CLICK HERE to search
600,000 scholarships!
http://us.click.yahoo.com/zoU8wD/4m7CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, email

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

There are 13 messages in this issue.

Topics in this digest:

1. lcmp and base odd behavior?
From: "Shawn Campbell" <shawn@electricstitch.com>
2. Re: more wish list items
From: Rob Bowes <rob@wolflair.com>
3. Re: lcmp and base odd behavior?
From: Rob Bowes <rob@wolflair.com>
4. Re: Re: Linking options to other options uniquely
From: jizbrand@kc.rr.com
5. Portability
From: Ken & Mary <ken_mary@pacbell.net>
6. Re: Portability
From: "Chris Beilby" <cbeilby@hroads.net>
7. Re: lcmp and base odd behavior?
From: "Shawn Campbell" <shawn@electricstitch.com>
8. Re: lcmp and base odd behavior?
From: "Shawn Campbell" <shawn@electricstitch.com>
9. Re: Re: Linking options to other options uniquely
From: Rob Bowes <rob@wolflair.com>
10. Re: Portability
From: Rob Bowes <rob@wolflair.com>
11. Re: more wish list items
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
12. uadd and multiple model units
From: "Shawn Campbell" <shawn@electricstitch.com>
13. Re: uadd and multiple model units
From: Rob Bowes <rob@wolflair.com>


________________________________________________________________________
________________________________________________________________________

Message: 1
Date: Thu, 23 Aug 2001 03:12:39 -0700
From: "Shawn Campbell" <shawn@electricstitch.com>
Subject: lcmp and base odd behavior?

The following didn't work for me. I found a solution, but I thought it was
odd. First what I attempted:

Unit Alpha can have a child 'Unit Beta'. Unit Alpha can only have child
"Unit Beta' if it possess 'Item Beta'.

My thought was to do this:
Option Beta: base:beta+1
Item Beta: base:beta-1
Unit Alpha: lcmp:beta=1-msg=nobeta

beta is defualt 0.

I figured Item Beta and Option beta would cancel each other out, equaling 0.
If option beta is taken alone, then lcmp:beta=1 would kick in.

I got odd results. (I forget exactly, it took a lot of trial and error to
figure out a way to make it work).

What I had to do was this:

Option Beta: base:beta+5
Item Beta: base:beta=(-5)
Unit Alpha: lcmp:beta<1-msg=nobeta

I thought this was odd, but it actually works!?

I also note that when I debug the hidden stats, it shows beta=0 regardless
of if option beta is taken. (shouldn't taking Option Beta alone cause debug
to show beta=5?) If I take Item beta, it debugs as beta-5 (I expected this).
and when I take option beta w/ Item beta it debugs at beta=0 (expected). I
had figured that lcmp:beta=5 would have been appropriate, but this causes
Item Beta (alone) to error instead of Option Beta (alone).

I admit, I am still learning the ropes here. but this just seems odd to
me... I also hope my explanation made sense.

Thanks,
-Shawn



________________________________________________________________________
________________________________________________________________________

Message: 2
Date: Thu, 23 Aug 2001 02:45:56 -0700
From: Rob Bowes <rob@wolflair.com>
Subject: Re: more wish list items

At 07:34 PM 8/22/2001 +0000, you wrote:
>I would _really_ like to have some subset of the following:
>For items:
> invs: and/or disp: and/or hide (e.g. let me determine whether the
>item will be rendered on-screen, on-report, neither, or both)
>improved and expanded version: permit such an implementation
>mechanism to be toggled by environmentals (particularly unit type at
>run-time). This might be implemented by #when. An alternative
>implementation might be to provide a set of tweak attributes that
>control the rendering of the parent item - thus permitting rich
>semantics through existing tweak logical controls.

The AB engine is already highly complex. And most people's eyes cross when
they try to wrap their arms around the complexity already present. You must
truly be a sado-masochist, since adding this would be ugly for me AND ugly
for yourself if I can implement it. :-)

Give me an idea of how "invs" would truly be useful for items. Same for
"disp". I can almost see where "hide" might be useful in rare
circumstances, but I'd appreciate a concreate example or two. I REALLY need
to understand how a complex set of rendering controls is going to make AB
vastly more useful. The more justification you can provide, the more likely
your requests get implemented. :-)

>For Rendering:
>consistency in rendering for comments, notes, and report output.
>currently, the three sets of output operate differently in units,
>items, options, tweaks, etc., etc. Particularly tiresome is the
>inconsistent implementation of ^ (which I'll address next).

This is artifactual. When V1.0 was released three years ago, the scope of
comments, notes, and report output was quite limited. It was also very
distinct for each type of record. As AB evolved, the line began to blur.
However, AB has always provided 99.8% backwards compatability (I'm sure I
broke something along the way that I can't remember). That means that all
of the original (distinct and dissimilar) handling of the different record
types has needed to remain.

You will find that the behavior of comments, notes, and report output work
identically between options and tweaks. They also work VERY similarly to
units (I'm sure there are differences, but I honestly can't even think of
them at the moment). The big exception is items, which are utterly unique
unto themselves. I'm guessing from your other posts that the oddness of
items is what's really bugging you.

As for the inconsistent handling of "^", there are only two ways it's
handled. Normally, it's a literal character, except within items. For
items, it provides a means of inheriting the notes from the previous level,
which was intended as a means of minimizing data entry for data file
writers. This worked quite well for the WFB5 data files and a few others
from way back. As AB's engine has grown in sophistication, this has become
less used (if at all anymore). But again, the issue here is backwards
compatability.

>Also... can I have a line-break please? at the moment, semi-colon
>does it in some places, but not others... It would also make tabular
>output _so_ much easier (such as the spell lists from WFB)

In the old days, data file writers had to use ABData. Nowadays, few people
use it, but it is still valuable in some circumstances. However, since
ABData uses a tab/carriage-return delimited file structure, it doesn't work
to embed carriage returns within the data. The semi-colon was used to let
authors insert appropriate breaks, although some authors refused to bother
with semi-colens (Hi Colen!), so I had to make AB a bit more adaptive.
That's what has resulted in the less than optimal behaviors with
semi-colens in AB. :-(

It would be possible to introduce the notion of a line-break, but it can't
be a carriage return (since ABData would be hosed), so it would need to be
a character sequence that has never been used within an AB data file before
(remember backwards compatability!). Then everything within the AB engine
and output would have to be modified to support that special sequence. It
has never been a big enough need for the few people who have asked for it,
so it's never been a priority to implement, but it IS on the todo list. :-)

>For Maintainability:
>Floating Text Blocks!! If there were an extension for the messages
>mechanism that permitted the incorporation of text blocks into
>comments/notes/report output THAT WAS CONSUMABLE BY ALL OBJECTS (e.g.
>both _options_ and _items_ then a lot of overlap/multiple text
>instances might be avoided, improving the
>maintainability/orthogonalization of some data files (again, see the
>WBF magic section, which must be a _bear_ to maintain...). A possible
>implementation might be to have a special category of message
>objects, with id's beginning with <& (in a manner similar to the x*
>unit types). Any comment/note/report field could than include a
>reference (with a trailing >), and "suck in" all the text from the
>shared message. Example: messages <&foo defined as "rockin' common
>text into uncommon places", and referenced as "my local object is
><&foo>"

That's an interesting idea that I never thought of. With all the data files
I've written, I've never run into a situation where I needed to duplicate
text across options and items for multiple records. Yes, there have been
the rare instance, but it was always a special case. I'll put this on the
todo list, since it's a cool idea.

>and now back to retyping a few hundred entries, once as options, and
>again as items <sigh>

What about copy and paste? It's still duplication, but it's not nearly as
bad as retyping things. :-)

Thanks, Rob

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



________________________________________________________________________
________________________________________________________________________

Message: 3
Date: Thu, 23 Aug 2001 04:49:37 -0700
From: Rob Bowes <rob@wolflair.com>
Subject: Re: lcmp and base odd behavior?

There are two issues here. First, I'm not sure why you are using a stat to
track whether an option should be available for selection. If I understand
correctly, you could much more easily solve this with a simple
"type:BetaOK" attribute on the item and a "utyp:BetaOK" on the option. If
the option is required when the item is taken, you can either use the
"uadd" attribute on the item or you can define a "must" attribute on the
parent unit that requires selection of the child unit only "when" the
assigned type is present. So if the item is selected, the type is assigned,
which means the option must be selected.

The second issue is that I believe you have the "lcmp" attribute inverted
in its meaning. The attribute verifies that the stat comparison
relationship is complied with. If it is NOT complied with, THEN the
validation error is triggered. This means that "lcmp:beta=1" will trigger
an error any time that "beta" is NOT equal to 1. From your description it
appears that you are assuming the error will be reported if "beta" DOES
equal 1, which is exactly the opposite from how it works.

Another important detail to keep in mind is the bounds specified for stats.
Within the definition file, each stat has a bounding range specified. Make
sure that you don't inadvertently expect a stat to go outside of that
bounding range, because it won't. For example, if the range has a minimum
of 0 and a maximum of 100, subtracting 5 from a starting value of 0 will
yield a result of 0 (the minimum). This can be very confusing, since it's
controlled in the definition file and everything in the data files will
look great, but AB will appear to be generating incorrect results. Even
though it is generating the exact results you told it to. :-)

If I have misunderstood anything, please clarify for me. Otherwise, I hope
this helps out a bit. :-)

Thanks, Rob


At 03:12 AM 8/23/2001 -0700, you wrote:
>The following didn't work for me. I found a solution, but I thought it was
>odd. First what I attempted:
>
>Unit Alpha can have a child 'Unit Beta'. Unit Alpha can only have child
>"Unit Beta' if it possess 'Item Beta'.
>
>My thought was to do this:
>Option Beta: base:beta+1
>Item Beta: base:beta-1
>Unit Alpha: lcmp:beta=1-msg=nobeta
>
>beta is defualt 0.
>
>I figured Item Beta and Option beta would cancel each other out, equaling 0.
>If option beta is taken alone, then lcmp:beta=1 would kick in.
>
>I got odd results. (I forget exactly, it took a lot of trial and error to
>figure out a way to make it work).
>
>What I had to do was this:
>
>Option Beta: base:beta+5
>Item Beta: base:beta=(-5)
>Unit Alpha: lcmp:beta<1-msg=nobeta
>
>I thought this was odd, but it actually works!?
>
>I also note that when I debug the hidden stats, it shows beta=0 regardless
>of if option beta is taken. (shouldn't taking Option Beta alone cause debug
>to show beta=5?) If I take Item beta, it debugs as beta-5 (I expected this).
>and when I take option beta w/ Item beta it debugs at beta=0 (expected). I
>had figured that lcmp:beta=5 would have been appropriate, but this causes
>Item Beta (alone) to error instead of Option Beta (alone).
>
>I admit, I am still learning the ropes here. but this just seems odd to
>me... I also hope my explanation made sense.
>
>Thanks,
>-Shawn


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



________________________________________________________________________
________________________________________________________________________

Message: 4
Date: Thu, 23 Aug 2001 14:08:57 -0000
From: jizbrand@kc.rr.com
Subject: Re: Re: Linking options to other options uniquely

Daniel, Rob: Thanks for the advice -- it is very nearly exactly what
I was looking for. The only challenge left is to figure a way to
append or prepend text to the notes indicating which weapon the
equipment is for. But I'll figure a way to do that, or else add a
bunch of tweaks unique to each weapons. Thanks for your help.

-- John

======================================================================


Yeah. What he said. :-)

Also, when you create the items, make sure to have a hidden item
category
and assign all the weapon items to that category. This way, they
won't even
exist in the special items list for the user to get confused with.

Hope this helps,
Rob


At 06:49 PM 8/22/2001 +0000, you wrote:
>I hate to say it (as you've mentioned you'd prefer not to...), but it
>really sounds like your best implementation is as items with tweaks
>(for sights, etc., etc.). What you might want to look at is
>triggering items through options with take:, which allows your
>primary weapon/option to show up on the options panel (rather than
>needing to go into the equipment dialog). Individual tweaks can then
>be accomplished by selecting the new line item, and the tweaks will
>show up in the options box.
>
>good luck,
>daniel
>
>
>--- In armybuilder@y..., jizbrand@k... wrote:
> > I'm working on AB files for Trinity Battleground. Each weapon is
> > entered as an option. I also have things like sights and
>ammunition
> > as options too. What I need to do is to set up, say, a rifle such
> > that it has the option of taking a laser, infrared, or telescopic
> > sight. Taking any one should disable all the others.
> >
> > I can link the sight to the weapon via a "more" attribute. And I
>can
> > set up each of the sights to deselect all other sights once the
> > primary sight is selected using the "over" attribute.
> >
> > Now here's the problem I'm trying to solve. A figure can have
more
> > than one weapon, hence more than one sight. If I set up weapons
>and
> > sights as described above, when the second weapon is selected, it
> > opens up all the sights again for selection. Selecting any one
> > deselects the sight for the first weapon.
> >
> > Question: How do I set up the weapon and the sight so that the
two
> > are linked independently of a second weapon and sight combination?
> >
> > Constraints: I'd prefer not to have the weapons as Items
(probably
> > the easiest way to do this); and, I'd prefer not to have to define
> > each type of sight for each type of weapon (e.g.,
> > Laser_Sight_for_Pistol, Laser_Sight_for_Submachinegun, etc.).
> >
> > Any ideas?




________________________________________________________________________
________________________________________________________________________

Message: 5
Date: Thu, 23 Aug 2001 10:32:54 -0700
From: Ken & Mary <ken_mary@pacbell.net>
Subject: Portability

I have the cd format of Armybuilder. My problem is I use several
different computers and printers to design and print my armies.(ie maybe
at wife's parents place, kinkos, and or friends) It is not practical to
install it on each system. This is like buying music cd that can only
play on my home system. Basically is it possible to run army builder
from the cd and any assocated files on floppies without a complete
installation being dxone each time?
Sorry for the long post.


[Non-text portions of this message have been removed]



________________________________________________________________________
________________________________________________________________________

Message: 6
Date: Thu, 23 Aug 2001 13:52:02 -0400
From: "Chris Beilby" <cbeilby@hroads.net>
Subject: Re: Portability



> I have the cd format of Armybuilder. My problem is I use several
> different computers and printers to design and print my armies.(ie maybe
> at wife's parents place, kinkos, and or friends) It is not practical to
> install it on each system. This is like buying music cd that can only
> play on my home system. Basically is it possible to run army builder
> from the cd and any assocated files on floppies without a complete
> installation being dxone each time?
> Sorry for the long post.

Three words. Army Builder Lite

I keep my copy of AB on my home system, and ABL on my fiance's laptop for
taking to the game shop when I play.

Or you could save copies of your rosters in txt or XML formats.




________________________________________________________________________
________________________________________________________________________

Message: 7
Date: Thu, 23 Aug 2001 11:28:02 -0700
From: "Shawn Campbell" <shawn@electricstitch.com>
Subject: Re: lcmp and base odd behavior?

Rob,

I think you answered my question. lcmp makes more sense now... might have a
little to do with it being 3am when I was working on the datafile.

Thanks,
-Shawn




________________________________________________________________________
________________________________________________________________________

Message: 8
Date: Thu, 23 Aug 2001 11:46:34 -0700
From: "Shawn Campbell" <shawn@electricstitch.com>
Subject: Re: lcmp and base odd behavior?

> "type:BetaOK" attribute on the item and a "utyp:BetaOK" on the option. If
> the option is required when the item is taken, you can either use the
> "uadd" attribute on the item or you can define a "must" attribute on the
> parent unit that requires selection of the child unit only "when" the
> assigned type is present. So if the item is selected, the type is
assigned,
> which means the option must be selected.

I used uadd and it did exactly what I wanted. Thanks Rob. No need for
validation now!!

-Shawn



________________________________________________________________________
________________________________________________________________________

Message: 9
Date: Thu, 23 Aug 2001 13:15:40 -0700
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Re: Linking options to other options uniquely

Tweaks are definitely the best way to do this.

Thanks, Rob


At 02:08 PM 8/23/2001 +0000, you wrote:
>Daniel, Rob: Thanks for the advice -- it is very nearly exactly what
>I was looking for. The only challenge left is to figure a way to
>append or prepend text to the notes indicating which weapon the
>equipment is for. But I'll figure a way to do that, or else add a
>bunch of tweaks unique to each weapons. Thanks for your help.
>
>-- John


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



________________________________________________________________________
________________________________________________________________________

Message: 10
Date: Thu, 23 Aug 2001 13:23:03 -0700
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Portability

Software requires that you install it. That is the unfortunate nature of
software. Data files still need to be installed, and they have to go
somewhere that the product knows to look for them, so that information is
setup when the product is installed. Besides, installation takes less than
a minute, so it's not as if the installation process is a hugely
time-consuming task. :-)

Thanks, Rob


At 10:32 AM 8/23/2001 -0700, you wrote:
>I have the cd format of Armybuilder. My problem is I use several
>different computers and printers to design and print my armies.(ie maybe
>at wife's parents place, kinkos, and or friends) It is not practical to
>install it on each system. This is like buying music cd that can only
>play on my home system. Basically is it possible to run army builder
>from the cd and any assocated files on floppies without a complete
>installation being dxone each time?
> Sorry for the long post.


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



________________________________________________________________________
________________________________________________________________________

Message: 11
Date: Thu, 23 Aug 2001 23:53:12 +0100
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: Re: more wish list items

At 02:45 23/08/2001 -0700, you wrote:

>As for the inconsistent handling of "^", there are only two ways it's
>handled. Normally, it's a literal character, except within items. For
>items, it provides a means of inheriting the notes from the previous level,
>which was intended as a means of minimizing data entry for data file
>writers. This worked quite well for the WFB5 data files and a few others
>from way back.

Indeed, the 40k files use it a lot too.

>In the old days, data file writers had to use ABData. Nowadays, few people
>use it, but it is still valuable in some circumstances. However, since
>ABData uses a tab/carriage-return delimited file structure, it doesn't work
>to embed carriage returns within the data. The semi-colon was used to let
>authors insert appropriate breaks, although some authors refused to bother
>with semi-colens (Hi Colen!),

oi! I didn't refuse, I just forgot :(

And "semi-colens"? What a horrible thought, there's quite enough of me
already :)

>That's what has resulted in the less than optimal behaviors with
>semi-colens in AB. :-(

There you go again :)


--
Colen 'Skrillboy' McAlister, demandred@skrill.org
http://www.skrill.org/, http://www.incompetence-central.co.uk/
1 = 2, for large values of 1.



________________________________________________________________________
________________________________________________________________________

Message: 12
Date: Fri, 24 Aug 2001 00:08:58 -0700
From: "Shawn Campbell" <shawn@electricstitch.com>
Subject: uadd and multiple model units

Rob,

I used the uadd:UnitBeta@1 for item Foo.

UnitBeta has a size of 1:2, but because of uadd I must set the unit size, I
can't make it adjustable.

What am I doing wrong. Is their something else I can put with uadd? I tried
uadd:UnitBeta@1:2 and few others, but it appears uadd. It appears I can only
have a specific, unadjustable amount of models in UnitBeta.

Is their a better way to do this?

ItemFoo allows UnitAlpha to take 1-2 UnitBeta's.

It looks like I might have to go back to my original plan of putting an
OptionUnitBeta on UnitAlpha that gives validation message if ItemFoo isn't
used. (using lcmp).

I had this working, I just really liked the way uadd worked and hoped I
could do something.

Thanks for your help,
-Shawn



________________________________________________________________________
________________________________________________________________________

Message: 13
Date: Fri, 24 Aug 2001 02:38:42 -0700
From: Rob Bowes <rob@wolflair.com>
Subject: Re: uadd and multiple model units

The "uadd" attribute attaches a child unit of a fixed size. If you need a
variable size, then you can't use "uadd". Instead, use the method I
suggested in my previous response (where I also suggested "uadd"). This is
quite easy to do WITHOUT needing to resort to using stat comparisons and
without forcing the user to add the child unit. You can do it all
automatically with an auto-based option and "utyp". If you have questions
after reading my earlier post, let me know.

Thanks, Rob


At 12:08 AM 8/24/2001 -0700, you wrote:
>Rob,
>
>I used the uadd:UnitBeta@1 for item Foo.
>
>UnitBeta has a size of 1:2, but because of uadd I must set the unit size, I
>can't make it adjustable.
>
>What am I doing wrong. Is their something else I can put with uadd? I tried
>uadd:UnitBeta@1:2 and few others, but it appears uadd. It appears I can only
>have a specific, unadjustable amount of models in UnitBeta.
>
>Is their a better way to do this?
>
>ItemFoo allows UnitAlpha to take 1-2 UnitBeta's.
>
>It looks like I might have to go back to my original plan of putting an
>OptionUnitBeta on UnitAlpha that gives validation message if ItemFoo isn't
>used. (using lcmp).
>
>I had this working, I just really liked the way uadd worked and hoped I
>could do something.
>
>Thanks for your help,
>-Shawn


---------------------------------------------------------------------------
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/
 
Back
Top