Lone Wolf Development Forums  

Go Back   Lone Wolf Development Forums > Army Builder Forums > Army Builder

Notices

Reply
 
Thread Tools Display Modes
TheDaR
Junior Member
 
Join Date: May 2005
Posts: 10

Old May 27th, 2005, 02:58 PM
In an effort to produce a viable AB3 data file set for GW's Epic Armageddon, I've been slowly setting up my definition file schemes and data model, but have run into a few small problems. I was hoping people could offer suggestions for what they've done that works in similar situations.

Since Epic uses "formations", which function more or less exactly like AB squads do (they contain multiple first-class units, whose composition usually depends on the core detachment and then some number of upgrade units that formation is allowed), I decided to use the squad feature as it will automatically count units in a formation and do other useful things. To use Space Marines as an example, a Tactical Detachment 'unit' will have 6 Tactical squads (child units), base, plus some other upgrades which also become child units (like Dreadnoughts or Vindicators). The squads can't be purchased independently, so they really shouldn't have a cost and min/max size of their own (as a unit can potentially be added either as a core formation or a formation upgrade, with different costs and unit max/mins). But a child link only allows me to add one 'unit' worth to the detachment, when what I'd really like to do is add 6 with one option. Using a range link just makes the option appear in the option pane, without actually adding the child unit to the squad. Is there a "proper" way to set the count of a child entity this way?

Proceeding from here, certain units have the multiple option combinations. Pretty easy, really, for most of them. Simple exclusion lists work for the most part Dreadnoughts, however, present a problem. A Dread can choose either a Twin Lascannon and Missile Launcher or An Autocannon and Dreadnought Power Fist. You always get two weapons, and the pairs are not intermixable. So my thought was to give the Dreadnought unit two options, each of which linked to the two child weapon items (units, actually, in this case, as I've gone the route Flames of War did, with weapons as units, so that the various weapon stat tags can show up in seperate columns on the roster view). However, this seems to have prevented me from being able to use default selection options, remainder lists and exclusions. I'd like to have two range option boxes, one for AC&PF, one for TL&ML, and have each select both weapons at once, but also be able to have one be selected by default and have selecting some number of the other option decrease the default option, exactly like a remainder. Any ideas, or do I have to go into script-land in order to override this behavior?

Thanks for any advice,

-DaR
TheDaR is offline   #1 Reply With Quote
deathlynx
Senior Member
Volunteer Data File Author
 
Join Date: Mar 2005
Location: New Hampshire, USA
Posts: 388

Old May 28th, 2005, 06:01 AM
I've been working on some of these in my current project...granted my squads only require a single child unit with a maximum size limit...What I did was create a non-visable stat that controls the max size of a child unit...You then give the child unit an option (deslected when the unit doesn't have the tag "runtime.child") that regulates its minsize or maxsize dependant on the uplevel.stat[statid]...
At the moment this doesn't actually work but Colen has assured us it's already fixed for the next release...
Hope this helps...
Also (I haven't played Epic so forgive me if I'm wrong) aren't "units" in Epic simply a single base of multiple minis? In effect like a swarm from WFB or 40K? If so couldn't you simply use model count as the unit count? Just a thought...
deathlynx is offline   #2 Reply With Quote
TheDaR
Junior Member
 
Join Date: May 2005
Posts: 10

Old May 28th, 2005, 10:03 AM
For epic a single base ("stand") with multiple minis is indeed a single unit, for infantry. So that's what gets stats. Vehicles are also first class units. But you generally can't buy single stands, but they function more like members of squads in 40k. So yeah, using the AB squads with their model count also tracks the unit count perfectly, which is why I want to use it.

The trick though, in comparison to 40k, is that almost every "squad" consists of a fixed number of specific (and not necessarily uniform) units, plus some arbitrary number of different units as upgrades. And some units can be both core parts of a formation, or upgrades, and will have different costs depending. Tau, for example, can take a formation of 6 Stealth Suit stands for 275 points. But most formations can also take 3 Stealth Suit stands as an upgrade for 125 points. Note that if you work out the points, it doesn't end up a nice even number per suit, and your min/max is different depending on if it's an option or core formation, so I'd like the option/link to be able to specify how many of them end up appearing on the roster. Likewise, Eldar have an Aspect Warrior formation, where you can choose 4 or 8 stands from among 8 possible Aspect choices in any combination, so I'd like range options which let me set how many of each aspect there are in the formation, adding child units with appropriate counts on the roster.

-DaR
TheDaR is offline   #3 Reply With Quote
deathlynx
Senior Member
Volunteer Data File Author
 
