2 scripting questions.

Dwane Diblie · August 8th, 2009, 03:47 AM

Hi,

First a quick one. Is it posable to change/edit the abreviation of an option in a similar way to changing the name of the option using a script?

Secondly, How would I go about assigning a stat to a child unit when I do not know the child units name. I can do it when I know the name but I was hoping for a script that can find the name of the child unit and then apply the stat change to that unit. Or alternatly I can provide the name through a blank option that is conected to the option that that is looking for the child. I can do all of this if I know all child entry already and that would meen writing alot of different options for the same thing just so I can asign it to different children.

Thanks.

Oh and good job on 3.2, but is there a way to bring back the old tab system for the options?

rob · August 8th, 2009, 02:38 PM

Quote:

Originally Posted by Dwane Diblie

First a quick one. Is it posable to change/edit the abreviation of an option in a similar way to changing the name of the option using a script?

No. This has never been asked for, so we never thought to add it. :-(

Quote:

Originally Posted by Dwane Diblie

Secondly, How would I go about assigning a stat to a child unit when I do not know the child units name.

You can't key on the child unit's name - only the unique id. It sounds like you are trying to solve a problem using a technique that AB doesn't support. Please outline the actual *GAME* mechanics that you are trying to solve. Then we can perhaps suggest an alternate approach that will work smoothly within AB.

Quote:

Originally Posted by Dwane Diblie

Oh and good job on 3.2, but is there a way to bring back the old tab system for the options?

The vast majority of users disliked the tabs for the options, and we've received lots of comments about how folks are happy that we've replaced them with the new mechanism. So I can't think of any reason why we would want to switch back to the old tabs mechanism. Please explain how the tabs were better and we can potentially investigate giving users the option.

Dwane Diblie · August 8th, 2009, 03:22 PM

Quote:

Originally Posted by rob

You can't key on the child unit's name - only the unique id. It sounds like you are trying to solve a problem using a technique that AB doesn't support. Please outline the actual *GAME* mechanics that you are trying to solve. Then we can perhaps suggest an alternate approach that will work smoothly within AB.

Yeah, there I go again. Sorry. And to think I re-read it this time before posting to make sure it made sence.

Yes, I actualy ment the Child's Unique Id.

So I have successfuly been able to change the stat of a child unit with.

Code:

this.unit.child[id].stat[id] = this.unit.child[id].stat[id] + val

That dose exactly what I want. So now what I am looking for is a way to have the script get the first child id for me and insert it in to the script. The way I came up with was to have a blank, none visable option and to use to link to change its name to mimic the unique id and then have a script like;

Code:

var line as string
line = this.option[blank_id].name

var long as string
long = "this.unit.child[" & line & "].stat[id]"

long = long + val

but that did not work. So I am thinking I have done it wrong. If this could be achieved then it would save a lot of time coding options that would use this code as I would only have to have one option to do it reguardless of what unit it is attached to.

Quote:

Originally Posted by rob

The vast majority of users disliked the tabs for the options, and we've received lots of comments about how folks are happy that we've replaced them with the new mechanism. So I can't think of any reason why we would want to switch back to the old tabs mechanism. Please explain how the tabs were better and we can potentially investigate giving users the option.

I am just use to it. That is all. I hate trees. Just a personal prefferance thing. Though it would be nice to beable to chose what method I would like to use. Oh and while we are talking about the catagories. I am right in that they cannot recieve encoding? I would have liked to use little Icons for them but no biggie.

Anyway thanks again for all your help rob.
Oh and as for the game system. It is something I am creating myself for me and my friends to play.

rob · August 10th, 2009, 11:47 AM

Unfortunately, you can't synthesize code on-the-fly like you are trying to do. So you haven't done anything "wrong", per se. The technique you are trying simply isn't supported right now.

If you could outline the game mechanics that you've designed that prompted this particular solution, perhaps I could suggest an alternative way to solve the problem. A way that *is* supported by AB. :-)

Starting in V3.2, you *can* use encoded text in option category names. This is now possible because we have abandoned the tabs, which don't support encoded text.

Dwane Diblie · August 10th, 2009, 04:54 PM

Trying to create a unit that has multipule warrior types in it, but all warriors and the unit leader all have to have the same equiptment so I want to select it on the root entity. I was hoping for the root to act like a holding container like how 40k IG works. On selecting it it would ad just the compulsery Leader. Then in the options for the root I would like to select the weapons and armour and any vehicles that belong to the unit as well as how many of warrior type a, b and c I want with the Leader.
So if I wanted to add 4 of warrior A, 3 warrior B and 2 of warrior C the it would look somthing like the following in army builder.

Unit Root. (all unit options are here)
|_Leader. (List of unchangale equiptment)
|_4 Warrior A. (List of unchangale equiptment)
|_3 Warrior B. (List of unchangale equiptment)
|_2 Warrior C. (List of unchangale equiptment)

Now with the options, most will change a stat or 2 of all units in the unit while some only apply to particulay warriors or give different stat changes according to what the warrior type is.

Thanks

rob · August 10th, 2009, 08:52 PM

This is actually pretty easy to solve. It's been done numerous times over the years for different games.

Use the "mirror" and "contingent" attributes on links. Just give the child units *all* the various options, and have each of the options use both "mirror" and "contingent". With "mirror", the option on the child unit matches the parent. With "contingent", the child only possesses the same links that the parent has. Voila! :-)

