Cutting feat taxes

[wdmartin]

I have a new GM who is using a bunch of rules modifications spelled out in this blog post:

http://theworldissquare.com/feat-taxes-in-pathfinder/

Basically it eliminates or consolidates a whole lot of feat taxes.

Has anyone implemented this particular set of homebrew rules before?

Some of them are pretty easy to fix using adjustments. Others are straightforward to fix using the editor. And some of them are notably complicated.

If somebody else has already implemented these in HL, I'd rather just use their work. If not, I'll take a crack at it, even though it'll be seriously pushing the bounds of my data-file authoring knowledge.

 

[wdmartin]

Well, I've launched into implementing the rules in the blog from post #1. I tackled Weapon Focus first. The blog says:

Combat feats like Weapon Focus now apply to weapon groups instead of a specific weapon by default.

I fired up the editor and made a copy of Weapon Focus. Happily, it seems that the code to make this happen is already built in! There's a feat Martial Versatility which makes this exact change to the rules. Weapon Focus checks for the relevant tags to see if the character has that feat, and applies it to the weapon group if so:

if (tagcount[Hero.MartVersa] + hero.tagcount[Hero.MartMaster] <> 0) then

Since this is supposed to be the default behavior now, I changed this to always execute:

if (1 <> 0) then

And it worked! Hooray, bounce bounce.

But ... if you don't have proficiency with a weapon, and this script gives you weapon focus, HL quite logically throws an error. For example, a wizard with Weapon Focus (club) who picks up a warhammer will then get an error about having weapon focus without proficiency.

The blog post is silent about what happens if you lack proficiency with a weapon in a group that you have focus in. I'm assuming that if you lack proficiency, you cannot gain weapon focus.

I've just spent three hours banging my head against figuring out how to detect whether the character has proficiency. Here's the original unmodified loop from Weapon Focus that I'm working with:

        foreach pick in hero from BaseWep
          if (eachpick.tagmatch[wFtrGroup,wFtrGroup,initial] <> 0) then
              perform eachpick.assign[Broadcast.WepFocus]
              perform eachpick.pulltags[WepFocus.?]
            endif
          nexteach

Between looking at a bunch of other feats and some reading in the manuals, I've determined that I can test for proficiency with something like:

tagis[WepProf.wWarhammer]

I've also determined that I can get the ID of the weapon currently being iterated over using eachpick.idstring. Then all I need to do is add a nested IF that checks the hero to see if they have the WepProf.whatever tag, and only proceed if they do.

So ... how do I put these things together? So far all of the following have failed:

~ This turned out to be a wildcard, not subbing eachpick
if (tagis[WepProf.?] <> 0) then

~ eachpick is not defined on WepProf
if (tagis[WepProf.eachpick.idstring] <> 0) then

~ weapon is not defined on WepProf
var weapon as string
weapon = eachpick.idstring
if (tagis[WepProf.weapon] <> 0) then

~ invalid tag syntax
var weapon as string
weapon = "WepProf." & eachpick.idstring
if (tagis[weapon] <> 0) then

I've got the tag, and the ID. How do I put them together? I've spent ages dredging through the help files, the authoring kit wiki, and assorted posts on this forum, with no luck. It seems like such a basic thing to want to put together a tag and an ID like this, but I can't find the syntax for the life of me.

 

[Aaron]

Depending on the timing you are running the script, there should be a tag on the weapon which marks it as proficient. If that isn't present, don't apply the weapon focus tag.

 

[wdmartin]

Interesting. What's the tag called? Or how do I find out what tags are on the thing?

If this were PHP, I would just feed eachpick into var_dump and have it send the output to the Debug pane. Is there an equivalent in Hero Lab?

I'd love to be able to do that in Hero Lab -- send the structure of eachpick (or whatever) to the Debug palette. Half the time I'm just guessing as to what tags/things/picks I should be referring to. Just having the ability to make it tell me what's available within a given thing (in the non-technical sense of "thing") would be soooo helpful.

 