Join Date: Mar 2005
Location: New Hampshire, USA
Posts: 388

Old May 28th, 2005, 04:57 PM
I would deffinately suggest doing this with options...It's fairly straight forward for the core units (an option directly changes the min/max)...In the case of the Aspect warriors you set the initial min AND max to 4 and add an option that resets both of these to 8 and adjusts the cost appropriately...Unofrtunately I'm not the best person to ask for the cost advice as I'm currently having my own dilemas on this account...

For child units you can set some invisible stats that are nothing more the placeholders for multiple children...
When you select the option that adds, say stealth suits, that same option sets the value of one of the stats to indicate the min/max model for the child unit (in the case of stealth suits to 3)...Then you can give the stealth suit unit an option that is only live when it has the tag "runtime.child" and the size script mentioned earlier...I would have script which sets the unit cost to zero if it contains the tag "runtime.child" and procede to add the cost through the option...That way you don't have to worry about cost per model...Very useful for the afformentioned stealth suits...
deathlynx is offline   #4 Reply With Quote
Warmonger
Member
Volunteer Data File Author
 
Join Date: Apr 2005
Location: North Western Arizona
Posts: 97

Old May 29th, 2005, 09:47 AM
Take a look at the way the 40k Imperial Guard is set up. Specifically the Infantry Platoon.

It uses hidden options to add the command squad and minimum 2 regular squads. Then you can use the same options made visible to add more. And then you use exclusion groups to watch the min/max number of the options taken.

For a few things in those files, and in another game I'm working on, if there is a cost per model issue, I get the CPM close and then use an automatic hidden option to add/subtract the final points adjustment needed.
Warmonger is offline   #5 Reply With Quote
TheDaR
Junior Member
 
Join Date: May 2005
Posts: 10

Old May 30th, 2005, 12:06 PM
Thanks guys. Sounds like the idea of using scripts to modify the min and max is going to be the only real option to get the exact child sizes I want for the default selections. Still mulling how I'm going to be able to do multiple child options in pairs (for dreadnought weapons).

-DaR
TheDaR is offline   #6 Reply With Quote
rob
Senior Member
Lone Wolf Staff
 
Join Date: May 2005
Posts: 8,232

Old May 30th, 2005, 02:57 PM
I don't know anything about Epic beyond what you provide below, so this is
my "best guess" based on what you've outlined....

First of all, lets look at your unit structure. You say you're going to use
squads, then you talk about lots of child units. So I'm definitely missing
something here. Please clarify what you've got in mind.

Based on your limited description, though, I'll take a stab at how I'd set
things up. Since the structure sounds highly regimented, with only a small
number of customizable options, using AB's squads seems NOT to make sense
for Epic. AB3 is extremely flexible for managing child units now, so I'd
just keep everything within the context of a single top-level unit for each
"formation".

Therefore, I'd start with a "Tactical Detachment" as the unit that can be
user-selected in the Available Units list. This gets added to the roster
(min/max of 1/1) and it has multiple child units hanging off of it. The
first child would be the Tactical Squad, and it would have an initial size
of 6. Dreadnoughts and Vindicators would be added as child units via
options on the "Tactical Detachment" top-level unit.

You can set the initial size of the Tactical Squad child to 6 via the
option script that set the min/max/start of a child entity. This would be
attached to the option which is adding the Tactical Squad child unit to the
parent. The script will be trivial to write, as it will consist of
something similar to what's shown below:
@minimum = 6
@maximum = 9
@start = 6

The actual numbers above may be different, since I don't know the game, but
you get the idea. You can also use the above script to restrict the min/max
values dynamically, based on other changes made to the parent unit (i.e the
Tactical Detachment). If other selections on the parent unit change the
limits, just have the script enforce appropriately. All you'll really need
to worry about with this is your priority assignments so that evaluation is
performed in the proper order and the options which influence the childsize
script are performed before the option that applies the childsize script.

Now, let's look at the Dreadnought options situation. Use of range-based
options DOES eliminate the ability to specify initial default selections
via the standard method. You must instead set the initial default count as
part of the range specification. However, remainders and exclusions all
work normally based on range options. The current range value can be
designated to be used as the amount applied to the exclusion. You have to
make sure that your exclusion references are all setup correctly for this
to work, though.

I think your idea of having an AC/PF option and a TL/ML option is correct.
Each of these options would then chain to the corresponding separate AC,
PF, TL, and ML options (two each). That way, the footnotes with game-time
reminders at the end of the roster will map to the proper options and there
is no need for redundancy.

