A
armybuilder at egroups.co
Guest
-------------------------- eGroups Sponsor -------------------------~-~>
PLAY GAMES. WIN PRIZES. GUARANTEED.
Get $5.00 in FREE credits when you register at
http://click.egroups.com/1/10501/0/_/36190/_/976082672/
---------------------------------------------------------------------_->
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
------------------------------------------------------------------------
There are 25 messages in this issue.
Topics in this digest:
1. Far-flung ideas
From: "Lars Gottlieb" <larsgottlieb@forum.dk>
2. GW Version of Computer Army Creator for Space Marines
From: "Christepher McKenney" <cam1@nrc.gov>
3. Re: GW Version of Computer Army Creator for Space Marines
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
4. Re: Vehicle Upgrade Problems in new 40Kv3 files
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
5. Re: Far-flung ideas
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
6. Re: Problem with Dark Eldar in Gamma-III datafiles
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
7. Re: Far-flung ideas
From: Rob Bowes <rob@wolflair.com>
8. RE: Problem with Dark Eldar in Gamma-III datafiles
From: "Brad Morgan" <B-Morgan@concentric.net>
9. RE: Far-flung ideas
From: "Brad Morgan" <B-Morgan@concentric.net>
10. Re: Far-flung ideas
From: Rob Bowes <rob@wolflair.com>
11. Re: Vehicle Upgrade Problems in new 40Kv3 files
From: Michael Nixon <mnixon@macn.bc.ca>
12. Re: GW Version of Computer Army Creator for Space Marines
From: Rob Bowes <rob@wolflair.com>
13. Re: Far-flung ideas
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
14. Re: Far-flung ideas
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
15. RE: Problem with Dark Eldar in Gamma-III datafiles
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
16. RE: GW Version of Computer Army Creator for Space Marines
From: "Michael E. Gilkison Sr." <mgilkison@kc.rr.com>
17. Re: Possible Idea for future AB
From: freds67@aol.com
18. Re: Possible Idea for future AB
From: Eric Landes <eric@landesfamily.com>
19. Re: Digest Number 233
From: "SUPrUNown" <matrix@pangea.ca>
20. Re: Digest Number 233
From: Eric Landes <eric@landesfamily.com>
21. RE: GW Version of Computer Army Creator for Space Marines
From: "Brad Morgan" <B-Morgan@concentric.net>
22. Re: GW Version of Computer Army Creator for Space Marines
From: extremezen@hotmail.com
23. (unknown)
From: "Praetor James " <praetorian-guard@home.com>
24. Re: Far-flung ideas
From: "Bern" <bern@pcug.org.au>
25. Re: A complex option cost question (Crucible)
From: "Russell Sparkes" <rjs@inorbit.com>
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Tue, 05 Dec 2000 15:21:22 -0000
From: "Lars Gottlieb" <larsgottlieb@forum.dk>
Subject: Far-flung ideas
Hi List, hi Rob.
I know this might be a bit into the future, but ...
Would it be possible to change the way the Army Builder saves a
roster, so that if the datafiles were changed, it could still be
imported?
I manage the system in my local club, and I'm having tons of trouble
explaning to the other members why they can't import their old
rosters ...
Personally I see two solutions:
1: Some kind of versioning in the ABCreator, that would build-in the
old files into any new version of the datafiles, so that the
ArmyBuílder would read the version of the datafiles from the save,
then load up the correct version of the datafiles, or change the
roster to comply with the newest files.
2: A component in the ArmyBuilder itself, combined with changes in
the Creator, so the user could parse through old files & update the
contents. This could be done right after datafile update.
Lars Gottlieb
________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Tue, 05 Dec 2000 11:48:00 -0500
From: "Christepher McKenney" <cam1@nrc.gov>
Subject: GW Version of Computer Army Creator for Space Marines
FYI, in the latest Inquistor's report by GWUK, they had the following blurb for a computer program to create Space Marine armies that they are selling.
>>>>>>
However in times of need one can always rely on the Emperor's finest. A new
CD to help even the most numerically challenged to develop Space Marine
armies is now available in the Online Store. I have located it alongside the
Codexes and with the Space Marines themselves.
Go here to track down these new arrivals:
http://www.games-workshop.co.uk/storefront/games.asp
<<<<<<
Christepher
________________________________________________________________________
________________________________________________________________________
Message: 3
Date: Tue, 05 Dec 2000 18:51:41 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: Re: GW Version of Computer Army Creator for Space Marines
At 11:48 05/12/00 -0500, you wrote:
>FYI, in the latest Inquistor's report by GWUK, they had the following
>blurb for a computer program to create Space Marine armies that they are
>selling.
> >>>>>>
>However in times of need one can always rely on the Emperor's finest. A new
>CD to help even the most numerically challenged to develop Space Marine
>armies is now available in the Online Store. I have located it alongside the
>Codexes and with the Space Marines themselves.
>Go here to track down these new arrivals:
>http://www.games-workshop.co.uk/storefront/games.asp
><<<<<<
Ah, we've been looking for info on this. Ta
--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time
________________________________________________________________________
________________________________________________________________________
Message: 4
Date: Tue, 05 Dec 2000 19:07:51 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: Re: Vehicle Upgrade Problems in new 40Kv3 files
At 05:44 05/12/00 +0000, you wrote:
>hi, was just playing with the 40kV3 files with the WD-VDR mods and i
>ran into a bit of a problem. when i tried to create a unit of
>standard sentinels - none of the normal upgrades showed up. i could
>add aa-mounts and something else, but none of the normal upgrades.
>
>if i built a custom battle-walker, all standard upgrades were listed
>admist the VDR upgrades.
Are you using the latest version of Army Builder?
--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time
________________________________________________________________________
________________________________________________________________________
Message: 5
Date: Tue, 05 Dec 2000 19:12:00 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: Re: Far-flung ideas
At 15:21 05/12/00 +0000, you wrote:
>Hi List, hi Rob.
>I know this might be a bit into the future, but ...
>
>Would it be possible to change the way the Army Builder saves a
>roster, so that if the datafiles were changed, it could still be
>imported?
I asked before - apparently not
>I manage the system in my local club, and I'm having tons of trouble
>explaning to the other members why they can't import their old
>rosters ...
>
>Personally I see two solutions:
>
>1: Some kind of versioning in the ABCreator, that would build-in the
>old files into any new version of the datafiles, so that the
>ArmyBuílder would read the version of the datafiles from the save,
>then load up the correct version of the datafiles, or change the
>roster to comply with the newest files.
That's probably not an option, as it would quickly inflate the size of new
datafiles to several megabytes
>2: A component in the ArmyBuilder itself, combined with changes in
>the Creator, so the user could parse through old files & update the
>contents. This could be done right after datafile update.
Sounds more feasible... one thing I was thinking of was that, if AB
couldn't load a file normally, it tried a "reliable" load method - i.e. it
was a lot more liberal in what it accepted, and just chucked away any
options that it didn't know about (or something similar). Does that sound
more feasible?
--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time
________________________________________________________________________
________________________________________________________________________
Message: 6
Date: Tue, 05 Dec 2000 19:29:43 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: Re: Problem with Dark Eldar in Gamma-III datafiles
At 20:41 04/12/00 -0700, you wrote:
>In test building a Dark Eldar army, I think I've discovered a minor error
>in the 40K Gamma-III datafiles...
>
>A Warrior Squad is allowed up to 2 Splinter Cannons or 2 Dark Lances and
>up to 2 Blasters or 2 Shredders. The datafiles allow 2 of each (i.e. the
>"or"s are implemented as "and"s).
I'm not having a problem with it - if you take, say, 2 Splinter Cannons and
a Dark Lance it produces a message saying "oi", although it lets you
actually take them. Does that make sense?
--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time
________________________________________________________________________
________________________________________________________________________
Message: 7
Date: Tue, 05 Dec 2000 13:25:22 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Far-flung ideas
Actually, reconciling this issue is nigh impossible without changing the
saved roster files so that they become more than a 1MB in size. :-( Here is
the explanation from the web-site....
The contents of the saved roster file are tightly coupled to the set of
data files that are in use when the roster is created. It does not matter
whether you go forward or backward in versions. If the data files are
different when you load a saved roster from when that roster was saved, it
is quite probable that the roster will not be able to be loaded. The only
solution is to revert back to the original set of data files that were in
use when the roster file was originally saved.
As an attempt at explaining this, consider the following. Data file set #1
uses an id of "xxx" for a particular unit. In data file set #2, a different
id of "yyy" is used for the same unit. Any roster saved with data set #1
will be unable to resolve the reference to id "xxx" when loaded with set
#2. Similarly, a roster saved with set #2 will have an unrecognized id
("yyy") when loaded by set #1.
This is a gross simplification of things, but it illustrates the problem
going on within the roster files vis-a-vis the data files. Suffice to say,
whether a roster remains readable is completely dependent on how the data
files are changed from one version to the next. It also depends on whether
your roster actually makes use of any of the things that are changed
between versions. If your roster is all Elves and the new release of the
files only changes stuff for Dwarves, then your roster will work fine
across the versions, but some else's (that uses Elves) will not work any
longer.
To continue....
Presently, the saved rosters reference the contents of the data files so
that the data file contents don't need to be repeated in the saved file. If
the saved files need to include all of those references, then the roster
files will grow to be nearly the size of all the data files. The argument
could be made to only save what is referenced. However, then the file could
be reloaded but NOT EDITED. That doesn't provide much value. :-(
You suggested that AB could automatically convert old rosters to new
rosters. Unfortunately, that would require that AB somehow knew what
changes from one set of data files to the next AND that AB knew WHY each
change was made. AB would have to know how to change X to Y, which means a
mapping must be either determined by AB automatically (impossible) or the
author must specify it (lots more work for the authors and major amounts of
work to support this ability within AB).
Your suggestion about AB building old files into the new files has some
merit. The only gotcha is that the files will progressively get huge in
size. This will have a few major impacts. First, download times will
steadily increase as the files bloat - even for people that don't need or
want any of the old stuff. Second, loading of data files AND roster files
will slow down significantly. Third, EVERY time a new roster is created
and/or old roster is loaded, all of the data files will need to be
RELOADED, since AB will need to reset itself properly. I don't think this
is a performance hit that the majority of users will accept.
At present, only the data file writers can control this issue. They have to
take extreme steps to ensure that the files don't change between releases.
That's often in direct conflict with the demands of users for more and more
capabilities within the files. In order to add new material to the files,
the authors need to modify existing material to integrate the new stuff.
Those changes break the old saved rosters. The only REAL solution I can
think of here is for the data files to achieve stability and stop evolving.
That works great for many games, but certainly not for the GW games, since
the GW business model relies on constantly changing and evolving the game
system on a monthly (weekly?) basis.
I'm open to ideas on this if anyone has them. It may be that I'm completely
missing a simple solution to all this. If so, please let me know!!!
Thanks, Rob
At 03:21 PM 12/5/00 +0000, you wrote:
>Hi List, hi Rob.
>I know this might be a bit into the future, but ...
>
>Would it be possible to change the way the Army Builder saves a
>roster, so that if the datafiles were changed, it could still be
>imported?
>
>I manage the system in my local club, and I'm having tons of trouble
>explaning to the other members why they can't import their old
>rosters ...
>
>Personally I see two solutions:
>
>1: Some kind of versioning in the ABCreator, that would build-in the
>old files into any new version of the datafiles, so that the
>ArmyBuílder would read the version of the datafiles from the save,
>then load up the correct version of the datafiles, or change the
>roster to comply with the newest files.
>
>2: A component in the ArmyBuilder itself, combined with changes in
>the Creator, so the user could parse through old files & update the
>contents. This could be done right after datafile update.
>
>Lars Gottlieb
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 8
Date: Tue, 5 Dec 2000 15:07:48 -0700
From: "Brad Morgan" <B-Morgan@concentric.net>
Subject: RE: Problem with Dark Eldar in Gamma-III datafiles
I guess I'm used to the way the Space Marine Troops work. When you add a
weapon from one category, the other two choices immediately grey (or is it
gray?... Colen or Colin?... I'm so confused <G>) out.
I was (I guess optimistically) expecting that when I selected 2 Dark Lances,
the Splinter Cannon option would grey out.
Since at the time we were just generating test units to determine what bitz
(this is proper UK spelling, yes?) to buy, the army was already invalid and
I missed the additional reason for it being invalid.
Regards,
Brad
From: Colen 'Skrillboy' McAlister [mailto:demandred@skrill.org]
Sent: Tuesday, December 05, 2000 12:30 PM
To: ab@support.wolflair.com
Subject: Re: [AB] Problem with Dark Eldar in Gamma-III datafiles
At 20:41 04/12/00 -0700, you wrote:
>In test building a Dark Eldar army, I think I've discovered a minor error
>in the 40K Gamma-III datafiles...
>
>A Warrior Squad is allowed up to 2 Splinter Cannons or 2 Dark Lances and
>up to 2 Blasters or 2 Shredders. The datafiles allow 2 of each (i.e. the
>"or"s are implemented as "and"s).
I'm not having a problem with it - if you take, say, 2 Splinter Cannons and
a Dark Lance it produces a message saying "oi", although it lets you
actually take them. Does that make sense?
--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time
eGroups Sponsor
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
[This message contained attachments]
________________________________________________________________________
________________________________________________________________________
Message: 9
Date: Tue, 5 Dec 2000 15:23:30 -0700
From: "Brad Morgan" <B-Morgan@concentric.net>
Subject: RE: Far-flung ideas
I understand the issues about why it is this way, but it would still be nice
to have the ability to take a roster saved under one set of data files and
move (most) of it to a new set of data files.
Perhaps this can be done with an additional program that allows two sets of
data files for each game system. It would
read a file created with the "old" set and then "convert" it to the "new"
set perhaps by comparing descriptions or something.
When it found something it didn't understand, it would query the user for
help. One of the options could be throw that bit out. I could guess that
this program would handle 90+% of the conversions 90+% of the time.
I think most of us would accept that a small amount of hand editing might
still be needed, but it would much better than
re-entering all of the saved rosters completely from scratch.
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.
Regards,
Brad
-----Original Message-----
From: Rob Bowes [mailto:rob@wolflair.com]
Sent: Tuesday, December 05, 2000 2:25 PM
To: ab@support.wolflair.com
Subject: Re: [AB] Far-flung ideas
Actually, reconciling this issue is nigh impossible without changing the
saved roster files so that they become more than a 1MB in size. :-( Here is
the explanation from the web-site....
The contents of the saved roster file are tightly coupled to the set of
data files that are in use when the roster is created. It does not matter
whether you go forward or backward in versions. If the data files are
different when you load a saved roster from when that roster was saved, it
is quite probable that the roster will not be able to be loaded. The only
solution is to revert back to the original set of data files that were in
use when the roster file was originally saved.
As an attempt at explaining this, consider the following. Data file set #1
uses an id of "xxx" for a particular unit. In data file set #2, a different
id of "yyy" is used for the same unit. Any roster saved with data set #1
will be unable to resolve the reference to id "xxx" when loaded with set
#2. Similarly, a roster saved with set #2 will have an unrecognized id
("yyy") when loaded by set #1.
This is a gross simplification of things, but it illustrates the problem
going on within the roster files vis-a-vis the data files. Suffice to say,
whether a roster remains readable is completely dependent on how the data
files are changed from one version to the next. It also depends on whether
your roster actually makes use of any of the things that are changed
between versions. If your roster is all Elves and the new release of the
files only changes stuff for Dwarves, then your roster will work fine
across the versions, but some else's (that uses Elves) will not work any
longer.
To continue....
Presently, the saved rosters reference the contents of the data files so
that the data file contents don't need to be repeated in the saved file. If
the saved files need to include all of those references, then the roster
files will grow to be nearly the size of all the data files. The argument
could be made to only save what is referenced. However, then the file could
be reloaded but NOT EDITED. That doesn't provide much value. :-(
You suggested that AB could automatically convert old rosters to new
rosters. Unfortunately, that would require that AB somehow knew what
changes from one set of data files to the next AND that AB knew WHY each
change was made. AB would have to know how to change X to Y, which means a
mapping must be either determined by AB automatically (impossible) or the
author must specify it (lots more work for the authors and major amounts of
work to support this ability within AB).
Your suggestion about AB building old files into the new files has some
merit. The only gotcha is that the files will progressively get huge in
size. This will have a few major impacts. First, download times will
steadily increase as the files bloat - even for people that don't need or
want any of the old stuff. Second, loading of data files AND roster files
will slow down significantly. Third, EVERY time a new roster is created
and/or old roster is loaded, all of the data files will need to be
RELOADED, since AB will need to reset itself properly. I don't think this
is a performance hit that the majority of users will accept.
At present, only the data file writers can control this issue. They have to
take extreme steps to ensure that the files don't change between releases.
That's often in direct conflict with the demands of users for more and more
capabilities within the files. In order to add new material to the files,
the authors need to modify existing material to integrate the new stuff.
Those changes break the old saved rosters. The only REAL solution I can
think of here is for the data files to achieve stability and stop evolving.
That works great for many games, but certainly not for the GW games, since
the GW business model relies on constantly changing and evolving the game
system on a monthly (weekly?) basis.
I'm open to ideas on this if anyone has them. It may be that I'm completely
missing a simple solution to all this. If so, please let me know!!!
Thanks, Rob
At 03:21 PM 12/5/00 +0000, you wrote:
>Hi List, hi Rob.
>I know this might be a bit into the future, but ...
>
>Would it be possible to change the way the Army Builder saves a
>roster, so that if the datafiles were changed, it could still be
>imported?
>
>I manage the system in my local club, and I'm having tons of trouble
>explaning to the other members why they can't import their old
>rosters ...
>
>Personally I see two solutions:
>
>1: Some kind of versioning in the ABCreator, that would build-in the
>old files into any new version of the datafiles, so that the
>ArmyBuílder would read the version of the datafiles from the save,
>then load up the correct version of the datafiles, or change the
>roster to comply with the newest files.
>
>2: A component in the ArmyBuilder itself, combined with changes in
>the Creator, so the user could parse through old files & update the
>contents. This could be done right after datafile update.
>
>Lars Gottlieb
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
eGroups Sponsor
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
[This message contained attachments]
________________________________________________________________________
________________________________________________________________________
Message: 10
Date: Tue, 05 Dec 2000 14:15:28 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Far-flung ideas
At 07:12 PM 12/5/00 +0000, you wrote:
>Sounds more feasible... one thing I was thinking of was that, if AB
>couldn't load a file normally, it tried a "reliable" load method - i.e. it
>was a lot more liberal in what it accepted, and just chucked away any
>options that it didn't know about (or something similar). Does that sound
>more feasible?
Hmmm. And just throwing things out arbitrarily is considered "reliable"???
What if one of those things thrown out is an option that uses "more" to
chain to a whole bunch of other options? What if those options are attached
directly to the unit in the newer files? How is AB supposed to handle this
cleanly and provide the user with something USEFUL to manipulate?
This is one of the simpler and LESS complicated issues that arises with
your proposed solutoin.
Reliability, predictability, and usability are three critical components of
good software IMHO. I have striven for these within AB. Anytime that you
expect software to automatically "do the right thing" with something as
complex as AB data files, you open up a Pandora's Box of problems that
undermine those tenets. I'm not going there unless I can figure out a way
to tightly control those problems, and that's (a) not likely possible and
(b) extremely costly to implement and test if it IS possible.
Thanks, Rob
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 11
Date: Tue, 5 Dec 2000 14:30:02 -0800 (PST)
From: Michael Nixon <mnixon@macn.bc.ca>
Subject: Re: Vehicle Upgrade Problems in new 40Kv3 files
> >hi, was just playing with the 40kV3 files with the WD-VDR mods and i
> >ran into a bit of a problem. when i tried to create a unit of
> >standard sentinels - none of the normal upgrades showed up. i could
> >add aa-mounts and something else, but none of the normal upgrades.
> Are you using the latest version of Army Builder?
Same thing happened to be when I installed the Gamma-III datafiles, using
AB v2.0c. Most stuff didn't show their normal upgrades as mentioned.
Upgrade to AB v2.0d, and you'll be fine.
-Michael
________________________________________________________________________
________________________________________________________________________
Message: 12
Date: Tue, 05 Dec 2000 14:08:53 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: GW Version of Computer Army Creator for Space Marines
Thanks for flagging this to my attention. I've been wondering when this
would finally come out and have been unable to find out any info about it
until now.
I've ordered my copy and I'll see what GW has put together. My initial
reaction isn't very positive regarding their price/value target, since they
are charging only a little less than AB for the Space Marine Codex alone.
If anyone else picks up a copy of this, I'd love to hear what your thoughts
are on it. Send them to me directly at rob@wolflair.com (or post them to
the list if you feel it's important to do so).
Thanks, Rob
At 11:48 AM 12/5/00 -0500, you wrote:
>FYI, in the latest Inquistor's report by GWUK, they had the following
>blurb for a computer program to create Space Marine armies that they are
>selling.
> >>>>>>
>However in times of need one can always rely on the Emperor's finest. A new
>CD to help even the most numerically challenged to develop Space Marine
>armies is now available in the Online Store. I have located it alongside the
>Codexes and with the Space Marines themselves.
>Go here to track down these new arrivals:
>http://www.games-workshop.co.uk/storefront/games.asp
><<<<<<
>
>Christepher
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 13
Date: Tue, 05 Dec 2000 22:42:03 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: Re: Far-flung ideas
At 14:15 05/12/00 -0800, you wrote:
>Hmmm. And just throwing things out arbitrarily is considered "reliable"???
>What if one of those things thrown out is an option that uses "more" to
>chain to a whole bunch of other options? What if those options are attached
>directly to the unit in the newer files? How is AB supposed to handle this
>cleanly and provide the user with something USEFUL to manipulate?
Look at it this way. Either you can:
a) Have to re-enter your entire roster by hand, including loads of small
things you may well forget, or
b) Have about 80% of it converted, so you have to do the rest.
I'd really prefer b. As long as you stress that this isn't a "heavy duty"
mechanism, in fact that it's a very lightweight one, a lot of people would
be made happier.
--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time
________________________________________________________________________
________________________________________________________________________
Message: 14
Date: Tue, 05 Dec 2000 22:46:59 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: Re: Far-flung ideas
At 13:25 05/12/00 -0800, you wrote:
>As an attempt at explaining this, consider the following. Data file set #1
>uses an id of "xxx" for a particular unit. In data file set #2, a different
>id of "yyy" is used for the same unit. Any roster saved with data set #1
>will be unable to resolve the reference to id "xxx" when loaded with set
>#2. Similarly, a roster saved with set #2 will have an unrecognized id
>("yyy") when loaded by set #1.
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?
--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time
________________________________________________________________________
________________________________________________________________________
Message: 15
Date: Tue, 05 Dec 2000 22:48:15 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: RE: Problem with Dark Eldar in Gamma-III datafiles
At 15:07 05/12/00 -0700, you wrote:
>I guess I'm used to the way the Space Marine Troops work. When you add a
>weapon from one category, the other two choices immediately grey (or is it
>gray?... Colen or Colin?... I'm so confused <G>) out.
It's "grey". We invented the language, we get to choose how to spell it
>I was (I guess optimistically) expecting that when I selected 2 Dark
>Lances, the Splinter Cannon option would grey out.
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.
>
>Since at the time we were just generating test units to determine what
>bitz (this is proper UK spelling, yes?) to buy, the army was already
>invalid and I missed the additional reason for it being invalid.
--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time
________________________________________________________________________
________________________________________________________________________
Message: 16
Date: Tue, 5 Dec 2000 17:03:39 -0600
From: "Michael E. Gilkison Sr." <mgilkison@kc.rr.com>
Subject: RE: GW Version of Computer Army Creator for Space Marines
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
-----Original Message-----
From: Rob Bowes [mailto:rob@wolflair.com]
Sent: Tuesday, December 05, 2000 4:09 PM
To: ab@support.wolflair.com
Subject: Re: [AB] GW Version of Computer Army Creator for Space Marines
Thanks for flagging this to my attention. I've been wondering when this
would finally come out and have been unable to find out any info about it
until now.
I've ordered my copy and I'll see what GW has put together. My initial
reaction isn't very positive regarding their price/value target, since they
are charging only a little less than AB for the Space Marine Codex alone.
If anyone else picks up a copy of this, I'd love to hear what your thoughts
are on it. Send them to me directly at rob@wolflair.com (or post them to
the list if you feel it's important to do so).
Thanks, Rob
At 11:48 AM 12/5/00 -0500, you wrote:
>FYI, in the latest Inquistor's report by GWUK, they had the following
>blurb for a computer program to create Space Marine armies that they are
>selling.
> >>>>>>
>However in times of need one can always rely on the Emperor's finest. A new
>CD to help even the most numerically challenged to develop Space Marine
>armies is now available in the Online Store. I have located it alongside
the
>Codexes and with the Space Marines themselves.
>Go here to track down these new arrivals:
>http://www.games-workshop.co.uk/storefront/games.asp
><<<<<<
>
>Christepher
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
________________________________________________________________________
________________________________________________________________________
Message: 17
Date: Tue, 5 Dec 2000 19:04:53 EST
From: freds67@aol.com
Subject: Re: Possible Idea for future AB
This is just an idea for AB that I'm not sure would be possible, but I'm
throwing it out anyway. Have some sort of alternate screen or database where
the user can input all of the miniatures in their army (like an army roster,
but all of their minis are in it). Then, when creating a roster, AB would
refer back to the database and let the user know if the unit choice they are
making is available or not to them in their current collection. Maybe even
have a cut and paste or drag with pre-made units from the database. Also
have a toggle to turn it off if you don't want to use it. Just an idea...
see ya!
Fred
________________________________________________________________________
________________________________________________________________________
Message: 18
Date: Tue, 05 Dec 2000 16:13:52 -0800
From: Eric Landes <eric@landesfamily.com>
Subject: Re: Possible Idea for future AB
This has actually been tossed around quite a bit. It would be INCREDIBLY
valuable for historical players as you could specify a number of different
armies a unit can be used it.
I'd like to have it right now as I start building up my WH collection.
I still think it's on Rob's "to do someday" list. I wouldn't expect it any
time soon, though.
E
At 07:04 PM 12/5/2000 -0500, freds67@aol.com wrote:
>This is just an idea for AB that I'm not sure would be possible, but I'm
>throwing it out anyway. Have some sort of alternate screen or database where
>the user can input all of the miniatures in their army (like an army roster,
>but all of their minis are in it). Then, when creating a roster, AB would
>refer back to the database and let the user know if the unit choice they are
>making is available or not to them in their current collection. Maybe even
>have a cut and paste or drag with pre-made units from the database. Also
>have a toggle to turn it off if you don't want to use it. Just an idea...
>see ya!
>
>Fred
>
>
>To unsubscribe from this group, email
>
>armybuilder-unsubscribe@egroups.com
________________________________________________________________________
________________________________________________________________________
Message: 19
Date: Tue, 5 Dec 2000 18:35:14 -0600
From: "SUPrUNown" <matrix@pangea.ca>
Subject: Re: Digest Number 233
> Highly unlikely. Why not just pay the ~$10 dollars for the upgrade?
>
A) Why pay for a new version when the old version suits my needs fine? What
is this, Microsoft? 8)
B) $10 American is about $17 Cdn right now, and getting worse all the time.
SUPrUNown
matrix@pangea.ca
www.pangea.ca/~matrix/matrix.htm
Could I have been anyone other than me?
________________________________________________________________________
________________________________________________________________________
Message: 20
Date: Tue, 05 Dec 2000 16:40:07 -0800
From: Eric Landes <eric@landesfamily.com>
Subject: Re: Digest Number 233
At 06:35 PM 12/5/2000 -0600, SUPrUNown wrote:
> > Highly unlikely. Why not just pay the ~$10 dollars for the upgrade?
> >
>A) Why pay for a new version when the old version suits my needs fine? What
>is this, Microsoft? 8)
Actually, it seems rather obvious that it's _not_ suiting your needs since
you need data files that contain newer units, and nobody's writing them for
the old version.
Kinda like owning an old Macintosh. It may work just fine for you, but
don't try to run anything new on it. If you need new software (i.e. choose
to play a new game) you must upgrade.
>B) $10 American is about $17 Cdn right now, and getting worse all the time.
And that new unit of figures cost how much again?
It's relatively cheap. You've bought the old version so you know how
valuable it is. You're the last type of customer that should need this
explanation
Eric
________________________________________________________________________
________________________________________________________________________
Message: 21
Date: Tue, 5 Dec 2000 17:55:18 -0700
From: "Brad Morgan" <B-Morgan@concentric.net>
Subject: RE: GW Version of Computer Army Creator for Space Marines
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
-----Original Message-----
From: Michael E. Gilkison Sr. [mailto:mgilkison@kc.rr.com]
Sent: Tuesday, December 05, 2000 4:04 PM
To: armybuilder@egroups.com
Subject: RE: [AB] GW Version of Computer Army Creator for Space Marines
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
-----Original Message-----
From: Rob Bowes [mailto:rob@wolflair.com]
Sent: Tuesday, December 05, 2000 4:09 PM
To: armybuilder@egroups.com
Subject: Re: [AB] GW Version of Computer Army Creator for Space Marines
Thanks for flagging this to my attention. I've been wondering when this
would finally come out and have been unable to find out any info about it
until now.
I've ordered my copy and I'll see what GW has put together. My initial
reaction isn't very positive regarding their price/value target, since
they
are charging only a little less than AB for the Space Marine Codex alone.
If anyone else picks up a copy of this, I'd love to hear what your
thoughts
are on it. Send them to me directly at rob@wolflair.com (or post them to
the list if you feel it's important to do so).
Thanks, Rob
At 11:48 AM 12/5/00 -0500, you wrote:
>FYI, in the latest Inquistor's report by GWUK, they had the following
>blurb for a computer program to create Space Marine armies that they are
>selling.
> >>>>>>
>However in times of need one can always rely on the Emperor's finest. A
new
>CD to help even the most numerically challenged to develop Space Marine
>armies is now available in the Online Store. I have located it alongside
the
>Codexes and with the Space Marines themselves.
>Go here to track down these new arrivals:
>http://www.games-workshop.co.uk/storefront/games.asp
><<<<<<
>
>Christepher
--------------------------------------------------------------------------
-
Rob Bowes (rob@wolflair.com) (650)
726-9689
Lone Wolf Development
www.wolflair.com
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
eGroups Sponsor
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
[This message contained attachments]
________________________________________________________________________
________________________________________________________________________
Message: 22
Date: Wed, 06 Dec 2000 01:26:33 -0000
From: extremezen@hotmail.com
Subject: Re: GW Version of Computer Army Creator for Space Marines
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: 23
Date: Wed, 06 Dec 2000 04:45:12 -0000
From: "Praetor James " <praetorian-guard@home.com>
Subject: (unknown)
is there a WHFB 6ed ravening hordes ab file that includes the changes
in it that are in the main book.. because the lizardmen have point
and stats that have been changed..??
________________________________________________________________________
________________________________________________________________________
Message: 24
Date: Wed, 6 Dec 2000 16:05:03 +1100
From: "Bern" <bern@pcug.org.au>
Subject: Re: Far-flung ideas
Well,
Given that the tech solutions are problematic (for very good reasons)
why noy use low-tech solutions.
Save a roster as a text file or keep a (shudder) paper copy (which you
probably used at the game you played with that roster). With a print of
what was in your army roster before you can very quickly recreate it using
the latest datafiles.
Agreed, if you want to see what all the options were for armies etc with
the old roster you'd have to reload the old files. But for processing one
roster in the new files the effort is trivial.
And saves Rob's times for fancier stuff (or even for him to have a life!
;-> )
Cheers
Bern
Reality is a chronic condition,
& one generally ignored by cats.
bern@pcug.org.au
----- Original Message -----
From: "Rob Bowes" <rob@wolflair.com>
To: ab@support.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 25
Date: Wed, 06 Dec 2000 06:04:14 -0000
From: "Russell Sparkes" <rjs@inorbit.com>
Subject: Re: A complex option cost question (Crucible)
--- 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.
>
> 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!
Oh well...
Cheers,
Russell.
________________________________________________________________________
________________________________________________________________________
PLAY GAMES. WIN PRIZES. GUARANTEED.
Get $5.00 in FREE credits when you register at
http://click.egroups.com/1/10501/0/_/36190/_/976082672/
---------------------------------------------------------------------_->
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
------------------------------------------------------------------------
There are 25 messages in this issue.
Topics in this digest:
1. Far-flung ideas
From: "Lars Gottlieb" <larsgottlieb@forum.dk>
2. GW Version of Computer Army Creator for Space Marines
From: "Christepher McKenney" <cam1@nrc.gov>
3. Re: GW Version of Computer Army Creator for Space Marines
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
4. Re: Vehicle Upgrade Problems in new 40Kv3 files
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
5. Re: Far-flung ideas
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
6. Re: Problem with Dark Eldar in Gamma-III datafiles
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
7. Re: Far-flung ideas
From: Rob Bowes <rob@wolflair.com>
8. RE: Problem with Dark Eldar in Gamma-III datafiles
From: "Brad Morgan" <B-Morgan@concentric.net>
9. RE: Far-flung ideas
From: "Brad Morgan" <B-Morgan@concentric.net>
10. Re: Far-flung ideas
From: Rob Bowes <rob@wolflair.com>
11. Re: Vehicle Upgrade Problems in new 40Kv3 files
From: Michael Nixon <mnixon@macn.bc.ca>
12. Re: GW Version of Computer Army Creator for Space Marines
From: Rob Bowes <rob@wolflair.com>
13. Re: Far-flung ideas
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
14. Re: Far-flung ideas
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
15. RE: Problem with Dark Eldar in Gamma-III datafiles
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
16. RE: GW Version of Computer Army Creator for Space Marines
From: "Michael E. Gilkison Sr." <mgilkison@kc.rr.com>
17. Re: Possible Idea for future AB
From: freds67@aol.com
18. Re: Possible Idea for future AB
From: Eric Landes <eric@landesfamily.com>
19. Re: Digest Number 233
From: "SUPrUNown" <matrix@pangea.ca>
20. Re: Digest Number 233
From: Eric Landes <eric@landesfamily.com>
21. RE: GW Version of Computer Army Creator for Space Marines
From: "Brad Morgan" <B-Morgan@concentric.net>
22. Re: GW Version of Computer Army Creator for Space Marines
From: extremezen@hotmail.com
23. (unknown)
From: "Praetor James " <praetorian-guard@home.com>
24. Re: Far-flung ideas
From: "Bern" <bern@pcug.org.au>
25. Re: A complex option cost question (Crucible)
From: "Russell Sparkes" <rjs@inorbit.com>
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Tue, 05 Dec 2000 15:21:22 -0000
From: "Lars Gottlieb" <larsgottlieb@forum.dk>
Subject: Far-flung ideas
Hi List, hi Rob.
I know this might be a bit into the future, but ...
Would it be possible to change the way the Army Builder saves a
roster, so that if the datafiles were changed, it could still be
imported?
I manage the system in my local club, and I'm having tons of trouble
explaning to the other members why they can't import their old
rosters ...
Personally I see two solutions:
1: Some kind of versioning in the ABCreator, that would build-in the
old files into any new version of the datafiles, so that the
ArmyBuílder would read the version of the datafiles from the save,
then load up the correct version of the datafiles, or change the
roster to comply with the newest files.
2: A component in the ArmyBuilder itself, combined with changes in
the Creator, so the user could parse through old files & update the
contents. This could be done right after datafile update.
Lars Gottlieb
________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Tue, 05 Dec 2000 11:48:00 -0500
From: "Christepher McKenney" <cam1@nrc.gov>
Subject: GW Version of Computer Army Creator for Space Marines
FYI, in the latest Inquistor's report by GWUK, they had the following blurb for a computer program to create Space Marine armies that they are selling.
>>>>>>
However in times of need one can always rely on the Emperor's finest. A new
CD to help even the most numerically challenged to develop Space Marine
armies is now available in the Online Store. I have located it alongside the
Codexes and with the Space Marines themselves.
Go here to track down these new arrivals:
http://www.games-workshop.co.uk/storefront/games.asp
<<<<<<
Christepher
________________________________________________________________________
________________________________________________________________________
Message: 3
Date: Tue, 05 Dec 2000 18:51:41 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: Re: GW Version of Computer Army Creator for Space Marines
At 11:48 05/12/00 -0500, you wrote:
>FYI, in the latest Inquistor's report by GWUK, they had the following
>blurb for a computer program to create Space Marine armies that they are
>selling.
> >>>>>>
>However in times of need one can always rely on the Emperor's finest. A new
>CD to help even the most numerically challenged to develop Space Marine
>armies is now available in the Online Store. I have located it alongside the
>Codexes and with the Space Marines themselves.
>Go here to track down these new arrivals:
>http://www.games-workshop.co.uk/storefront/games.asp
><<<<<<
Ah, we've been looking for info on this. Ta
--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time
________________________________________________________________________
________________________________________________________________________
Message: 4
Date: Tue, 05 Dec 2000 19:07:51 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: Re: Vehicle Upgrade Problems in new 40Kv3 files
At 05:44 05/12/00 +0000, you wrote:
>hi, was just playing with the 40kV3 files with the WD-VDR mods and i
>ran into a bit of a problem. when i tried to create a unit of
>standard sentinels - none of the normal upgrades showed up. i could
>add aa-mounts and something else, but none of the normal upgrades.
>
>if i built a custom battle-walker, all standard upgrades were listed
>admist the VDR upgrades.
Are you using the latest version of Army Builder?
--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time
________________________________________________________________________
________________________________________________________________________
Message: 5
Date: Tue, 05 Dec 2000 19:12:00 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: Re: Far-flung ideas
At 15:21 05/12/00 +0000, you wrote:
>Hi List, hi Rob.
>I know this might be a bit into the future, but ...
>
>Would it be possible to change the way the Army Builder saves a
>roster, so that if the datafiles were changed, it could still be
>imported?
I asked before - apparently not
>I manage the system in my local club, and I'm having tons of trouble
>explaning to the other members why they can't import their old
>rosters ...
>
>Personally I see two solutions:
>
>1: Some kind of versioning in the ABCreator, that would build-in the
>old files into any new version of the datafiles, so that the
>ArmyBuílder would read the version of the datafiles from the save,
>then load up the correct version of the datafiles, or change the
>roster to comply with the newest files.
That's probably not an option, as it would quickly inflate the size of new
datafiles to several megabytes
>2: A component in the ArmyBuilder itself, combined with changes in
>the Creator, so the user could parse through old files & update the
>contents. This could be done right after datafile update.
Sounds more feasible... one thing I was thinking of was that, if AB
couldn't load a file normally, it tried a "reliable" load method - i.e. it
was a lot more liberal in what it accepted, and just chucked away any
options that it didn't know about (or something similar). Does that sound
more feasible?
--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time
________________________________________________________________________
________________________________________________________________________
Message: 6
Date: Tue, 05 Dec 2000 19:29:43 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: Re: Problem with Dark Eldar in Gamma-III datafiles
At 20:41 04/12/00 -0700, you wrote:
>In test building a Dark Eldar army, I think I've discovered a minor error
>in the 40K Gamma-III datafiles...
>
>A Warrior Squad is allowed up to 2 Splinter Cannons or 2 Dark Lances and
>up to 2 Blasters or 2 Shredders. The datafiles allow 2 of each (i.e. the
>"or"s are implemented as "and"s).
I'm not having a problem with it - if you take, say, 2 Splinter Cannons and
a Dark Lance it produces a message saying "oi", although it lets you
actually take them. Does that make sense?
--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time
________________________________________________________________________
________________________________________________________________________
Message: 7
Date: Tue, 05 Dec 2000 13:25:22 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Far-flung ideas
Actually, reconciling this issue is nigh impossible without changing the
saved roster files so that they become more than a 1MB in size. :-( Here is
the explanation from the web-site....
The contents of the saved roster file are tightly coupled to the set of
data files that are in use when the roster is created. It does not matter
whether you go forward or backward in versions. If the data files are
different when you load a saved roster from when that roster was saved, it
is quite probable that the roster will not be able to be loaded. The only
solution is to revert back to the original set of data files that were in
use when the roster file was originally saved.
As an attempt at explaining this, consider the following. Data file set #1
uses an id of "xxx" for a particular unit. In data file set #2, a different
id of "yyy" is used for the same unit. Any roster saved with data set #1
will be unable to resolve the reference to id "xxx" when loaded with set
#2. Similarly, a roster saved with set #2 will have an unrecognized id
("yyy") when loaded by set #1.
This is a gross simplification of things, but it illustrates the problem
going on within the roster files vis-a-vis the data files. Suffice to say,
whether a roster remains readable is completely dependent on how the data
files are changed from one version to the next. It also depends on whether
your roster actually makes use of any of the things that are changed
between versions. If your roster is all Elves and the new release of the
files only changes stuff for Dwarves, then your roster will work fine
across the versions, but some else's (that uses Elves) will not work any
longer.
To continue....
Presently, the saved rosters reference the contents of the data files so
that the data file contents don't need to be repeated in the saved file. If
the saved files need to include all of those references, then the roster
files will grow to be nearly the size of all the data files. The argument
could be made to only save what is referenced. However, then the file could
be reloaded but NOT EDITED. That doesn't provide much value. :-(
You suggested that AB could automatically convert old rosters to new
rosters. Unfortunately, that would require that AB somehow knew what
changes from one set of data files to the next AND that AB knew WHY each
change was made. AB would have to know how to change X to Y, which means a
mapping must be either determined by AB automatically (impossible) or the
author must specify it (lots more work for the authors and major amounts of
work to support this ability within AB).
Your suggestion about AB building old files into the new files has some
merit. The only gotcha is that the files will progressively get huge in
size. This will have a few major impacts. First, download times will
steadily increase as the files bloat - even for people that don't need or
want any of the old stuff. Second, loading of data files AND roster files
will slow down significantly. Third, EVERY time a new roster is created
and/or old roster is loaded, all of the data files will need to be
RELOADED, since AB will need to reset itself properly. I don't think this
is a performance hit that the majority of users will accept.
At present, only the data file writers can control this issue. They have to
take extreme steps to ensure that the files don't change between releases.
That's often in direct conflict with the demands of users for more and more
capabilities within the files. In order to add new material to the files,
the authors need to modify existing material to integrate the new stuff.
Those changes break the old saved rosters. The only REAL solution I can
think of here is for the data files to achieve stability and stop evolving.
That works great for many games, but certainly not for the GW games, since
the GW business model relies on constantly changing and evolving the game
system on a monthly (weekly?) basis.
I'm open to ideas on this if anyone has them. It may be that I'm completely
missing a simple solution to all this. If so, please let me know!!!
Thanks, Rob
At 03:21 PM 12/5/00 +0000, you wrote:
>Hi List, hi Rob.
>I know this might be a bit into the future, but ...
>
>Would it be possible to change the way the Army Builder saves a
>roster, so that if the datafiles were changed, it could still be
>imported?
>
>I manage the system in my local club, and I'm having tons of trouble
>explaning to the other members why they can't import their old
>rosters ...
>
>Personally I see two solutions:
>
>1: Some kind of versioning in the ABCreator, that would build-in the
>old files into any new version of the datafiles, so that the
>ArmyBuílder would read the version of the datafiles from the save,
>then load up the correct version of the datafiles, or change the
>roster to comply with the newest files.
>
>2: A component in the ArmyBuilder itself, combined with changes in
>the Creator, so the user could parse through old files & update the
>contents. This could be done right after datafile update.
>
>Lars Gottlieb
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 8
Date: Tue, 5 Dec 2000 15:07:48 -0700
From: "Brad Morgan" <B-Morgan@concentric.net>
Subject: RE: Problem with Dark Eldar in Gamma-III datafiles
I guess I'm used to the way the Space Marine Troops work. When you add a
weapon from one category, the other two choices immediately grey (or is it
gray?... Colen or Colin?... I'm so confused <G>) out.
I was (I guess optimistically) expecting that when I selected 2 Dark Lances,
the Splinter Cannon option would grey out.
Since at the time we were just generating test units to determine what bitz
(this is proper UK spelling, yes?) to buy, the army was already invalid and
I missed the additional reason for it being invalid.
Regards,
Brad
From: Colen 'Skrillboy' McAlister [mailto:demandred@skrill.org]
Sent: Tuesday, December 05, 2000 12:30 PM
To: ab@support.wolflair.com
Subject: Re: [AB] Problem with Dark Eldar in Gamma-III datafiles
At 20:41 04/12/00 -0700, you wrote:
>In test building a Dark Eldar army, I think I've discovered a minor error
>in the 40K Gamma-III datafiles...
>
>A Warrior Squad is allowed up to 2 Splinter Cannons or 2 Dark Lances and
>up to 2 Blasters or 2 Shredders. The datafiles allow 2 of each (i.e. the
>"or"s are implemented as "and"s).
I'm not having a problem with it - if you take, say, 2 Splinter Cannons and
a Dark Lance it produces a message saying "oi", although it lets you
actually take them. Does that make sense?
--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time
eGroups Sponsor
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
[This message contained attachments]
________________________________________________________________________
________________________________________________________________________
Message: 9
Date: Tue, 5 Dec 2000 15:23:30 -0700
From: "Brad Morgan" <B-Morgan@concentric.net>
Subject: RE: Far-flung ideas
I understand the issues about why it is this way, but it would still be nice
to have the ability to take a roster saved under one set of data files and
move (most) of it to a new set of data files.
Perhaps this can be done with an additional program that allows two sets of
data files for each game system. It would
read a file created with the "old" set and then "convert" it to the "new"
set perhaps by comparing descriptions or something.
When it found something it didn't understand, it would query the user for
help. One of the options could be throw that bit out. I could guess that
this program would handle 90+% of the conversions 90+% of the time.
I think most of us would accept that a small amount of hand editing might
still be needed, but it would much better than
re-entering all of the saved rosters completely from scratch.
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.
Regards,
Brad
-----Original Message-----
From: Rob Bowes [mailto:rob@wolflair.com]
Sent: Tuesday, December 05, 2000 2:25 PM
To: ab@support.wolflair.com
Subject: Re: [AB] Far-flung ideas
Actually, reconciling this issue is nigh impossible without changing the
saved roster files so that they become more than a 1MB in size. :-( Here is
the explanation from the web-site....
The contents of the saved roster file are tightly coupled to the set of
data files that are in use when the roster is created. It does not matter
whether you go forward or backward in versions. If the data files are
different when you load a saved roster from when that roster was saved, it
is quite probable that the roster will not be able to be loaded. The only
solution is to revert back to the original set of data files that were in
use when the roster file was originally saved.
As an attempt at explaining this, consider the following. Data file set #1
uses an id of "xxx" for a particular unit. In data file set #2, a different
id of "yyy" is used for the same unit. Any roster saved with data set #1
will be unable to resolve the reference to id "xxx" when loaded with set
#2. Similarly, a roster saved with set #2 will have an unrecognized id
("yyy") when loaded by set #1.
This is a gross simplification of things, but it illustrates the problem
going on within the roster files vis-a-vis the data files. Suffice to say,
whether a roster remains readable is completely dependent on how the data
files are changed from one version to the next. It also depends on whether
your roster actually makes use of any of the things that are changed
between versions. If your roster is all Elves and the new release of the
files only changes stuff for Dwarves, then your roster will work fine
across the versions, but some else's (that uses Elves) will not work any
longer.
To continue....
Presently, the saved rosters reference the contents of the data files so
that the data file contents don't need to be repeated in the saved file. If
the saved files need to include all of those references, then the roster
files will grow to be nearly the size of all the data files. The argument
could be made to only save what is referenced. However, then the file could
be reloaded but NOT EDITED. That doesn't provide much value. :-(
You suggested that AB could automatically convert old rosters to new
rosters. Unfortunately, that would require that AB somehow knew what
changes from one set of data files to the next AND that AB knew WHY each
change was made. AB would have to know how to change X to Y, which means a
mapping must be either determined by AB automatically (impossible) or the
author must specify it (lots more work for the authors and major amounts of
work to support this ability within AB).
Your suggestion about AB building old files into the new files has some
merit. The only gotcha is that the files will progressively get huge in
size. This will have a few major impacts. First, download times will
steadily increase as the files bloat - even for people that don't need or
want any of the old stuff. Second, loading of data files AND roster files
will slow down significantly. Third, EVERY time a new roster is created
and/or old roster is loaded, all of the data files will need to be
RELOADED, since AB will need to reset itself properly. I don't think this
is a performance hit that the majority of users will accept.
At present, only the data file writers can control this issue. They have to
take extreme steps to ensure that the files don't change between releases.
That's often in direct conflict with the demands of users for more and more
capabilities within the files. In order to add new material to the files,
the authors need to modify existing material to integrate the new stuff.
Those changes break the old saved rosters. The only REAL solution I can
think of here is for the data files to achieve stability and stop evolving.
That works great for many games, but certainly not for the GW games, since
the GW business model relies on constantly changing and evolving the game
system on a monthly (weekly?) basis.
I'm open to ideas on this if anyone has them. It may be that I'm completely
missing a simple solution to all this. If so, please let me know!!!
Thanks, Rob
At 03:21 PM 12/5/00 +0000, you wrote:
>Hi List, hi Rob.
>I know this might be a bit into the future, but ...
>
>Would it be possible to change the way the Army Builder saves a
>roster, so that if the datafiles were changed, it could still be
>imported?
>
>I manage the system in my local club, and I'm having tons of trouble
>explaning to the other members why they can't import their old
>rosters ...
>
>Personally I see two solutions:
>
>1: Some kind of versioning in the ABCreator, that would build-in the
>old files into any new version of the datafiles, so that the
>ArmyBuílder would read the version of the datafiles from the save,
>then load up the correct version of the datafiles, or change the
>roster to comply with the newest files.
>
>2: A component in the ArmyBuilder itself, combined with changes in
>the Creator, so the user could parse through old files & update the
>contents. This could be done right after datafile update.
>
>Lars Gottlieb
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
eGroups Sponsor
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
[This message contained attachments]
________________________________________________________________________
________________________________________________________________________
Message: 10
Date: Tue, 05 Dec 2000 14:15:28 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Far-flung ideas
At 07:12 PM 12/5/00 +0000, you wrote:
>Sounds more feasible... one thing I was thinking of was that, if AB
>couldn't load a file normally, it tried a "reliable" load method - i.e. it
>was a lot more liberal in what it accepted, and just chucked away any
>options that it didn't know about (or something similar). Does that sound
>more feasible?
Hmmm. And just throwing things out arbitrarily is considered "reliable"???
What if one of those things thrown out is an option that uses "more" to
chain to a whole bunch of other options? What if those options are attached
directly to the unit in the newer files? How is AB supposed to handle this
cleanly and provide the user with something USEFUL to manipulate?
This is one of the simpler and LESS complicated issues that arises with
your proposed solutoin.
Reliability, predictability, and usability are three critical components of
good software IMHO. I have striven for these within AB. Anytime that you
expect software to automatically "do the right thing" with something as
complex as AB data files, you open up a Pandora's Box of problems that
undermine those tenets. I'm not going there unless I can figure out a way
to tightly control those problems, and that's (a) not likely possible and
(b) extremely costly to implement and test if it IS possible.
Thanks, Rob
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 11
Date: Tue, 5 Dec 2000 14:30:02 -0800 (PST)
From: Michael Nixon <mnixon@macn.bc.ca>
Subject: Re: Vehicle Upgrade Problems in new 40Kv3 files
> >hi, was just playing with the 40kV3 files with the WD-VDR mods and i
> >ran into a bit of a problem. when i tried to create a unit of
> >standard sentinels - none of the normal upgrades showed up. i could
> >add aa-mounts and something else, but none of the normal upgrades.
> Are you using the latest version of Army Builder?
Same thing happened to be when I installed the Gamma-III datafiles, using
AB v2.0c. Most stuff didn't show their normal upgrades as mentioned.
Upgrade to AB v2.0d, and you'll be fine.
-Michael
________________________________________________________________________
________________________________________________________________________
Message: 12
Date: Tue, 05 Dec 2000 14:08:53 -0800
From: Rob Bowes <rob@wolflair.com>
Subject: Re: GW Version of Computer Army Creator for Space Marines
Thanks for flagging this to my attention. I've been wondering when this
would finally come out and have been unable to find out any info about it
until now.
I've ordered my copy and I'll see what GW has put together. My initial
reaction isn't very positive regarding their price/value target, since they
are charging only a little less than AB for the Space Marine Codex alone.
If anyone else picks up a copy of this, I'd love to hear what your thoughts
are on it. Send them to me directly at rob@wolflair.com (or post them to
the list if you feel it's important to do so).
Thanks, Rob
At 11:48 AM 12/5/00 -0500, you wrote:
>FYI, in the latest Inquistor's report by GWUK, they had the following
>blurb for a computer program to create Space Marine armies that they are
>selling.
> >>>>>>
>However in times of need one can always rely on the Emperor's finest. A new
>CD to help even the most numerically challenged to develop Space Marine
>armies is now available in the Online Store. I have located it alongside the
>Codexes and with the Space Marines themselves.
>Go here to track down these new arrivals:
>http://www.games-workshop.co.uk/storefront/games.asp
><<<<<<
>
>Christepher
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 13
Date: Tue, 05 Dec 2000 22:42:03 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: Re: Far-flung ideas
At 14:15 05/12/00 -0800, you wrote:
>Hmmm. And just throwing things out arbitrarily is considered "reliable"???
>What if one of those things thrown out is an option that uses "more" to
>chain to a whole bunch of other options? What if those options are attached
>directly to the unit in the newer files? How is AB supposed to handle this
>cleanly and provide the user with something USEFUL to manipulate?
Look at it this way. Either you can:
a) Have to re-enter your entire roster by hand, including loads of small
things you may well forget, or
b) Have about 80% of it converted, so you have to do the rest.
I'd really prefer b. As long as you stress that this isn't a "heavy duty"
mechanism, in fact that it's a very lightweight one, a lot of people would
be made happier.
--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time
________________________________________________________________________
________________________________________________________________________
Message: 14
Date: Tue, 05 Dec 2000 22:46:59 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: Re: Far-flung ideas
At 13:25 05/12/00 -0800, you wrote:
>As an attempt at explaining this, consider the following. Data file set #1
>uses an id of "xxx" for a particular unit. In data file set #2, a different
>id of "yyy" is used for the same unit. Any roster saved with data set #1
>will be unable to resolve the reference to id "xxx" when loaded with set
>#2. Similarly, a roster saved with set #2 will have an unrecognized id
>("yyy") when loaded by set #1.
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?
--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time
________________________________________________________________________
________________________________________________________________________
Message: 15
Date: Tue, 05 Dec 2000 22:48:15 +0000
From: Colen 'Skrillboy' McAlister <demandred@skrill.org>
Subject: RE: Problem with Dark Eldar in Gamma-III datafiles
At 15:07 05/12/00 -0700, you wrote:
>I guess I'm used to the way the Space Marine Troops work. When you add a
>weapon from one category, the other two choices immediately grey (or is it
>gray?... Colen or Colin?... I'm so confused <G>) out.
It's "grey". We invented the language, we get to choose how to spell it
>I was (I guess optimistically) expecting that when I selected 2 Dark
>Lances, the Splinter Cannon option would grey out.
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.
>
>Since at the time we were just generating test units to determine what
>bitz (this is proper UK spelling, yes?) to buy, the army was already
>invalid and I missed the additional reason for it being invalid.
--
'Not Colin' McAlister - License to Skrill
Email: demandred@skrill.org | Visit http://www.skrill.org/ today!
-----------------------------+------------------------------------
"Dovie'andi se tovya sagain" - Robert Jordan's Wheel Of Time
________________________________________________________________________
________________________________________________________________________
Message: 16
Date: Tue, 5 Dec 2000 17:03:39 -0600
From: "Michael E. Gilkison Sr." <mgilkison@kc.rr.com>
Subject: RE: GW Version of Computer Army Creator for Space Marines
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
-----Original Message-----
From: Rob Bowes [mailto:rob@wolflair.com]
Sent: Tuesday, December 05, 2000 4:09 PM
To: ab@support.wolflair.com
Subject: Re: [AB] GW Version of Computer Army Creator for Space Marines
Thanks for flagging this to my attention. I've been wondering when this
would finally come out and have been unable to find out any info about it
until now.
I've ordered my copy and I'll see what GW has put together. My initial
reaction isn't very positive regarding their price/value target, since they
are charging only a little less than AB for the Space Marine Codex alone.
If anyone else picks up a copy of this, I'd love to hear what your thoughts
are on it. Send them to me directly at rob@wolflair.com (or post them to
the list if you feel it's important to do so).
Thanks, Rob
At 11:48 AM 12/5/00 -0500, you wrote:
>FYI, in the latest Inquistor's report by GWUK, they had the following
>blurb for a computer program to create Space Marine armies that they are
>selling.
> >>>>>>
>However in times of need one can always rely on the Emperor's finest. A new
>CD to help even the most numerically challenged to develop Space Marine
>armies is now available in the Online Store. I have located it alongside
the
>Codexes and with the Space Marines themselves.
>Go here to track down these new arrivals:
>http://www.games-workshop.co.uk/storefront/games.asp
><<<<<<
>
>Christepher
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
________________________________________________________________________
________________________________________________________________________
Message: 17
Date: Tue, 5 Dec 2000 19:04:53 EST
From: freds67@aol.com
Subject: Re: Possible Idea for future AB
This is just an idea for AB that I'm not sure would be possible, but I'm
throwing it out anyway. Have some sort of alternate screen or database where
the user can input all of the miniatures in their army (like an army roster,
but all of their minis are in it). Then, when creating a roster, AB would
refer back to the database and let the user know if the unit choice they are
making is available or not to them in their current collection. Maybe even
have a cut and paste or drag with pre-made units from the database. Also
have a toggle to turn it off if you don't want to use it. Just an idea...
see ya!
Fred
________________________________________________________________________
________________________________________________________________________
Message: 18
Date: Tue, 05 Dec 2000 16:13:52 -0800
From: Eric Landes <eric@landesfamily.com>
Subject: Re: Possible Idea for future AB
This has actually been tossed around quite a bit. It would be INCREDIBLY
valuable for historical players as you could specify a number of different
armies a unit can be used it.
I'd like to have it right now as I start building up my WH collection.
I still think it's on Rob's "to do someday" list. I wouldn't expect it any
time soon, though.
E
At 07:04 PM 12/5/2000 -0500, freds67@aol.com wrote:
>This is just an idea for AB that I'm not sure would be possible, but I'm
>throwing it out anyway. Have some sort of alternate screen or database where
>the user can input all of the miniatures in their army (like an army roster,
>but all of their minis are in it). Then, when creating a roster, AB would
>refer back to the database and let the user know if the unit choice they are
>making is available or not to them in their current collection. Maybe even
>have a cut and paste or drag with pre-made units from the database. Also
>have a toggle to turn it off if you don't want to use it. Just an idea...
>see ya!
>
>Fred
>
>
>To unsubscribe from this group, email
>
>armybuilder-unsubscribe@egroups.com
________________________________________________________________________
________________________________________________________________________
Message: 19
Date: Tue, 5 Dec 2000 18:35:14 -0600
From: "SUPrUNown" <matrix@pangea.ca>
Subject: Re: Digest Number 233
> Highly unlikely. Why not just pay the ~$10 dollars for the upgrade?
>
A) Why pay for a new version when the old version suits my needs fine? What
is this, Microsoft? 8)
B) $10 American is about $17 Cdn right now, and getting worse all the time.
SUPrUNown
matrix@pangea.ca
www.pangea.ca/~matrix/matrix.htm
Could I have been anyone other than me?
________________________________________________________________________
________________________________________________________________________
Message: 20
Date: Tue, 05 Dec 2000 16:40:07 -0800
From: Eric Landes <eric@landesfamily.com>
Subject: Re: Digest Number 233
At 06:35 PM 12/5/2000 -0600, SUPrUNown wrote:
> > Highly unlikely. Why not just pay the ~$10 dollars for the upgrade?
> >
>A) Why pay for a new version when the old version suits my needs fine? What
>is this, Microsoft? 8)
Actually, it seems rather obvious that it's _not_ suiting your needs since
you need data files that contain newer units, and nobody's writing them for
the old version.
Kinda like owning an old Macintosh. It may work just fine for you, but
don't try to run anything new on it. If you need new software (i.e. choose
to play a new game) you must upgrade.
>B) $10 American is about $17 Cdn right now, and getting worse all the time.
And that new unit of figures cost how much again?
It's relatively cheap. You've bought the old version so you know how
valuable it is. You're the last type of customer that should need this
explanation
Eric
________________________________________________________________________
________________________________________________________________________
Message: 21
Date: Tue, 5 Dec 2000 17:55:18 -0700
From: "Brad Morgan" <B-Morgan@concentric.net>
Subject: RE: GW Version of Computer Army Creator for Space Marines
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
-----Original Message-----
From: Michael E. Gilkison Sr. [mailto:mgilkison@kc.rr.com]
Sent: Tuesday, December 05, 2000 4:04 PM
To: armybuilder@egroups.com
Subject: RE: [AB] GW Version of Computer Army Creator for Space Marines
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
-----Original Message-----
From: Rob Bowes [mailto:rob@wolflair.com]
Sent: Tuesday, December 05, 2000 4:09 PM
To: armybuilder@egroups.com
Subject: Re: [AB] GW Version of Computer Army Creator for Space Marines
Thanks for flagging this to my attention. I've been wondering when this
would finally come out and have been unable to find out any info about it
until now.
I've ordered my copy and I'll see what GW has put together. My initial
reaction isn't very positive regarding their price/value target, since
they
are charging only a little less than AB for the Space Marine Codex alone.
If anyone else picks up a copy of this, I'd love to hear what your
thoughts
are on it. Send them to me directly at rob@wolflair.com (or post them to
the list if you feel it's important to do so).
Thanks, Rob
At 11:48 AM 12/5/00 -0500, you wrote:
>FYI, in the latest Inquistor's report by GWUK, they had the following
>blurb for a computer program to create Space Marine armies that they are
>selling.
> >>>>>>
>However in times of need one can always rely on the Emperor's finest. A
new
>CD to help even the most numerically challenged to develop Space Marine
>armies is now available in the Online Store. I have located it alongside
the
>Codexes and with the Space Marines themselves.
>Go here to track down these new arrivals:
>http://www.games-workshop.co.uk/storefront/games.asp
><<<<<<
>
>Christepher
--------------------------------------------------------------------------
-
Rob Bowes (rob@wolflair.com) (650)
726-9689
Lone Wolf Development
www.wolflair.com
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
eGroups Sponsor
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
[This message contained attachments]
________________________________________________________________________
________________________________________________________________________
Message: 22
Date: Wed, 06 Dec 2000 01:26:33 -0000
From: extremezen@hotmail.com
Subject: Re: GW Version of Computer Army Creator for Space Marines
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: 23
Date: Wed, 06 Dec 2000 04:45:12 -0000
From: "Praetor James " <praetorian-guard@home.com>
Subject: (unknown)
is there a WHFB 6ed ravening hordes ab file that includes the changes
in it that are in the main book.. because the lizardmen have point
and stats that have been changed..??
________________________________________________________________________
________________________________________________________________________
Message: 24
Date: Wed, 6 Dec 2000 16:05:03 +1100
From: "Bern" <bern@pcug.org.au>
Subject: Re: Far-flung ideas
Well,
Given that the tech solutions are problematic (for very good reasons)
why noy use low-tech solutions.
Save a roster as a text file or keep a (shudder) paper copy (which you
probably used at the game you played with that roster). With a print of
what was in your army roster before you can very quickly recreate it using
the latest datafiles.
Agreed, if you want to see what all the options were for armies etc with
the old roster you'd have to reload the old files. But for processing one
roster in the new files the effort is trivial.
And saves Rob's times for fancier stuff (or even for him to have a life!
;-> )
Cheers
Bern
Reality is a chronic condition,
& one generally ignored by cats.
bern@pcug.org.au
----- Original Message -----
From: "Rob Bowes" <rob@wolflair.com>
To: ab@support.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 25
Date: Wed, 06 Dec 2000 06:04:14 -0000
From: "Russell Sparkes" <rjs@inorbit.com>
Subject: Re: A complex option cost question (Crucible)
--- 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.
>
> 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!
Oh well...
Cheers,
Russell.
________________________________________________________________________
________________________________________________________________________