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]

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.

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.

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]

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.

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".

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]

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

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.

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.

 

[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]

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.

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.

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.

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]

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.

Thanks for bumping this back to my attention. You can't evaluate strings from within the bootstrap conditions, so you're going to have to set the condition to something you can check. Then have the ability which has the SLAs bootstrapped to it check what is selected by mortal herald, and change something to fullfill its own SLA's bootstrap conditions but none else.

But there may be a cleaner way to do this. If I understand correctly, you currently have two links of bootstraps, such that:

Mortal Herald -- bootstrap --> Domain Specific Helper Ability -- bootstrap --> 9 SLA specific to that domain

Perhaps it would be better to break that first link? I am assuming you're programming this in a configurable or some other thing which has several tables available for user selected abilities. In that case, you can have Mortal Herald set the candidate expression of one of the other tables based on what the user has picked (god and domain). If you set the table's candidate expression correctly, there should only be a single Domain Specific Helper Ability which is available to be added through the table, and there will be no need for the conditions on the SLA bootstrap conditions.

 

[Aaron]

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?

 

[FluffyDingo]

Thanks for bumping this back to my attention. You can't evaluate strings from within the bootstrap conditions, so you're going to have to set the condition to something you can check. Then have the ability which has the SLAs bootstrapped to it check what is selected by mortal herald, and change something to fullfill its own SLA's bootstrap conditions but none else.

But there may be a cleaner way to do this. If I understand correctly, you currently have two links of bootstraps, such that:

Mortal Herald -- bootstrap --> Domain Specific Helper Ability -- bootstrap --> 9 SLA specific to that domain

Perhaps it would be better to break that first link? I am assuming you're programming this in a configurable or some other thing which has several tables available for user selected abilities. In that case, you can have Mortal Herald set the candidate expression of one of the other tables based on what the user has picked (god and domain). If you set the table's candidate expression correctly, there should only be a single Domain Specific Helper Ability which is available to be added through the table, and there will be no need for the conditions on the SLA bootstrap conditions.

Hmm, I haven't actually been messing with configurables, since there is no actual example of their construction that I could find when referencing the editor files. I'll take another look at it tonight though and see what I might be able to work up that way. It was a thought that crossed my mind, but I was really hoping I could get away with the simplicity that the string reference in the bootstrap condition would give.

I've been trying to stick with the original code for Mortal Herald, and just add to it, but it might be time to jump off that haha.

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

Thaaaaaaaat.... Okay, I should have thought of that.

 

[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.

 

[FluffyDingo]

Alrighty, real life intruded, but now I'm back at this. Almost have Multi-Headed done. I had to take off the hard cap on number of heads that could be added based on size, since I have to add those heads (the 2 HD per head really) before I can even check the size in order to have the BAB and other HD derivative stats calculate. As is, I just need to know how to throw an error from an evaluation script. A la:

if ((herofield[tSize].value <= 0) & (field[abValue].value > 1))
return an error

where abValue is the number of heads, since a medium or smaller creature can only have one additional head added to it.

 

[Mathias]

if (herofield[tSize].value <= 0) then
  if (field[abValue].value > 1) then
    return an error

 

[Mathias]

Eval Rules do the same things as eval scripts, and can also report errors.

 

[FluffyDingo]

What I need is the code that throws the error. "Return an error" was my placeholder, but is not what registers it as an error.

 

[Mathias]

In that case, you'll want to turn the logic around, so that you can turn it valid if both tests pass, since Eval Rules start out invalid by default.

validif (herofield[tSize].value > 0)
validif (field[abValue].value <= 0)

Since both need to be true in order for it to be valid, if either is false, then it's invalid.