Digest Number 235

-------------------------- eGroups Sponsor -------------------------~-~>
eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9699/0/_/36190/_/976103933/
---------------------------------------------------------------------_->

To unsubscribe from this group, email

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

There are 8 messages in this issue.

Topics in this digest:

1. WHFB ver6 problems
From: OgiertheDane@aol.com
2. Re: Far-flung ideas
From: Rob Bowes <rob@wolflair.com>
3. RE: Far-flung ideas
From: Rob Bowes <rob@wolflair.com>
4. RE: Problem with Dark Eldar in Gamma-III datafiles
From: Rob Bowes <rob@wolflair.com>
5. Re: Far-flung ideas
From: Rob Bowes <rob@wolflair.com>
6. Re: GW Version of Computer Army Creator for Space Marines
From: yoda@cox.rr.com
7. RE: GW Version of Computer Army Creator for Space Marines
From: Rob Bowes <rob@wolflair.com>
8. Re: Re: A complex option cost question (Crucible)
From: Rob Bowes <rob@wolflair.com>


__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 1
Date: Wed, 6 Dec 2000 01:59:04 EST
From: OgiertheDane@aol.com
Subject: WHFB ver6 problems

I downloaded a datafile from another site. it didn't work. Do you plan to
create a current datafile with the Empire and Orc Army Books?

(I'm not a member of your e-mail list)


__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 2
Date: Tue, 05 Dec 2000 22:58:12 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Far-flung ideas

Here is what it all boils down to......

It would definitely be possible to figure out a way for AB to salvage a
portion of an old saved roster when the data files are updated. My guess is
that it would take me about 4-6 weeks of effort to get something that would
salvage about 70% (on average) of a roster. The more salvaging required,
the more time required, and the recovery vs. effort curve starts to get
really steep after about 70%. In other words, it could easily be 8 weeks
total (2-4 weeks extra) to achieve a 75-80% salvage rate (i.e. a 5-10%
improvement). All of this effort would be invested to do a marginal (at
best) job and still leave lots of work to the user to perform. Is that
really a big benefit over printing out your old roster and re-entering it
in 5 minutes?

On the other hand, I could spend that same amount of time on new features
and/or new products. New features include things like being able to have AB
automatically retrieve and import new data files for you. You simply say
"go" and AB finds them, downloads them, and imports them. No muss, no fuss.
Or how about adding support for campaign systems where you can readily
track the additional resources acquired/lost and have AB reflect their
influences within the army roster automatically? Or the ability to add
graphics of your figs into your rosters and/or shown within AB. There is a
LONG list of features that people still keep asking for and that I'd like
to add. There are also lots of people asking for new tools, such as a lead
database. I've already got this mapped out pretty well, including an
integration into AB so you know whether you actually own all the lead that
you included in your roster. But I haven't had the time to write it yet.

The bottom line is determining which of the above is more valuable to the
end-user. My personal feelings are that half-assed solutions are usually
best avoided. They typically don't really help all that much in the long
run. That's why I've opted for adding features thus far.

But the real answer lies with all of you users. If there is anyone out
there that honestly feels that reading old rosters partially is better than
adding some major new features and/or products, please let me know. It's
quite possible that I've got a distorted perspective of what people most
want in the product - it wouldn't be the first time! Please don't turn this
into a high-bandwidth discussion with lots of "Me too!" posts, but I would
very much like to hear comments on the relative merits of these two
alternatives and which you would find more valuable.

Thanks, Rob

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


__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 3
Date: Tue, 05 Dec 2000 23:00:11 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: RE: Far-flung ideas

This is definitely an objective of mine in the reasonably near future. It
would definitely be nice for AB to be able to inform the user when a roster
relies on a different set of data files and/or different version of AB.

Thanks, Rob


At 03:23 PM 12/5/00 -0700, you wrote:
>Creating a consistant way to represent data file and Armybuilder version
>numbers along with storing both pieces of
>information in the saved roster could also aid the conversion
>process. The user could then be given an error message that says this
>saved roster was created using x.y.z version of Armybuilder using the
>a.b.c version of the datafiles. One could then find those versions and at
>least create a printout of the roster.


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

[This message contained attachments]



__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 4
Date: Wed, 06 Dec 2000 01:16:14 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: RE: Problem with Dark Eldar in Gamma-III datafiles

At 10:48 PM 12/5/00 +0000, you wrote:
>That's an Army Builder "feature". Conflict groups (the things that make
>stuff grey out) don't work properly with the +- options, so we have to use
>the validation message thing.

The conflict group mechanism works partially with the +/- options, but not
fully. The problem is that conflict groups and their behavior were designed
and implemented long before the +/- (ranged) options. Ranged options were
never intended for use in their current capacity. Colen opted to use them
in the way he did and I've been trying to get AB's functionality with them
to catch up with Colen ever since. :-)

You'll be happy to note that this limitation will be addressed in the next
release of AB. Then Colen will just have to come up with yet another way to
use them that I never intended and I'm back to playing catch-up. :-)

Thanks, Rob

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


__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 5
Date: Wed, 06 Dec 2000 01:20:52 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Far-flung ideas