Another tip: You can use a linkset to define all the options for the child units. Then you can re-use the linkset on multiple child units.

There are lots of ways to skin the proverbial cat within AB. If you give us the overall game mechanic you're trying to model, we can usually point you to a viable way of solving the problem. :-)

Dwane Diblie · August 11th, 2009, 04:19 AM

Ok first I do not know what you are talking about with contingent. But as for the mirroring, how dose that work with a range. I am assuming I have to make the potion a range on the child unit that is doing the mirroring. So if I have 3 of Warrior A with 3 each of Weapon A and Armour A....?

Also with the options applying different stat changes to different warriors?
And controling the number of each warrior type with in the root options list using, once again, a range?

rob · August 11th, 2009, 08:58 AM

Quote:

Originally Posted by Dwane Diblie

Ok first I do not know what you are talking about with contingent. But as for the mirroring, how dose that work with a range. I am assuming I have to make the potion a range on the child unit that is doing the mirroring. So if I have 3 of Warrior A with 3 each of Weapon A and Armour A....?

Mirror doesn't work with ranges, but you do *not* need to use ranges. The only time you need to use ranges is when *less than* the entire unit is able to take a particular option. If the entire unit must take a given option, then do *not* use a range and instead assign the option (or link) a cost of "each". This makes the quantity non-variable - all models possess the option - and properly calculates the cost.

Since all models in the child units must have the same weapon as the parent, this approach will work perfectly for you.

Quote:

Originally Posted by Dwane Diblie

Also with the options applying different stat changes to different warriors?

So the *same* option can apply a *different* change to different units? That's a little odd, but it's doable. You can use a script on the option to determine which unit it's assigned to. This can be most easily done via tags. Based on the type of unit, the option applies a different stat change to some units.

Quote:

Originally Posted by Dwane Diblie

And controling the number of each warrior type with in the root options list using, once again, a range?

The parent will use ranges to control the *number* of models in the child units - not the actual options assigned to those units. The actual options that need to be mirrored will not be ranges. So this should work out nicely.

Dwane Diblie · August 11th, 2009, 05:02 PM

Right got most of that. Thanks.

Though

Quote:

Originally Posted by rob

The parent will use ranges to control the *number* of models in the child units - not the actual options assigned to those units. The actual options that need to be mirrored will not be ranges. So this should work out nicely.

How is that done exactly? Every time I have attempted it it fails. Well the range dose not control the child unit count anyway. What I did was to link to an option that has the child unit and apply a range to that option. The child unit has the same range as the option that attaches it to the parrent. But all it dose is turns it on if I have more than 0 units selected. It then has to be manualy altered by its own spinners.