[Mathias]

Develop...Enable Data File Debugging, then right-click the item.

Please remember that there are several scripting resources available here: http://forums.wolflair.com/showthread.php?t=53560 and that most of them tell you how to debug and look at the tags.

 

[ShadowChemosh]

I would recommend reading the Glossary of Terms for the Editor. Then check out FAQ#2 for all the places to learn about the editor including YouTube videos.

 

[wdmartin]

Thanks. It looks like the tag I'm after is Helper.Proficient. In my test wizard, I can see this tag on a club (correct) but not on a warhammer (also correct).

In the script, I added a couple of debug lines to the foreach loop:

debug "Weapon: " & eachpick.idstring
debug "Proficiency: " & eachpick.tagcount[Helper.Proficient]

The theory was that tagcount should return a number higher than zero if the tag is present on eachpick. But the debug window tells me:

**********  Start Evaluation Cycle  **********

[Wizard 4.1] Weapon: wClub
[Wizard 4.1] Proficiency: 0
[Wizard 4.1] Weapon: wWarhammer
[Wizard 4.1] Proficiency: 0

This felt like an issue with timings. The script was running at Pre-Levels 5000, and when I checked the task list, it looks like the Wizard Weapon Proficiencies were happening around Pre-Levels 9000. So I tried setting the Weapon Focus script to run at Pre-Levels 9001. This yielded the correct output in the Debug window:

[Wizard 4.1] Weapon: wClub
[Wizard 4.1] Proficiency: 2
[Wizard 4.1] Weapon: wWarhammer
[Wizard 4.1] Proficiency: 0

... but also yields a timing error. From some experimentation, the script has to run at 9001 or higher in order to have access to Helper.Proficient, but throws a timing error at any value higher than 5000 even.

So ... I guess that approach won't work. Further suggestions?

For the record, here is the full text of the script. Though honestly, at the moment it's just the stock Weapon Focus with the martial mastery turned on by default and a couple of debug lines.

      ~ If we're disabled, do nothing
      doneif (tagis[Helper.FtDisable] <> 0)

      ~ If we haven't chosen anything, get out now
      doneif (field[usrChosen1].ischosen + tagis[Target.?] = 0)

      ~ If the hero has the correct tags, this effect should apply not just to
      ~ the chosen weapon, but to all weapons of the same weapon group.
~      if (tagcount[Hero.MartVersa] + hero.tagcount[Hero.MartMaster] <> 0) then
      if (1 <> 0) then
        perform field[usrChosen1].chosen.pulltags[wFtrGroup.?]
        perform field[usrChosen1].chosen.pulltags[wProfReq.?]

        if (tagis[Target.?] <> 0) then
          foreach thing in BaseWep
            if (eachthing.tagmatch[Target,Target,initial] <> 0) then
              perform eachthing.pulltags[wFtrGroup.?]
              endif
            nexteach
          endif

        foreach pick in hero from BaseWep
          if (eachpick.tagmatch[wFtrGroup,wFtrGroup,initial] <> 0) then
			debug "Weapon: " & eachpick.idstring
			debug "Proficiency: " & eachpick.tagcount[Helper.Proficient]
              perform eachpick.assign[Broadcast.WepFocus]
              perform eachpick.pulltags[WepFocus.?]
            endif
          nexteach
        perform hero.pushtags[WepFocus.?]
      else
        ~ Assign the appropriate tag to all weapons that meet the criteria
        var id as string
        var name as string

        call fTargetId

        foreach pick in hero from AttDam where "IsWeapon." & id
          perform eachpick.assign[Broadcast.WepFocus]
          nexteach

        foreach thing in BaseWep where "thingid." & id
          perform eachthing.pulltags[wProfReq.?]
          nexteach

        ~ Set our 'short name'
        field[shortname].text = "Focus: " & name
        field[sbName].text = "Weapon Focus (" & lowercase(name) & ")"

        ~ Forward the weapon focus tag for the weapon to the hero
        perform hero.assignstr["WepFocus." & id]
        endif

      ~ If the selected weapon is a natural weapon, then apply the Hero.NatWpFocus
      ~ tag to the hero. We do this here so that the hero doesn't actually have
      ~ to have such a weapon on their character in order to get the tag and
      ~ qualify for pre-reqs based on it. For example, a Druid/Monk may want
      ~ to take Weapon Focus (Claw) in order to take Feral Combat Training, but
      ~ may not actually have claws most of the time (only when wild shaped).
      if (field[usrChosen1].chosen.tagis[wGroup.Natural] <> 0) then
        perform hero.assign[Hero.NatWpFocus]
        endif

      ~ Choosing Grapple gives us a bonus on those checks
      if (field[usrChosen1].chosen.tagis[thingid.wGrapple] <> 0) then
        ~ Add a +1 bonus to the Grapple CMB
        hero.child[manGrapple].field[cmbBonus].value += 1
        endif

      ~ This is chiefly for the Low Templar PrC's pre-req (which requires weapon
      ~ focus in any martial weapon), but also checking Simple and Exotic as
      ~ well in case those are needed in the future.
      if (tagis[wProfReq.Simple] <> 0) then
        perform hero.assign[Hero.SimWpFocus]
        endif

      if (tagis[wProfReq.Martial] <> 0) then
        perform hero.assign[Hero.MrtWpFocus]
        endif

      if (tagis[wProfReq.Exotic] <> 0) then
        perform hero.assign[Hero.ExoWpFocus]
        endif

