• 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

More fun with AB3 child units.

W

Warmonger

Well-known member
Okay. Working on another 40k fileset. Tyranids.
Here's the situation:
I have a unit that is sized 1-6, each can have different options. To
make it easier for stats to show up correctly when they differ, I'm
creating child units. tyRavener and the child is tyRavener2. Parent
is size 1-6. Child is currently set to 1-5. The parent has the option
to add up to 5 child units. (so that all 6 can be different.) Problem
is, is that say I add two children. The parent drops to 0, and each
child can go up to 5. Doing this with both, gives me 10 models, with
no validation error or anything. Is there a way to dynamically
restrict the size of the child so that all combined, they do not
exceed 6 models? (the child IS set effective right now.)

I also need to set up the same type setting for a squad of 3-9, so
this is the simpler one.... :P








------------------------ Yahoo! Groups Sponsor --------------------~-->
Meet the McDonald¿s® Lincoln Fry get free digital souvenirs,
Web-only video and bid on the Lincoln Fry prop charity auction.
http://us.click.yahoo.com/bUT3FA/fV0JAA/5xWGAA/IMSolB/TM
--------------------------------------------------------------------~->
 
First of all, you're on the right track. It is VALID for the parent unit to
go to zero if enough children are taken. The way "effective" works, the
totals of all effective children are tallied and then subtracted from the
min/max limits on the parent. That establishes the "effective" min/max for
the parent.

There is no way for AB to control the limits on both children AND parents,
since evlaution (and bounding) has to be performed in a sequential process.
Children are evaluated and then their counts folded up into the parent. If
you want AB to be smarter than that, you'll have to explain to me a way to
bypass the "chicken & egg" problem that arises with trying to have parents
effect children at the same time that children effect their parents. :-)

So the user CAN create multiple child units, each with the maximum model
count. What you need is a way to control this to some extent. The simple
solution is to use a "unit" scope rule that compares the effective count of
the unit against the maximum unit size. This should be trivial to implement.

You can improve upon this solution with exclusion groups. Setup an
exclusion group with a maximum limit equal to the maximum size allowed for
the unit. Then assign an exclusion usage for the child unit equal to its
model count. Then create a hidden option on the parent unit whose selection
count is equal to the to model count of the parent unit. When this happens,
the user won't be able to add new child units once the maximum model count
is reached. The existing units will still be able to be increased, so
you'll still need the rule in place, but this will help a bit.

One of the key designs decisions in AB3 was to NOT limit what the user can
accomplish when possible. Instead, validation errors are intended to be
used to inform the user of a problem but still allow an illegal roster if
the user really wants to ignore the error message. This makes it possible
for users to design whatever roster they want, adapting to any custom
scenario rules or "house" rules that they see fit to use. Validation should
make sure the roster is legal, but the user can ignore things as he sees fit.

Hope this helps,
Rob


At 09:55 PM 2/8/2005 +0000, you wrote:
>Okay. Working on another 40k fileset. Tyranids.
>Here's the situation:
>I have a unit that is sized 1-6, each can have different options. To
>make it easier for stats to show up correctly when they differ, I'm
>creating child units. tyRavener and the child is tyRavener2. Parent
>is size 1-6. Child is currently set to 1-5. The parent has the option
>to add up to 5 child units. (so that all 6 can be different.) Problem
>is, is that say I add two children. The parent drops to 0, and each
>child can go up to 5. Doing this with both, gives me 10 models, with
>no validation error or anything. Is there a way to dynamically
>restrict the size of the child so that all combined, they do not
>exceed 6 models? (the child IS set effective right now.)
>
>I also need to set up the same type setting for a squad of 3-9, so
>this is the simpler one.... :P


---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 588-8252
Lone Wolf Development www.wolflair.com



------------------------ Yahoo! Groups Sponsor --------------------~-->
Meet the McDonald¿s® Lincoln Fry get free digital souvenirs,
Web-only video and bid on the Lincoln Fry prop charity auction.
http://us.click.yahoo.com/bUT3FA/fV0JAA/5xWGAA/IMSolB/TM
--------------------------------------------------------------------~->
 
