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

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

    - The Lone Wolf Development Team

Help with Inheritance and a Core Set of Units

  • Thread starter Thread starter errett at triusenterprise
  • Start date Start date
E

errett at triusenterprise

Guest
Hi All-

I would like to create a new set of files which leverage AB's
inheritance features. I am not sure if this system can be modeled and
if so, I am too stupid to figure it out. I've read through several
posts here on chld and the inherit attributes, as well as the
ABCreator docs and am just not smart enough to determine where to
start. Here is what I am hoping to accomplish:

A system in which all units (in every army) are based on a core set
of units (Humans for example) in terms of stats and costs. Each race
(in game terms - not AB terms; Orcs, Trolls, etc.) has a set of
modifiers to those stats and cost. So a Troll could be St+2, Ld-3,
etc. These races can be combined in a roster to create an army: an
army of Orcs, Goblins, and Trolls for example.

I had hoped to create a core set of units comprised of things
like 'Foot Trooper', 'Cavalry', etc. These units have a default set
of stats and cost. Then each race file has a set of units based on
the core set and inherit their stats and cost. The race file would
control the name and what options are available for each unit, such
that a unit 'Orc Infantry' would start out by inheriting the basic
Foot Trooper stats and cost and then via attributes would modify
these stats and the cost as per the Orc race. Furthermore, the user
can choose from core options (global to all armies) such as Shield,
or Light Armor; but also race specific options such as Choppa, and in
some cases unit specific options such as Upgrade to Big 'Uns.

The end result in all this is that once the core file is created, the
specific race files should be fairly easy to implement (I hope!). At
least in a sense that the race file authors do not need to create 35
units from scratch but rather create a global (to the new race) set
of stat and cost modifiers; point the new units to a logical parent
and add the unit specific data.

My hope is that ultimately most of this would be transparent to the
user who simply chooses an army type and picks units which appear to
be specific to that army.

So any general or specific help would be greatly appreciated. I'm
sorry if I am asking an age-old question, if so just point me to the
answer.

Thank you!
Errett


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get your FREE credit report with a FREE CreditCheck
Monitoring Service trial
http://us.click.yahoo.com/MDsVHB/bQ8CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
At 14:10 11/09/2001 +0000, you wrote:

>A system in which all units (in every army) are based on a core set
>of units (Humans for example) in terms of stats and costs. Each race
>(in game terms - not AB terms; Orcs, Trolls, etc.) has a set of
>modifiers to those stats and cost. So a Troll could be St+2, Ld-3,
>etc. These races can be combined in a roster to create an army: an
>army of Orcs, Goblins, and Trolls for example.
>
>I had hoped to create a core set of units comprised of things
>like 'Foot Trooper', 'Cavalry', etc. These units have a default set
>of stats and cost. Then each race file has a set of units based on
>the core set and inherit their stats and cost. The race file would
>control the name and what options are available for each unit, such
>that a unit 'Orc Infantry' would start out by inheriting the basic
>Foot Trooper stats and cost and then via attributes would modify
>these stats and the cost as per the Orc race. Furthermore, the user
>can choose from core options (global to all armies) such as Shield,
>or Light Armor; but also race specific options such as Choppa, and in
>some cases unit specific options such as Upgrade to Big 'Uns.

The only things that you can use inheritance for (in units) is attributes
and option links. It would be possible to do the above, but it would be
slightly non-standard, because you can't inherit the stats or cost of a unit.


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


------------------------ Yahoo! Groups Sponsor ---------------------~-->
The Nissan Sentra
Everything but compact
http://NissanDriven.com
http://us.click.yahoo.com/3vsIKC/txlCAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
From your description, it sounds like AB can achieve very close to what
you want. Here's how I would do it...

First create a race to test things with. Let's start with "Orcs".

Now create your generic "Foot Trooper" unit. For the unique id, have it
start with 'x' to indicate that it's not a unit that the user can select
(e.g. "xfoot"). AB won't inherit stat values, so you'll need to create an
option that initializes all the stats appropriately. You can do this with a
single option that has a sequence of "base:stat+4" style of attributes (one
for each stat). Make this option hidden and assign it to the option
category "Priority" so that it is processed before anything else. Be sure
to use the "+" or "-" adjustment for each "base" attribute instead of
saying "=". The reason for this is that you can mix this adjustment with
the race-specific adjustments (see below) without having to worry about
sequencing between them. All stats start with a default value of zero. Then
attach it to the generic foot trooped with an "incl" link nature. You now
have your basic trooper.