There's not much more I can glean from your brief description and my utter
lack of familiarity with the game, so I can't offer further suggestions. If
you want more detailed answers, you'll need to provide me with more
concrete specifics to work from. :-)

Hope this helps,
Rob

At 06:59 PM 5/27/2005 -0400, you wrote:

>In an effort to produce a viable AB3 data file set for GW's Epic
>Armageddon, I've been slowly setting up my definition file schemes and
>data model, but have run into a few small problems. I was hoping people
>could offer suggestions for what they've done that works in similar situations.
>
>Since Epic uses "formations", which function more or less exactly like AB
>squads do (they contain multiple first-class units, whose composition
>usually depends on the core detachment and then some number of upgrade
>units that formation is allowed), I decided to use the squad feature as it
>will automatically count units in a formation and do other useful things.
>To use Space Marines as an example, a Tactical Detachment 'unit' will have
>6 Tactical squads (child units), base, plus some other upgrades which also
>become child units (like Dreadnoughts or Vindicators). The squads can't be
>purchased independently, so they really shouldn't have a cost and min/max
>size of their own (as a unit can potentially be added either as a core
>formation or a formation upgrade, with different costs and unit max/mins).
>But a child link only allows me to add one 'unit' worth to the detachment,
>when what I'd really like to do is add 6 with one option. Using a range
>link just makes the option appear in the option pane, without actually
>adding the child unit to the squad. Is there a "proper" way to set the
>count of a child entity this way?
>
>Proceeding from here, certain units have the multiple option combinations.
>Pretty easy, really, for most of them. Simple exclusion lists work for the
>most part Dreadnoughts, however, present a problem. A Dread can choose
>either a Twin Lascannon and Missile Launcher or An Autocannon and
>Dreadnought Power Fist. You always get two weapons, and the pairs are not
>intermixable. So my thought was to give the Dreadnought unit two options,
>each of which linked to the two child weapon items (units, actually, in
>this case, as I've gone the route Flames of War did, with weapons as
>units, so that the various weapon stat tags can show up in seperate
>columns on the roster view). However, this seems to have prevented me from
>being able to use default selection options, remainder lists and
>exclusions. I'd like to have two range option boxes, one for AC&PF, one
>for TL&ML, and have each select both weapons at once, but also be able to
>have one be selected by default and have selecting some number of the
>other option decrease the default option, exactly like a remainder. Any
>ideas, or do I have to go into script-land in order to override this behavior?
>
>Thanks for any advice,
>
>-DaR


---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (408) 927-9880
Lone Wolf Development www.wolflair.com
rob is offline   #7 Reply With Quote
TheDaR
Junior Member
 
Join Date: May 2005
Posts: 10

Old May 31st, 2005, 11:31 PM
Quote:
Originally Posted by rob
I don't know anything about Epic beyond what you provide below, so this is
my "best guess" based on what you've outlined....

First of all, lets look at your unit structure. You say you're going to use
squads, then you talk about lots of child units. So I'm definitely missing
something here. Please clarify what you've got in mind.
Okay, in more depth.

In Epic, the "formation" is the basic unit of deployment and maneuver. They act more or less the same as a "squad" does in 40k (but not necessarily Army Builder). Each "unit" (stand of infantry or vehicle) is part of one formation, and there are rules about coherency of units within a formation. Formations are also the basic unit of army building. You'd buy a Space Marine Tactical Detachment as one of the core choices for a list. It comes with 6 unit-stands of Tactical Marines and costs 300 points. One of the basic formations for Eldar in the new Swordwind supplement, by comparison, is a Aspect Warhost, which also costs 300 points. These formations come with 8 Aspect warrior unit-stands, which must be selected from among the 8 possible types of selections (Fire Dragons, Dire Avengers, Striking Scorpions, etc).

Now, each core formation you buy usually has some relatively small number of options, which almost always add some (possibly variable) number of additional units to that formation. A Space Marine Tactical Detachment can, for instance, have the 'Dreadnoughts' upgrade, the 'Vindicators' upgrade, and a few other similar sorts. The Dreadnoughts upgrade allows you to buy 1 or 2 Dreadnoughts for 50 points each. Those units add directly to your formation size, which is actually quite relevant in Epic (it determines how hard it is to suppress or break the formation, for example). Also important is the cost of the formation, not just for army list purposes, but because the single biggest cost unit in an army being destroyed may qualify for an opponent's objective, so you want to know how big each is at a glance.

