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

Re: Modding ABILITYCATEGORYs

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.