Now create an "Orc Foot Trooper" unit, giving it the appropriate race
prefix for Orcs (in the unique id). Create an option that applies all the
base stat adjustments for the race. This would be another option similar to
the one created above. It would have an assortment of "base" attributes
that apply the adjustments, and it should also belong to the "Priority"
category and be hidden. Attach the option to the unit via "incl".

If you assign the "Orc Foot Trooper" unit the "clon:xfoot" attribute, it
will now inherit all of the basic foot trooper stats. The race-specific
option will then apply the additional adjustments, yielding a properly
adjusted "Orc Foot Trooper".

The next step is to create all of the standard options that all "Foot
Trooper" units possess (e.g. "shield"). You can attach all of these options
to the generic "xfoot" unit with the appropriate link natures (probably
"cost"). These options will then be inherited by the "Orc Foot Trooper". If
you want race-specific options for Orcs, you can define a separate set of
options that you attach directly to the Orcs. If the Orc-specific options
are accessible by all Orc units, you can simplify this even further. If you
create an "Orc Weapons" optoin that is hidden and then assign it a bunch of
"more" attributes to the various Orc weapons, you can have a single option
automatically assign all the Orc weapons to a unit (making the creation of
new units really fast and easy). Another method would be to create a
generic "Orc" unit that all Orc units inherit from in ADDITION to the
generic base unit (units CAN inherit from multiple other units).

You can also re-use the race-specific adjustments option for other Orc
units. If you have a unit of "Orc Cavarly", they would inherit from the
basic "Cavalry" unit. You could then attach the generic "Orc" option to the
"Orc Cavalry" and have the same adjustments applied to the unit.

This type of technique is used in a number of data files for AB. Sometimes,
looking at existing data files can provide a great deal of information
about how they are structured. You can also learn a lot of interesting
tricks that other authors have come up with. :-) You might consider doing
this in conjunction with your own design efforts.

The one thing that AB can't handle is the inheritance of the base cost.
Each unit will have to have its own cost specified for it, but that should
be easier than defining a cost adjustment for each unit.

Hope this helps,
Rob


At 02:10 PM 9/11/2001 +0000, you wrote:
>Hi All-
>
>I would like to create a new set of files which leverage AB's
>inheritance features. I am not sure if this system can be modeled and
>if so, I am too stupid to figure it out. I've read through several
>posts here on chld and the inherit attributes, as well as the
>ABCreator docs and am just not smart enough to determine where to
>start. Here is what I am hoping to accomplish:
>
>A system in which all units (in every army) are based on a core set
>of units (Humans for example) in terms of stats and costs. Each race
>(in game terms - not AB terms; Orcs, Trolls, etc.) has a set of
>modifiers to those stats and cost. So a Troll could be St+2, Ld-3,
>etc. These races can be combined in a roster to create an army: an
>army of Orcs, Goblins, and Trolls for example.
>
>I had hoped to create a core set of units comprised of things
>like 'Foot Trooper', 'Cavalry', etc. These units have a default set
>of stats and cost. Then each race file has a set of units based on
>the core set and inherit their stats and cost. The race file would
>control the name and what options are available for each unit, such
>that a unit 'Orc Infantry' would start out by inheriting the basic
>Foot Trooper stats and cost and then via attributes would modify
>these stats and the cost as per the Orc race. Furthermore, the user
>can choose from core options (global to all armies) such as Shield,
>or Light Armor; but also race specific options such as Choppa, and in
>some cases unit specific options such as Upgrade to Big 'Uns.
>
>The end result in all this is that once the core file is created, the
>specific race files should be fairly easy to implement (I hope!). At
>least in a sense that the race file authors do not need to create 35
>units from scratch but rather create a global (to the new race) set
>of stat and cost modifiers; point the new units to a logical parent
>and add the unit specific data.
>
>My hope is that ultimately most of this would be transparent to the
>user who simply chooses an army type and picks units which appear to
>be specific to that army.
>
>So any general or specific help would be greatly appreciated. I'm
>sorry if I am asking an age-old question, if so just point me to the
>answer.
>
>Thank you!
>Errett


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


