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

[ 1687659 ] Eq Customizer ignores PLUS: Token restrictions after removal

Expand Messages
  • Dan Parks
    What is the correct behavior? Should removing the plus auto remove all dependencies? Or should you not be able to remove the plus until dependencies are
    Message 1 of 6 , Nov 4, 2008
    • 0 Attachment
      What is the correct behavior?

      Should removing the plus auto remove all dependencies? Or should you
      not be able to remove the plus until dependencies are resolved?

      re:

      Weapon Editor does not enforce PLUS when removing the + modifier.

      e.g. you can:

      Customize Longsword
      - Bane is not available
      Make it +1
      - Bane is now available
      Add Bane(Dragons)
      Remove +1, leaving Bane
      - Except Bane should be illegal
    • Michael W. Fender
      ... Let s rephrase this... Should removing the requirement auto remove all dependencies? Or should you not be able to remove the requirement until
      Message 2 of 6 , Nov 4, 2008
      • 0 Attachment
        On Tuesday 04 November 2008 03:47:40 pm Dan Parks wrote:
        > What is the correct behavior?
        >
        > Should removing the plus auto remove all dependencies? Or should you
        > not be able to remove the plus until dependencies are resolved?

        Let's rephrase this...
        Should removing the requirement auto remove all dependencies? Or should you
        not be able to remove the requirement until dependencies are resolved?

        > re:
        >
        > Weapon Editor does not enforce PLUS when removing the + modifier.
        >
        > e.g. you can:
        >
        > Customize Longsword
        > - Bane is not available
        > Make it +1
        > - Bane is now available
        > Add Bane(Dragons)
        > Remove +1, leaving Bane
        > - Except Bane should be illegal

        How does a sword end up losing its +1 to begin with. Honestly, this is
        unexpected behavior... HOWEVER, there's a flip side where having the Bane
        property without a +1 would be acceptable, and that's a house rule. But I
        digress...

        The way I see it is how Dodge, Mobility, Spring Attack, and Whirlwind Attack
        should be operating (and I believe the tags to implement this is in the
        works). If you lose one prerequisite, you can't use the higher feats. If
        you lose Mobility, you cannot use Spring Attack or Whirlwind Attack until
        Mobility is restored.

        So with the weapon, if the +1 gets removed, the Bane should be disabled until
        the +1 (or +2, +3, etc.) gets reinstated. Your Dragonslayer should just act
        like a regular Longsword.
        --
        Fluxxdog

        The worst crime you can commit against another human being is to make them
        think.
      • Martijn Verburg
        Hi all, ... This would be the ideal way to deal with this case, I m not sure how much support the item customizer has for that though (in terms of making the
        Message 3 of 6 , Nov 5, 2008
        • 0 Attachment
          Hi all,

          > The way I see it is how Dodge, Mobility, Spring Attack, and
          > Whirlwind Attack should be operating (and I believe the tags to
          > implement this is in the works). If you lose one prerequisite, you
          > can't use the higher feats. If you lose Mobility, you cannot use
          > Spring Attack or Whirlwind Attack until Mobility is restored.
          >
          > So with the weapon, if the +1 gets removed, the Bane should be
          > disabled until the +1 (or +2, +3, etc.) gets reinstated. Your
          > Dragonslayer should just act like a regular Longsword.

          This would be the ideal way to deal with this case, I'm not sure how
          much support the item customizer has for that though (in terms of
          making the item on the RHS of the pane invalid because you've taken
          away a pre req). There is the concept of qualifying so I'm guessing
          you could loop back through the list of items on the RHS and make sure
          they still qualify after you take something away.

          This is a great bug to fix BTW so keep posting here or on dev if you
          need further assistance!

          K
        • Tom Parker
          ... Actually, I think the ideal would be to flag it as a rules violation, but not remove or disable it. Basically give an indication to the user that they can
          Message 4 of 6 , Nov 5, 2008
          • 0 Attachment
            --- In pcgen@yahoogroups.com, "Martijn Verburg" <martijnverburg@...>
            wrote:
            > > So with the weapon, if the +1 gets removed, the Bane should be
            > > disabled until the +1 (or +2, +3, etc.) gets reinstated. Your
            > > Dragonslayer should just act like a regular Longsword.
            >
            > This would be the ideal way to deal with this case,

            Actually, I think the ideal would be to flag it as a rules violation,
            but not remove or disable it. Basically give an indication to the
            user that they can have this combination *if they want*, but that it's
            not normal. This goes back to the "don't prohibit anything"
            philosophy, since being super-rules-strict is a pain... notify of the
            rules violation, but make the user fix it if they want to fix it.

            > I'm not sure how
            > much support the item customizer has for that though (in terms of
            > making the item on the RHS of the pane invalid because you've taken
            > away a pre req). There is the concept of qualifying so I'm guessing
            > you could loop back through the list of items on the RHS and make sure
            > they still qualify after you take something away.

            I agree this will be an interesting challenge, but a good one to address.

            TP.
          • ovka
            ... What s the point of coding a rule into a dataset if you are going to ignore it? Isn t the normal process to allow for bypassing of rules to include a
            Message 5 of 6 , Nov 6, 2008
            • 0 Attachment
              >Actually, I think the ideal would be to flag it as a rules violation,
              >but not remove or disable it. Basically give an indication to the
              >user that they can have this combination *if they want*, but that
              >it's
              >not normal. This goes back to the "don't prohibit anything"
              >philosophy, since being super-rules-strict is a pain... notify of the
              >rules violation, but make the user fix it if they want to fix it.

              What's the point of coding a rule into a dataset if you are going to
              ignore it? Isn't the normal process to allow for bypassing of rules to
              include a checkbox in the house-rules section?

              Cheers,

              Sir George Anonymous
            • Tom Parker
              ... 1) Ease of use. Assuming the user coded the rule into the dataset is a bad assumption. I would assert most users use our datasets without modification,
              Message 6 of 6 , Nov 6, 2008
              • 0 Attachment
                --- In pcgen@yahoogroups.com, "ovka" <lpacdavis@...> wrote:
                > What's the point of coding a rule into a dataset if you are going to
                > ignore it?

                1) Ease of use. Assuming the user coded the rule into the dataset is
                a bad assumption. I would assert most users use our datasets without
                modification, which means they are not familiar with LST and want the
                program to "just work".

                2) Flexibility. There have been posts here and elsewhere about
                getting flexibility and not having PCGen enforce the rules at the
                expense of the user. This isn't law - the rules should be bendable.

                > Isn't the normal process to allow for bypassing of rules to
                > include a checkbox in the house-rules section?

                Normal does not necessarily imply good, and I was reacting as much to
                Karianna's use of "ideal" as I was to the question of "what should be
                done in 5.16?". Like many things I believe we should do, this one may
                not appear in the ideal state in 5.16. So be it. We have to
                prioritize what we do. However, I will remain of the opinion that the
                user is first, and we need to give flexibility to that user without
                requiring explicit action by the code team.

                My issue with the existing house rules section is that it's not
                flexible. Effectively, it's code overhead - we have to add a
                preference to the preference UI, storage into the options file, and
                allow that preference to have an impact in the code (which often makes
                the code harder to read and follow). It is - in my opinion - a huge
                inhibitor to having a house rule. If every house rule has to run
                through the code team, then we've defeated the concept of a "house
                rule" and made it a "world-wide rule you can apply in your house".
                There's a difference there, and one I hope we can someday resolve.

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