For the Chosen I ended up having a tag that was counted by the parent
unit, and each child unit model assigned +1 to the parent. A roster
level rule then counted the number of tags present in the roster (as
you can take two units of Chosen dependant upon them being a retinue
and also an elite choice) - this got round the prob I think you are
up against.

However I still had probs with the effective tag allowing the parent
to end up at less than the allowed limit when you had added, reduced
and then removed the child unit

--- In armybuilder@yahoogroups.com, Rob Bowes <rob@w...> wrote:
> First of all, you're on the right track. It is VALID for the parent
unit to
> go to zero if enough children are taken. The way "effective" works,
the
> totals of all effective children are tallied and then subtracted
from the
> min/max limits on the parent. That establishes the "effective"
min/max for
> the parent.
>
> There is no way for AB to control the limits on both children AND
parents,
> since evlaution (and bounding) has to be performed in a sequential
process.
> Children are evaluated and then their counts folded up into the
parent. If
> you want AB to be smarter than that, you'll have to explain to me a
way to
> bypass the "chicken & egg" problem that arises with trying to have
parents
> effect children at the same time that children effect their
parents. :-)
>
> So the user CAN create multiple child units, each with the maximum
model
> count. What you need is a way to control this to some extent. The
simple
> solution is to use a "unit" scope rule that compares the effective
count of
> the unit against the maximum unit size. This should be trivial to
implement.
>
> You can improve upon this solution with exclusion groups. Setup an
> exclusion group with a maximum limit equal to the maximum size
allowed for
> the unit. Then assign an exclusion usage for the child unit equal
to its
> model count. Then create a hidden option on the parent unit whose
selection
> count is equal to the to model count of the parent unit. When this
happens,
> the user won't be able to add new child units once the maximum
model count
> is reached. The existing units will still be able to be increased,
so
> you'll still need the rule in place, but this will help a bit.
>
> One of the key designs decisions in AB3 was to NOT limit what the
user can
> accomplish when possible. Instead, validation errors are intended
to be
> used to inform the user of a problem but still allow an illegal
roster if
> the user really wants to ignore the error message. This makes it
possible
> for users to design whatever roster they want, adapting to any
custom
> scenario rules or "house" rules that they see fit to use.
Validation should
> make sure the roster is legal, but the user can ignore things as he
sees fit.
>
> Hope this helps,
> Rob
>
>
> At 09:55 PM 2/8/2005 +0000, you wrote:
> >Okay. Working on another 40k fileset. Tyranids.
> >Here's the situation:
> >I have a unit that is sized 1-6, each can have different options.
To
> >make it easier for stats to show up correctly when they differ, I'm
> >creating child units. tyRavener and the child is tyRavener2.
Parent
> >is size 1-6. Child is currently set to 1-5. The parent has the
option
> >to add up to 5 child units. (so that all 6 can be different.)
Problem
> >is, is that say I add two children. The parent drops to 0, and
each
> >child can go up to 5. Doing this with both, gives me 10 models,
with
> >no validation error or anything. Is there a way to dynamically
> >restrict the size of the child so that all combined, they do not
> >exceed 6 models? (the child IS set effective right now.)
> >
> >I also need to set up the same type setting for a squad of 3-9, so
> >this is the simpler one.... :P
>
>
> --------------------------------------------------------------------
-------
> Rob Bowes (rob@w...) (650) 588-8252
> Lone Wolf Development
www.wolflair.com








------------------------ Yahoo! Groups Sponsor --------------------~-->
Meet the McDonald¿s® Lincoln Fry get free digital souvenirs,
Web-only video and bid on the Lincoln Fry prop charity auction.
http://us.click.yahoo.com/bUT3FA/fV0JAA/5xWGAA/IMSolB/TM
--------------------------------------------------------------------~->
 
You can tell AB to double-check the model count during validation, which
will automatically handle the problem with the parent having too few models
when the user deletes a child. For the parent unit, enable the "checksize"
attribute. Then AB will verify everything for you during validation.

