• Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.

    If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.

    - The Lone Wolf Development Team

Knowledge skills

S

SeeleyOne

Well-known member
A recent menu array thread got me thinking about how best to handle the Knowledge skills. Truth be told, it is annoying to have to type in the name each time you want one. Added to that, some players cannot spell correctly. :/

If it were possible -- OK, it definitely is possible, but the real question is if it would ever be scripted -- I think that perhaps the best way to handle Knowledge skills is much the same way as they are handled in Pathfinder. That is, to say, they are static skills that are marked with a "Knowledge" tag, which makes them searchable by things like the Scholar edge.

Yeah, an array could work, but a static skill has the following benefits:
1) it is easy to preclude from specific settings
2) it is easier to directly modify by edges, races, etc
3) it is easier to determine if it meets requirements
4) it is easier than scrolling down a menu (which can get REALLY long in some games)
5) it is easier than typing (or mistyping, as the case may be) in the correct term
6) it is easier to recall what the correct term is supposed to be, as it can have its own description

A generic fill-in-the-blank should be used for those that insist in typing it out, for adding new knowledges outside of the editor, and for backwards compatibility with other settings and mods that still use the "old" way. This of course would also have the "Knowledge" tag.
 
Unfortunately, that would go against the Savage Worlds design. The game system itself calls for it to be open-ended. We shouldn't be setting Hero Lab up to work so differently from the game system. Static Knowledge Skills aren't the way Savage Worlds is set up. Also, we'd have to re-write a lot of the existing material, as so much is written to handle the special nature of Knowledge Skills. It would be easier to program and use if they were a static list, but that's not the way the game system is designed. Also, if we left an open-ended choice available, you'd still have to do everything you do now, just with the added work of dealing with it both ways. I don't think it's feasible.
 
I guess you are right that the core concept wants it to be open. It is that I have only really seen very specific knowledge skills being used. Most settings tend to either use the same knowledge skills, or add in a few specific new options.
 
The other issue is that Pathfinder only operates on one "Setting". Savage Worlds has to accommodate anything anybody thinks up.
 
People can make up different settings for Pathfinder if they want to. Many people just use Golarion, but there are many other settings. Midgard is one that is also available in Hero Lab.

Or maybe you mean genre. There are some different genres for Pathfinder but none of them have made it to Pathfinder yet. There are a handful of sci-fi supplements. In August the Technology book will come out, and that will open it up for some official sci-fi stuff.

Either way I am not convinced that is a relevant position. As I said before, regardless of setting I tend to see mostly the same Knowledge skills. I am not convinced that it is a good enough rationale to not be able to have "real" Knowledge skills, as opposed to having to fill them out every single time. It is kind of a minor deterrent to not have Knowledge skills. They get picked on for being able to be diverse.
 
I might suggest that it may be true in your experience that Knowledge skills are limited, but that may also be said of things like Powers in how most folks use/trap them. I can tell you that in the various campaigns I've been in and run we've got players that get quite creative and Knowledge is well used as a way to get those ideas into their characters. Just like we also tend to use the renaming mechanic on Powers to rename them appropriately for our characters trappings on them as well. It's one of the massive strengths, IMHO, of Savage Worlds. I'm with CC on this one that I don't think it's a good idea to try and force limited tables for Knowledge skills. Now if you could have a flexible table that allowed selections or the ability to leave it blank to type your own in then I don't really have any issue with that.
 
I sure it's not doable now, But the skills could of been set up in a similar fashion as Shadowrun were you could pick Knowledge skills, and also regular skills as specialties, if you wanted that able to do so with a check box to activate it. In that manner you could set the optional rule up that's in the main savage world rule book. Then you could add specialties as needed. If you just wanted to use the straight rules you could, but if you wanted to branch out you could with the specialty rule. Like savage worlds does allow you to break Shoot down to Pistols, Rifles etc., but the way it's set up you can't because if you make a new shoot it won't work. But if you had a specialty option you could. I wish there was a way to set it up like that. Adding specialties in the editor in shadowrun is very easy.
 
The structure of the two game system is too different for Skill Specialties to work. Yes, Savage Worlds could be set up that way as well, but at this point it would take such a major re-write you'd basically have to start all over because all the code is based on how it's set up now. The basic idea of Savage Worlds is simplicity. Unfortunately, Skill Specialties is the exact opposite. It would take a complete structural re-write.
 
I do have a fix for this for those that want to implement it in their house rules.

Each new knowledge skill must start with a tag id of skKn and only knowledge skills should have it. Existing edges would need to be fixed so that they can check for the specified skill (whether it be a domain of the generic Knowledge skill or a specific instance). There are not all that many edges that reference it so this is not as daunting a task as one might think.

Anyway, the one fix that needs to be made is the Scholar edge, which specifically does need to know to look for both types. My assumption is that there will be specified knowledges as well as a generic "fill in the blank" (the normal knowledge skill).

For Scholar, the first fix needs to be in the Menu #1 and #2 Tag expressions. Change it to this:
Code: 
thingid.skKn? & fieldval:trtFinal >= 4
The change is that it looks for a wild card, which is why above all knowledge skills need to be the only skills that start with skKn. I suppose that if someone came up with a Kneading skill it would collide with this, but I seriously doubt that such a skill would be used. :D