At 10:46 PM 12/5/00 +0000, you wrote:
>This is cool and froody for units. If I changed the unit ID of something,
>there's no way I'd expect it to work out which unit to add instead. But
>take the following example: The saved file references option "skrill1", but
>the unit can't get option "skrill"! Instead of falling over and refusing to
>load the file, just ignore "skrill" completely. Then produce a message
>saying "By the way, you might want to check unit X, as odd things happened
>when I was loading it". Is this feasible, and would it help at all?

That's a lot easier said than done, except in the simplest case - which you
have happily chosen to use for your example. What if the missing option
assigns the unit type "Foo"? And what if there are other options that use
"utyp:Foo" and are now invalid. And what if there are items on the unit
that are only valid if type "Foo" is assigned (which is no longer the
case)? These are just a few of the SIMPLE cases that quickly emerge. They
get a LOT nastier - especially with the highly complex 40K files. So it is
NOT a simple matter to just ignore the option. There are WAY too many
inter-dependencies within data files that AB would have to gracefully
handle for this to be anything short of a major undertaking to solve.

Thanks, Rob

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


__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 6
Date: Wed, 06 Dec 2000 09:25:35 -0000
From: yoda@cox.rr.com
Subject: Re: GW Version of Computer Army Creator for Space Marines

i founfd info here
http://www.blacklibrary.co.uk/40kinteractive/index.htm

--- In armybuilder@egroups.com, extremezen@h... wrote:
> Well Rob's product is called "Army Builder" and games workshop's
> product is called "Space Marine Interactive Army Builder". While
not
> exactly the same title I can how this could cause some "confusion"
> issues.
> Hopefully the product itself is different enough that GW does
gain
> customers from the great reputation and product that Rob has put
out.
>
> --- In armybuilder@egroups.com, "Brad Morgan" <B-Morgan@c...> wrote:
> > An army builder and ArmyBuilder are different. I not a lawyer so
I
> don't
> > know if Army Builder and ArmyBuilder are considered the same or
> different.
> >
> > I'm disappointed in Games Workshop for even starting this war
> because if
> > there is a legal issue here, I can almost guarantee that the only
> people
> > that will get rich are the lawyers.
> >
> > Good Luck,
> >
> > Brad armybuilder-unsubscribe@egroups.com



__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 7
Date: Wed, 06 Dec 2000 01:28:09 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: RE: GW Version of Computer Army Creator for Space Marines

The only protection on a name is a trademark. I'm investigating how to
handle this situation. While I knew that GW was coming out with their own
product, I certainly did not expect them to trade on the reputation
established by AB. They are definitely opening themselves up for potential
legal remedy, although they may also be expecting I won't have the
financial resources to contest them. Things could get interesting here, and
I would appreciate it if everyone did not speculate on this matter on the
forum any further. The moment that the potential for lawyers comes into
play, nothing can be commented on publicly until things become a matter of
public record. So I won't be able to say anything further for awhile.

Rest assured that I'll let everyone know as soon as there is anything
concrete that I can publicy state.

Thanks for everyone's continued support, and please make sure that anyone
confusing the two products has the differences clarified for them. :-)

Thanks, Rob


At 05:03 PM 12/5/00 -0600, you wrote:
>My question to you Rob is do you have the name Army Builder patented or
>copyrighted because I do believe that they are calling their version the
>same thing. If not then copyrights are usually a use it or lose it deal.
>
>Thanks
>
>Mike


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


__________________________________________________ ______________________
__________________________________________________ ______________________

Message: 8
Date: Wed, 06 Dec 2000 01:34:46 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Re: A complex option cost question (Crucible)

At 06:04 AM 12/6/00 +0000, you wrote:
>--- In armybuilder@egroups.com, Rob Bowes <rob@w...> wrote:
> > First, are you sure that the behavior you are getting with "ucst"
> > is not what Tim intended? Have you asked him? He took a look at the
> > original files and didn't flag any cost calculation errors, so I
> > just want to be sure before you change everything. :-)
>
>He goofed. Its wrong.

Ah. Well, then you're in for a fair bit of work to fix things.... :-(

> > Second, the proper solution for what you are asking for is to use
> > two hidden stats. The first stat would have the percentage
> > multiplier assigned to it. The second stat should use a calculation
> > with the proper rounding control on it, multiplying the unit cost
> > (which is thankfully fixed for Crucible units) by the percentage.
> > Then you can use the proper "cost" attribute on an option to set
> > the cost equal to the value of the second hidden stat.
>
>How do I "multiply the unit cost by the percentage" in a stat calc?
>Do I have to manually specify the cost for each unit in a "UCost"
>stat and then use that? If that is the case, I'm going to have to
>have a stat "Ucst" for each unit that is equal to their cost, and a
>second stat that I modify in an option something like:
>stat:Mcst=(Ucst*0.15)-roundup and then cost:expr=(Mcst*#)
>Is that what you meant? Yuck!

You basically have the idea. The biggest gotcha is going to be how to
handle the multipliers for the new native troops mechanism on top of this.
Yuck is definitely the word I would use for it. :-( At least V2 allows you
to handle most of this through a few attributes that you can inherit from a
base class unit. That ought to make life a good bit easier that it
otherwise would be. :-)

Good luck,
Rob

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

[This message contained attachments]



__________________________________________________ ______________________
__________________________________________________ ______________________