Lone Wolf Development Forums  

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

Notices

Reply
 
Thread Tools Display Modes
stubbdog
Member
 
Join Date: Dec 2006
Posts: 54

Old August 29th, 2007, 11:20 AM
Can an override be figured at the time of model choice?

That is, I have a model that would have a nested override:

if roster.faction then
model is can be either a soldier and/or a solo. But, as a solo it costs 15 more points.

The first part of that equation is easy, just throw in:

<override index="0" group="type" empty="yes">
<condition>roster.faction</condition>
<tagover id="Tgrunt"/>
<tagover id="Ssolo"/>
</override>

But, I am not sure how to pull off the second part. The 15 point penalty only applies to the solo, not to the soldier (or whatever the model happensto hae been before). So, I cant just say:

<condition>type.Ssolo</condition> cause by definition of the override, that would be true no matter if it were fielded as a solo or not.

Anyone have a suggestion, other than simply creating a second datacard to handle them individually?
stubbdog is offline   #1 Reply With Quote
Mathias
Senior Member
Lone Wolf Staff
 
Join Date: May 2005
Posts: 13,207

Old August 29th, 2007, 10:08 PM
Actually, overrides aren't where you want to be looking for this functionality. What you want is an option. At first glance, what you want to do is code in an Eval script.

First, here's something from the manual on how to check if you're a top-level unit (which would be the case for solos or leaders, but not models added to a leader)

if (entity.tagis[runtime.child] = 0) then
~apply effects
endif

So, if the unit is a solo, then you remove the Tgrunt tag, add the Ssolo tag, and add 15 to the cost. Or, vice-versa if you want the higher cost to be what shows up on the unit s\election window.

If you want the option to display whether the unit is a solo or troop, you can alter the option's name in the script, so that it is named "Grunt" when the model is a grunt, and "Solo" when it's a solo. On the other hand, you could simply have the option hidden at all times to keep it from cluttering everything up.
Mathias is online now   #2 Reply With Quote
stubbdog
Member
 
Join Date: Dec 2006
Posts: 54

Old August 30th, 2007, 09:01 AM
Sounds like a plan. I will definetly try that.

Question..

one of my weaknesses is that I am not really a programmer and I kinda fumble my way along. Do, I put it just like you have it there:

(entity.tagis[runtime.child] = 0)

or do I need to be swapping out variable names or something?


That and I figure the adding the 15 points to the cost is simply going to be some sort of equation of x = x + 15
stubbdog is offline   #3 Reply With Quote
Mathias
Senior Member
Lone Wolf Staff
 
Join Date: May 2005
Posts: 13,207

Old August 30th, 2007, 05:14 PM
I just cut and pasted the if/then from the manual. Didn't try it yet myself, but it looks complete.

Here's what's supposed to happen: transfer to the entity context (the entity that contains the option this is on), then, ask the question; does it have the tag runtime.child? (is this a child unit?) If no (=0) then run everything inside the if statement.

The cost will be in a cost script. Use the same if/then statement, and inside;
@single = 15
Mathias is online now   #4 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 08:19 AM.


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