In other news, the Dodge, Deft Maneuvers, and Powerful Maneuvers feats from the blog post were pretty straightforward and work fine.

 

[TobyFox2002]

I want to start by saying thank you for tackling this, I have long hoped that this is something I could see for hero labs. So thank you for taking a crack at it. If there is anything I can do to help, let me know.

This felt like an issue with timings. The script was running at Pre-Levels 5000, and when I checked the task list, it looks like the Wizard Weapon Proficiencies were happening around Pre-Levels 9000. So I tried setting the Weapon Focus script to run at Pre-Levels 9001. This yielded the correct output in the Debug window:

Well, I dont know why you'd need to even bother with wizard weapon proficiencies. They are not a valid selection group for Weapon mastery.

The following is a list of the valid choices for weapon groups (as listed on the pfsrd):

Martial Mastery

Gone. Combat feats like Weapon Focus now apply to weapon groups instead of a specific weapon by default.

Pathfinder frequently forces a player to invest heavily in a single weapon. For instance, two-weapon fighting rogues are stuck with mirrored weapons so their Weapon Finesse and Weapon Focus benefits apply to both their attacks. Expanding these feats to cover the weapon groups mentioned under the fighter’s Weapon Training would make things much more flexible. We might finally see a samurai wielding a daisho.

Axes, Light Blades, Heavy Blades, Bows, Close, Crossbows, Double, Firearms, Flails, Hammers, Monk, Natural, Polearms, Siege engines, Spears and Thrown.

Nothing else should be a choice by the exact wording of the the entry. The entry for weapon mastery says nothing at all about weapon proficiency. Although the point you made about requiring weapon proficiency first is a good one. An prereq rule to match if they have the correct proficiency is a good idea, but those normally run in the validation phase.

Now if you are trying to set this up to have weapon proficiency cover the entire category. I possibly see your issue, however, I am not sure that is how this was originally intended. I think it was only intended to cover Weapon Focus, Weapon Specialization, Improved Critical, etc. (But that could just be an interpretation difference.)

So basically, try separating out the weapon Proficiency element from the equation entirely. Handle that as a validation script later on.

 

[wdmartin]

Right! So, here is what led me to the point I'm at.

1) Per the blog, Weapon Focus is supposed to apply to weapon groups, not individual weapons.

