Multiple Scripting Questions

[FluffyDingo]

Okay, so I've been making/fixing things left and right, but I've run into a couple issues that have ground me to a halt. Hopefully someone can help me out here.

1. Been working on the Multi-Headed template, and it adds 2 additional racial hit dice per additional head. This is the line handling that so far:

field[tmHitDice].value += heads*2

It adds 2 hit dice, but I haven't figured out how to pull the hit die type from the creature's type (both for size of the hit die, and I suspect additional BAB, saves, and skills). This is the theoretical line of code I was using, but "Type" isn't a child of hero I suspect, nor will it provide the BAB, etc, information for the HD either:

field[tmHDSides].value = hero.child[Type].field[tpHDSides].value

2. Also on Multi-headed, it increases CR based on number of heads, and while I have the variable working properly using this:

herofield[tCR].value += cr

It isn't calculating it as a CR modifier from the template, or altering the CR estimation panel accordingly. Since I don't think I can use a script to alter the fields for "CR by HD", I tried to alter the "Minimum CR" it X plus the previous CR, but it didn't actually work. Figured I'd ask if there was an easier way before delving into that further.

3. And finally, making the mythic abilities Mortal Herald and Divine Source display spell-like abilities, is there a Bootstrap Container Requirement Expression that I can use to check if a particular domain has been selected from the list? So, say, only if the "Air" domain has been chosen does it add the particular custom ability to provide those spell-like abilities.

Thanks! Hopefully I included enough info, but happy to provide more if needed.

[Aaron]

Originally Posted by FluffyDingo

Okay, so I've been making/fixing things left and right, but I've run into a couple issues that have ground me to a halt. Hopefully someone can help me out here.

1. Been working on the Multi-Headed template, and it adds 2 additional racial hit dice per additional head. This is the line handling that so far:

field[tmHitDice].value += heads*2

It adds 2 hit dice, but I haven't figured out how to pull the hit die type from the creature's type (both for size of the hit die, and I suspect additional BAB, saves, and skills). This is the theoretical line of code I was using, but "Type" isn't a child of hero I suspect, nor will it provide the BAB, etc, information for the HD either:

field[tmHDSides].value = hero.child[Type].field[tpHDSides].value

Try creating a variable, then foreaching through all the types on the hero that are active instead, and setting the variable to the highest you find.

Originally Posted by FluffyDingo

2. Also on Multi-headed, it increases CR based on number of heads, and while I have the variable working properly using this:

herofield[tCR].value += cr

It isn't calculating it as a CR modifier from the template, or altering the CR estimation panel accordingly. Since I don't think I can use a script to alter the fields for "CR by HD", I tried to alter the "Minimum CR" it X plus the previous CR, but it didn't actually work. Figured I'd ask if there was an easier way before delving into that further.

I believe there is a CR field on the template you can use, instead of adding it to the CR herofield.

Originally Posted by FluffyDingo

3. And finally, making the mythic abilities Mortal Herald and Divine Source display spell-like abilities, is there a Bootstrap Container Requirement Expression that I can use to check if a particular domain has been selected from the list? So, say, only if the "Air" domain has been chosen does it add the particular custom ability to provide those spell-like abilities.

Thanks! Hopefully I included enough info, but happy to provide more if needed.

I think you'd have to bootstrap all possible SLAs with mutually exclusive conditions, and then add a script to the mythic ability which checks for the presence of a certain domain, and if it finds it, does something which fulfills only the condition for the correct ability.

[FluffyDingo]

Originally Posted by Aaron

Try creating a variable, then foreaching through all the types on the hero that are active instead, and setting the variable to the highest you find.

I'm wondering what I would use for code to check the Type of the hero. The hero should just have one primary creature type that I should be able to pull, but I'm not sure how to access that.

Originally Posted by Aaron

I believe there is a CR field on the template you can use, instead of adding it to the CR herofield.

There's "CR by HD" which I am unsure how to edit in an evaluation script, and "Minimum CR", no straight "+X CR" since that is just line 0 of "CR by HD".

