Replace a Class (or perhaps not)

[JadedDragoon]

The "right" way to "replace" a core class.

tl;dr: What is the "right" way to duplicate a core class in such a way that it can be used as a replacement for that core class without also duplicating every single thing that references that core class?

I'm just now sinking my teeth into Hero Labs, despite having had it for a while, I've never been in a position to use it much. I've built a character or ten with it... but never used it to run one of my campaigns, never mind a combat. I've decided to change that.

I have a custom setting that I have been working on and fine tuning for over a decade. I also have a number of home-brew rules that are thoroughly tested and solve many of my gripes with 3.5 and Pathfinder. Now I want to add these home brew rules to Hero Lab's pathfinder rules. Easy peazy... just make a copy of the pathfinder module under a new name. Done. I thought I'd start simple, combine Swim and Jump into "Athletics". I've considered purchasing the Pathfinder Unleashed module with the combined skills... but I only intend to merge just these two skills. And I'm not fully in agreement with the way combined skills work. Group skills fall even further from the mark. Plus I'm going to add back the Search skill and replace Diplomacy with my own, entirely custom Diplomacy skill anyway. So what the heck, I'll add this myself.

And that was easy. Make a copy of the Climb skill. Change the name. Give it a unique identifier. Copy some of the rules text from Swim to it. Done. Great. Now I need to make it a class skill for this Fighter in our group... oh look, I can make it automatically a class skill anytime swim or jump are. Nifty. Except... that means Climb and Jump are still class skills. That's no good. And what about all the other stuff that keys off Swim and Jump having X amount of ranks? Well ok... one problem at a time. How do I make this a proper class skill... copy the classes I use? That's ok... done. Wait... now my new fighter class has no archetypes. I can fix that... but then... what about all the other stuff that's keyed to the fighter class?

Oh look! I can make my thing replace another thing! Ok so the original fighter class has id cHelpFtr. Just put that in and... viola that did it, everything is all better now! Wait... why am I getting this run-time error when I go to add levels? Aaaand Hero Lab crashed. Blah!

And that's where I'm at.

And this is literally the smallest change I need to make. When it comes time to do my home-brew health and healing rules I'll be fundamentally re-writing one of the core components of 3.5/Pathfinder. Fortunately I was careful to keep my home brew rules as compatible as possible with whatever expansions I might run into... but still... it's going to be a chore... especially if I'm fighting uphill battles like this one over even the smallest change. :-(

So tell me, where did I go wrong. And what can I do to avoid it moving forward?

For reference, here's the error(s).

Invalid tag expression specified for 'foreach' statement
Location: 'pre-requisite rule' script for Component Set 'ClassLevel' near line 13
- - -
Invalid tag expression specified for 'foreach' statement
Location: 'pre-requisite rule' script for Component Set 'ClassLevel' near line 13
- - -
Invalid tag expression specified for 'findchild'
Location: 'pre-requisite rule' script for Component Set 'ClassLevel' near line 15
- - -
Invalid tag expression specified for 'findchild'
Location: 'pre-requisite rule' script for Component Set 'ClassLevel' near line 15
- - -
Invalid tag expression specified for 'findchild'
Location: 'pre-requisite rule' script for Component Set 'ClassLevel' near line 13
- - -
Invalid tag expression specified for 'findchild'
Location: 'pre-requisite rule' script for Component Set 'ClassLevel' near line 11
- - -
Invalid tag expression specified for 'foreach' statement
Location: 'pre-requisite rule' script for Component Set 'ClassLevel' near line 13
- - -
Invalid tag expression specified for 'foreach' statement
Location: 'pre-requisite rule' script for Component Set 'ClassLevel' near line 13
- - -
Invalid tag expression specified for 'findchild'
Location: 'pre-requisite rule' script for Component Set 'ClassLevel' near line 15
- - -
Invalid tag expression specified for 'findchild'
Location: 'pre-requisite rule' script for Component Set 'ClassLevel' near line 15

My customizations are attached:

 

[JadedDragoon]

I've done some more tinkering, starting over I attempted to make a replacement class for fighter without using the replace thing box. I copied the fighter class, set "Use archetypes for X", "'Counts As' Classes (Feats)", and "'Counts As' Classes" to the original fighter class. And made several of the needed changes.

Then I added a level of my new custom fighter class to a new character. Everything seems to be working... except archetypes. It flags the archetype I'm using (Two-Handed Fighter) with the message "Linked Class Required" and none of the Two-Handed Fighter abilities are showing up.