2) When I cracked open the code for Weapon Focus, I found that it had existing code to apply the bonus to every weapon which shares a group with the selected weapon if the hero has the right tags. It was perhaps lazy of me, but I thought it would be easier to just jigger that tag check to always return true, then you use weapon focus with a specific weapon and it just gives you the bonus on all weapons in the group.

You're right, though, that that is probably a dumb user interface choice, because it's not obvious what's going on. I should probably just tear out the existing Weapon Focus code and redo it with a proper group selector.

However, even if I do, that does not mean I have to stop worrying about proficiencies. Suppose we have a human fighter with Weapon Focus (heavy blades). He picks up an Elven Curve Blade. It's an exotic weapon, and he lacks proficiency with it, but Hero Lab still sees it as a Heavy Blade and applies the bonus. That triggers an error from the validator complaining that you can't have Weapon Focus for a weapon you lack proficiency with. So either I need to tear out the validation rule and apply Weapon Focus to all weapons in the group regardless of whether you're proficient or not, OR I need to write the code so it only applies the bonus to weapons in the group that you have proficiency with.

I've been testing against a wizard simply because anybody can take Weapon Focus, and wizards have very few proficiencies. So it seemed sensible for testing.

I wonder if I'm going to have to do something about outliers like Weapon Focus (ray) and Weapon Focus (grapple). What weapon groups are those in? I didn't even know that grapple was an option till I took a close look at the wording of the original feat. It's weird.

I put in some late hours last night, and I think I've got most of the rest of it done:


- Combat Expertise: bootstrapped as a bonus feat via Mechanics tab.
- Power Attack: bootstrapped as a bonus feat via Mechanics tab.
- Deadly Aim: bootstrapped as a bonus feat via Mechanics tab.

In the case of all three of these, I wrote in an Eval script that checks the hero's BAB. If it's less than 1, then it hides, disables, and removes validation checking for these feats. Once your BAB hits one, they show up automatically.

I'd like a way to hide them from the hero's list of feats taken, but Helper.FtHide also disables the UI on the In Play tab, which needs to be there. If there's a way to suppress their display on the feats tab while leaving the actual UI in place, I don't know what it is.

- Weapon Finesse: bootstrapped as a bonus feat via Mechanics tab.

This seemed like the easiest way to implement it. The blog didn't change which weapons work with Weapon Finesse. Technically it allows you to choose to use your STR modifier in place of DEX if you want. But I'm pretty sure the Weapon Finesse code already just takes the higher modifier -- and who's going to choose to use the lower one? So just granting it as a bonus feat gets the functional bits done.

- Point Blank Shot: bootstrapped via Mechanics, then disabled.

This way the PC technically has the feat in order to satisfy pre-reqs for later feats (like Precise Shot), but does not actually gain any mechanical benefit from it. It also doesn't appear in the list of feats.

- Deft Maneuvers: implemented.

The blog post merely says you get a +2 bonus, without specifying CMB or CMD or both. I assumed both, because that's how most of the original feats worked. Also, I assumed the author did not intend to give you a +2 bonus on Bluff checks to feint, but instead meant to retain the change in action type per Improved Feint.

I set this up to count as all of the feats it replaces so it'll satisfy pre-reqs.

- Powerful Maneuvers: implemented.

Same +2 logic as Deft Maneuvers; applies to both CMB and CMD for each listed maneuver. Counts as the feats it replaces, for pre-reqs.

- Dodge: implemented.

Incorporates the effects of Mobility, and replaces the original Dodge feat.

- Greater Two-Weapon Fighting: implemented.

Grants extra off-hand attacks at the appropriate BAB levels, replaces the original Greater Two-Weapon Fighting, and counts as Improved Two-Weapon Fighting for pre-req purposes. Shows up as a bonus feat at Ranger level 6.

I could not find a way to prevent Improved Two-Weapon Fighting from appearing as an option in the full list of feats available to be taken. Just ignore it.

