Catch 22 with bootstrap condition priority.

[JadedDragoon]

This was original part of another thread that evolved into an entirely different question and diverged into multiple questions. Since that thread is no longer generating responses and the question at hand is radically different from the one I started the thread with, I'm making a new thread here.

So here's the problem: I need to add a class feat to all heroes based on whether or not they have a specific skill as a class skill (by any means, including feats/abilities/adjustments that make a cross-class skill into a class skill).

To quote myself:

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

The Helper.ClassSkill tag can be added to a skill pick as late as Final/20000 and at the earliest Final/1000. the ClassSkill.<skilltag> tag can be added to the hero container as late as Final/1000 and as early as PostLevels/9000... both that only indicates if the class skill comes from the hero's classes or feats (an acceptable limitation if it comes to it. The problem is that, apparently, any feat bootstrap must occur before First/2380.

That means that for the bootstrap condition to compile I must run the bootstrap condition before First/2380 but for the bootstrap condition to be able to check what it needs to check I must run the bootstrap condition after PostLevels/9000. "before First/2380" and "after PostLevels/9000" are mutually exclusive. Ergo, catch 22.

So my questions are thus:

1. Is there a smarter way to "preserve" the class/cross-class state in keeping with Pathfinder rules that would also work better with Hero Lab? (special abilities or somethign, i duno)
2. Is there a way to add a feat to hero based on having a specific cross-class skill?

 

[Mathias]

Check out ShadowChemosh's recommended method in your other thread - this catch-22 is why we designed that functionality, and why we did not implement the consolidated skill rules by making skills turn non-live.

 

[Minous]

Or you could always add the feat, get the class skills added, and then either hide or keep the feat.

 

[JadedDragoon]

Miscommunication is such a PITA. It just screws up everything. And I fear there might be a little miscommunication going on here so... allow me to clarify some important points.

My goal is NOT "Combine Swim and Climb into Athletics". That is not my goal. It's one part of my goal. The guiding focus of my goal, even. But it is not the entirety of my goal. I'm a detail oriented guy. I tend care as much about how I get the to end result as the end result itself... especially when there are complex interactions between dozens of different rules that I wish to account for in specific ways.

My goal, to quote myself again, is as follows:

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.

This is a "house rule" (one of a dozen or so) that I have been using for over a decade, first on 3.5... and now (with slight modification) on Pathfinder. It's "battle tested", consistently compatible with modular content, and both I and my players understand it's implications well. I am not at all interested in fundamental changing these rules. What I am interested in is implementing these rules in Hero Lab.

I do realize that I've a lot to learn about how Hero Lab works and I am grateful to have knowledgeable people like yourself and ShadowChemos around to help me when I get stuck. Something that's going to happen a lot here at first because I'm trying to go from barely having tinkered with Hero Lab to being able to make it stand up and dance a merry jig in a couple of weeks time. But, as immodest as it might be to say this, I also know I can do it. I taught myself HTML, PHP, CSS, SQL, and Javascript in a month so I could build a custom website for a client. ::shrug:: I'm smart. That and $5 gets you a burger.

I have already implemented most of this house rule myself. When I add ranks to my new Athletics skill pick on the hero... Swim and Climb picks on the same hero go up an equal number of ranks. When the hero has the ClassSkill.skSwim or ClassSkill.skClimb tag (or the skSwim pick or skClimb pick on that hero has the Helper.ClassSkill tag more than once) I ensure the appropriate skill pick has it's skClsSkBon field set to 3.

As of starting this thread what remained was:

1. hiding the the Climb and Swim skills from the UI and printout
2. added the appropriate athletics proficiency feats to remind the players when they do and don't get their class skill bonus to athletics checks.

So I created one thread for each of those two remaining problems. While I never really received an answer on how to accomplish the former I did get advice that brought me close enough that I stumbled across the existence of the Hide.Skill tag. (I would still very much like a way to list all tags).

So now the skill hiding problem is solved... that leaves only the feats. If the bit with the feats simply can't be done as I described above and there is no way to create a reasonable analogue for it... then I will simply have to tell my players to write in the feats on their character sheet and try add them appropriately to my notes as DM. Detail-oriented and compromise-averse as I may be, I understand the value of admitting defeat and moving on. But I'm still going to put forth my best effort to accomplish it before I throw in the towel.

