• 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

What Improvised Solutions Have You Used?

rob

Administrator
Staff member
Basically, what I'm looking for is a recap of the various improvised
solutions that you guys have come up with to handle various situations. An
"improvised" solution is the use of a mechanism within AB that wasn't
specifically designed for a task but is now being used for that purpose. An
example is the "race-specific unit" (see other thread), that makes it
possible to include ruleset-specific notes and stats.

I'm asking for this list for TWO reasons....

Reason #1 is that ideas that are extremely useful need to be included in
the "Tips & Tricks" chapter of the new Kit docs that are nearing completion.

Reason #2 is that ideas that are less than ideal will flag the current
shortcomings of V3.0. We can then think through appropriate changes that
can be incorporated into a new release.

Thanks in advance for the feedback!!!

-Rob

---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (408) 927-9880
Lone Wolf Development www.wolflair.com
 
I've already mentioned this in the post for suggestions for ammendments, but the work around am currently using is to set up a mirrored option that the user can still select on the child indepedantly of the parent.

The 'game option' (daemonic gifts) is currently set up as an item with two option that inherit of it. Option A and B both point to the same item as a child entity, however option B's name is changed so it is marked up as squad based selection.

Within the linkset, both options are dropped in, option A is a default entry in the linkset, option B is a mirror to the parent equivalent option, both with an exclusion of 0 - 1.

The unit for the possessed champion has a prescript that checks the selection state of the parnt unit option, if selcted then then option A is made invisible while option B is made visible and then selected by the mirror.

It allows a user to have the mirrored option from the parent unit but also to select the option on the child independantly.
 
In order to get around the fact that you cannot use "this.selection" in the sizelimit script of an option I have created an invisible stat ('carrier') and set the script to "@maximum = uplevel.tagvalue[runtime.carrier?]"

All of this is in fact an improvisation to get around the fact that you cannot use "this.selection" in order to directly control the size of a child unit...
 
deathlynx said:
In order to get around the fact that you cannot use "this.selection" in the sizelimit script of an option I have created an invisible stat ('carrier') and set the script to "@maximum = uplevel.tagvalue[runtime.carrier?]"

All of this is in fact an improvisation to get around the fact that you cannot use "this.selection" in order to directly control the size of a child unit...

Can you explain the context you used this in? It sounds like it might be the solution to one of the problems I've been wrestling with (trying to control the size of a child unit based on the size of a second "sibling" child unit).

-DaR
 
TheDaR said:
Can you explain the context you used this in? It sounds like it might be the solution to one of the problems I've been wrestling with (trying to control the size of a child unit based on the size of a second "sibling" child unit).

B5 is a space combat game...You can take fighters as a unit in their own right or they come free with carriers...As a unit they have a maximum number of 4 models (actually bases)...
Unfortunately every carrier has a different maximum number of fighters so I've set this up in order to change the maximum unit size...

There's still some confusion about the rules for this (check AB authorkit forum's thread "size limit") and it's not going to be fully available until the next release as it depends on "uplevel" which was only just found not to work properly in sizelimit, and has been fixed...
 
I've gotten them pretty much worked out...I've uploaded the newest release of the files and the link in the downloads should get you there...Check out the unit and option id "thdblt" for the earthal dat file...
There are other fighters in the files but they aren't working quite right yet...
 
What is the actual situation that you are trying to handle? Having the size of one child unit impact the size of a sibling unit is probably NOT something you should be doing directly. I'm guessing that there is a different way that the problem should be solved, but I have no idea what you're trying to  accomplish. Please describe it in detail and I'll do my best to offer some suggestions.

-Rob

At 06:16 PM 6/16/2005 -0400, you wrote:

deathlynx wrote:
In order to get around the fact that you cannot use "this.selection" in the sizelimit script of an option I have created an invisible stat ('carrier') and set the script to "@maximum = uplevel.tagvalue[runtime.carrier?]"

All of this is in fact an improvisation to get around the fact that you cannot use "this.selection" in order to directly control the size of a child unit...


Can you explain the context you used this in? It sounds like it might be the solution to one of the problems I've been wrestling with (trying to control the size of a child unit based on the size of a second "sibling" child unit).

-DaR

---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com)                                 (408) 927-9880
Lone Wolf Development                                      www.wolflair.com
 
I'm actually having a simmilar stumbling block...Two sybling child units where you may have no more models combind then a specific stat in the parent...

For example; Unit A has the stat runtime.carir5
Units Y and Z are children of Unit A
The total number of models in Units Y + Z cannot exceed Unit A's carir stat (in this case 5)...

Is it simmilar for you DaR?
 
Use an exclusion group that is based on the unit stat. Then assign
exclusion references directly to the child units with a "count" of "#".
This will cause the model count of the child unit to be counted against the
exclusion group limit. If the user exceeds the limit, AB automatically
flags a validation error.

-Rob

At 08:50 AM 7/5/2005 -0400, you wrote:

>I'm actually having a simmilar stumbling block...Two sybling child units
>where you may have no more models combind then a specific stat in the parent...
>
>For example; Unit A has the stat runtime.carir5
>Units Y and Z are children of Unit A
>The total number of models in Units Y + Z cannot exceed Unit A's carir
>stat (in this case 5)...
>
>Is it simmilar for you DaR?


---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (408) 927-9880
Lone Wolf Development www.wolflair.com
 
I know it was discussed quite a while ago but howdo you make an exclusion group variable? The problem is, in order to do this I need to make a large number of exclusion groups (as most ships have different "carir" stats) or base it directly on the stat...Personally I would rather then later as it makes it easier to cut and paste...
 
There's a topic (actually, I think multiple ones) that covers exactly this
in the new Kit docs that were just releaed to the Beta team - which
includes you. Please take a look at the new docs, and many of your
questions should now be answered.

-Rob

At 08:50 AM 7/6/2005 -0400, you wrote:

>I know it was discussed quite a while ago but howdo you make an exclusion
>group variable? The problem is, in order to do this I need to make a large
>number of exclusion groups (as most ships have different "carir" stats) or
>base it directly on the stat...Personally I would rather then later as it
>makes it easier to cut and paste...


---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (408) 927-9880
Lone Wolf Development www.wolflair.com
 
Cool! Time to check out the new docs and see if even this bonehead can understand them :)

I checked it out and then remembered that it doesn't do me any good as the model count of a child unit is independant of the selection for the option...*sigh*...back to square one...
 
Back
Top