Senior Member
Join Date: Feb 2010
Posts: 874
|
Okay, in my slow work on cleaning up the 4e file, one of the items I hit was a "armor" proficiency for an item called a Barbed Shield. Its pre-req was supposed to be proficiency in Heavy Shield. The feat was listed incorrectly as an armor, rather than shield proficiency, but that was just a nomenclature error and easily fixed.
However, when I entered the proper id in the pick-req, (and it was a proper one, since the Editor accepted it), it still doesn't prevent the feat from being picked; I double checked to make sure that the character involved didn't have that proficiency, and they don't. Can anyone else see why this wouldn't be working as intended? I've used pick-reqs a million times, and while I've had them not be accepted for any number of reasons, this is the first time I've seen one be accepted but not work. Code:
thing id="ftShieBa" name="Shield Proficiency: Barbed Shield" description="{b}Benefit{/b}: You gain proficiency with barbed shields." compset="Feat" uniqueness="useronce"> <fieldval field="reqText" value="Proficiency with heavy shields"/> <usesource source="MordensEmp" parent="Supplement" name="Mordenkainen's Magnificent Emporium"/> <tag group="Hide" tag="Special" name="Special" abbrev="Special"/> <tag group="Tier" tag="Heroic" name="Heroic Tier" abbrev="Heroic Tier"/> <eval phase="Setup" priority="5000">perform hero.assign[ArmorProf.apShieldBr] <before name="Armor type proficiencies"/> </eval> <pickreq thing="apShieldHv"/> <prereq message="Already proficient with this armor."> <validate><![CDATA[ validif (@ispick <> 0) @valid = !hero.tagis[ArmorProf.apShieldBr]]]></validate> </prereq> </thing> |
#1 |
Senior Member
Volunteer Data File Contributor
Join Date: Jan 2010
Location: Chicago, IL (USA)
Posts: 10,729
|
Quote:
Then next line of code is very strange as I didn't even know HL could deal with "not" logic. So "@valid = !hero.tagis[ArmorProf.apShieldBr]" is actually saying if we do NOT find the tag ArmorProf.apShieldBr on the Hero then we are valid. Do you maybe mean to say you are valid when that tag is found? I am not 100% following what the validation is suppose to be from your post. Hero Lab Resources: Pathfinder - d20pfsrd and Pathfinder Pack Setup 3.5 D&D (d20) - Community Server Setup 5E D&D - Community Server Setup Hero Lab Help - Hero Lab FAQ, Editor Tutorials and Videos, Editor & Scripting Resources. Created by the community for the community - Realm Works kickstarter backer (Alpha Wolf) and Beta tester.- d20 HL package volunteer editor. |
|
#2 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 13,217
|
validif (hero.tagis[ArmorProf.apShieldBr] = 0)
is my recommendation, if you're looking for a prereq of "we don't have this tag" |
#3 |
Senior Member
Join Date: Feb 2010
Posts: 874
|
That part is just supposed to yield a negative if the character already has the proficiency I'd guess (it was already in the code when I got it). It was the pickreq that doesn't seem to be working and I couldn't figure out why. Is the piece you guys are talking about likely to be breaking that (because they seem to have used it as a component in almost all the armor and shield proficiencies)?
|
#4 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 13,217
|
Paragon - just for your information, in my own code, I have not used a pickreq in the last 4 years or so. I just do not find them useful for any real coding.
Take a look at the hero tags that get added when that particular pick is present and active on the character. I'd recommend using an exprreq based on those tags, not a pickreq based on the pick itself. |
#5 |
Senior Member
Join Date: Feb 2010
Posts: 874
|
Well, to describe what I do as "real coding" is probably a vast overstatement; to be honest, my understanding of how to construct a proper exprreq is, charitably, somewhat limited. I'm occasionally able to kitbash together other people's code chunks usefully, but that's about it.
|
#6 |
Senior Member
Join Date: Feb 2010
Posts: 874
|
On the other hand, I just realized this particular kind of exprreq I'd actually used before, so I went back over it and, sure enough, that worked fine. Odd.
|
#7 |
|
|