------------------------ Yahoo! Groups Sponsor ---------------------~-->
FREE COLLEGE MONEY
CLICK HERE to search
600,000 scholarships!
http://us.click.yahoo.com/47cccB/4m7CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
From your description, it sounds like AB can achieve very close to what
you want. Here's how I would do it...

First create a race to test things with. Let's start with "Orcs".

Now create your generic "Foot Trooper" unit. For the unique id, have it
start with 'x' to indicate that it's not a unit that the user can select
(e.g. "xfoot"). AB won't inherit stat values, so you'll need to create an
option that initializes all the stats appropriately. You can do this with a
single option that has a sequence of "base:stat+4" style of attributes (one
for each stat). Make this option hidden and assign it to the option
category "Priority" so that it is processed before anything else. Be sure
to use the "+" or "-" adjustment for each "base" attribute instead of
saying "=". The reason for this is that you can mix this adjustment with
the race-specific adjustments (see below) without having to worry about
sequencing between them. All stats start with a default value of zero. Then
attach it to the generic foot trooped with an "incl" link nature. You now
have your basic trooper.

Now create an "Orc Foot Trooper" unit, giving it the appropriate race
prefix for Orcs (in the unique id). Create an option that applies all the
base stat adjustments for the race. This would be another option similar to
the one created above. It would have an assortment of "base" attributes
that apply the adjustments, and it should also belong to the "Priority"
category and be hidden. Attach the option to the unit via "incl".

If you assign the "Orc Foot Trooper" unit the "clon:xfoot" attribute, it
will now inherit all of the basic foot trooper stats. The race-specific
option will then apply the additional adjustments, yielding a properly
adjusted "Orc Foot Trooper".

The next step is to create all of the standard options that all "Foot
Trooper" units possess (e.g. "shield"). You can attach all of these options
to the generic "xfoot" unit with the appropriate link natures (probably
"cost"). These options will then be inherited by the "Orc Foot Trooper". If
you want race-specific options for Orcs, you can define a separate set of
options that you attach directly to the Orcs. If the Orc-specific options
are accessible by all Orc units, you can simplify this even further. If you
create an "Orc Weapons" optoin that is hidden and then assign it a bunch of
"more" attributes to the various Orc weapons, you can have a single option
automatically assign all the Orc weapons to a unit (making the creation of
new units really fast and easy). Another method would be to create a
generic "Orc" unit that all Orc units inherit from in ADDITION to the
generic base unit (units CAN inherit from multiple other units).

You can also re-use the race-specific adjustments option for other Orc
units. If you have a unit of "Orc Cavarly", they would inherit from the
basic "Cavalry" unit. You could then attach the generic "Orc" option to the
"Orc Cavalry" and have the same adjustments applied to the unit.

This type of technique is used in a number of data files for AB. Sometimes,
looking at existing data files can provide a great deal of information
about how they are structured. You can also learn a lot of interesting
tricks that other authors have come up with. :-) You might consider doing
this in conjunction with your own design efforts.

The one thing that AB can't handle is the inheritance of the base cost.
Each unit will have to have its own cost specified for it, but that should
be easier than defining a cost adjustment for each unit.

Hope this helps,
Rob


At 02:10 PM 9/11/2001 +0000, you wrote:
>Hi All-
>
>I would like to create a new set of files which leverage AB's
>inheritance features. I am not sure if this system can be modeled and
>if so, I am too stupid to figure it out. I've read through several
>posts here on chld and the inherit attributes, as well as the
>ABCreator docs and am just not smart enough to determine where to
>start. Here is what I am hoping to accomplish:
>
>A system in which all units (in every army) are based on a core set
>of units (Humans for example) in terms of stats and costs. Each race
>(in game terms - not AB terms; Orcs, Trolls, etc.) has a set of
>modifiers to those stats and cost. So a Troll could be St+2, Ld-3,
>etc. These races can be combined in a roster to create an army: an
>army of Orcs, Goblins, and Trolls for example.
>
>I had hoped to create a core set of units comprised of things
>like 'Foot Trooper', 'Cavalry', etc. These units have a default set
>of stats and cost. Then each race file has a set of units based on
>the core set and inherit their stats and cost. The race file would
>control the name and what options are available for each unit, such
>that a unit 'Orc Infantry' would start out by inheriting the basic
>Foot Trooper stats and cost and then via attributes would modify
>these stats and the cost as per the Orc race. Furthermore, the user
>can choose from core options (global to all armies) such as Shield,
>or Light Armor; but also race specific options such as Choppa, and in
>some cases unit specific options such as Upgrade to Big 'Uns.
>
>The end result in all this is that once the core file is created, the
>specific race files should be fairly easy to implement (I hope!). At
>least in a sense that the race file authors do not need to create 35
>units from scratch but rather create a global (to the new race) set
>of stat and cost modifiers; point the new units to a logical parent
>and add the unit specific data.
>
>My hope is that ultimately most of this would be transparent to the
>user who simply chooses an army type and picks units which appear to
>be specific to that army.
>
>So any general or specific help would be greatly appreciated. I'm
>sorry if I am asking an age-old question, if so just point me to the
>answer.
>
>Thank you!
>Errett


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


