Loading ...
Sorry, an error occurred while loading the content.

Re: [pcgen_developers] Re: Question on CHOOSE:ARMORPROFICIENCY|TYPE=Text

Expand Messages
  • Eric C Smith
    Hi Tom, Thanks for the explanation. I think I can move forward with some clarification in the docs based upon this. As for the OP that had the problem, I had
    Message 1 of 3 , May 2, 2013
    • 0 Attachment
      Hi Tom,

      Thanks for the explanation. I think I can move forward with some clarification in the docs based upon this.

      As for the OP that had the problem, I had pointed him in the direction of using the EQUIPMENT[TYPE=x] syntax and it worked mostly for him. I haven't had the chance to followup with him but will tackle that next.

      Maredudd

      On May 2, 2013, at 11:51 AM, thpr wrote:

      >
      > CHOOSE:ARMORPROF was never fully implemented as best I can recall from my searching through CVS. CHOOSE:ARMORPROFICIENCY should work, but there is a subtlety to its use which is what seems to have been encountered (given the limited data I see here - I have not read listfilehelp in some time)
      >
      > The error is likely correct. If the ArmorProf files do not have a TYPE in the file (and they should not for reasons I will explain below), then the error message provided is valid. It's just as much of an error as attempting to ask for Level 15 Wizard spells... there simply aren't any in the data.
      >
      >
      > (The TYPE=x feature is there for completeness because someday we may find a use for a TYPE in ArmorProf that is not related to the type of Armor)
      >
      > Having said that, the solution should not be to put a TYPE in the ArmorProf files. (The formal discussion of the appropriate methodology in this case is probably on the order of 5 or 6 years old, and was between myself and Aaron and occurred on the developers list on SourceForge). Putting a TYPE in the ArmorProf file can result in some really small (but nasty) nuances of problems...
      >
      > Here is the design counter-example of we are dealing with and why it "breaks" (note my tokens may be off - read for intent not literal use):
      >
      > Equipment File:
      >
      > MyArmor <> TYPE:Medium <> ARMORPROF:MyArmorProf
      >
      > ArmorProfFile:
      >
      > #This is intentionally not Medium for clarity later in the example...
      >
      > Leather <> TYPE:LightArmorType
      > MyArmorProf <> TYPE:MediumArmorType
      >
      > EqMod File:
      >
      > SuperDuperArmor <> ITYPE:Light
      >
      > Feat File:
      > MyFeat <> ADD:ARMORPROF|%LIST <> CHOOSE:ARMORPROFICIENCY|TYPE=LightArmorType
      >
      > Now I make a character, add MyArmor and EqMod MyArmor with SuperDuperArmor. I select MyFeat. Should I be proficient with (or allowed to select) proficiency with the modified MyArmor???
      >
      > If the intent would be NO, then we're OK as it will fail as typed (the proficiency is not TYPE=LightArmorType but rather TYPE=MediumArmorType)
      > If the intent would be YES, then the logic used above means that the EqMod all of a sudden *can't just modify the type of the Equipment* - It must ALSO modify the proficiency of the equipment (a feature we don't really have and which means the EqMods have to make two redundant changes, which can lead to inconsistencies if the data team doesn't remember to do things twice [said in technical programmer terms, this forces a contract onto the data monkey to make two parallel and redundant changes, and CONTRACTS ARE BAD])
      >
      > Thus... we use the syntax system above when we want NO. When we want yes, we modify the CHOOSE to refer NOT to the ArmorProf (a proficiency object) but to refer to Armor that is TYPE=Light:
      >
      > MyFeat <> ADD:ARMORPROF|%LIST <> CHOOSE:ARMORPROFICIENCY|EQUIPMENT[TYPE=Light]
      >
      > Thus, when the Armor is modified by the EqMod to become TYPE=Light (a feature we have), the associated proficiency becomes valid under the CHOOSE.
      > The advantage here is that we only have to modify one TYPE. There is no risk of data having to have TYPE in two places and keep those consistent. Redundant information leads to bugs, so there is no redundancy in this design.
      >
      > This allows EITHER answer to the question (YES or NO) to be appropriately coded within PCGen.
      >
      > Yes, this is subtle. :)
      >
      > Generally, the rules as I understand them today are always intending to do YES, which is why we do not have types in the ArmorProf file... (and should avoid adding them without good cause)
      >
      > Thus, it is most likely true that what the user intends to get is "Proficiency with armor that is light armor". That is not achieved through a TYPE in the ArmorProf, but a TYPE on the Armor itself (and we refer to the Armor instead of the ArmorProf objects by using the Equipment Qualifier):
      >
      > CHOOSE:ARMORPROFICIENCY|EQUIPMENT[TYPE=Light]
      >
      > With that CHOOSE, it will be inspecting the Armor (Equipment) LST file, and I'm certain it will find "Light" and not produce any warnings/errors on load.
      >
      > TP.
      >
      > --- In pcgen_developers@yahoogroups.com, Eric C Smith <maredudd@...> wrote:
      >>
      >> Hi Folks!
      >>
      >> Got a question concerning the subject chooser . . .
      >>
      >> The original NEWTAG tracker (http://jira.pcgen.org/browse/NEWTAG-19) that added the CHOOSE:ARMORPROFICIENCY tag and deprecated the CHOOSE:ARMORPROF tag includes acknowledgement that, though we were adding the CHOOSE:ARMORPROFICIENCY|TYPE=x syntax, and that the armorprof files did not currently include types, the syntax "still works". There was even an example provided which made it into the docs.
      >>
      >> I've checked both the distributed data sets and the test data sets and none of them include any examples of the subject syntax. Based upon the reports from a user on PCGenListFileHelp, this syntax throws the following error:
      >>
      >> 10:06:47.112 SEVERE Thread-7 pcgen.cdom.reference.AbstractReferenceManufacturer resolveReferences Error: No ArmorProf objects of TYPE=Light were loaded but were referred to in the data
      >> 10:06:47.112 SEVERE Thread-7 pcgen.rules.context.TrackingReferenceContext unconstructedReferenceFound Was used in file:/C:/Program%20Files%20(x86)/PCGen/PCGen6000/data/homebrew/my_dataset/my_feats.lst in tokens: [plugin.lsttokens.choose.ArmorProficiencyToken]
      >>
      >> Can anyone confirm this syntax has ever actually worked and if so when did it break? If it is not a valid syntax was it intended to be one day and if this is the case, when was it planned?
      >>
      >> In any case, I need some additional info so I can figure out what changes need to be mae to the docs, i.e. do I remove the subtag altogether or do I just hid it until the subtag's functionality is enabled. If it is valid but broke, then we need to open a Code Tracker to get it fixed.
      >>
      >> Maredudd
      >> Doc 2nd
      >>
      >
      >
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.