I take "linked class" to be a reference to either "Class Helper Linkage" or "Class Helper Bootstrap" from the assicated class level... but changing these to "Fighter" defeats the whole purpose. So then what the hell is the "Use archetypes for X" setting for? I thought it meant that my new class could use the same archetypes as the selected class... but apparently not.

My new user file:

 

[ShadowChemosh]

Archetypes are you answer here which should be used to modify the base class for your houserules. You can add or remove abilities you don't want and you can prevent issues where the Base classes Unique ID is being changed.

Once you get into more advanced features like sources and mechanics you can use them to automatically apply your houserules archetype to the base class for players. Until then they will have to manually add the archetype.

This is easy way to prevent all the errors you are running into.

I can show you an example HERE from my own houserules data set. But I would work on getting the archetype working first then work on auto-applying it when a class is taken.

 

[JadedDragoon]

Thanks for the reply. I had considered trying that but managed to convince myself it wasn't the correct route. I'll give it a go.

Question, what if I also plan to use another archetype as well (Two-Handed Fighter, in this case)? Only one archetype is allowed normally, correct? Will I need to create mechanics to override that limitation for my custom-archetypes only? Or will I have to create a home-brew variant of every archetype?

Suspecting the latter outcome was my reasoning when I decided to try to recreate it as a base class instead. Though given how far down the rabbit hole I'm now getting as I chase incompatible features and skills an the like... that outcome might still be the lesser evil.

EDIT: Nope, just went back and checked the rules. Can have as many archetypes as I please. Also, I tried your suggestion and it's working perfectly... which makes me feel quite silly for wasting 3 days trying to do it the other way when 15 minutes was all I needed to get it working this way. Live and learn I suppose.

 

[Minous]

There are no limits to the number of archetypes a character can have. The only limiting factor is that no two archetypes can remove/modify the same class ability.

 

[Minous]

JadedDragoon, if you want to chat, I can see about walking you thru some of the basic changes you are wanting to do.

 

[JadedDragoon]

Hmm, chat? There an IRC or something I missed?

Actually I keep looking at this and thinking I may want to stop trying to get an easy win, man up, and do it "the right way" from the start... by which I mean stop trying to take a shortcut by implementing the changes I want per-class and do it via mechanics or something. Even with what ShadowChemosh suggested, I'd still need to make a separate archetype for every core class and any others I'm likely to use in the foreseeable future. And that doesn't even take the bestiary into account.

Basically, all classes (and monsters) lose climb and swim in favor of a single athletics skill. If the class originally had swim as a class skill, it gets a feat called "Athletic Proficiency - Swim" that allows it to use its class skill bonus on swim checks (normally it loses it for swim checks). Same with Climb. Most classes will end up getting both feats or neither but a rare few get only one or the other. Jump remains part of acrobatics.

The point is just to not have to put ranks in both climb _and_ swim. They improve together. That's always bugged the hell out of me. Both are skills you can learn in a day (in other words... a feat). The rest is practicing your form or identifying stable hand/toe holds and building upper body strength. Balancing this is the fact that I give _every_ class Perception as a class skill (because I tend to be quite ham-fisted with perception checks... and it ends up a save-or-die every now and then).

I had been thinking I would look for a way to hide the swim and climb skills on the character sheet and stat blocks but keep them on the classes... use a script to make them match the number of ranks as athletics, and remove/add Helper.ClassSkill based on the presence of the feats. This would also preserve them for swim-specific and climb-specific bonuses from feats, spells, and abilities.

Regardless, none of these changes are actually class specific. When I was developing these house-rules I tried to keep things simple and such that they would be compatible with any modules I decided to use in the future. Now that I want to use Hero Lab I was trying to jerry-rig it well enough that I could start using Hero Lab in the session I have planned for 7 days from now. Failing that, no later than the one 14 days after that. And then go back and "do it right" once I didn't have a dead line. But it's becoming clear that, in Hero Lab, jerry-rigging creates more problems than it solves.

 

[JadedDragoon]

Well, definitely making progress.

I decided to try implementing the Athletics changes via a mechanic with the following eval script at "Final Phase/20001":

var athlVal as number
athlVal = hero.child[skELDAthletics].field[skRanks].value

~ For other Things that may check how many ranks are in the skill.
hero.child[skClimb].field[skRanks].value = athlVal
hero.child[skSwim].field[skRanks].value = athlVal

~ Because the skRanks field doesn't affect the skill mod and we can't
~ set skUser from scripts.
hero.child[skClimb].field[Bonus].value += athlVal
hero.child[skSwim].field[Bonus].value += athlVal

