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

Re: [PCGenListFileHelp] Modding ABILITYCATEGORYs

Expand Messages
  • Michael W. Fender
    Accessing archive from Eddy Anthony ... Archive found in file ... The class this is going for is allowed a choice of bonuses feats limited to Wizards feats,
    Message 1 of 22 , Feb 8, 2009
    • 0 Attachment
      Accessing archive from "Eddy Anthony"...
      Archive found in file
      > Michael W. Fender scribed:
      > > This seems simple enough, but I don't see .MOD in the docs. Is the
      > > following possible/allowed in an ABILITYCATEGORY file or am I going to
      > > have to put a FReq in for it?
      > >
      > > ABILITYCATEGORY:Wizard Feat.MOD TYPE:Whatever
      > >
      > > The basic premise is to allow a new TYPE of feat for the Wizard Feat
      > > pool. And before you say "Well, just put TYPE:Wizard in the feat",
      > > there's a very good reason why I don't want to do that.
      >
      > OK, but what is it?

      The class this is going for is allowed a choice of bonuses feats limited to
      Wizards feats, but none of the broad categories. For example, ItemCreation,
      Metamagic, or (from Complete Mage) Reserve feats are not allowable choices. In
      other words, TYPE:Wizard. Honestly, this also brings up the issue of the
      redundancy of labeling Brew Potion (and other such feats) as both an
      ItemCreation and Wizard feat since the ABILITYCATEGORY already defines those
      types as inclusive, but that's for another day ^^

      > Offhand that looks like the easiest way to go. I take
      > it you tried MODing ABILITYCATEGORY and it didn't work?

      No, I hadn't. I went to make sure it was allowable first, since I've been
      told "If it's not in the docs, it shouldn't work" and since I didn't see
      mention in the docs, I figured I'd ask. And for the record, when I try this
      line:

      ABILITYCATEGORY:Wizard Feat.MOD TYPE:Fighter

      ...I get this error:

      LSTERROR TYPE is not valid in 'parent' category Wizard Feat.MOD of
      file:/home/fluxxdog/pcgen/data/homebrew/massive/FeatsAbil/NewAbilityCat.lst.
      --
      Fluxxdog

      The worst crime you can commit against another human being is to make them
      think.
    • Eddy Anthony
      ... So you are trying to MOD the Wizard Feat pool to remove TYPE:ItemCreation.Metamagic from it? Doesn t seem the right way to go, why no just make a new pool
      Message 2 of 22 , Feb 8, 2009
      • 0 Attachment
        Michael W. Fender scribed:

        >>> The basic premise is to allow a new TYPE of feat for the Wizard Feat
        >>> pool. And before you say "Well, just put TYPE:Wizard in the feat",
        >>> there's a very good reason why I don't want to do that.
        >>
        >> OK, but what is it?
        >
        > The class this is going for is allowed a choice of bonuses feats limited to
        > Wizards feats, but none of the broad categories. For example, ItemCreation,
        > Metamagic, or (from Complete Mage) Reserve feats are not allowable choices. In
        > other words, TYPE:Wizard.

        So you are trying to MOD the Wizard Feat pool to remove
        TYPE:ItemCreation.Metamagic from it?

        Doesn't seem the right way to go, why no just make a new pool for this class
        that is JUST TYPE:Wizard?

        If you are MODing the Wizard class for a campaign setting of something you
        can use negative numbers in BONUS:ABILITYPOOL so it won't get the standard
        pool and then add the replacement pool.

        > Honestly, this also brings up the issue of the
        > redundancy of labeling Brew Potion (and other such feats) as both an
        > ItemCreation and Wizard feat since the ABILITYCATEGORY already defines those
        > types as inclusive, but that's for another day ^^

        Probably it was to make the ADD:FEAT tag we used to use for that short and
        sweet.

        >> Offhand that looks like the easiest way to go. I take
        >> it you tried MODing ABILITYCATEGORY and it didn't work?
        >
        > No, I hadn't. I went to make sure it was allowable first, since I've been
        > told "If it's not in the docs, it shouldn't work" and since I didn't see
        > mention in the docs, I figured I'd ask. And for the record, when I try this
        > line:
        >
        > ABILITYCATEGORY:Wizard Feat.MOD TYPE:Fighter
        >
        > ...I get this error:
        >
        > LSTERROR TYPE is not valid in 'parent' category Wizard Feat.MOD of
        > file:/home/fluxxdog/pcgen/data/homebrew/massive/FeatsAbil/NewAbilityCat.lst.

        So it doesn't work but really I don't see a need for it as there are easy
        way around that as I suggested above.
        --
        ~ Eddy Anthony (MoSaT)
        ~ PCGen Board of Directors
        ~ Content Silverback, Chair Second
      • Michael W. Fender
        Accessing archive from Eddy Anthony ... Archive found in file ... No... ... That s what I m trying to do, but in order to make sure the Wizard has access to
        Message 3 of 22 , Feb 8, 2009
        • 0 Attachment
          Accessing archive from "Eddy Anthony"...
          Archive found in file
          > Michael W. Fender scribed:
          > >>> The basic premise is to allow a new TYPE of feat for the Wizard Feat
          > >>> pool. And before you say "Well, just put TYPE:Wizard in the feat",
          > >>> there's a very good reason why I don't want to do that.
          > >>
          > >> OK, but what is it?
          > >
          > > The class this is going for is allowed a choice of bonuses feats limited
          > > to Wizards feats, but none of the broad categories. For example,
          > > ItemCreation, Metamagic, or (from Complete Mage) Reserve feats are not
          > > allowable choices. In other words, TYPE:Wizard.
          >
          > So you are trying to MOD the Wizard Feat pool to remove
          > TYPE:ItemCreation.Metamagic from it?

          No...

          > Doesn't seem the right way to go, why no just make a new pool for this
          > class that is JUST TYPE:Wizard?

          That's what I'm trying to do, but in order to make sure the Wizard has access
          to the appropriate feats, I have to be able to MOD the Wizard Feat
          ABILITYCATEGORY so he has access to the new TYPEs of feats he's supposed to
          have access to while the other class doesn't.

          I should end up having something like this:
          ABILITYCATEGORY:Wizard Feat.MOD TYPE:Whatever.New.Stuff.Reserve
          ABILITYCATEGORY:New Class Feat TYPE:Wizard

          > > Honestly, this also brings up the issue of the
          > > redundancy of labeling Brew Potion (and other such feats) as both an
          > > ItemCreation and Wizard feat since the ABILITYCATEGORY already defines
          > > those types as inclusive, but that's for another day ^^
          >
          > Probably it was to make the ADD:FEAT tag we used to use for that short and
          > sweet.

          So would it be OK to put in a DATA FReq to remove that redundancy? Keep the
          code neat and appropriate to the rules and all that. For example, with the
          RSRD:
          "At 5th, 10th, 15th, and 20th level, a wizard gains a bonus feat. At each such
          opportunity, she can choose a metamagic feat, an item creation feat, or Spell
          Mastery."
          ...meaning Spell Mastery really should be the only feat in the basics listed
          as a TYPE:Wizard feat. Since we have the pools, I'd think this would be the
          better way to go. And such a clean up should not affect any characters since
          the feat pools were implemented since all the ItemCreation and Metamagic feats
          qualify on those types regardless of the Wizard type.

          > >> Offhand that looks like the easiest way to go. I take
          > >> it you tried MODing ABILITYCATEGORY and it didn't work?
          > >
          > > No, I hadn't. I went to make sure it was allowable first, since I've
          > > been told "If it's not in the docs, it shouldn't work" and since I didn't
          > > see mention in the docs, I figured I'd ask. And for the record, when I
          > > try this line:
          > >
          > > ABILITYCATEGORY:Wizard Feat.MOD TYPE:Fighter
          > >
          > > ...I get this error:
          > >
          > > LSTERROR TYPE is not valid in 'parent' category Wizard Feat.MOD of
          > > file:/home/fluxxdog/pcgen/data/homebrew/massive/FeatsAbil/NewAbilityCat.l
          > >st.
          >
          > So it doesn't work but really I don't see a need for it as there are easy
          > way around that as I suggested above.

          See above...
          --
          Fluxxdog

          The worst crime you can commit against another human being is to make them
          think.
        • Eddy Anthony
          ... OK so why involve the Wizard pool at all? Just make a new pool and a new type for that pool and MOD the feats with the new type. The sole purpose of the
          Message 4 of 22 , Feb 8, 2009
          • 0 Attachment
            Michael W. Fender scribed:

            >> Doesn't seem the right way to go, why no just make a new pool for this
            >> class that is JUST TYPE:Wizard?
            >
            > That's what I'm trying to do, but in order to make sure the Wizard has access
            > to the appropriate feats, I have to be able to MOD the Wizard Feat
            > ABILITYCATEGORY so he has access to the new TYPEs of feats he's supposed to
            > have access to while the other class doesn't.

            OK so why involve the Wizard pool at all? Just make a new pool and a new
            type for that pool and MOD the feats with the new type.

            The sole purpose of the Wizard type is to make a feat part of the Wizard
            bonus feat list, it sounds like you are trying to expand that usage.
            --
            ~ Eddy Anthony (MoSaT)
            ~ PCGen Board of Directors
            ~ Content Silverback, Chair Second
          • Michael W. Fender
            Accessing archive from Eddy Anthony ... Archive found in file ... Heh, here s the funny part about that... That d mean going through over 50 sources we use
            Message 5 of 22 , Feb 8, 2009
            • 0 Attachment
              Accessing archive from "Eddy Anthony"...
              Archive found in file
              > Michael W. Fender scribed:
              > >> Doesn't seem the right way to go, why no just make a new pool for this
              > >> class that is JUST TYPE:Wizard?
              > >
              > > That's what I'm trying to do, but in order to make sure the Wizard has
              > > access to the appropriate feats, I have to be able to MOD the Wizard Feat
              > > ABILITYCATEGORY so he has access to the new TYPEs of feats he's supposed
              > > to have access to while the other class doesn't.
              >
              > OK so why involve the Wizard pool at all? Just make a new pool and a new
              > type for that pool and MOD the feats with the new type.
              >
              > The sole purpose of the Wizard type is to make a feat part of the Wizard
              > bonus feat list, it sounds like you are trying to expand that usage.

              Heh, here's the funny part about that... That'd mean going through over 50
              sources we use and altering those feats in each one, not to mention making
              sure future additions abide by that as well. I'm not trying to reinvent the
              wheel here, I'm just trying to smooth the edges :)

              In any case, using MOD for an ABILITYCATEGORY is going to have be a FReq,
              right?
              --
              Fluxxdog

              The worst crime you can commit against another human being is to make them
              think.
            • Andrew Maitland
              Yes, that would be a FREQ. Might as well go the full mile if you re going to freq this: Add .MOD to ABILITYCATEGORY Add .CLEAR to ABILITYCATEGORY Add .COPY to
              Message 6 of 22 , Feb 8, 2009
              • 0 Attachment
                Yes, that would be a FREQ.

                Might as well go the full mile if you're going to freq this:

                Add .MOD to ABILITYCATEGORY
                Add .CLEAR to ABILITYCATEGORY
                Add .COPY to ABILITYCATEGORY

                Does that cover your foreseeable needs?

                Let me know if this is what we want.

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



                Michael W. Fender wrote:
                > Accessing archive from "Eddy Anthony"...
                > Archive found in file
                >
                >> Michael W. Fender scribed:
                >>
                >>>> Doesn't seem the right way to go, why no just make a new pool for this
                >>>> class that is JUST TYPE:Wizard?
                >>>>
                >>> That's what I'm trying to do, but in order to make sure the Wizard has
                >>> access to the appropriate feats, I have to be able to MOD the Wizard Feat
                >>> ABILITYCATEGORY so he has access to the new TYPEs of feats he's supposed
                >>> to have access to while the other class doesn't.
                >>>
                >> OK so why involve the Wizard pool at all? Just make a new pool and a new
                >> type for that pool and MOD the feats with the new type.
                >>
                >> The sole purpose of the Wizard type is to make a feat part of the Wizard
                >> bonus feat list, it sounds like you are trying to expand that usage.
                >>
                >
                > Heh, here's the funny part about that... That'd mean going through over 50
                > sources we use and altering those feats in each one, not to mention making
                > sure future additions abide by that as well. I'm not trying to reinvent the
                > wheel here, I'm just trying to smooth the edges :)
                >
                > In any case, using MOD for an ABILITYCATEGORY is going to have be a FReq,
                > right?
                >


                [Non-text portions of this message have been removed]
              • Eddy Anthony
                ... I don t follow. What would mean making this large number of changes? Perhaps some confusion follows from the fact that types are used for different things.
                Message 7 of 22 , Feb 8, 2009
                • 0 Attachment
                  Michael W. Fender scribed:

                  > Accessing archive from "Eddy Anthony"...
                  > Archive found in file
                  >> Michael W. Fender scribed:
                  >>>> Doesn't seem the right way to go, why no just make a new pool for this
                  >>>> class that is JUST TYPE:Wizard?
                  >>>
                  >>> That's what I'm trying to do, but in order to make sure the Wizard has
                  >>> access to the appropriate feats, I have to be able to MOD the Wizard Feat
                  >>> ABILITYCATEGORY so he has access to the new TYPEs of feats he's supposed
                  >>> to have access to while the other class doesn't.
                  >>
                  >> OK so why involve the Wizard pool at all? Just make a new pool and a new
                  >> type for that pool and MOD the feats with the new type.
                  >>
                  >> The sole purpose of the Wizard type is to make a feat part of the Wizard
                  >> bonus feat list, it sounds like you are trying to expand that usage.
                  >
                  > Heh, here's the funny part about that... That'd mean going through over 50
                  > sources we use and altering those feats in each one, not to mention making
                  > sure future additions abide by that as well. I'm not trying to reinvent the
                  > wheel here, I'm just trying to smooth the edges :)

                  I don't follow. What would mean making this large number of changes?

                  Perhaps some confusion follows from the fact that types are used for
                  different things. General, Itemcreation and Metamagic represent groups of
                  feats defined by the Source text, while Fighter and Wizard are types we data
                  monkeys have created to group bonus feat pools. Game wise there are no
                  Wizard type feats, only feats Wizards can take as a bonus feat. So a feat
                  that has Wizard.Itemcreation is not really a redundancy as it is an
                  overlapping of purposes.

                  > In any case, using MOD for an ABILITYCATEGORY is going to have be a FReq,
                  > right?

                  Yes, I'm just unconvinced of it's need.
                  --
                  ~ Eddy Anthony (MoSaT)
                  ~ PCGen Board of Directors
                  ~ Content Silverback, Chair Second
                • Michael W. Fender
                  Accessing archive from Eddy Anthony ... Archive found in file ... My groups have access to over 50 sources that we use for our campaigns that I have to code
                  Message 8 of 22 , Feb 8, 2009
                  • 0 Attachment
                    Accessing archive from "Eddy Anthony"...
                    Archive found in file
                    > Michael W. Fender scribed:
                    > > Accessing archive from "Eddy Anthony"...
                    > > Archive found in file
                    > >
                    > >> Michael W. Fender scribed:
                    > >>>> Doesn't seem the right way to go, why no just make a new pool for this
                    > >>>> class that is JUST TYPE:Wizard?
                    > >>>
                    > >>> That's what I'm trying to do, but in order to make sure the Wizard has
                    > >>> access to the appropriate feats, I have to be able to MOD the Wizard
                    > >>> Feat ABILITYCATEGORY so he has access to the new TYPEs of feats he's
                    > >>> supposed to have access to while the other class doesn't.
                    > >>
                    > >> OK so why involve the Wizard pool at all? Just make a new pool and a new
                    > >> type for that pool and MOD the feats with the new type.
                    > >>
                    > >> The sole purpose of the Wizard type is to make a feat part of the Wizard
                    > >> bonus feat list, it sounds like you are trying to expand that usage.
                    > >
                    > > Heh, here's the funny part about that... That'd mean going through over
                    > > 50 sources we use and altering those feats in each one, not to mention
                    > > making sure future additions abide by that as well. I'm not trying to
                    > > reinvent the wheel here, I'm just trying to smooth the edges :)
                    >
                    > I don't follow. What would mean making this large number of changes?

                    My groups have access to over 50 sources that we use for our campaigns that I
                    have to code fore, a lot of the WotC material.

                    > Perhaps some confusion follows from the fact that types are used for
                    > different things. General, Itemcreation and Metamagic represent groups of
                    > feats defined by the Source text, while Fighter and Wizard are types we
                    > data monkeys have created to group bonus feat pools. Game wise there are no
                    > Wizard type feats, only feats Wizards can take as a bonus feat. So a feat
                    > that has Wizard.Itemcreation is not really a redundancy as it is an
                    > overlapping of purposes.

                    As things work now, having TYPE:Wizard identifies it as part of the Wizard
                    Feat pool. Having TYPE:ItemCreation identifies it as part of the Wizard Feat
                    pool. If the only purpose of TYPE:Wizard is to identify it as part of the
                    Wizard Feat pool, then having TYPE:Wizard.ItemCreation makes the Wizard type
                    redundant. Actually, unnecessary.

                    It's also inconsistent. The RSRD lists feats as Wizard.Metamagic or
                    Wizard.ItemCreation, but other sources don't add the Wizard type. For
                    example:

                    /data/d20ogl/fantasyflightgames/legendsandlairs/spellsandspellcraft/spellsspellcraft_feats.lst
                    ItemCreation feats are not typed as Wizard feats

                    > > In any case, using MOD for an ABILITYCATEGORY is going to have be a FReq,
                    > > right?
                    >
                    > Yes, I'm just unconvinced of it's need.

                    I found the book of Eldritch Might. This is an example of where a MOD could
                    be used easily. Eldritch feats can be chosen as Wizard bonus feats simply by
                    TYPE:Eldritch. Why should dozens of adjustments be made to implement one
                    adjustment? The rule of "Wizard may choose Eldritch feats" is suggested as
                    optional. A person should be able to have such a simple adjustment at hand.
                    Why MOD every single Eldritch feat to allow a Wizard to choose it when a MOD
                    to the Wizard Feat ABILITYCATEGORY will not only ensure those work properly
                    but future ones without having to detail future feats? "Why is this new
                    Eldritch feat I made not showing up for my Wizard? All the other do!"
                    MODding the ABILITYCATEGORY would take care of that for good.

                    Base line is, making the MOD available in such a manner can make the LST
                    coding easier for home users, kinda like how templates are routinely used to
                    implement different house rules.
                    --
                    Fluxxdog

                    The worst crime you can commit against another human being is to make them
                    think.
                  • Tir Gwaith
                    ... I am. Pathfinder has the ABILITYLIST tag, which specifies a set a feats w/ specific choices of those feats. If I want to modify the Fey Bloodline, I d have
                    Message 9 of 22 , Feb 8, 2009
                    • 0 Attachment
                      >> In any case, using MOD for an ABILITYCATEGORY is going to have be a FReq,
                      >> right?
                      >
                      > Yes, I'm just unconvinced of it's need.

                      I am.

                      Pathfinder has the ABILITYLIST tag, which specifies a set a feats w/
                      specific choices of those feats.

                      If I want to modify the Fey Bloodline, I'd have to make a new
                      CATEGORY, and change all the references to BONUS:ABILITYPOOL|Fey
                      Bloodline Feat| to my new one. All to add Skill Focus(Knowledge (The
                      Planes)) to the list of choices (for say, a campaign that makes Fey
                      more 'other-worldly'...

                      That's jumping through hoops. Something I associate with a work-around.

                      As an Aside: TYPE:Wizard was not done for Spell Mastery - the
                      original had it set up as an addition to TYPEs in the ADD:FEAT. The
                      TYPE reference was added for a FReq for support for ppl that wanted to
                      use Complete ?Mage? - where some extra feats were granted to the list
                      of choices, with specific Specialists getting other options....

                      --
                      Tir Gwaith
                      PCGen LST Chimp
                    • Michael W. Fender
                      Accessing archive from Tir Gwaith ... Archive found in file ... ...whereas a MOD could just let you add the Skill Focus without a circus trick. ... One feat
                      Message 10 of 22 , Feb 8, 2009
                      • 0 Attachment
                        Accessing archive from "Tir Gwaith"...
                        Archive found in file
                        > >> In any case, using MOD for an ABILITYCATEGORY is going to have be a
                        > >> FReq, right?
                        > >
                        > > Yes, I'm just unconvinced of it's need.
                        >
                        > I am.
                        >
                        > Pathfinder has the ABILITYLIST tag, which specifies a set a feats w/
                        > specific choices of those feats.
                        >
                        > If I want to modify the Fey Bloodline, I'd have to make a new
                        > CATEGORY, and change all the references to BONUS:ABILITYPOOL|Fey
                        > Bloodline Feat| to my new one. All to add Skill Focus(Knowledge (The
                        > Planes)) to the list of choices (for say, a campaign that makes Fey
                        > more 'other-worldly'...
                        >
                        > That's jumping through hoops. Something I associate with a work-around.

                        ...whereas a MOD could just let you add the Skill Focus without a circus
                        trick.

                        > As an Aside: TYPE:Wizard was not done for Spell Mastery - the
                        > original had it set up as an addition to TYPEs in the ADD:FEAT. The
                        > TYPE reference was added for a FReq for support for ppl that wanted to
                        > use Complete ?Mage? - where some extra feats were granted to the list
                        > of choices, with specific Specialists getting other options....

                        One feat I'm looking at from Complete Mage that you're talking about requires
                        Spell Focus (Illusion) and Illusionist level 1st (PREFEAT and PRECLASS, to be
                        sure), but something like that would certainly have to have TYPE:Wizard to
                        make sure it would show up in the list of Wizard feats.

                        That's what I was talking about with the redundancy. A Metamagic feat doesn't
                        need TYPE:Wizard now. Put simply: Each Metamagic and ItemCreation type in the
                        RSRD is taking up extra memory with TYPE:Wizard for no rational reason now
                        that the ability pools have been added.

                        Trackers have been raised for the .MOD and for .CLEAR[ALL] per private
                        discussion with LegacyKing at:
                        https://sourceforge.net/tracker2/?func=detail&aid=2580529&group_id=25576&atid=384722
                        https://sourceforge.net/tracker2/?func=detail&aid=2580532&group_id=25576&atid=384722

                        I'll let higher up have final say from there :p However, I still have to
                        question whether a FReq for cleaning up unneeded Wizard types should be made.
                        If they're not needed anymore with the ItemCreation and Metamagic feats,
                        should we leave them be or get rid of them before they actually do cause a
                        problem?
                        --
                        Fluxxdog

                        The worst crime you can commit against another human being is to make them
                        think.
                      • Tom Parker
                        As you ve found, this doesn t work. As far as a FREQ, I feel this is a challenging problem, as it builds on an already difficult foundation (and potentially
                        Message 11 of 22 , Feb 8, 2009
                        • 0 Attachment
                          As you've found, this doesn't work.

                          As far as a FREQ, I feel this is a challenging problem, as it builds
                          on an already difficult foundation (and potentially violates a deeply
                          held assumption about Ability Categories - mainly that they exist
                          before they are used)

                          The addition of .MOD changes that - for many reasons. The ability to
                          use CATEGORY, or alter the key of the Ability Category in a .MOD
                          wreaks havoc on the pre-constructed assumption. (And no, preventing
                          the use of certain tokens in a .MOD doesn't make this problem easier;
                          as we have no code that does that today, it only makes it a different,
                          and potentially more difficult, problem)

                          Already, our data is in a position where changes I plan to make in
                          5.17 will cause errors due to references to non-existent ability
                          categories (exposing a similar problem that already exists in our
                          current data)

                          The challenge is that "Ability Category" is not simply an object like
                          other objects, it is a rather deeply rooted object, upon which
                          Abilities are built.

                          The problem is that there are certain game modes (35e) that reference
                          some AbilityCategories (e.g. Special Ability) that are not in the game
                          mode.

                          ...and before anyone starts making claims about it being in the RSRD,
                          *it doesn't matter*. To the game mode, those ability category files
                          don't exist (Game modes load when PCGen is launched)

                          Therefore, the 35e gamemode places a dependency on the datasets which
                          use it (in particular, to implement the "Special Ability" category).
                          This is - in my opinion - less than ideal (especially since we don't
                          have a method of documenting those things), and if the PRExxx tokens
                          were up to the standard of the rebuilt tokens, then this would already
                          be a problem.

                          This will result in one of two things occurring in 5.17:
                          (1) The data gets updated to put "Special Ability" back into the Game
                          Mode to avoid preconstruction.
                          (2) The input system and core get rebuilt to allow for deferred
                          creation of all ability category references (with all of the penalties
                          of dereferencing)

                          Either way, this issue needs to get resolved in order to even be able
                          to define how a .MOD/.COPY/.FORGET etc. would behave.

                          TP.
                        • Tir Gwaith
                          ... Which means all abilitycategory.lst files get loaded, .MOD d, etc. FIRST, then move on to start loading all other files. ... See below....
                          Message 12 of 22 , Feb 8, 2009
                          • 0 Attachment
                            > As far as a FREQ, I feel this is a challenging problem, as it builds
                            > on an already difficult foundation (and potentially violates a deeply
                            > held assumption about Ability Categories - mainly that they exist
                            > before they are used)

                            Which means all abilitycategory.lst files get loaded, .MOD'd, etc.
                            FIRST, then move on to start loading all other files.

                            > The addition of .MOD changes that - for many reasons. The ability to
                            > use CATEGORY, or alter the key of the Ability Category in a .MOD
                            > wreaks havoc on the pre-constructed assumption. (And no, preventing
                            > the use of certain tokens in a .MOD doesn't make this problem easier;
                            > as we have no code that does that today, it only makes it a different,
                            > and potentially more difficult, problem)

                            See below....

                            <snip some other good stuff, but not needed to repeat here.>

                            > Therefore, the 35e gamemode places a dependency on the datasets which
                            > use it (in particular, to implement the "Special Ability" category).
                            > This is - in my opinion - less than ideal (especially since we don't
                            > have a method of documenting those things), and if the PRExxx tokens
                            > were up to the standard of the rebuilt tokens, then this would already
                            > be a problem.
                            >
                            > This will result in one of two things occurring in 5.17:
                            > (1) The data gets updated to put "Special Ability" back into the Game
                            > Mode to avoid preconstruction.
                            > (2) The input system and core get rebuilt to allow for deferred
                            > creation of all ability category references (with all of the penalties
                            > of dereferencing)

                            I didn't know the Parent "Special Ability" was removed from GameMode.
                            That doesn't really make sense to me. (For that matter, the GameMode
                            references a specific Data object - Uncanny Dodge - which gets weird
                            for a GameMode..)

                            Penalties of dereferencing besides slowness in recalculation are? I
                            can guess, but I think I'd rather have it spelled out so I'm not
                            making bad assumptions.

                            > Either way, this issue needs to get resolved in order to even be able
                            > to define how a .MOD/.COPY/.FORGET etc. would behave.

                            Personally, I'd leave the Parent's un-moddable, and allow the
                            Child-nodes re-definable.

                            We are getting into the messy business discussed when we first asked
                            for GameMode stuff in PCC references (I think it was the Rules file
                            discussion where it first game up) - changing stuff gets _MESSY_.

                            I personally see the parent definitions as a part of defining an DB
                            array, and the children (TYPE filter, now ABILITYLIST) as a relational
                            link. Changing a relational link means re-calculating what is linked
                            and what isn't. Re-defining a DB array means dumping memory and
                            basically starting over (or losing data).

                            --
                            Tir Gwaith
                            PCGen LST Chimp
                          • Tir Gwaith
                            ... Not needed anymore.. Ok, I m going to have to ponder that a bit. I now see we added TYPE:Wizard to all the ItemCreation and Metamagic feats. Makes it a
                            Message 13 of 22 , Feb 8, 2009
                            • 0 Attachment
                              > I'll let higher up have final say from there :p However, I still have to
                              > question whether a FReq for cleaning up unneeded Wizard types should be made.
                              > If they're not needed anymore with the ItemCreation and Metamagic feats,
                              > should we leave them be or get rid of them before they actually do cause a
                              > problem?

                              Not needed anymore.. Ok, I'm going to have to ponder that a bit. I
                              now see we added TYPE:Wizard to all the ItemCreation and Metamagic
                              feats. Makes it a bit like the MSRD type set-up, and I'm not exactly
                              sure why that was done, unless it was someone's idea of help on the UI
                              side. We've done that with a number of Equipment TYPEs....

                              --
                              Tir Gwaith
                              PCGen LST Chimp
                            • Michael W. Fender
                              Accessing archive from Tom Parker ... Archive found in file ... I see what you re saying. Case in point, the AC Types in the 35e game mode: ACTYPE:Flatfooted
                              Message 14 of 22 , Feb 8, 2009
                              • 0 Attachment
                                Accessing archive from "Tom Parker"...
                                Archive found in file
                                > As you've found, this doesn't work.
                                >
                                > As far as a FREQ, I feel this is a challenging problem, as it builds
                                > on an already difficult foundation (and potentially violates a deeply
                                > held assumption about Ability Categories - mainly that they exist
                                > before they are used)
                                >
                                > The addition of .MOD changes that - for many reasons. The ability to
                                > use CATEGORY, or alter the key of the Ability Category in a .MOD
                                > wreaks havoc on the pre-constructed assumption. (And no, preventing
                                > the use of certain tokens in a .MOD doesn't make this problem easier;
                                > as we have no code that does that today, it only makes it a different,
                                > and potentially more difficult, problem)
                                >
                                > Already, our data is in a position where changes I plan to make in
                                > 5.17 will cause errors due to references to non-existent ability
                                > categories (exposing a similar problem that already exists in our
                                > current data)
                                >
                                > The challenge is that "Ability Category" is not simply an object like
                                > other objects, it is a rather deeply rooted object, upon which
                                > Abilities are built.
                                >
                                > The problem is that there are certain game modes (35e) that reference
                                > some AbilityCategories (e.g. Special Ability) that are not in the game
                                > mode.

                                I see what you're saying. Case in point, the AC Types in the 35e game mode:
                                ACTYPE:Flatfooted ADD:TOTAL REMOVE:Ability|
                                PRESTAT:1,DEX=10|!PREABILITY:1,CATEGORY=Special Ability,Uncanny Dodge
                                REMOVE:Dodge|!PREABILITY:1,CATEGORY=Special Ability,Uncanny Dodge

                                It's already referencing a Special Ability, one that, in fact, doesn't exist
                                until the RSRD is loaded. The only ability categories that are already
                                defined in the game mode are FEAT and Internal.

                                > ...and before anyone starts making claims about it being in the RSRD,
                                > *it doesn't matter*. To the game mode, those ability category files
                                > don't exist (Game modes load when PCGen is launched)
                                >
                                > Therefore, the 35e gamemode places a dependency on the datasets which
                                > use it (in particular, to implement the "Special Ability" category).
                                > This is - in my opinion - less than ideal (especially since we don't
                                > have a method of documenting those things), and if the PRExxx tokens
                                > were up to the standard of the rebuilt tokens, then this would already
                                > be a problem.

                                Circular dependency. A needs B, B needs A, but you can't load one without the
                                other. Ewww...

                                > This will result in one of two things occurring in 5.17:
                                > (1) The data gets updated to put "Special Ability" back into the Game
                                > Mode to avoid preconstruction.

                                I'd be lying if I didn't say this should be the case. IMHO, since a vast
                                number of abilties depend on that category alone, let alone the use of the
                                category in the game mode itself, it should exist with the game mode.
                                Question though: As far the ACTYPE tag goes, if a data set is loaded that
                                didn't have Uncanny Dodge at all, would PCGen throw an error?

                                > (2) The input system and core get rebuilt to allow for deferred
                                > creation of all ability category references (with all of the penalties
                                > of dereferencing)

                                And that sounds like a lot of work that shouldn't have to be done.

                                > Either way, this issue needs to get resolved in order to even be able
                                > to define how a .MOD/.COPY/.FORGET etc. would behave.

                                --
                                Fluxxdog

                                The worst crime you can commit against another human being is to make them
                                think.
                              • Tom Parker
                                ... that ... No, but it should. It only succeeds because the PRExxx tokens are not rebuilt tokens. Once that changes in 5.17, then yes, it would (as it
                                Message 15 of 22 , Feb 8, 2009
                                • 0 Attachment
                                  --- In PCGenListFileHelp@yahoogroups.com, "Michael W. Fender"
                                  <fluxxdog@...> wrote:
                                  > Question though: As far the ACTYPE tag goes, if a data set is loaded
                                  that
                                  > didn't have Uncanny Dodge at all, would PCGen throw an error?

                                  No, but it should. It only succeeds because the PRExxx tokens are not
                                  "rebuilt" tokens. Once that changes in 5.17, then yes, it would (as
                                  it should) produce an "Unconstructed Reference"

                                  TP.
                                • Michael W. Fender
                                  Accessing archive from Tir Gwaith ... Archive found in file ... What I understood from what Eddy was saying, the only purpose of it was to have feats with the
                                  Message 16 of 22 , Feb 8, 2009
                                  • 0 Attachment
                                    Accessing archive from "Tir Gwaith"...
                                    Archive found in file
                                    > > I'll let higher up have final say from there :p However, I still have to
                                    > > question whether a FReq for cleaning up unneeded Wizard types should be
                                    > > made. If they're not needed anymore with the ItemCreation and Metamagic
                                    > > feats, should we leave them be or get rid of them before they actually do
                                    > > cause a problem?
                                    >
                                    > Not needed anymore.. Ok, I'm going to have to ponder that a bit. I
                                    > now see we added TYPE:Wizard to all the ItemCreation and Metamagic
                                    > feats. Makes it a bit like the MSRD type set-up, and I'm not exactly
                                    > sure why that was done, unless it was someone's idea of help on the UI
                                    > side. We've done that with a number of Equipment TYPEs....

                                    What I understood from what Eddy was saying, the only purpose of it was to
                                    have feats with the 'Wizard type show up as a "Wizard Feat". Such as for
                                    CHOOSE or ADD tags. Using it with an ItemCreation/Metamagic type feat is
                                    pointless now, and with other LST files, this does not seem to be the standard
                                    as those feats are listed as only ItemCreation/Metamagic, no Wizard.

                                    --
                                    Fluxxdog

                                    The worst crime you can commit against another human being is to make them
                                    think.
                                  • Tom Parker
                                    ... This sounds simple, but is very different from how we load data today... thus will require us to move around processing in order to ensure that behavior
                                    Message 17 of 22 , Feb 8, 2009
                                    • 0 Attachment
                                      --- In PCGenListFileHelp@yahoogroups.com, Tir Gwaith <Tir.Gwaith@...>
                                      wrote:
                                      > Which means all abilitycategory.lst files get loaded, .MOD'd, etc.
                                      > FIRST, then move on to start loading all other files.

                                      This sounds simple, but is very different from how we load data
                                      today... thus will require us to move around processing in order to
                                      ensure that behavior (which brings up risks of breaking other things
                                      that make assumptions based on the current order - such as the
                                      assumption that STATs are pre-built.) Not saying it can't be done,
                                      but it's work and we need to evaluate the impact of that change.

                                      > [Parent "Special Ability" being removed from GameMode]
                                      > doesn't really make sense to me.

                                      Me either, but I didn't notice the reference in the game mode until a
                                      few days ago.

                                      > (For that matter, the GameMode
                                      > references a specific Data object - Uncanny Dodge - which gets weird
                                      > for a GameMode..)

                                      I suspect we'd want to change this to a variable at some point?

                                      > Penalties of dereferencing besides slowness in recalculation are? I
                                      > can guess, but I think I'd rather have it spelled out so I'm not
                                      > making bad assumptions.

                                      To the user, processing time. Memory, too, but that's minor. To me,
                                      I have to rethink processing Abilities from the Ability LST file,
                                      since it's currently indexed by AbilityCategory. I have to think if
                                      indexing by a reference is a problem or not. I'm honestly not sure
                                      given the 5 minutes of thought I've given it so far :)

                                      > > Either way, this issue needs to get resolved in order to even be able
                                      > > to define how a .MOD/.COPY/.FORGET etc. would behave.
                                      >
                                      > Personally, I'd leave the Parent's un-moddable, and allow the
                                      > Child-nodes re-definable.

                                      Neat idea, but this might be harder than just making everything
                                      changeable. Of course, this concept also interacts with the whole
                                      "let's split ability categories into the multiple separate functions
                                      they perform" (This is the whole category/pool discussion/FREQ

                                      TP.
                                    • Andrew Maitland
                                      I would venture a guess that these were added the following reasons: ADD:FEAT usage - Homebrews likely still use this method UI - Clean Look for older versions
                                      Message 18 of 22 , Feb 8, 2009
                                      • 0 Attachment
                                        I would venture a guess that these were added the following reasons:

                                        ADD:FEAT usage - Homebrews likely still use this method
                                        UI - Clean Look for older versions
                                        Overlap of Uses - Any new 'wizard' feat can just add the TYPE:Wizard
                                        to be included in the Old and New systems
                                        Seemed like a good idea at the time.

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



                                        Michael W. Fender wrote:
                                        > Accessing archive from "Tir Gwaith"...
                                        > Archive found in file
                                        >
                                        >>> I'll let higher up have final say from there :p However, I still have to
                                        >>> question whether a FReq for cleaning up unneeded Wizard types should be
                                        >>> made. If they're not needed anymore with the ItemCreation and Metamagic
                                        >>> feats, should we leave them be or get rid of them before they actually do
                                        >>> cause a problem?
                                        >>>
                                        >> Not needed anymore.. Ok, I'm going to have to ponder that a bit. I
                                        >> now see we added TYPE:Wizard to all the ItemCreation and Metamagic
                                        >> feats. Makes it a bit like the MSRD type set-up, and I'm not exactly
                                        >> sure why that was done, unless it was someone's idea of help on the UI
                                        >> side. We've done that with a number of Equipment TYPEs....
                                        >>
                                        >
                                        > What I understood from what Eddy was saying, the only purpose of it was to
                                        > have feats with the 'Wizard type show up as a "Wizard Feat". Such as for
                                        > CHOOSE or ADD tags. Using it with an ItemCreation/Metamagic type feat is
                                        > pointless now, and with other LST files, this does not seem to be the standard
                                        > as those feats are listed as only ItemCreation/Metamagic, no Wizard.
                                        >
                                        >


                                        [Non-text portions of this message have been removed]
                                      • taluroniscandar
                                        ... Just FYI, I am updating my lst files to 5.15 (from .12 or so) I have a .MOD on All Automatics Proficiencies and got the same error as the OP. ...
                                        Message 19 of 22 , Feb 12, 2009
                                        • 0 Attachment
                                          --- In PCGenListFileHelp@yahoogroups.com, Andrew Maitland
                                          <drew0500@...> wrote:
                                          >
                                          > Yes, that would be a FREQ.
                                          >
                                          > Might as well go the full mile if you're going to freq this:
                                          >
                                          > Add .MOD to ABILITYCATEGORY
                                          > Add .CLEAR to ABILITYCATEGORY
                                          > Add .COPY to ABILITYCATEGORY
                                          >
                                          > Does that cover your foreseeable needs?
                                          >
                                          > Let me know if this is what we want.
                                          >
                                          > ---------

                                          Just FYI, I am updating my lst files to 5.15 (from .12 or so)
                                          I have a .MOD on All Automatics Proficiencies and got the same error
                                          as the OP.

                                          Under the .MOD documentation there is this entry:
                                          -----------------------------------
                                          CATEGORY=Mutation|Weak Immune System.MOD

                                          Modifies an ability of the category Mutation, which is called Weak
                                          Immune System. Another ability of the same name, which belongs to
                                          another category, would not be affected.
                                          -----------------------------------

                                          I changed mine into this format and the pcgen lst loader no longer
                                          complains about the .MOD.

                                          CATEGORY=Special Ability|All Automatic Proficiencies.MOD
                                          [TAB]
                                          AUTO:WEAPONPROF|etc|etc

                                          Havent tried it yet but at least the loader in 5.15.9 thinks this
                                          works. Some of the functionality may already be there.
                                        • Michael W. Fender
                                          Accessing archive from taluroniscandar ... Archive found in file ... I have the same thing for Touch spells. It works perfectly fine now. -- Fluxxdog The
                                          Message 20 of 22 , Feb 12, 2009
                                          • 0 Attachment
                                            Accessing archive from "taluroniscandar"...
                                            Archive found in file
                                            > --- In PCGenListFileHelp@yahoogroups.com, Andrew Maitland
                                            >
                                            > <drew0500@...> wrote:
                                            > > Yes, that would be a FREQ.
                                            > >
                                            > > Might as well go the full mile if you're going to freq this:
                                            > >
                                            > > Add .MOD to ABILITYCATEGORY
                                            > > Add .CLEAR to ABILITYCATEGORY
                                            > > Add .COPY to ABILITYCATEGORY
                                            > >
                                            > > Does that cover your foreseeable needs?
                                            > >
                                            > > Let me know if this is what we want.
                                            > >
                                            > > ---------
                                            >
                                            > Just FYI, I am updating my lst files to 5.15 (from .12 or so)
                                            > I have a .MOD on All Automatics Proficiencies and got the same error
                                            > as the OP.
                                            >
                                            > Under the .MOD documentation there is this entry:
                                            > -----------------------------------
                                            > CATEGORY=Mutation|Weak Immune System.MOD
                                            >
                                            > Modifies an ability of the category Mutation, which is called Weak
                                            > Immune System. Another ability of the same name, which belongs to
                                            > another category, would not be affected.
                                            > -----------------------------------
                                            >
                                            > I changed mine into this format and the pcgen lst loader no longer
                                            > complains about the .MOD.
                                            >
                                            > CATEGORY=Special Ability|All Automatic Proficiencies.MOD
                                            > [TAB]
                                            > AUTO:WEAPONPROF|etc|etc

                                            I have the same thing for Touch spells. It works perfectly fine now.

                                            --
                                            Fluxxdog

                                            The worst crime you can commit against another human being is to make them
                                            think.
                                          Your message has been successfully submitted and would be delivered to recipients shortly.