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

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

Expand Messages
  • 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 1 of 6 , Nov 4, 2008
      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 2 of 6 , Nov 5, 2008
        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 3 of 6 , Nov 5, 2008
          --- 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 4 of 6 , Nov 6, 2008
            >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 5 of 6 , Nov 6, 2008
              --- 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.