Originally Posted by Aaron

I think you'd have to bootstrap all possible SLAs with mutually exclusive conditions, and then add a script to the mythic ability which checks for the presence of a certain domain, and if it finds it, does something which fulfills only the condition for the correct ability.

Currently each domain is a separate custom ability bootstrapped with each spell-like ability, each with a condition that checks for the the particular mythic tier you need to be to cast it. I have a way I can make it work, but checking if the selection against a particular string (each domain), then returning an integer that corresponds to that particular domain. I'd then have to have conditions for each of the bootstrapped custom abilities to check for their unique integer values, but that's a lot of lines of evaluation script to write (145 unique domains/subdomain I believe it was, at 3 lines per). It would be easier if it was possible just to have a condition on each bootstrap to go "Did you select STRING from the Mortal Herald domain list?"

[Aaron]

Originally Posted by FluffyDingo

I'm wondering what I would use for code to check the Type of the hero. The hero should just have one primary creature type that I should be able to pull, but I'm not sure how to access that.

The way types work for herolab is that all of them are on all heroes, but only the ones with a matching tag on the hero are shown. If there are multiple shown, one of them is the primary (usually there are only 2 because a template replaced the previous primary and made it "augmented"). There is a #hasrace macro which works for types as well, but since you need to set the template field early, I don't think the tags it checks for a present yet. Are you familiar with foreaches? They are a way to cycle through all picks of a certain kid that meet some condition.

An example:

       foreach pick in hero from Type where "thing.activated & !Helper.Augmenting"
          DO SOME STUFF TO THE CURRENT PICK
          nexteach

Originally Posted by FluffyDingo

There's "CR by HD" which I am unsure how to edit in an evaluation script, and "Minimum CR", no straight "+X CR" since that is just line 0 of "CR by HD".

Yeah, that's the way. Everything has at least 1 hit die, so anything put in the first row is always added to the CR. Manipulating arrays is a little different than other fields, because you need to specify the row of the array you are changing, like so:

field[FIELDNAME].arrayvalue[ROWNUMBER]

Keep in mind that the first row of the array is Row 0, and the second Row 1, and so on.

Originally Posted by FluffyDingo

Currently each domain is a separate custom ability bootstrapped with each spell-like ability, each with a condition that checks for the the particular mythic tier you need to be to cast it. I have a way I can make it work, but checking if the selection against a particular string (each domain), then returning an integer that corresponds to that particular domain. I'd then have to have conditions for each of the bootstrapped custom abilities to check for their unique integer values, but that's a lot of lines of evaluation script to write (145 unique domains/subdomain I believe it was, at 3 lines per). It would be easier if it was possible just to have a condition on each bootstrap to go "Did you select STRING from the Mortal Herald domain list?"

So if I am understanding correctly, you have made 1 custom ability for each domain, and each custom ability bootstraps a different SLA. When the user chooses the Custom ability they want, the SLA comes along too? If that's the case, then you don't need bootstrap conditions, you can intervene at the point where the user is choosing which custom ability is added. I would add a pair of expr-reqs, one for the minimum tier required, and the other using #hasability[DOMAIN UNIQUE ID] for the associated domain.

[FluffyDingo]

Originally Posted by Aaron

The way types work for herolab is that all of them are on all heroes, but only the ones with a matching tag on the hero are shown. If there are multiple shown, one of them is the primary (usually there are only 2 because a template replaced the previous primary and made it "augmented"). There is a #hasrace macro which works for types as well, but since you need to set the template field early, I don't think the tags it checks for a present yet. Are you familiar with foreaches? They are a way to cycle through all picks of a certain kid that meet some condition.

Ah, so you have to look for active types among all types because all are there, just hidden if they don't match. Yeah, I've done some code work, it's just translating what I know into Hero Lab practicality. A lot of trial, error, and tons of cross referencing going into learning all the details. It's been really fun though, and rather satisfying when things finally work.