Pre-Reqs will have a small change. Change the line that says foreach pick in hero where "thingid.skKnow" to
Code: 
foreach pick in hero where "thingid.skKn?"
The second Eval script (the Render one) will need a code such as this:
Code: 
      ~determine the text to append to the name
      var choices as string

      if (field[usrChosen1].ischosen <> 0) then
        if (field[usrChosen1].chosen.field[domDomain].text <> 0) then
          choices = field[usrChosen1].chosen.field[domDomain].text
        else
          choices = field[usrChosen1].chosen.field[shortname].text
        endif
      else
        choices = "-Choose-"
        endif

      if (field[usrChosen2].ischosen <> 0) then
        if (field[usrChosen2].chosen.field[domDomain].text <> 0) then
          choices &= ", " & field[usrChosen2].chosen.field[domDomain].text
        else
          choices &= ", " & field[usrChosen2].chosen.field[shortname].text
        endif
      else
        choices = "-Choose-"
        endif

      ~add the selection to both the livename and shortname (if present) fields
      field[livename].text = field[thingname].text & ": " & choices
      if (tagis[component.shortname] <> 0) then
        field[shortname].text &= " (" & choices & ")"
        endif
I am sure that I am not the only one that would rather just select a knowledge skill and not fill it in. My players will be happier, too. I like options, and this one is a fairly easy fix.
 
Last edited:
Watch out, there are side effects for messing with the Knowledge Skill. There are a lot of places in the code (both base code and the various Setting files) that make allowances for Knowledge Skills that will not work with this structure.
 
And what I meant by Setting is just that. Pathfinder is Swords and Sorcery, period. It's rather easy to come up with a dozen or so Knowledge Skills and have that be your list. You could never get away with that in Savage Worlds. Each Setting would have it's own list. Also, since Savage Worlds is designed around the idea of a limited Skill list, Knowledge is meant to be a catch-all for anything a player wants that's not on the list. It's a completely different design philosophy in the game system itself, not Hero Lab. Savage Worlds is not meant to have a set list of Knowledge Skills. It's supposed to be open ended. Hero Lab was/is coded to match this design.
 
It seems that you are misunderstanding my intent.

As you say, Savage Worlds is all about free-form Knowledge. That is ok, you can keep the Fill-in-the-Blank Knowledge. I never said to take it away, and the example that I showed for a revised Scholar edge allows it.

However, It is clear to me by reading the Savage World rulebook that there are, in fact, predefined Knowledge skills. Two relatively common examples are Arcana and Battle. I admit that a specific knowledge is only shown in the core book for three edges: Soul Drain, Tactician, and Wizard. Three or four archetypes in the SWD use Battle, Arcana, and Science (although in this case I think it is a generic slot for a science).

Mr. Fix It and Gadgeteer are not actually validated in Hero Lab as there is no way of knowing if there is a science skill or not. But it IS possible to make up some as predefined knowledges, and check for those. In fact, my suggestion for this is to extend the wildcard to "skKnS?" and require all predefined science skills to have that.

Do you want Computers in your fantasy game? Probably not. Preclude it, just like everything else that is not wanted is precluded. It is easy to do, probably the easiest "mod" to make. However there is a very high likelihood that the same Knowledge definitions will come up over and over again (Battle and Arcana are two examples). I see those same two popping up in setting books as well. Most settings have some Knowledge skill overlap, and I see no reason to punish people -- there is absolutely no need to have ONLY the fill-in-the-blank version.

I guess we can just agree to disagree here. I don't understand what the big deal is. It seems to me that your real concern is that some things will have to be revised. That is true, but they are easy fixes and I have already started to tackle them all in my house rules.

I am curious what these other problem areas are that you mention. My guess is magic items and creatures, but that is really easy to fix. I will probably just search the source files with Visual Studio to find them. I thank you for the caution but I have to admit that in this case it seems to me to be rather minor concern.
 
CapedCrusader what you is say is correct to a point, In the main book, it does give the optional rule to allow a more narrower skill set. To say you worked no power point option into the program yet just didn't think about the other option is a loss to me. My gaming group liked the idea of a narrower skill set, which the deluxe rules allow as an optional rule. not a house rule. To me the knowledge skill is the same can work the same way. To say Savage Worlds is design that way to me is plain wrong. Yes most is set up that way, but the optional rule is there for people to use if they like, Which means that the game designs knew there would be people that would want to use it. So that's makes it a viable rule and what it sounds like to me is your saying the way we run our game is wrong to the rules.
It says on page 95