As I mentioned, I've found it's very much worth while to clarify when I suspect there is miscommunication afoot. Hopefully this will help.

 

[Farling]

Since the athletic proficiency swim/climb will be automatically added, you could code them up as merely special abilities rather than feats. The special ability can then update the tool tip of the athletics skill to indicate a situational bonus.

 

[JadedDragoon]

Or you could always add the feat, get the class skills added, and then either hide or keep the feat.

That's definitely an option. One I've asked about before. But, I can't find any documentation on how to hide things outside of making them non-live... which has the exact same problem as bootstrap conditions (and the additional problem of making those picks inaccessible to scripts... thought that doesn't matter here).

Me wanting a list of tags is pretty much exactly because I keep needing to do things I'm nearly certain can be done but can't find documentation on. I don't even need a description of how the tags are used. If I at least have a decent starting point I can trial and error the most likely ones till it works.

Since the athletic proficiency swim/climb will be automatically added, you could code them up as merely special abilities rather than feats. The special ability can then update the tool tip of the athletics skill to indicate a situational bonus.

I'll look into that, thank you.

 

[JadedDragoon]

On a whim I decided to just try using the Hide.Feat tag and see if it worked. It did. Problem solved.

To expand on this just a bit, I bootstrapped the two feats with no condition, then used the Hide.Feat tag to hide them by default. Then I remove the Hide.Feat tag from them if the associated skills become class skills. The feats themselves have no logic of any kind. No special tags or fields. They are purely notational. So this works wonderfully.

On an aside, I'm really curious why no one seems to want to share the presence of Hide tags with me. They aren't documented anywhere that I can find... and they were a ready solution to both of my remaining problems. It's not that I don't appreciate the help I've been getting but it's just... odd... that such a simple and obvious solution never got suggested despite me specifically asking if such was possible multiple times. Is there a reason why it's unwise to use the Hide tags?

 

[Minous]

On a whim I decided to just try using the Hide.Feat tag and see if it worked. It did. Problem solved.

To expand on this just a bit, I bootstrapped the two feats with no condition, then used the Hide.Feat tag to hide them by default. Then I remove the Hide.Feat tag from them if the associated skills become class skills. The feats themselves have no logic of any kind. No special tags or fields. They are purely notational. So this works wonderfully.

On an aside, I'm really curious why no one seems to want to share the presence of Hide tags with me. They aren't documented anywhere that I can find... and they were a ready solution to both of my remaining problems. It's not that I don't appreciate the help I've been getting but it's just... odd... that such a simple and obvious solution never got suggested despite me specifically asking if such was possible multiple times. Is there a reason why it's unwise to use the Hide tags?

Its not unwise, because the current documentation is how do you say, Less than optimal? None of us have them handy and are going from memory. I know I can reference concepts but I wont provide exact code snippets unless I have the editor available. Often the easiest way to figure something out is to look at something similar and modify it to suite your needs. Also remember that others will read these issues later looking for guidance when they want to do something similar, so ensuring that code examples are valid is important.

 

[JadedDragoon]

Its not unwise, because the current documentation is how do you say, Less than optimal? None of us have them handy and are going from memory. I know I can reference concepts but I wont provide exact code snippets unless I have the editor available. Often the easiest way to figure something out is to look at something similar and modify it to suite your needs. Also remember that others will read these issues later looking for guidance when they want to do something similar, so ensuring that code examples are valid is important.

Good points. I've noticed the "sub-optimal" nature of the documentation. I suppose that's just an unfortunate and unavoidable reality for small closed-source projects like this. None the less, thanks again for the help.

 

[Toblakai]

Good points. I've noticed the "sub-optimal" nature of the documentation. I suppose that's just an unfortunate and unavoidable reality for small closed-source projects like this. None the less, thanks again for the help.

Not sure why you bring up closed-source vs open source. But in my experience open source projects are typically documented even more poorly.

 

[JadedDragoon]

Not sure why you bring up closed-source vs open source. But in my experience open source projects are typically documented even more poorly.

This is getting off topic, but to clarify... with open source the code itself can be used as documentation for those who know the languages used. And absolutely anyone can write documentation for the app based on this... it doesn't have to be the developers. Which lets the devs continue focusing on the app itself.

I'm no open-source fanboy. But there are pros and cons to both open and closed source. It being entirely on the Devs to write any documentation is one of the cons of closed source.