I'd started out using AB Squads, because with relatively little work (setting Model Count to 0 for those things which shouldn't count, like weapon 'units'), I got a nice immediate visual running total of both the points and the number of units in each formation. In the end, though, being able to put the options for a formation on an actual selectable unit proved too tempting, and I did what you've suggested and created separate unit entities for each detachment type. I've kept the squads option on, though, giving me those totals, even if it does introduce one additional level in the roster screen.

So, next, the data model:

Right now I have three types of entities. First are my basic units. These each have a certain number of tagged stats, like any other model for any game would have. So far I've avoided putting either model costs or unit size min/max on them, as in many lists the basic units can be part of core formations, separate auxiliary formations, or even unit upgrades, each with different costs and min/maxes. For example, in the main IG list, a super-heavy tank company formation costs 500 points for 3 tanks, but as a support formation, you can take a single platoon formation of one solitary super-heavy for 200 points.

The second entity type is weapons. As I mentioned, I'm using the idea Flames of War did to put the weapon stats into the roster view. Each regular unit include links the appropriate options which are all set up with Child Unit links for the weapons themselves. All the weapon entities have Model Count set to 0 so they don't affect the formation size, and a different StatSet with the appropriate stats included. Like the individual units, they don't have cost set, since they're always include linked, rather than cost linked.

Finally, I have the formation units. These are the only thing which get the Race tag, so they're the only ones that show up in the actual Available view. They have the auto and cost links to the various mandatory and option units. Having implemented the suggestion to use the sizelimit script to make the unit min/max work, the auto add now appropriately adds the right number of mandatory units to the child unit.

Now to my current areas of confusion/frustration:

Using the cost script on the option does not appear to do what I'd expect. If I set the cost script of the Vindicator option to '@each = 75', the cost does not show up in the roster view (shows "[0]"), and while the first selection gets properly added to the formation and roster cost, clicking the "+" button to add another to the child unit does not consume another 75 points, presumably because the cost is being set on the option itself, rather than the child. Likewise the same happens if I set the cost on either the link itself or the option. The Childcost script seems to be the one I'd need to use, but that's on the parent unit, not the option. Since multiple core formations all have the option to take identical Vindicator upgrades, it seems there should be some script I can set the child's base cost from the option itself, rather than from each parent unit's script.

In the end, what I really want is for the parent formation to have an option (range preferable, but select okay) which adds a child unit to the formation, with the right cost and count as an upgrade, with the ability to click either the option range or the add model button on the roster view and add another one to that child group and have the costs and counts appropriately tallied. Clearly AB is capable of doing this. I'm just bent as for how to make it do so at my command.

-DaR
TheDaR is offline   #8 Reply With Quote
rob
Senior Member
Lone Wolf Staff
 
Join Date: May 2005
Posts: 8,232

Old June 4th, 2005, 01:53 PM
At 03:31 AM 6/1/2005 -0400, you wrote:
>Now to my current areas of confusion/frustration:
>
>Using the cost script on the option does not appear to do what I'd expect.
>If I set the cost script of the Vindicator option to '@each = 75', the
>cost does not show up in the roster view (shows "[0]"), and while the
>first selection gets properly added to the formation and roster cost,
>clicking the "+" button to add another to the child unit does not consume
>another 75 points, presumably because the cost is being set on the option
>itself, rather than the child. Likewise the same happens if I set the cost
>on either the link itself or the option. The Childcost script seems to be
>the one I'd need to use, but that's on the parent unit, not the option.
>Since multiple core formations all have the option to take identical
>Vindicator upgrades, it seems there should be some script I can set the
>child's base cost from the option itself, rather than from each parent
>unit's script.

Thanks for the detailed description. I think I now have a decent idea of
(a) the game structure and (b) how you've modeled it. :-)

The issue you've got is that you want the cost to come from the option, yet
you want the user to control the model count on the child unit. You can't
mix the two approaches. Let me explain.

Using "@each" within the cost script set the cost of each selection of the
OPTION. If you have a simple "select/deselect" option, then there will only
be a single selection, which is why the cost is always stuck with the same
value. If you were to use a range-based link, then there would be multiple
selections and "@each" would do as you intend.

On the flipside, you are having the user modify the model count via the
child unit. But since the unit cost is zero, the model count is only
meaningful for display to the user. The model count is always being
multiplied by zero, so the net cost is zero.

Basically, you have to make a choice of where you want the costs AND counts
both tracked. They have to be tracked within the same context, either at
the option level or at the child unit level.