Originally Posted by Aaron

Yeah, that's the way. Everything has at least 1 hit die, so anything put in the first row is always added to the CR. Manipulating arrays is a little different than other fields, because you need to specify the row of the array you are changing, like so:

field[FIELDNAME].arrayvalue[ROWNUMBER]

Keep in mind that the first row of the array is Row 0, and the second Row 1, and so on.

Awesome! I should have tried that, didn't even think of it as an array... That answers a lot of potential questions in the future too.

EDIT: Okay, in debug mode I discovered that there's field[tmCRAdjust].value that doesn't have a field in the GUI of the editor, but it works like editing the 0th row of the array with slightly less text than editing the array. I apparently just wasn't doing the right thing to find it the first time, but just a random thing of note. Moral: this now works.

Originally Posted by Aaron

So if I am understanding correctly, you have made 1 custom ability for each domain, and each custom ability bootstraps a different SLA. When the user chooses the Custom ability they want, the SLA comes along too? If that's the case, then you don't need bootstrap conditions, you can intervene at the point where the user is choosing which custom ability is added. I would add a pair of expr-reqs, one for the minimum tier required, and the other using #hasability[DOMAIN UNIQUE ID] for the associated domain.

Each domain is 1 custom ability, each of those abilities bootstraps all 9 spell-like abilities that domain provides via Mortal Herald. Each of those spell-like abilities has a condition that makes to only show up at sufficient tier. The source ability Mortal Herald itself is a separate custom ability, which when selected provides a droplist of deities, then once a deity is selected provides a droplist of domains they provide. Currently I have all of the domain custom abilities bootstrapped to it. An actual domain custom ability is never being selected as I currently have it, just a domain name from a droplist. What I would like is for each of the bootstrapped domain abilities check the droplist for the second Mortal Herald field, go "was this particular domain name selected in this droplist or not?", and if yes it will be enabled. So if the Air domain is selected from the second droplist, it will check the condition to the Air custom ability, say "yes" enabling it, and reject every other domain custom ability condition. I'm not sure if this is possible though.

Basically "add Mortal Herald > select a diety from droplist > select domain from droplist > check each bootstrapped ability to see if it is enabled based on domain name selection" is my current thought.

Originally Posted by Mathias

There's an easier way to look up the number of sides the HD on the race is using, rather than figuring out what type is currently in use, since your goal here is to have the template in effect add more HD to the race, right?

Timing: After First/590

field[tmHDSides].value = hero.findchild[BaseRace].field[rHDSides].value

Sweet, BaseRace was what I was missing! I had just tried using "Race" but it obviously wasn't working.

EDIT: This now adds the proper HD type, but does not increase BAB, saves, feats, and skill points. I hope there's some way to enable this.

Thanks for all the help on this!

[FluffyDingo]

Still hoping for an assist so I can get this wrapped up. Thanks!

[Aaron]

Originally Posted by FluffyDingo

Sweet, BaseRace was what I was missing! I had just tried using "Race" but it obviously wasn't working.

EDIT: This now adds the proper HD type, but does not increase BAB, saves, feats, and skill points. I hope there's some way to enable this.

Thanks for all the help on this!

Is it possible you are setting the number of bonus Hit dice gained too late for them to affect the BAB, saves, etc?

[Mathias]

There's an easier way to look up the number of sides the HD on the race is using, rather than figuring out what type is currently in use, since your goal here is to have the template in effect add more HD to the race, right?

Timing: After First/590

field[tmHDSides].value = hero.findchild[BaseRace].field[rHDSides].value

[FluffyDingo]

What's the latest point I can add Hit Dice and still have them process that info? I'm thinking First 498 is when that is processed, but since maximum number of heads that can be added is based on size, I can't process how many heads are added (and therefor how many hit dice) until First 680.

[ShadowChemosh]

Hit Dice are like "Levels" so it needs them set before Post-Levels. This is why class scripts run mostly at Post-Levels/10000 as all the Level calculations are done.