Agile Maneuvers ... is tricky. The blog post says: "A character adds their dexterity to the CMB if they’re wielding a finesse weapon and their strength otherwise." I think that's deliberately designed to make non-weapon-based maneuvers harder for dex-based characters. For example, generally you don't use a weapon to grapple.

I'm not sure exactly how to go about checking for actively-wielded finesse weapons, though. It's tempting just to use Mechanics to bootstrap Agile Maneuvers and disable it if your STR mod is higher than your DEX mod. Basically you'd wind up using the higher of the two modifiers. That would be easy, but I don't think it really captures what the author was aiming for.

So my todo list has shrunk down to:

- Weapon Focus
- Weapon Specialization
- Greater Weapon Focus
- Greater Weapon Specialization
- Agile Maneuvers

I'll post a .user file with what I've got so far sometime this evening once I get home.

 

[wdmartin]

Okay, here's what I've got so far. I'll continue working on the Weapon Focus stuff.

 

[wdmartin]

So progress, I think. I tore out my copy of the existing Weapon Focus and have started writing a new one. This is what I've got so far (running at Post-Levels, 10000).

~ If we're disabled, do nothing
doneif (tagis[Helper.FtDisable] <> 0)

~if we haven't chosen anything yet, just get out now
doneif (field[usrChosen1].ischosen = 0)

~get the wFtrGroup tag from our choice
perform field[usrChosen1].chosen.pulltags[wFtrGroup.?]

~if we didn't find a wFtrGroup tag, there's nothing more we can do
doneif (tagis[wFtrGroup.?] = 0)

~ Get the list of weapons int he group.
var searchexp as string
searchexp = tagids[wFtrGroup.?,"|"]

~ Tag the hero has having weapon focus for each weapon
~ in order to satisfy pre-requisites for feats that
~ require weapon focus with a specific weapon.
foreach thing in BaseWep where searchexp
	perform hero.assignstr["WepFocus." & eachthing.idstring]
nexteach

~ Iterate through the weapons currently in the hero's possession
~ and apply the bonus to those that the hero is proficient with.
foreach pick in hero from BaseWep
	var proceed as number
	proceed = 0

	~ Must be part of this weapon group.
    if (eachpick.tagmatch[wFtrGroup,wFtrGroup,initial] <> 0) then
		proceed += 1
	endif

	~ Hero must be proficient with the weapon.
    if (eachpick.tagcount[Helper.Proficient] <> 0) then
		proceed += 1
	endif

	~ Yay, passed both tests.  Award them their shiny +1.
    if (proceed > 1) then
		perform eachpick.assign[Broadcast.WepFocus]
    endif
nexteach

This works. It successfully assigns the +1 bonus, only to weapons the hero is proficient with, and tags them as having weapon focus with each weapon in the group. But in some weapon groups it yields errors like this:

Tag 'WepFocus.iBodPieGr' not defined

Here's a list of the weapons that trigger the error, by weapon group:

Close Weapons:
	WepFocus.iBodPieGr
	WepFocus.iElephShWe
	WepFocus.iCKKGspDro

Flails:
	WepFocus.iFGKrakBit

Hammers:
	WepFocus.wNeuralInh

Heavy Blades:
	WepFocus.iFGBlaSwor
	WepFocus.iEroeme

Light Blades:
	WepFocus.iWoWHelbra
	WepFocus.iSunBlade

Thrown Weapons:
	WepFocus.iAxeDwLord

The other groups are all ok (Bows, Crossbows, Double Weapons, Firearms, Monk Weapons, Natural Weapons, Pole Arms, Siege Weapons and Spears).

Is there a way to test whether a tag is defined before assigning it? In pseudo-code, something like:

if (tag_exists["WepProf." & eachthing.idstring] <> 0) then
~ assign the tag
endif

That would get the tags assigned, but silently skip any invalid ones. I could write in specific exceptions for the tags listed above, but chances are good that as the game system evolves eventually some weird new weapon would get added without a WepFocus tag, and the error would recur.

I've attached an updated .user file.

 

