Overriding things using the Authoring Kit

[phantomwhale]

Dear Hero Lab support,

In an attempt to add code for "Chi Mastery" for Deadlands Reloaded, I've decided I'd need to override the default "skills" used for Super Hero powers. In the basic savage rules, these powers are based off the "SuperPower" attribute, which means they take a major advance to increase the skills as stipulated in the main rules.

But in Deadlands, these power skills are based off the Spirit Attribute, which makes it possible to advance these skills much quicker with the appropriate level of Spirit. So I copied the definitions of the "super power" skills and turned them into the "chi mastery" skills required, based off Spirit.

When I add these into the savage rules set (along with rules written by dartnet) I get errors loading the savage worlds ruleset, as obviously there are existing "super power" skills with the same ID. First thought was "change the unique IDs" on the new "chi mastery" skills. But my second thought was "Deadlands doesn't have super powers, or super power skills", so I don't want these available at all. Otherwise when I add a power to my Chi Mastery hero, they get access to both the "super power" skill for that power, and the new "Chi Mastery" sklll for that power.

Can I "override" skills ? Or is there a better approach to removing unwanted elements from the "Deadlands" herolab setup ?

Thanks,
Ben

[rob]

First of all, trying to crowbar Chi Mastery into super powers is ill-advised. There are some fundamental differences, as you've noted, which make this approach problematic. You'll be much better off creating a new mechanism that parallels super powers in concept and replaces the super powers mechanics with appropriate ones for chi mastery.

I saw a separate post from you that looks like you may have done this, but I haven't looked closely at that post yet.

Everything in Hero Lab needs a *unique* id. Hence the name. It's not possible to have two different things with the identical id, even if one is disabled in some situations. Unless you physically delete the original thing from the data files, you can't use the same id for something else. And physically deleting things is generally a poor approach, since it makes maintaining separate sets of data files more complicated when updates are released to the core files.

Fortunately, there are ways to solve this that are easy to implement. I'll outline each in a subsequent post.

[rob]

If you want to physically remove a thing from access *always", you can use the "hidden" element within a data file. Within the Editor, you can use the "Hidden" tab to add these entries. A "hidden" thing is exactly that - removed from access by the user. All you need to do is specify the unique id of the thing to remove and the compiler takes care of it when you next reload the data files.

This is primarily useful for house rules, where a GM might say things X and Y are forbidden from use in his game. For data files that are to be shared, keep reading.

[rob]

If you want to physically remove a thing from access for specific settings, you can use the "preclude" element in a data file. Alternately, you can use the "Preclude" tab within the Editor. The lone difference between "hidden" and "preclude" is that the "preclude" entry also specifies the unique id of a source. Whenever that source is enabled by the user, the thing behaves as if it were hidden. This makes it possible to omit things only when appropriate. For example, you can preclude the super powers content when the Deadlands Reloaded setting is desired.

When precluding things, you can potentially find yourself with a long list of stuff to deal with. It's much easier to identify the few things that grant access to a mechanism and simply preclude those. For example, with super powers in Savage Worlds, you can simply preclude the arcane background edge. If you do that, all the other mechanics for super powers can never be accessed.

[rob]

If you want to replace the behavior of one thing with different behavior, Hero Lab supports that as well. The obvious approach is to preclude the replaced thing based on a source id and add the new thing as dependent on the source id.

This approach works fine in most cases, but not in some. What if the thing you want to replace is bootstrapped by something else? In that case, the old thing will still be bootstrapped. A simple example is weapons in the d20 system. There are lots of magic longswords that all bootstrap the basic behavior for the longsword thing. If you want to change the damage of all longswords in your game, you would have to replace all those magic swords as well.

Fortunately, Hero Lab has this situation covered. If you want to change the behavior of a specific thing, you can use the integrated "replace" mechanism. To use this, create your replacement thing normally - often as a modified copy of the thing being replaced. Then enter the unique id of the thing to be replaced within the "Replaces Thing Id" field in the Editor (or use the "replaces" attribute in the XML).

Once your new thing is in place, every instance where the replaced thing is referenced is automatically updated to refer to your replacement thing. In the example above, creating a new longsword and specifying that it replaces the built-in longsword will cause ALL longswords to use the new thing you added. Hero Lab does all the work for you to hook everything up properly.

[CapedCrusader]

What if you want to Preclude the same thing in more than one Source?
If I want to Preclude Power Points in both Hellfrost and Deadlands, how is this done? I keep getting a duplicate entry error, like it's only looking at the Unique Thing Id and not the Source Id in the Precludes on load...

[rob]

This is a limitation that we hadn't realized before. We'll see if we can solve this and get it into the imminent V3.7 release.

[rob]

Good news. We were able to get this solved in the V3.7 release that is due out in the next 24-48 hours.

[CapedCrusader]

Very cool!

[tatteredking]

now to figure out how it works thanks rob, this helps me out too!