if (hero.child[skClimb].tagis[Helper.ClassSkill] > 0) then
    ~ don't work
    ~perform hero.assign[Ability.fELDFeatProfClimb]
    hero.child[skClimb].field[skClsSkBon].value = 3
endif

if (hero.child[skSwim].tagis[Helper.ClassSkill] > 0) then
    ~ don't work
    ~perform hero.assign[Ability.fELDFeatProfSwim]
    hero.child[skSwim].field[skClsSkBon].value = 3
endif

And it works... sorta. For starters I can't figure out how to conditionally add the feats. I'm aware of "containerreq" but there I find myself with a catch 22. Something is running scripts on my feats at "First/2380" but the ClassSkill.skClimb and ClassSkill.skSwim tags don't get added to the hero till sometime in the "Levels" phase. And I'm beginning to doubt they can be added without bootstrapping. Maybe something with gadgets? I'll have to research more.

The other big problem with the above script is that setting the value of the skRanks field doesn't get calculated in to the final skill mod result. skUser might... but trying to change that gets me an error about only modifying derived fields. I've tried setting the eval script to run as early a "Post-Levels/100" without the issue resolving. Any earlier than the "Levels" phase and the changes of my script seems to get overridden. So I change the skRanks and the Bonus fields. It looks effed up in the tooltip for the skills... but otherwise gives the correct result. No idea what kind of problems it might cause.

Finally, still can't figure a way to make the climb and swim skills not show but still be accessible to scripts. Making them non-live makes them disappear... but also prevents reading and writing to them.

Still open to advice.

 

[Minous]

If you look at the "Debug Tasks" of a skill you can get a sense of where things are getting modified. With your feats I would bootstrap them with conditionals.
Because of the way your writing the skill you might want to write each of its parts as different scripts within the same thing, and then just adjust the timing on each part as needed.

If your looking to hide it from the user but keep it functional try:

thing.assign[Hide.All]
thing.assign[Hide.Statblock]

 

[JadedDragoon]

Thanks for the info. I did manage to resolve the issue with skill ranks by running that script at exactly Post-Levels/9000. Any earlier and the skRanks Field gets overwritten. I also switched to testing against the 'ClassSkill.<skillid>' tags on the hero... which lets me make that test as early as (surprise!) Post-Levels/9000.

I had suspected there would be something like the Hide.All tag... but I couldn't find anything in any of the documentation. Is there a standard place to look up tags and tag groups in the editor/main gui?

That said, I haven't been able to get Hide.All to work. I've tried every listed task priority in the task list for the associated skills with no apparent result.

Here is my task list for the skills in question (the other is identical):

Here are the scripts I am currently running:

And here are the resulting tags list for those skills:

And the result:

Haven't tried tinkering with bootstraps for the feats again yet. That's next on my list.

 

[JadedDragoon]

With your feats I would bootstrap them with conditionals.

This is what I get when I try bootstrapping the feats.

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

Thing 'ELDAthletics' - Condition phase/priority (PostLevel/9001) for bootstrap thing 'fELDFeatProfClimb' occurs after earliest rule/script (First/2380)
Thing 'ELDAthletics' - Condition phase/priority (PostLevel/9001) for bootstrap thing 'fELDFeatProfSwim' occurs after earliest rule/script (First/2380)

For whatever reason these feats _must_ be bootstrapped before First/2380... but the conditional I need to check isn't available till Post-Level/9000. Like I said before, it's a catch 22. How do I get around this?

EDIT: the more I think about ti the less this problem makes sense to me. Class levels aren't handled till the Levels phase. So before that... it should be impossible to know what class features (such as weapon proficiency) the hero should get... but this makes it seem like you would have to know what class feats the hero gets before the hero even has a class.

So obviously there is a trick here that gets around the problem.

 

[JadedDragoon]

After splitting off two threads (here and here) to resolve the two remaining problems... I have a working athletics skill. I've attached it in it's own user file below for reference.

Again, I'd like to say thank you again to everyone that has offered advice. Especially the legendary ShadowChemosh who has been ridiculously patient and helpful. Thank you.

I've also been completing other parts of the house rules that have not managed to stump me in parallel. And now have almost all my house rules implemented (i think). The big one, the one that's probably going to kick my ass for real, is what's left: Health and Healing. It's not so much a homebrew rule as a complete overhaul of how damage is handled though out 3.5 and Pathfinder. If anything is going to run face first into a brick wall of "Hero Lab doesn't support that" this will be it.

Sooo... sorry in advance when I come hat in hand to the forums with whatever that problem ends up being.