-Rob

At 01:03 PM 2/9/2005 +0000, you wrote:
>For the Chosen I ended up having a tag that was counted by the parent
>unit, and each child unit model assigned +1 to the parent. A roster
>level rule then counted the number of tags present in the roster (as
>you can take two units of Chosen dependant upon them being a retinue
>and also an elite choice) - this got round the prob I think you are
>up against.
>
>However I still had probs with the effective tag allowing the parent
>to end up at less than the allowed limit when you had added, reduced
>and then removed the child unit
>
>--- In armybuilder@yahoogroups.com, Rob Bowes <rob@w...> wrote:
> > First of all, you're on the right track. It is VALID for the parent
>unit to
> > go to zero if enough children are taken. The way "effective" works,
>the
> > totals of all effective children are tallied and then subtracted
>from the
> > min/max limits on the parent. That establishes the "effective"
>min/max for
> > the parent.
> >
> > There is no way for AB to control the limits on both children AND
>parents,
> > since evlaution (and bounding) has to be performed in a sequential
>process.
> > Children are evaluated and then their counts folded up into the
>parent. If
> > you want AB to be smarter than that, you'll have to explain to me a
>way to
> > bypass the "chicken & egg" problem that arises with trying to have
>parents
> > effect children at the same time that children effect their
>parents. :-)
> >
> > So the user CAN create multiple child units, each with the maximum
>model
> > count. What you need is a way to control this to some extent. The
>simple
> > solution is to use a "unit" scope rule that compares the effective
>count of
> > the unit against the maximum unit size. This should be trivial to
>implement.
> >
> > You can improve upon this solution with exclusion groups. Setup an
> > exclusion group with a maximum limit equal to the maximum size
>allowed for
> > the unit. Then assign an exclusion usage for the child unit equal
>to its
> > model count. Then create a hidden option on the parent unit whose
>selection
> > count is equal to the to model count of the parent unit. When this
>happens,
> > the user won't be able to add new child units once the maximum
>model count
> > is reached. The existing units will still be able to be increased,
>so
> > you'll still need the rule in place, but this will help a bit.
> >
> > One of the key designs decisions in AB3 was to NOT limit what the
>user can
> > accomplish when possible. Instead, validation errors are intended
>to be
> > used to inform the user of a problem but still allow an illegal
>roster if
> > the user really wants to ignore the error message. This makes it
>possible
> > for users to design whatever roster they want, adapting to any
>custom
> > scenario rules or "house" rules that they see fit to use.
>Validation should
> > make sure the roster is legal, but the user can ignore things as he
>sees fit.
> >
> > Hope this helps,
> > Rob
> >
> >
> > At 09:55 PM 2/8/2005 +0000, you wrote:
> > >Okay. Working on another 40k fileset. Tyranids.
> > >Here's the situation:
> > >I have a unit that is sized 1-6, each can have different options.
>To
> > >make it easier for stats to show up correctly when they differ, I'm
> > >creating child units. tyRavener and the child is tyRavener2.
>Parent
> > >is size 1-6. Child is currently set to 1-5. The parent has the
>option
> > >to add up to 5 child units. (so that all 6 can be different.)
>Problem
> > >is, is that say I add two children. The parent drops to 0, and
>each
> > >child can go up to 5. Doing this with both, gives me 10 models,
>with
> > >no validation error or anything. Is there a way to dynamically
> > >restrict the size of the child so that all combined, they do not
> > >exceed 6 models? (the child IS set effective right now.)
> > >
> > >I also need to set up the same type setting for a squad of 3-9, so
> > >this is the simpler one.... :P


---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 588-8252
Lone Wolf Development www.wolflair.com



------------------------ Yahoo! Groups Sponsor --------------------~-->
Meet the McDonald¿s® Lincoln Fry get free digital souvenirs,
Web-only video and bid on the Lincoln Fry prop charity auction.
http://us.click.yahoo.com/bUT3FA/fV0JAA/5xWGAA/IMSolB/TM
--------------------------------------------------------------------~->
 
You must log in or register to reply here.
Back
Top