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

RE: [PCGenListFileHelp] SPROP substitution value issue

Expand Messages
  • Barak
    ... Umm, fixed? That s planned behavior. Granted, older, but still planned behavior. Barak
    Message 1 of 9 , Jan 31, 2011
    • 0 Attachment
      > -----Original Message-----
      > I have a work around (insert a substitution that will never equal 0)
      > but this should probably get fixed just in case there was any parsing
      > code being recycled into version 6.

      Umm, fixed? That's planned behavior.

      Granted, older, but still planned behavior.

      Barak
    • torryschreiner
      It is planned behavior that variables used by substitutions are evaluated as part of the qualifier to determine whether or not the SPROP shows? Can I ask what
      Message 2 of 9 , Feb 1, 2011
      • 0 Attachment
        It is planned behavior that variables used by substitutions are evaluated as part of the qualifier to determine whether or not the SPROP shows? Can I ask what the logic behind this is since it seems completely broken to me. I come from a C/Perl background and this is like saying printf will output absolutely nothing if all of the variables in the parameter list evaluate to a value of zero.

        If I were to write this parser, I would treat the SPROP as a '|' delimited stack:
        1. Shift display text off of stack
        2. Process display text looking for substitutions. If % found, shift variable/equation off of stack, evaluate and substitute value.
        3. Repeat step 2 until no substitutions remain.
        4. Process remainder of the slack as qualifiers. Evaluate each stack member into TRUE/FALSE value and AND resulting values together.

        Also, besides adding another substitution that can't equal zero, how else can I deal with this "feature"?

        --- In PCGenListFileHelp@yahoogroups.com, "Barak" <barak@...> wrote:
        >
        > > -----Original Message-----
        > > I have a work around (insert a substitution that will never equal 0)
        > > but this should probably get fixed just in case there was any parsing
        > > code being recycled into version 6.
        >
        > Umm, fixed? That's planned behavior.
        >
        > Granted, older, but still planned behavior.
        >
        > Barak
        >
      • Andrew Maitland
        Hi, First off - you re talking to the non-Java coders on this list. All the actual coders hang out over on the Developer list, so telling us something in code
        Message 3 of 9 , Feb 1, 2011
        • 0 Attachment
          Hi,

          First off - you're talking to the non-Java coders on this list. All the actual coders hang out over
          on the Developer list, so telling us something in code speak isn't really going to help - I only
          understood about half of what you were talking about - stacks traces are errors I deal with, Stacks,
          shifting, etc, you kinda lost me. Since this group is meant to help people make their own Data Sets
          and that has nothing to do with Bugs, Feature Requests on the Code Side, or anything else code
          related, they don't monitor this group.

          Coder for PCGen = Java Programmers
          Data Monkeys = LST Coding which is an internal language developed specifically to adhere to the OGL
          terms of being easily understood by humans.

          Now, as to answer why this is expected behavior - The Substitutions and everything else behind the
          Pipe have a two fold function. The First Being to Qualify if to display the Text, If the Answer is
          Null for the Substitutions (Zero) then it won't display, if the PRExxx is not met, it will not
          display. So, everything after the PIPE '|' is essentially a Display Qualifier or PRExxx in that regard.
          Secondarily, the Substitutions grants a dynamic number. I believe this was a later addition of a new
          feature being added, so the "expected behavior" would be the natural progression of this path. That
          is what makes logical sense to me. However, I cannot speak with any clarity as I wasn't present when
          this came into being.

          So while it might not be perfect, it's the expected behavior since at least 5.4 and earlier.

          The Final Answer to the work around, is as you stated, make sure you don't have zero for all your
          values. If you expect this will happen but still need the text to display, have a secondary
          substitution that isn't in the text.

          DEFINE:DisplayAlways|1

          SPROP:Your Text %, more of the text %|Sub1|Sub2|DisplayAlways|PREALIGN:LG

          As to why this was implemented in this fashion? Again, I cannot say, I wasn't part of the planning
          process. That is before I joined the team. Should the behavior be re-evaluated? If you think it
          should then open a Feature Request and explain the pros and cons. Mind you since this affects
          existing data and is established precedent, you'll likely have some strong push back. But that
          shouldn't stifle good ideas.

          If you want to get a Java Coders attention though, you need to post bug reports like this on the
          correct list. PCGen Main Yahoo Group. If you want to bring up the discussion with this or other odd
          behavior, head over to the Pcgen Developer Yahoo Group. James, Tom and several of our in-the-wings
          code monkeys will be most happy to have a conversation with you. If your really serious about
          changing it, then make the proposal, and submit a patch, join the code team and improve the program.
          [That's abbreviated of course, as any data side change proposed for code would have to get the data
          teams stamp of approval].

          Hope that explained everything in perspective. Any further questions don't hesitate to ask. If it's
          code-related though I'll pass you along to the Code team for follow up.

          Cheers,

          On 2/1/2011 12:08 AM, torryschreiner wrote:
          > It is planned behavior that variables used by substitutions are evaluated as part of the qualifier to determine whether or not the SPROP shows? Can I ask what the logic behind this is since it seems completely broken to me. I come from a C/Perl background and this is like saying printf will output absolutely nothing if all of the variables in the parameter list evaluate to a value of zero.
          >
          > If I were to write this parser, I would treat the SPROP as a '|' delimited stack:
          > 1. Shift display text off of stack
          > 2. Process display text looking for substitutions. If % found, shift variable/equation off of stack, evaluate and substitute value.
          > 3. Repeat step 2 until no substitutions remain.
          > 4. Process remainder of the slack as qualifiers. Evaluate each stack member into TRUE/FALSE value and AND resulting values together.
          >
          > Also, besides adding another substitution that can't equal zero, how else can I deal with this "feature"?
          >
          > --- In PCGenListFileHelp@yahoogroups.com, "Barak"<barak@...> wrote:
          >>> -----Original Message-----
          >>> I have a work around (insert a substitution that will never equal 0)
          >>> but this should probably get fixed just in case there was any parsing
          >>> code being recycled into version 6.
          >> Umm, fixed? That's planned behavior.
          >>
          >> Granted, older, but still planned behavior.
          >>
          >> Barak
          >>
          >
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
          >

          --
          Andrew Maitland (LegacyKing)
          Admin Silverback - PCGen Board of Directors
          Data 2nd, Docs Tamarin, OS Lemur
          Unique Title "Quick-Silverback Tracker Monkey"
          Unique Title "The Torturer of PCGen"


          [Non-text portions of this message have been removed]
        • FerretDave
          Greetings, I dont know the original reasoning behind it, however I can see very practical reasons for it to be this way. If you re substituting in a variable,
          Message 4 of 9 , Feb 1, 2011
          • 0 Attachment
            Greetings,
            I dont know the original reasoning behind it, however I can see very practical reasons for it to be this way.

            If you're substituting in a variable, and that variable is zero, then the result is 'nothing'.

            An SPROP could be 'you can do this x times per day', or somesuch, and if that variable comes up zero, then the logic is not to display any of the SPROP at all rather than than a pointless display of: 'you can do this zero times per day'.

            As the experts have pointed out, there's ways to work around this, but by default, thats the behaviour we expect.

            Cheers
            D
            --- In PCGenListFileHelp@yahoogroups.com, Andrew Maitland <drew0500@...> wrote:
            >
            >
            > DEFINE:DisplayAlways|1
            >
            > SPROP:Your Text %, more of the text %|Sub1|Sub2|DisplayAlways|PREALIGN:LG
            >
            > As to why this was implemented in this fashion? Again, I cannot say,

            > On 2/1/2011 12:08 AM, torryschreiner wrote:
            > > It is planned behavior that variables used by substitutions are evaluated as part of the qualifier to determine whether or not the SPROP shows? Can I ask what the logic behind this is since it seems completely broken to me. I come from a C/Perl background and this is like saying printf will output absolutely nothing if all of the variables in the parameter list evaluate to a value of zero.
            > >
          • Barak
            ... Well I was around then. :p SPROP didn t take PRExxx back then, and no one wanted to see Grants 0d6 additional damage . So if all the variables are 0,
            Message 5 of 9 , Feb 1, 2011
            • 0 Attachment
              > -----Original Message-----
              > As to why this was implemented in this fashion? Again, I cannot say, I
              > wasn't part of the planning
              > process. That is before I joined the team. Should the behavior be re-

              Well I was around then. :p

              SPROP didn't take PRExxx back then, and no one wanted to see "Grants 0d6
              additional damage". So if all the variables are 0, the SPROP is not
              displayed.

              Barak
            • torryschreiner
              Sorry about the code speak. In perl, the shift command grabs and removes the first value off of a list. I see the reasoning behind the current behavior based
              Message 6 of 9 , Feb 1, 2011
              • 0 Attachment
                Sorry about the code speak. In perl, the shift command grabs and removes the first value off of a list.

                I see the reasoning behind the current behavior based on history but at the same time don't feel it was the correct way to handle the situation. I feel you would get a more predictable and consistent outcome if the substitution variables were "consumed" by the act of substitution and removed from the evaluation of the qualifier list. If you did want their value(s) evaluated to determine whether or not to display, you just repeat them later in the list after the last substitution variable. In effect, this is kind of the opposite of the work around Andrew gave but should be easier for new LST file hackers with a coding background who probably wouldn't assume that the current behavior is intended, like me.

                A documentation update would also help. I don't see anything in the SPROP documentation explaining that substitution variables AND the PRExxx tags are evaluated as the display qualifier or the clue Andrew gave in order to force display. The SPROP documentation points to the SAB documentation: "Variable substitution can be used in the same manor as the SA tag" and the SAB documentation says: "The Special Ability will not be displayed if the last variable or formula equals zero." By extension, one might assume this statement also applies the SPROP but this is not the case. SPROP will not display if all of the substitution variables are equal to zero regardless of the value of the last variable or formula. I have not tested the actual SAB behavior.

                If I decide to pursue this, I will join the developer list. I'm useless in Java and XML but willing to help otherwise if I can.

                Thanks.

                --- In PCGenListFileHelp@yahoogroups.com, "Barak" <barak@...> wrote:
                >
                > > -----Original Message-----
                > > As to why this was implemented in this fashion? Again, I cannot say, I
                > > wasn't part of the planning
                > > process. That is before I joined the team. Should the behavior be re-
                >
                > Well I was around then. :p
                >
                > SPROP didn't take PRExxx back then, and no one wanted to see "Grants 0d6
                > additional damage". So if all the variables are 0, the SPROP is not
                > displayed.
                >
                > Barak
                >
              • Andrew Maitland
                Hi, ... No worries, just letting you know that this isn t the coder section, so code-speak won t be grok d here. ... Well, believe it or not, Tom (One of our
                Message 7 of 9 , Feb 1, 2011
                • 0 Attachment
                  Hi,




                  On 2/1/2011 9:04 AM, torryschreiner wrote:
                  > Sorry about the code speak. In perl, the shift command grabs and removes the first value off of a list.

                  No worries, just letting you know that this isn't the coder section, so code-speak won't be grok'd here.

                  > I see the reasoning behind the current behavior based on history but at the same time don't feel it was the correct way to handle the situation. I feel you would get a more predictable and consistent outcome if the substitution variables were "consumed" by the act of substitution and removed from the evaluation of the qualifier list. If you did want their value(s) evaluated to determine whether or not to display, you just repeat them later in the list after the last substitution variable. In effect, this is kind of the opposite of the work around Andrew gave but should be easier for new LST file hackers with a coding background who probably wouldn't assume that the current behavior is intended, like me.

                  Well, believe it or not, Tom (One of our coders), is leading the charge to fix ambiguous code
                  behavior, and clean up the architecture. He's been cleaning up and standardizing the CHOOSE tags,
                  and touched on the BONUS tags.

                  Clean efficient and clear code is the end goal. Feel free to open that FREQ - NEWTAG 'MODIFY TOKEN'
                  as you want to fix an existing Tag 'SPROP' behavior with Variables.
                  jira.pcgen.org

                  You may also want to check out the Architecture and Code Wiki pages.
                  wiki.pcgen.org



                  > A documentation update would also help. I don't see anything in the SPROP documentation explaining that substitution variables AND the PRExxx tags are evaluated as the display qualifier or the clue Andrew gave in order to force display. The SPROP documentation points to the SAB documentation: "Variable substitution can be used in the same manor as the SA tag" and the SAB documentation says: "The Special Ability will not be displayed if the last variable or formula equals zero." By extension, one might assume this statement also applies the SPROP but this is not the case. SPROP will not display if all of the substitution variables are equal to zero regardless of the value of the last variable or formula. I have not tested the actual SAB behavior.

                  Well, ;) You're free to open a Doc FREQ for that update for the docs

                  jira.pcgen.org


                  > If I decide to pursue this, I will join the developer list. I'm useless in Java and XML but willing to help otherwise if I can.

                  Another point of view is always good.

                  Cheers,

                  > Thanks.
                  >
                  > --- In PCGenListFileHelp@yahoogroups.com, "Barak"<barak@...> wrote:
                  >>> -----Original Message-----
                  >>> As to why this was implemented in this fashion? Again, I cannot say, I
                  >>> wasn't part of the planning
                  >>> process. That is before I joined the team. Should the behavior be re-
                  >> Well I was around then. :p
                  >>
                  >> SPROP didn't take PRExxx back then, and no one wanted to see "Grants 0d6
                  >> additional damage". So if all the variables are 0, the SPROP is not
                  >> displayed.
                  >>
                  >> Barak
                  >>
                  >
                  >
                  >
                  > ------------------------------------
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >

                  --
                  Andrew Maitland (LegacyKing)
                  Admin Silverback - PCGen Board of Directors
                  Data 2nd, Docs Tamarin, OS Lemur
                  Unique Title "Quick-Silverback Tracker Monkey"
                  Unique Title "The Torturer of PCGen"


                  [Non-text portions of this message have been removed]
                Your message has been successfully submitted and would be delivered to recipients shortly.