------------------------ Yahoo! Groups Sponsor ---------------------~-->
FREE COLLEGE MONEY
CLICK HERE to search
600,000 scholarships!
http://us.click.yahoo.com/47cccB/4m7CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
Thanks Rob and Colen!

I came to the same conclusion in terms of the option links and it
will work good enough to allow me to create this system I think. I
have looked through a couple other systems and I like some of the
tricks in there, however with the exception of Warhammer I don't have
rulebooks and don't understand a lot of what I see there.
Specifically the CAV and Clan War Daimyo stuff - looks neat(!) but
I'll be darned if I can see what the heck all that means!

Anyway, thanks again for your detailed description Rob - I ran
through it in a minute and lots of stuff made more sense. I have a
couple more questions though:

1. When I bring in the stats via the option links the adjusted stats
do not appear in the list of available units. Is there a way to cause
those to appear there? If I understand the docs right - there would
not be a way as the attribs are applied once the unit is added to the
active roster. This is not a system killer - it just means that
either I need to add all the stats to each unit (I was using 0s - and
this would pretty much make the whole stat inheritance thing moot) or
deal with not knowing the stats/cost of the units until they are
selected.

2. What if AB had a set of inherit attribs which would inherit the
stats and/or cost of another unit? Would this break some internal
processing/validation stuff? Maybe it would be something for a future
release - or am I the only one who can see the value in this type of
thing? Furthermore could this inheritance happen before the list of
available units is displayed? I suspect not, but this would probly be
necessary for the feature to be valuable IMO.

Anyway, thanks again for taking the time to read my long-winded
ramblings. Its a great product and I am looking forward to using it
for years!

Errett


------------------------ Yahoo! Groups Sponsor ---------------------~-->
FREE COLLEGE MONEY
CLICK HERE to search
600,000 scholarships!
http://us.click.yahoo.com/47cccB/4m7CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
At 12:32 PM 9/12/2001 +0000, you wrote:
>1. When I bring in the stats via the option links the adjusted stats
>do not appear in the list of available units. Is there a way to cause
>those to appear there? If I understand the docs right - there would
>not be a way as the attribs are applied once the unit is added to the
>active roster. This is not a system killer - it just means that
>either I need to add all the stats to each unit (I was using 0s - and
>this would pretty much make the whole stat inheritance thing moot) or
>deal with not knowing the stats/cost of the units until they are
>selected.

Your assessment is correct, and I didn't even think of this issue. :-( Only
a very few attributes are actually get applied to the list of available
units. All adjustments are applied only after the unit is added to the
roster, so the units would not be able to appear to the user for selection
with the proper adjustments. :-(

>2. What if AB had a set of inherit attribs which would inherit the
>stats and/or cost of another unit? Would this break some internal
>processing/validation stuff? Maybe it would be something for a future
>release - or am I the only one who can see the value in this type of
>thing? Furthermore could this inheritance happen before the list of
>available units is displayed? I suspect not, but this would probly be
>necessary for the feature to be valuable IMO.

Again, your assessment is correct. It would be possible to extend AB to
inherit stats and costs from other units. All inheritance IS applied to the
basic unit, so inherited information like this COULD be made visible in the
list of available units. I'll add this to the todo list. Hopefully, I'll
get a chance to add this into a future release.

Thanks, Rob

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


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get your FREE credit report with a FREE CreditCheck
Monitoring Service trial
http://us.click.yahoo.com/MDsVHB/bQ8CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
You must log in or register to reply here.
Back
Top