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

[Pathfinder] Acrobatics (jump)

Expand Messages
  • peacecorpsbrian
    PCGen 5.16.1 on a Mac) I m getting two different skill mods for Acrobatics - one a regular mod of 19, and the other an 18 for Jump. I ve seen split
    Message 1 of 8 , Oct 24, 2009
    • 0 Attachment
      PCGen 5.16.1 on a Mac)

      I'm getting two different skill mods for Acrobatics - one a regular mod of 19, and the other an 18 for Jump. I've seen split Acrobatics/Jump mods before with slower characters (move = 20'), but I'm trying to create a human with move = 30'.

      I tried looking at the "PC Modifier:" line in the Skill Info box but it's CRAZY complicated. For something like Climb it just says "+3[cskill CLIMB gteq 1|skill CLIMB gteq 1|TYPE=CLASSSKILL] +1[STAT]", which I can tell is Class Skill +3, Stat +1.

      But for Acrobatics it says "+3[cskill ACROBATICS gteq 1|skill ACROBATICS gteq 1|TYPE=CLASSSKILL] +5[TYPE=COMPETENCE] +8[Acrobatics] -1[var SKILLINFO("RANK", "ACROBATICS") neq 0|rule DISPLAYSKILLUSE gteq 1|var VAR("SKILL.ACROBATICS (JUMP).MISC") neq VAR("SKILL.ACROBATICS.MISC")] +5[STAT] -7[OTHER]"

      I recognize a few things in there... +3 Class Skill, +5 Competence (Boots of Elvenkind), +5 Stat. Together those plus my 6 ranks give me the correct Skill Mod of 19. But what are the +8 Acrobatics, the -1 Jump Misc., and the -7 Other? I can do the math and see that those generate my lower Jump modifier, but #1 what do the mean, and #2 are they correct? I don't feel like I should have a lower Jump.

      Thanks
    • Andrew Maitland
      peacecorpsbrian wrote: I m not a PF expert - but let s see what we can see here: Acrobatics the primary skill is coming out with a correct modifier of 19.
      Message 2 of 8 , Oct 25, 2009
      • 0 Attachment
        peacecorpsbrian wrote:

        I'm not a PF expert - but let's see what we can see here:

        Acrobatics the primary skill is coming out with a correct modifier of 19.
        (Excellent)


        +3
        [cskill ACROBATICS gteq 1|
        skill ACROBATICS gteq 1|TYPE=CLASSSKILL]
        +5[TYPE=COMPETENCE]
        +8[Acrobatics]

        <<< So far Normal <<<

        -1[var SKILLINFO("RANK", "ACROBATICS") neq 0|rule DISPLAYSKILLUSE gteq 1|var VAR("SKILL.ACROBATICS (JUMP).MISC") neq
        VAR("SKILL.ACROBATICS.MISC")]

        That is a Conditional Skill Modifier = If the Rank in acrobatics does not equal 0 then the -1 is not activated... It's a work around to display any skills that are 'conditional' when a character has a modifier for that skill, but no skill rank. Such is our workaround till we can get things working, however that should not be getting activated. So it's in error IF acrobatics (Jump) is actually displaying less than the Acrobatics skill. Which I think is what you are saying. *Sigh* Something in the formula doesn't like the end result.

        +5[STAT]

        Pcgen will - things out in the background. As long as the end result is correct I wouldn't worry bout that.
        -7[OTHER]



        > PCGen 5.16.1 on a Mac)
        >
        > I'm getting two different skill mods for Acrobatics - one a regular mod of 19, and the other an 18 for Jump. I've seen split Acrobatics/Jump mods before with slower characters (move = 20'), but I'm trying to create a human with move = 30'.
        >
        > I tried looking at the "PC Modifier:" line in the Skill Info box but it's CRAZY complicated. For something like Climb it just says "+3[cskill CLIMB gteq 1|skill CLIMB gteq 1|TYPE=CLASSSKILL] +1[STAT]", which I can tell is Class Skill +3, Stat +1.
        >
        > But for Acrobatics it says "+3[cskill ACROBATICS gteq 1|skill ACROBATICS gteq 1|TYPE=CLASSSKILL] +5[TYPE=COMPETENCE] +8[Acrobatics] -1[var SKILLINFO("RANK", "ACROBATICS") neq 0|rule DISPLAYSKILLUSE gteq 1|var VAR("SKILL.ACROBATICS (JUMP).MISC") neq VAR("SKILL.ACROBATICS.MISC")] +5[STAT] -7[OTHER]"
        >
        > I recognize a few things in there... +3 Class Skill, +5 Competence (Boots of Elvenkind), +5 Stat. Together those plus my 6 ranks give me the correct Skill Mod of 19. But what are the +8 Acrobatics, the -1 Jump Misc., and the -7 Other? I can do the math and see that those generate my lower Jump modifier, but #1 what do the mean, and #2 are they correct? I don't feel like I should have a lower Jump.
        >
        > Thanks
        >
        >
        >
        >

        --

        Andrew Maitland (LegacyKing)
        Admin Silverback, PCGen Board of Directors
        Data Chimp, Docs Tamarin
        Unique Title "Quick-Silverback Tracker Monkey"
      • Andrew Maitland
        ... I think I ve nailed it down after doing some tests: PREVARNEQ is having issues... I ve replaced it with PREMULT:1,[PREVARGT:var( SKILL.Blah
        Message 3 of 8 , Oct 25, 2009
        • 0 Attachment
          Andrew Maitland wrote:
          > peacecorpsbrian wrote:
          >
          > I'm not a PF expert - but let's see what we can see here:
          >
          > Acrobatics the primary skill is coming out with a correct modifier of 19.
          > (Excellent)
          >
          >
          > +3
          > [cskill ACROBATICS gteq 1|
          > skill ACROBATICS gteq 1|TYPE=CLASSSKILL]
          > +5[TYPE=COMPETENCE]
          > +8[Acrobatics]
          >
          > <<< So far Normal <<<
          >
          > -1[var SKILLINFO("RANK", "ACROBATICS") neq 0|rule DISPLAYSKILLUSE gteq 1|var VAR("SKILL.ACROBATICS (JUMP).MISC") neq
          > VAR("SKILL.ACROBATICS.MISC")]
          >
          > That is a Conditional Skill Modifier = If the Rank in acrobatics does not equal 0 then the -1 is not activated... It's a work around to display any skills that are 'conditional' when a character has a modifier for that skill, but no skill rank. Such is our workaround till we can get things working, however that should not be getting activated. So it's in error IF acrobatics (Jump) is actually displaying less than the Acrobatics skill. Which I think is what you are saying. *Sigh* Something in the formula doesn't like the end result.
          >
          > +5[STAT]
          >
          > Pcgen will - things out in the background. As long as the end result is correct I wouldn't worry bout that.
          > -7[OTHER]
          >
          >
          >
          >
          >> PCGen 5.16.1 on a Mac)
          >>
          >> I'm getting two different skill mods for Acrobatics - one a regular mod of 19, and the other an 18 for Jump. I've seen split Acrobatics/Jump mods before with slower characters (move = 20'), but I'm trying to create a human with move = 30'.
          >>
          >> I tried looking at the "PC Modifier:" line in the Skill Info box but it's CRAZY complicated. For something like Climb it just says "+3[cskill CLIMB gteq 1|skill CLIMB gteq 1|TYPE=CLASSSKILL] +1[STAT]", which I can tell is Class Skill +3, Stat +1.
          >>
          >> But for Acrobatics it says "+3[cskill ACROBATICS gteq 1|skill ACROBATICS gteq 1|TYPE=CLASSSKILL] +5[TYPE=COMPETENCE] +8[Acrobatics] -1[var SKILLINFO("RANK", "ACROBATICS") neq 0|rule DISPLAYSKILLUSE gteq 1|var VAR("SKILL.ACROBATICS (JUMP).MISC") neq VAR("SKILL.ACROBATICS.MISC")] +5[STAT] -7[OTHER]"
          >>
          >> I recognize a few things in there... +3 Class Skill, +5 Competence (Boots of Elvenkind), +5 Stat. Together those plus my 6 ranks give me the correct Skill Mod of 19. But what are the +8 Acrobatics, the -1 Jump Misc., and the -7 Other? I can do the math and see that those generate my lower Jump modifier, but #1 what do the mean, and #2 are they correct? I don't feel like I should have a lower Jump.
          >>
          >> Thanks
          >>
          >>
          >>
          >>
          >>
          >
          >


          I think I've nailed it down after doing some tests:

          PREVARNEQ is having issues... I've replaced it with
          PREMULT:1,[PREVARGT:var("SKILL.Blah
          (Sub).TOTAL"),var("SKILL.Blah.TOTAL],[PREVARLT:var("SKILL.SKILL.Blah
          (Sub).MISC"),var("SKILL.Blah.MISC")]

          And that seems to do the trick on my end. Apparently NEQ is the trouble
          child each time I used it, I'd get the freeze loop. Replacing it with
          that should solve the ongoing issue

          Reasoning - I figure, MISC bonus is going to be less in the Sub Skill,
          so use LT for that, and then GT for the TOTAL.

          Anyways, I'll let Stefan evaluate this for the PF set.

          --

          Andrew Maitland (LegacyKing)
          Admin Silverback, PCGen Board of Directors
          Data Chimp, Docs Tamarin
          Unique Title "Quick-Silverback Tracker Monkey"



          [Non-text portions of this message have been removed]
        • ovka
          ... I ve had similar issues with !PREVARGTEQ. I have an ability with a variable that gets defined. The variable is bonused elsewhere. This ability
          Message 4 of 8 , Oct 26, 2009
          • 0 Attachment
            > I think I've nailed it down after doing some tests:
            >
            >PREVARNEQ is having issues... I've replaced it with
            >PREMULT:1,[PREVARGT:var("SKILL.Blah
            >(Sub).TOTAL"),var("SKILL.Blah.TOTAL],[PREVARLT:var("SKILL.SKILL.Blah
            >(Sub).MISC"),var("SKILL.Blah.MISC")]
            >
            >And that seems to do the trick on my end. Apparently NEQ is the
            >trouble
            >child each time I used it, I'd get the freeze loop. Replacing it
            >with
            >that should solve the ongoing issue
            >
            >Reasoning - I figure, MISC bonus is going to be less in the Sub
            >Skill,
            >so use LT for that, and then GT for the TOTAL.

            I've had similar issues with !PREVARGTEQ. I have an ability with a variable that gets defined. The variable is bonused elsewhere. This ability conditially grants two other abilities like this:

            DEFINE:myVar|0
            ABILITY:yadayada1|PREVARGTEQ:myVar,1
            ABILITY:yadayada2|!PREVARGTEQ:myVar,1

            When myVar = 0, yadayada2 is granted as it should be. When myVar = 1, both yadayada1 and yadayada2 are granted. If I remember correctly, I tested with

            ABILITY:yadayada2|PREVARLT:myVar,1

            and got the same results. The problem is that it PREVAR seems to work for me in most cases, so I haven't been able to isolate the problem.

            I'm using 5.16.1.

            Cheers,

            Sir George Anonymous
          • ovka
            ... I tried changing the PREVAR tags to just about every different combination possible (including wrapping them in PREMULTS and rearranging the order of
            Message 5 of 8 , Oct 27, 2009
            • 0 Attachment
              >DEFINE:myVar|0
              >ABILITY:yadayada1|PREVARGTEQ:myVar,1
              >ABILITY:yadayada2|!PREVARGTEQ:myVar,1
              >
              >When myVar = 0, yadayada2 is granted as it should be. When myVar =
              >1, both yadayada1 and yadayada2 are granted.
              >
              >I'm using 5.16.1.

              I tried changing the PREVAR tags to just about every different combination possible (including wrapping them in PREMULTS and rearranging the order of several tags), and got the same results for this. Then I added

              DEFINE:mySecondVar|0
              BONUS:VAR|mySecondVar|1-myVar

              and changed the second ABILITY tag to be

              ABILITY:yadayada2|PREVARGTEQ:mySecondVar,1

              It worked after that. It seems like using a single variable to choose between two mutually exclusive ability tags doesn't work properly. It *does* work when you have

              ABILITY:yadayada1|PREVARGTEQ:myVar,2
              ABILITY:yadayada2|PREVARGTEQ:myVar,4
              ABILITY:yadayada3|PREVARGTEQ:myVar,6

              Hopefully someone can use this information to squash a bug.

              Cheers,

              Sir George Anonymous
            • Andrew Maitland
              ... Thanks, Sir George... I think there is something up in the vars. I ll add it to a tracker. -- Andrew Maitland (LegacyKing) Admin Silverback, PCGen Board of
              Message 6 of 8 , Oct 27, 2009
              • 0 Attachment
                ovka wrote:
                >> DEFINE:myVar|0
                >> ABILITY:yadayada1|PREVARGTEQ:myVar,1
                >> ABILITY:yadayada2|!PREVARGTEQ:myVar,1
                >>
                >> When myVar = 0, yadayada2 is granted as it should be. When myVar =
                >> 1, both yadayada1 and yadayada2 are granted.
                >>
                >> I'm using 5.16.1.
                >>
                >
                > I tried changing the PREVAR tags to just about every different combination possible (including wrapping them in PREMULTS and rearranging the order of several tags), and got the same results for this. Then I added
                >
                > DEFINE:mySecondVar|0
                > BONUS:VAR|mySecondVar|1-myVar
                >
                > and changed the second ABILITY tag to be
                >
                > ABILITY:yadayada2|PREVARGTEQ:mySecondVar,1
                >
                > It worked after that. It seems like using a single variable to choose between two mutually exclusive ability tags doesn't work properly. It *does* work when you have
                >
                > ABILITY:yadayada1|PREVARGTEQ:myVar,2
                > ABILITY:yadayada2|PREVARGTEQ:myVar,4
                > ABILITY:yadayada3|PREVARGTEQ:myVar,6
                >
                > Hopefully someone can use this information to squash a bug.
                >
                > Cheers,
                >
                > Sir George Anonymous
                >
                >
                >
                >
                Thanks, Sir George... I think there is something up in the vars. I'll
                add it to a tracker.

                --

                Andrew Maitland (LegacyKing)
                Admin Silverback, PCGen Board of Directors
                Data Chimp, Docs Tamarin
                Unique Title "Quick-Silverback Tracker Monkey"



                [Non-text portions of this message have been removed]
              • Andrew Maitland
                2887533 PREVAR using the same VAR has issues [Non-text portions of this
                Message 7 of 8 , Oct 27, 2009
                • 0 Attachment
                  2887533 PREVAR using the same VAR has issues
                  <https://sourceforge.net/tracker/?func=detail&aid=2887533&group_id=25576&atid=384719>



                  [Non-text portions of this message have been removed]
                • thpr
                  ... Tom1 ABILITY:FEAT|NORMAL|Tom2|PREVARGTEQ:myVar,1 ABILITY:FEAT|NORMAL|Tom3|!PREVARGTEQ:myVar,1 Tom2 SAB:WooHoo Tom3 SAB:WooHoo2 TomVar1 DEFINE:myVar|0
                  Message 8 of 8 , Oct 30, 2009
                  • 0 Attachment
                    --- In pcgen@yahoogroups.com, "ovka" <lpacdavis@...> wrote:
                    >
                    > >DEFINE:myVar|0
                    > >ABILITY:yadayada1|PREVARGTEQ:myVar,1
                    > >ABILITY:yadayada2|!PREVARGTEQ:myVar,1
                    > >
                    > >When myVar = 0, yadayada2 is granted as it should be. When myVar =
                    > >1, both yadayada1 and yadayada2 are granted.

                    Tom1 ABILITY:FEAT|NORMAL|Tom2|PREVARGTEQ:myVar,1 ABILITY:FEAT|NORMAL|Tom3|!PREVARGTEQ:myVar,1
                    Tom2 SAB:WooHoo
                    Tom3 SAB:WooHoo2
                    TomVar1 DEFINE:myVar|0
                    TomVar2 BONUS:VAR|myVar|1
                    TomVar3 BONUS:VAR|myVar|1

                    works just fine for me.

                    I can apply:
                    TomVar1
                    Tom1
                    and get
                    Tom3 added

                    TomVar1
                    Tom1
                    TomVar2
                    and get
                    Tom2 added


                    Therefore, I cannot reproduce the issue as described in either the Trunk or 5.16 branch.

                    Can someone please pull together a dataset and specific instructions to reproduce the issue? It appears more complicated than implied by this thread.

                    TP.
                  Your message has been successfully submitted and would be delivered to recipients shortly.