Last session, my Artificer mentioned to me that his implement - crossbow, by way of the Crossbow Caster feat - had never worked in HeroLab. I hadn't realised this, although obviously a few minutes poking around here has shown me a bunch of issues with various implements, superior implements and "weapliments".
The idea right now seems to be to patch individual items, so I thought I'd do that for weapons that can be used as implements. Then I remembered Monks, because I've actually played one of those, unlike all the other implement users, and went "hey, wait a minute...". Sure enough, the Monk in HeroLab has a major error in its Implement Proficiencies. Sure, it gets all the weapons Monks receive automatic proficiency with, but that's not the actual rule - monks can use any weapon they're proficient with as an implement, not just the ones they get by default. So any proficiency they acquire with feats, background, racial bonuses, theme, hybrid or multiclassing options, whatever. Literally any weapon in the game.
My point being, "weapons which can also be implements" is the same as just "weapons".
I know this is a biiiig task, and that parts of it are all being worked on, but I didn't see any discussion of its overall scope, so I wanted to raise it as a whole. I wanted to find out more about how people are approaching this, and how it should be approached.
I saw people fixing certain weapliments by adding them to an "Implement type" group. Will this work for all weapons without a change to the underlying files? I mean, is it just a matter of tagging items so the program "notices" that they can be implements, or is the program not able to use them correctly even if they include such a tag? In particular, since non-magical weapon properties (Proficiency bonus, damage dice, Reach etc) don't apply when a weapon is used an an implement, I assume HL isn't "looking" for such properties when it connects an implement to a power. Is it able to apply the magical properties safely and ignore the mundane characteristics?
And, if simply tagging all weapons is the way to go, do folks think it would be better to for all weapons to be in one big "weapons" implement group? Or should weapon groups be mirrored to implement groups? I'm happy to put in the effort, just not sure what the better approach would be.
Last time I looked at implements for whatever reason (bard, I think) it was a complete trainwreck. I think the only way to fix it was that I manually repaired each songblade and created a whole new implement type (well, implemented an already created implement type).
The good news is that they are no longer adding new implements or types of implements, so we can go in and fix them. The fix for monks might be even easier - probably just a matter of in the monk class pointing it to a substitution version of the implement system which just checks for proficiency rather than implement type before granting the bonus from the weapon. It's been more than a year though since I worked on instruments (songblades, I think were the problem), so take this all with a grain of salt. I'll be happy to look up my notes if you think it will help.
Yes please, anything you can send my way would be much appreciated. It seems doable, but I have so little information that anything you can tell me would probably save me a lot of time - in research, if nothing else! Thanks :)
I'm in the process of trying to make the [Implement] Expertise feats work, but I'm not particularly optimistic. I'll try to remember to post here if I work it out.
Okay, the problem with making Implement Expertise work seems to be that the game system has no generic way to add to attack value, but only attack value. The weapons get by because they have their own attack value, which can be modified by various class features and so on. Implements don't. The magic implements end ran this by having a magic bonus attribute that is fed into output.
This creates problems not just here. As it is, its not clear how, if at all, you can have something add to attack values with, for example, all powers that are dependent on a readied orb, except by building it into the orb at hand.
Anybody who actually still read this know if there's something I'm missing?