[TobyFox2002]

Something to consider as well, in many of my games that run with pregenerated npcs, like adventure paths and such. I allow the players, cohorts and some BIG npcs or Bosses to use these rules. But most of the basic npcs, I dont. because its alot of set up and preparing them.

I suggest, something like this be added, as a mechanic:

Timing: VERY Early. Just after the npc tag is added.

        if (hero.tagis[CharType.typNPC] <> 0) then
          perform hero.assign Custom.NoFeatTax
          endif

You'd first have to define the Custom variable somewhere, but once you do it should work. Then on each of the scripts for your rules add this:

      ~ If we're an NPC, Get out Now!
      doneif (hero.tagis[Custom.NoFeatTax] <> 0)

I know its possible to just do this using precludes and also just testing for the CharType.typNPC directly. However, doing it this way would allow for more variant rules to be added based on the GM's desire. Like... certain types of npcs could use these rules etc or certain players could use these and not others and so on.

It might be possible to test for if the hero is a cohort as well, but I'm not sure how to do that.

 

[ShadowChemosh]

        if (hero.tagis[CharType.typNPC] <> 0) then
          perform hero.assign Custom.NoFeatTax
          endif

First I think this is a good idea actually as it provides some nice flexibility.

Just FYI the above script is missing the [] around the tag you want to assign:

perform hero.assign[Custom.NoFeatTax]

 

[wdmartin]

Hmm. So the idea is you could leave the source enabled by default, but the mechanics rules would be skipped for anything tagged as an NPC (which I assume happens with the PC/NPC selector on the Hero Configuration screen). Any NPCs who wanted, say, Power Attack, would have to select it normally. Then if you actually wanted the no-feat-taxes rules to apply to an NPC, you change them to a PC, they get the bonus feats and so on.

That makes good sense, I think. It'd be nice if there was a checkbox in the configuration screen to enable/disable the NoFeatTax tag, for GMs who prefer NPCs to use the same rules as PCs.

Let me focus on getting the remaining feat modifications done first, and then we can visit this before doing a formal release.

 

[ShadowChemosh]

That makes good sense, I think. It'd be nice if there was a checkbox in the configuration screen to enable/disable the NoFeatTax tag, for GMs who prefer NPCs to use the same rules as PCs.

You can do this using a mechanic very easily with a script like TobyFox was showing. A mechanic is always "live" and running on all heroes.

You can also do this logic with a .1st file and have the source auto-apply the tag for you. I do this for the Eberron campaign system to turn on Factions. Look HERE for an example.

 

[wdmartin]

Today I learned how to use the *Preclude tab, and why it's better than "Replace with Thing ID" in this case. Namely, using "Replace" messes up portfolios that don't use these rules, even if the source is de-selected. Whereas "Preclude" lets them function normally.

Also, feats bootstrapped via Mechanics still complain about unfilled pre-reqs, like ability scores. Who knew? I've assigned skipprereq universally to those now to prevent annoying errors about feats that were auto-assigned.

I think I've got Weapon Focus working correctly:

1) It only applies the bonus to weapons you're proficient in.
2) It correctly applies the bonus to all weapons in the selected group.
3) For feat pre-reqs, it tags the user as having WepFocus in all weapons in the group (see below).
4) It doesn't throw up errors about undefined tags any more.

I fixed the undefined tag errors by pulling the WepFocus tag off the weapon itself and assigning that to the hero instead of simply tagging them with "WepFocus" and the idstring. This seems to work correctly in all cases, with two exceptions:

- Elephant Shield (iElephShWe)
- Eroeme (iEroeme)

These two items lack a WepFocus tag. The still receive the actual bonus correctly based on their membership in the weapon group, but they don't tag the user as having a Weapon Focus appropriate to their type. I wrote in a test to skip any weapons that lack a WepFocus tag.

I've attached an updated .user file.

Next up: Weapon Specialization. Oh, though I may implement a Weapon Focus (ray) feat for casters, since it's not part of any weapon group.

 