Option #1 is to do it at the child unit level. You stated that the same
unit can be used in different places with different size limits and costs,
which is why you're not assigning costs and sizes to the child units. AB
can easily accommodate through "overrides". So one solution would be to use
overrides on the various units to specify different costs/sizes on the
child units, in which case you simply need to add the child unit to the
roster and they do all the work for you.

Another solution would be to calculate the cost of the child unit within
the PostLinks script of the entity. You could have the parent unit specify
the unit cost to be used via a tag. Then you could retrieve the value of
that tag within the child unit and calculate the cost appropriately.
Personally, I dislike this approach, but it's a valid way of doing things.

Option #2 is to do things at the option level within the parent unit. In
this case, your Cost script needs to retrieve the model count of the child
entity. You then need to set the final cost equal to the model count times
the per-model cost. This is done with "@single".

On the surface, using the Cost script probably seems the closest to what
you want, but there are some drawbacks to be aware of. Within AB, costs are
tracked from different sources. Normally, units are tracked with their own
cost category, but using the Cost script re-classifies all those child unit
costs as OPTION costs. So if you want to write rules and/or stats that rely
on the total unit costs, those values will NOT be what you expect. I point
this out because you stated that knowing the highest priced unit is
important, and AB's ability to discern this readily will be undermined. I
think you can still get the information correctly, but you'll have to do
some extra work to get it.

Anyways, I hope this explanation proves helpful. Let me know if you still
have questions about any of this.

-Rob

---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (408) 927-9880
Lone Wolf Development www.wolflair.com
rob is offline   #9 Reply With Quote
TheDaR
Junior Member
 
Join Date: May 2005
Posts: 10

Old June 7th, 2005, 04:10 PM
Quote:
Originally Posted by rob
At 03:31 AM 6/1/2005 -0400, you wrote:
Thanks for the detailed description. I think I now have a decent idea of
(a) the game structure and (b) how you've modeled it. :-)

The issue you've got is that you want the cost to come from the option, yet
you want the user to control the model count on the child unit. You can't
mix the two approaches. Let me explain.

Using "@each" within the cost script set the cost of each selection of the
OPTION. If you have a simple "select/deselect" option, then there will only
be a single selection, which is why the cost is always stuck with the same
value. If you were to use a range-based link, then there would be multiple
selections and "@each" would do as you intend.

On the flipside, you are having the user modify the model count via the
child unit. But since the unit cost is zero, the model count is only
meaningful for display to the user. The model count is always being
multiplied by zero, so the net cost is zero.

Basically, you have to make a choice of where you want the costs AND counts
both tracked. They have to be tracked within the same context, either at
the option level or at the child unit level.

Option #1 is to do it at the child unit level. You stated that the same
unit can be used in different places with different size limits and costs,
which is why you're not assigning costs and sizes to the child units. AB
can easily accommodate through "overrides". So one solution would be to use
overrides on the various units to specify different costs/sizes on the
child units, in which case you simply need to add the child unit to the
roster and they do all the work for you.

Another solution would be to calculate the cost of the child unit within
the PostLinks script of the entity. You could have the parent unit specify
the unit cost to be used via a tag. Then you could retrieve the value of
that tag within the child unit and calculate the cost appropriately.
Personally, I dislike this approach, but it's a valid way of doing things.

Option #2 is to do things at the option level within the parent unit. In
this case, your Cost script needs to retrieve the model count of the child
entity. You then need to set the final cost equal to the model count times
the per-model cost. This is done with "@single".

On the surface, using the Cost script probably seems the closest to what
you want, but there are some drawbacks to be aware of. Within AB, costs are
tracked from different sources. Normally, units are tracked with their own
cost category, but using the Cost script re-classifies all those child unit
costs as OPTION costs. So if you want to write rules and/or stats that rely
on the total unit costs, those values will NOT be what you expect. I point
this out because you stated that knowing the highest priced unit is
important, and AB's ability to discern this readily will be undermined. I
think you can still get the information correctly, but you'll have to do
some extra work to get it.

Anyways, I hope this explanation proves helpful. Let me know if you still
have questions about any of this.
Hrm. That does clarify the limitations to some extent. A few minutes work and the PostLink version works mostly correctly (using PostLink instead of Overrides in this case because the cost is for 3 items at a value that's not evenly divisible by 3, and I want it to show up right in the cost column of the roster view).

Now to conquer being able to control the size of a sibling unit based on the size of another sibling...
TheDaR is offline   #10 Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 07:26 AM.


Powered by vBulletin® - Copyright ©2000 - 2024, vBulletin Solutions, Inc.
wolflair.com copyright ©1998-2016 Lone Wolf Development, Inc. View our Privacy Policy here.