Configurables and Racial Custom Abilities

[Quintain]

Question for the more advanced coders here.

When dealing with a configurable (example the astral suit configurable in the 3PP Ultimate Psionics files), those racial custom abilities are (from what I can see) tied to the configurable by this tag:

<tag group="AllowRCust" tag="cfgPUAstSu"/>

My question is this...given that there are multiple classes and archetypes and now secondary classes that will give access to customizations (for those who don't know, these are synonymous with evolutions for the Eidolon), is it possible to have multiple tag groups that give access to this ability without having to recreate it for every class/archetype/secondary class that exists?

It seems that this method is used for powers, but I'm not 100% positive whether it can be used for racial custom abilities.

 

[Aaron]

Custom specials can be added to both configurables and classes, but racial custom specials can only be added to configurables (and races, as their name implies). If these customizations are intended to be addable to different classes, I would say make them as custom specials.

One thing I did when revamping the eidolon for the unchained summoner was to move evolution selection to a configurable (where they have more space than on the background tab), and had them use the custom specials created for (originally) the summoner Aspect class feature. I'm hoping eventually we'll be able to shift the old summoner over to a similar setup, because as things stand now we need to create every new evolution twice (once for the eidolon and once for the summoner). That's a real pain, and if we can consolidate everything under the custom specials we won't have to duplicate this work moving forward.

 

[ShadowChemosh]

So any Configurable or Class can be scripted to display Any list of Custom Abilities or Racial Custom Abilities. The idea you have to change the Custom Expression its using to build its list.

This is why LW recently made allot of its changes to use the AbCategory.? instead of the linking the Custom Ability to the class. Its basically reverse logic where the Class/Configurable sets the Expression of what to display instead of the Custom Ability figuring out where to display.

For example I started work last night to get the Monk of Four Winds archetype to work with the Unchained Monk. So I had to manually overwrite the 5th class expression as follows:

Final/99999999

      ~ Re-write 5th custom ability expression to allow for the Primary
      ~ abilities of the Monk of the Four Winds archetype
      linkage[varies].field[cCstS5Expr].text = "(SpecSource.arMnkFourW) & !Helper.Secondary & !Helper.Tertiary & !Helper.Quaternary & !Helper.Quintenary & !Helper.Obsolete"]]></eval>

So you just need to set the Custom Expression for your Configurable to the following. Which is easier as the Configurable has a place to just type this in:

(AllowRCust.cfgPUAstSu) & !Helper.Secondary & !Helper.Tertiary & !Helper.Quaternary & !Helper.Quintenary & !Helper.Obsolete

 

[Aaron]

Ah, I guess in answer to your original question, the tag you cite is used while the configurable generates the candidate expressions for each of the tables in it (candidate expressions control what can be added to a table). They basically look for anything with the matching SpecSource or AllowRCust tag to themselves, plus another tag which determines what table the added pick should show in. You can apply multiple AllowRCust/SpecSource tags to the same thing if you want it to be addable to different tables.

 

[ShadowChemosh]

Going forward I am doing my best to change things to use the AbCategory.? or another custom tag. So that it is easier to do the above actually. But some of this stuff was implemented long ago and was never put in with allowing for easy adjustments later.

 

[Aaron]

ShadowChemosh's point about abCategory is a good one. Because of all the mixing an matching of custom specials through various archetypes and hybrid classes, we could no longer rely on the SpecSource + Helper.WHATEVER tags to determine if something was, say, a Shaman Hex vs. a Witch Hex. So abCategory serves are a signal of the type of an ability, regardless of where it is showing up. I'd urge you to adopt such tagging for yourself if you're going to have these abilities show up in numerous places.

 

[Quintain]

Custom specials can be added to both configurables and classes, but racial custom specials can only be added to configurables (and races, as their name implies). If these customizations are intended to be addable to different classes, I would say make them as custom specials.

One thing I did when revamping the eidolon for the unchained summoner was to move evolution selection to a configurable (where they have more space than on the background tab), and had them use the custom specials created for (originally) the summoner Aspect class feature. I'm hoping eventually we'll be able to shift the old summoner over to a similar setup, because as things stand now we need to create every new evolution twice (once for the eidolon and once for the summoner). That's a real pain, and if we can consolidate everything under the custom specials we won't have to duplicate this work moving forward.

Ok, a question then on making this change. Currently customizations are built as racial custom abilities. Is changing them to a class special a matter of editing the xml file and replacing the compset="RaceCustom" field with "ClSpecial", or will they have to be re-entered manually through the editor?

I'm looking to see what level of effort would be to implement.

 

[ShadowChemosh]