[The World Is Square]

Hey everyone! This is Michael from The World Is Square. I'm one of the guys who worked on these feat changes.

First off: I just wanted to say that it is really cool that you guys have put this together. I'm always surprised at how popular this alternate set of rules has become.

Secondly: We ended up making a full feat tree based on these rules. The feat progression has been custom tailored to our campaign setting (which is P6), but 90% of it is still compatible with Pathfinder Core. It may be worth a look if you want to see the tic-and-tac of how feats and their prerequisites shake down.

Finally: Would it be okay if I post the .user file on my blog? It seems like something my (meager) audience would be interested in!

 

[wdmartin]

Woo, cool! Nice to see you here. Also interesting to see how your ideas developed after the initial blog. I may go through and cherry-pick some of the further developments that aren't campaign-setting specific, especially Unarmed Combatant. What's P6, btw?

As for posting the .user file, please don't! Not because I don't want to share, but because a copy on a blog post will inevitably get outdated, and not get bug fixes or further developments. It would be better to post instructions for setting up a custom source in Hero Lab, and a link to a forum thread here for bug reports. Then people who used it would have an automated update channel and a place to report weird errors.

TobyFox contacted me privately about integrating it into his existing channel. I kind of wonder if if that's the best place to put it -- Toby's channel has a bunch of campaign setting material also (Faerun stuff, I think), which people would then get in addition to the World is Square rules. It might make more sense to set up a separate channel so they only get stuff they want. Setting up a channel isn't especially hard; I've done it before for private stuff from my own campaign, mostly magic items and archetypes for specific factions.

Anyway, stay tuned a bit longer until I can finalize an initial release, and then you can post about that.

Speaking of which, progress! I think I've got all the rules from the (original!) blog post implemented. I still need to make an option for charging NPCs normal feat taxes, but after that, I think it'll be time for an initial release.

I've attached an updated .user file. I would be grateful for any testing. I'm not especially experienced with HL scripting. There are probably bugs and oversights.

Note: I had to add some custom tags to deal with validation of prerequisites. That required adding a .1st file. I have uploaded it as a .txt file, because apparently the forums are not set up to allow the .1st file extension as an attachment. So, put both files in your Hero Lab Pathfinder data folder, then rename "world-is-square.txt" to "world-is-square.1st".

------- Notes on Implementation -------

Feats:

[X] Martial Mastery - combat feats apply to weapon group instead of individual weapon
[X] Weapon Focus
[X] Weapon Focus (ray)
[X] Weapon Specialization
[X] Greater Weapon Focus
[X] Greater Weapon Specialization
[X] Improved Critical

[X] Dodge (combined with mobility)
[X] Deft Maneuvers
[X] Powerful Maneuvers
[X] Greater Two-Weapon Fighting

System level changes:
[X] Agile Maneuvers (Add DEX to CMB if higher -- see notes)
[X] Weapon Finesse automatic for light weapons group + finessable weapons

[X] Combat Expertise is now just a combat option for anyone with BAB +1 or higher
[X] Power Attack is now just a combat option for anyone with BAB +1 or higher
[X] Deadly Aim is now just a combat option for anyone with BAB +1 or higher

[X] Point Blank Shot removed from game; everyone counts as having it for feat pre-reqs
[X] Improved Two-Weapon Fighting removed from game


------- Notes on specific points -------

-- Bonus feats

All characters currently get Combat Expertise and Weapon Finesse as bonus feats. They also get Power Attack and Deadly Aim if they have a +1 BAB. As noted, I plan to adjust this so that NPCs do not automatically get these feats for free, unless the GM checks a box saying so.

All characters get Point Blank Shot for free, but its effects are suppressed. It's just there to satisfy prerequisites for other feats.

-- Agile Maneuvers

I have implemented this as automatically granting Agile Maneuvers as a bonus feat if your Dex modifier is higher than your Str modifier. The result is that you always use the higher of the two modifiers for CMB calculations, regardless of what weapon you happen to be holding.

