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

Re: SPROP substitution value issue

Expand Messages
  • 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 1 of 9 , Feb 1, 2011
    View Source
    • 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 2 of 9 , Feb 1, 2011
      View Source
      • 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 3 of 9 , Feb 1, 2011
        View Source
        • 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 4 of 9 , Feb 1, 2011
          View Source
          • 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 5 of 9 , Feb 1, 2011
            View Source
            • 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 6 of 9 , Feb 1, 2011
              View Source
              • 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.