Ok, a question then on making this change. Currently customizations are built as racial custom abilities. Is changing them to a class special a matter of editing the xml file and replacing the compset="RaceCustom" field with "ClSpecial", or will they have to be re-entered manually through the editor?

I'm looking to see what level of effort would be to implement.

No need. See post #3 in this thread....

 

[Quintain]

Shadow:

This doesn't seem to be working out. This is probably above my knowledge level of the editor at this point.

Here's what I'm trying to accomplish.

At 3rd level the secondary aegis class gets the form astral suit class ability(cPUAstSuit) ...I have this bootstrapped and it shows up as it should.

At 7th level, the ability to purchase customizations (evolutions) comes into play. The secondary aegis calculates his customization point allocation as his character level -5 * 50%, based on the normal aegis customization point values (these are likely manually inputted). This calculation is exactly the same as that for the unchained summoner and the eidolon evolution points.

The "Allow Secondary Abilities..." selection when I choose Aegis doesn't seem to operate as it "should" (given my limited understanding).

I get everything to show in HL, but when I click on customizations, no list is generated to choose from.

What am I missing? -- will the form astral suit -> configurable -> customization list have to be recreated?

 

[ShadowChemosh]

I get everything to show in HL, but when I click on customizations, no list is generated to choose from.

What am I missing? -- will the form astral suit -> configurable -> customization list have to be recreated?

The rules info is nice but I need to know what your script looks like to help...

 

[Quintain]

Ok, I think I see a mechanical difference between the way I have thing running and the normal aegis class.

With the Astral suit configurable, after you choose the type of suit, you get bonus (free customizations), then under the configurable tab, you are able to select additional customizations.

But under mine, after the astral suit type is chosen, the additional customizations (above and beyond the free ones) that you can select when you are eligible for them (at level 7) shows up under the Aegis class tab.

I think this is where I'm going wrong. Just not sure on how to fix it.

 

[ShadowChemosh]

Ok, I think I see a mechanical difference between the way I have thing running and the normal aegis class.

With the Astral suit configurable, after you choose the type of suit, you get bonus (free customizations), then under the configurable tab, you are able to select additional customizations.

But under mine, after the astral suit type is chosen, the additional customizations (above and beyond the free ones) that you can select when you are eligible for them (at level 7) shows up under the Aegis class tab.

I think this is where I'm going wrong. Just not sure on how to fix it.

So once again I need to see the "scripts" to help debug. If you want to post your whole .user file that is fine also.

I do have to get a community release out today. But if you post it I can take a look during the week.

 

[Quintain]

Ok, I've been able to figure out why I wasn't able to get the configurations to show up under the Astral Suit tab like the normal Aegis class.

I did not know to bootstrap the aegis class helper to the secondary class and then once I entered the eval scripts to grab the class level and derive the number of customization points.

Once I copied that part into the secondary aegis class, it worked like a charm.

 

[Quintain]

However, it seems like my primary class levels aren't applying as secondary class levels in so far as customization pre-reqs are concerned.

Any idea on how to get them to transfer? Eval script?

 

[Aaron]

Add CSCountAs tags to the secondary class (or one of the other appropriate we count our level for pre-reqs of something tags), and then change the expr reqs on the aegis abilities to use the custspeciallevelcount macro instead of levelcount.

 

[Quintain]

I have "ClsCountAs" as the cHelpPU0 (Aegis Helper) already.

I'm not positive if this should be a different value?

 

[Aaron]

ClsCountAs tags are for a different purpose, they don't do anything for custom special pre-reqs

 

[Quintain]

Any idea on what the tag should be referencing? I tried the CSCountAs tag with the Aegis helper and got this error:

Hero Lab was forced to stop compilation after the following errors were detected:

File: COM_3PPPack_PsionicsUnchained - Classes.user (line 29) - Thing 'csPU2Aegis' (dynamic tag) - Tag 'cHelpPU0' not defined

 

[Aaron]

The tag ID will be the same as the Classes tag you want to count as. So if your primary Aegis class adds one "Classes.Aegis" tag per level, you would want to add the "CSCountAs.Aegis" tag to the secondary class.

 

[Quintain]

Nothing I put in with the Tags button in the UI with the values being:

CSCountAs with "Aegis", CHelpPU0" "(helper ID), "CPUAegis" (class level ID), AegisLvls (Custom) -- nothing seems to work.

So, that leaves two options:

I'm not putting the tag in in the right place or the tag value is wrong.

Now, the summoner secondary class gives "Summoner" as the tag value -- which leads me to believe that there is something odd happening with the Aegis class that is preventing this linkage from happening.