This is chiefly because of laziness. It was a lot easier to compare ability modifiers and give them the higher of the two than it would be to iterate through the hero's equipment and check to see if they're wielding a finesseable weapon.

-- Weapon Focus, Greater Weapon Focus, Weapon Specialization, Greater Weapon Specialization

I assume that PCs only recieve the benefits of these feats if they also have proficiency with the weapon in question. For example, a wizard with Weapon Focus (club) should not receive the +1 bonus on attacks with warhammers, because he lacks proficiency with that weapon. Likewise, a human fighter with Weapon Focus (Heavy Blades) will receive his +1 for a Greatsword, but not an Elven Curve Blade.

-- Weapon Focus (Ray)

The original Weapon Focus allows you to select Ray as a weapon, but "Ray" is not part of any weapon group. I therefore implemented a static Weapon Focus (Ray) feat which gives you a +1 on ranged touch attacks.

-- Weapon Proficiencies

Although weapon proficiencies are combat feats that require you select a specific weapon, and thus covered under the blog's rules as shifting to weapon groups, I have opted not to modify them. Chiefly because 1) they are so basic to the system that re-implementing them without screwing up other stuff would be pretty involved; and 2) most people rely on their class for weapon proficiencies, and only use the feats to cherry-pick one weapon. It didn't seem worth the effort.

-- Deft Maneuvers

With the exception of Improved Feint, all of the feats that this replaces grant a +2 on both CMB and CMD regarding their respective manuevers. The blog only specifies a +2 bonus. I am assuming that the intent was for that to apply to both CMB and CMD, as in the original feats.

Improved Feint as originally written does not grant any kind of numerical bonus to Feint attempts. Instead it changes the type of action required to perform the maneuver. I have retained the changed action type, and opted not to give anyone an untyped +2 bonus on Bluff checks to feint.

-- Powerful Maneuvers

See Deft Maneuvers, re +2 CMB and also CMD.

 

[TobyFox2002]

As for posting the .user file, please don't! Not because I don't want to share, but because a copy on a blog post will inevitably get outdated, and not get bug fixes or further developments. It would be better to post instructions for setting up a custom source in Hero Lab, and a link to a forum thread here for bug reports. Then people who used it would have an automated update channel and a place to report weird errors.

Not necessarily, the file wouldnt go out of date if he posted the link to your dropbox or some other site you use. That way you could keep it update and the download link to the update.xml file would never change.

TobyFox contacted me privately about integrating it into his existing channel. I kind of wonder if if that's the best place to put it -- Toby's channel has a bunch of campaign setting material also (Faerun stuff, I think), which people would then get in addition to the World is Square rules. It might make more sense to set up a separate channel so they only get stuff they want. Setting up a channel isn't especially hard; I've done it before for private stuff from my own campaign, mostly magic items and archetypes for specific factions.

I did, but my stuff is separated into different packs, we could keep it separate from all the others very easily. My offer was just one of where it is hosted and so that it appears as an option when people go add my download source to their hero labs. However, if you maintained it it would make things easier for you to update. That I do agree.

Either way I suggest changing the sourcing of these files a bit. So it shows up in the Hero Configuration as part of either the User Content or House Rules. I suggest House Rules unless you intend to make category in the User Content to share your personal work

 

[wdmartin]

My offer was just one of where it is hosted and so that it appears as an option when people go add my download source to their hero labs. However, if you maintained it it would make things easier for you to update. That I do agree.

I think I'll do it that way, then -- I have hosting and some suitable domains where I could put it.

Either way I suggest changing the sourcing of these files a bit. So it shows up in the Hero Configuration as part of either the User Content or House Rules. I suggest House Rules unless you intend to make category in the User Content to share your personal work

I agree. House Rules would be best for this. I'll work on that this evening.

It'll be ready soon! Which is good, because one of my groups is kinda going to need these rules for Friday. ^_^;