Skill Specialization
Savage Worlds skills are intended to be broad, allowing
characters to focus primarily on Edges for customization rather
than multiple iterations of something like Fighting for edged
weapons, Fighting for blunt weapons, etc.
If it’s important to your setting to have more detail, a
character uses his normal skill for one device of choice. When
using any other variation he suffers a –2 penalty.
Gaining an additional specialization counts as raising a skill
below its linked Attribute. So a character can gain two new
specializations with an Advance, or gain a specialization and
increase a skill below its linked Attribute.
Below are skills appropriate for this extra detail and some
example specializations:
• Boating: Powered, Sailed, Steam
• Driving: Hover, Tracked, Wheeled
• Fighting: Axe, Blunt Weapon, Exotic (such as nunchaku;
each is separate), Long blade, Pole arm, Short blade.
• Piloting: Fixed Wing, Rotary, Space
• Riding: Camel, Horse, etc.
• Shooting: Bow, Crossbow, Pistol, Rifle, Shotgun, etc.
• Survival: Arctic, Desert, Temperate

I'm not trying to start any thing, I'm just saying the rules do allow it, if it works for your setting is all. and to not thought about it when you were building the program is a real bummer. Considering that you thought to do the No power point option.
 
Ah, but unfortunately, Skill Specialization is not supported by Hero Lab. It would take a rewrite of the entire Savage Worlds module to accomplish, and it was decided that there wasn't enough demand to allow a rewrite at that level.

That being said, I never said don't do it. I just said be aware that there can be side effects. There aren't a lot of them, but they can jump up and slap you. If you are warned, you have a better chance of identifying the issue faster. Seeley, you seem quick enough that I'm fairly sure you'd roll right through it, but I just want everyone to be aware of the possible pitfalls.

I just keep remembering all the times I had to write code specifically to allow for the open-ended nature of Knowledge Skills. Most of the places had to do with adding additional code to deal with Knowledge Skills rather than making allowances for them in existing code. Most of those shouldn't get in your way.
 
Last edited:
Skill specializations would require some sort of rewrite. I have a couple of ideas, but the best idea that I have is to make it like an edge that has two menus. Those menus would then search its own list of whatever it has. For sanity purposes, I would have the edge be skill specific. So a Fighting Proficiency edge would cover two Fighting weapons, but it could not be one Fighting and one Shooting.
 
Regarding Skill Specialization, a solution dawned on me.

I remembered that you can put a fractional value in for an Edge cost. So make each Specialization be a half of an edge (0.5). This works at creation and during Advancements.

Then you can put an eval script inside a mechanic that checks for them if its source is checked. If the edge is there, the penalty is removed. Otherwise the penalty is applied by the mechanic to eachpick of the weapon. Skill specializations that do not affect weapons are even easier to implement (no mechanic is needed).

It is an easy mod to do, actually.
 
CapedCrusader said:
Also, look at it this way - Skill Specialization makes EVERYTHING as open-ended as Knowledge Skills.
Click to expand...

Maybe. Or "kind of".

It really depends on how you want to implement them. Weapons are an easy division -- but that can be divided by specific weapon, or more broad groups. One-handed weapons and Two-Handed weapons might be an idea, the eval would check for if the weapon requires two hands. But you might just want to use the book's ideas.

For other skills I would be more inclined to have sub-versions. Like for Lockpicking have a traps specialization. For stealth have Pick Pockets and Sneaking.

As I said, the only specializations that the sheet is likely to really care about are where they involve weapons.
 
There are a couple of options on how to make Hero Lab recognize different weapons. Obviously it would depend on how you want to group them.

1. Specific weapon (where the script has to know about each weapon specifically). I do not recommend this.

2. As I mentioned, whether or not the weapon is two-handed. This is how the Divinty Original Sin game does it.

3. Weapon Type. This is the best way, redefine this on the weapon and have it search for that. Since you can make new tags you can define them and then coordinate it with the appropriate Specialization. You might be able to make a mechanic that can redefine this (again, for specified weapons), but if that works like the defined fields in a new Power, it will not work. I tried to make the cost field for the Zombie spell change when the character has the Necromancer edge but it does not allow you to do that with an eval script (and it even told me that on what was going to be a "smart" version of the Zombie power). So you would probably have to use a new version of all of the weapons that use the desired Weapon Type. On the bright side, a Weapon Type can make it easier to look for a weapon that you know how to use.
 
I'm trying to brute force in a specializations system for Interface Zero. What I was thinking of doing was just typing multiple specializations in one skill Domain. That works fine, except that it breaks compare in Edges like Hacker. I was stunned to discover when reading the documentation that there's no "contains" and wild card capability?!?!? So something like this:

foreach pick in hero where "thingid.skIZKnow"
if (compare(lowercase(eachpick.field[domDomain].text),"programming") = 0)


could become

foreach pick in hero where "thingid.skIZKnow"
if (contains(lowercase(eachpick.field[domDomain].text),"program") = 0)


or at least have the ability to do wildcard searches like so

foreach pick in hero where "thingid.skIZKnow"
if (compare(lowercase(eachpick.field[domDomain].text),"?program?") = 0)


Is there a way to convert the text field search into a tag evaluation so I can use wildcards? That would give me the ability to handle the hardest part of specializations. Without that, I would need to count how many instances of each skill shows up and deduct the cost of everything beyond the first one, and then add a flat +1 for the specialization. The most brute force method I've come up with is to simply note the specializations in the character description text and somehow kluge the cost of skills.

I'm wide open to ideas. What I've done up to this point is to make skills non-unique.
 
You must log in or register to reply here.
Back
Top