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

Re: [pcgen] [Devon][CODE] [FREQ] p7+ trackers - 10/31/04

Expand Messages
  • Éric Beaudoin
    For the record, Tir talks for all the senior data monkeys on this issue. Any functionality linked to a TYPE (especially the hardcoded ones) should be seen as
    Message 1 of 13 , Oct 31, 2004
    • 0 Attachment
      For the record, Tir talks for all the senior data monkeys on this
      issue. Any functionality linked to a TYPE (especially the hardcoded
      ones) should be seen as Evil(tm).

      We've done that in the past and we are still paying (kind of like the
      Olympic Stadium in Montreal).


      On Sun, 31 Oct 2004 21:05:16 +0100, Stefan Radermacher <ml@...> wrote:
      >
      > thoron-tir-gwaith@... wrote:
      >
      > > Devon, I didn't know this FReq was on the 5.8 list. Zaister, is this
      > > one nearly complete? I haven't heard in a while... I'm not even
      > > sure if we came up with a final syntax for the new choice system. At
      > > least, I think I was IRCing about it with Zaister a while back....
      >
      > This would be easy, if we would introduce an TYPE for the equipment that
      > can be chosen, but Tir was opposed to that, so no, we haven't found a
      > dfinal syntax yet. However, I think it doesn't need to be a 5.8 priority.
      >
      > Stefan.
      > (aka Zaister)
      --
      Éric "Space Monkey" Beaudoin
      Founding Member of the Hidden-in-the-Trench Club
      Release Monkey and Syntax Watchdog
      >> In space, no one can hear you sleep.
      >> Camels to can climb trees (and sometime eat them).
      <mailto:eric.beaudoin@...>
    • Paul W. King
      May I ask why? Alright, I ve already asked. :) May I know why this is Evil ? Paul W. King TM SB, OGL/PL Chimp, Data Tamarin, BoD ... From: Éric Beaudoin
      Message 2 of 13 , Oct 31, 2004
      • 0 Attachment
        May I ask why? Alright, I've already asked. :)

        May I know why this is 'Evil'?

        Paul W. King
        TM SB, OGL/PL Chimp, Data Tamarin, BoD

        -----Original Message-----
        From: Éric Beaudoin [mailto:eric.beaudoin@...]
        Sent: Sunday, October 31, 2004 6:10 PM
        To: pcgen@yahoogroups.com
        Subject: Re: [pcgen] [Devon][CODE] [FREQ] p7+ trackers - 10/31/04

        For the record, Tir talks for all the senior data monkeys on this
        issue. Any functionality linked to a TYPE (especially the hardcoded
        ones) should be seen as Evil(tm).
      • Stefan Radermacher
        ... Currently the way PCGen chooses which kind of equipment gets listed in the chooses for free clothing ist by looking at the TYPE, it lists all equiupment
        Message 3 of 13 , Nov 1, 2004
        • 0 Attachment
          Éric Beaudoin wrote:

          > For the record, Tir talks for all the senior data monkeys on this
          > issue. Any functionality linked to a TYPE (especially the hardcoded
          > ones) should be seen as Evil(tm).

          Currently the way PCGen chooses which kind of equipment gets listed in
          the chooses for free clothing ist by looking at the TYPE, it lists all
          equiupment witht the TYPE "Clothing.Resizable", and I don't really see a
          way to do something like that differently currently.

          Also, I'm wondering, what good is the TYPE qualifier if not for linking
          functionality to it? How else is the program supposed to differentiate
          between different kinds of equipment items? How else would PCGen be able
          to know that you can't use a lantern as a weapon or a sword as armor?

          Stefan.
        • Devon Jones
          ... I have to weigh in here, and say that I agree with Stefan. We *have* to refer to specific types in code, otherwise there is no way for us to know how this
          Message 4 of 13 , Nov 1, 2004
          • 0 Attachment
            Stefan Radermacher wrote:

            >Éric Beaudoin wrote:
            >
            >
            >
            >>For the record, Tir talks for all the senior data monkeys on this
            >>issue. Any functionality linked to a TYPE (especially the hardcoded
            >>ones) should be seen as Evil(tm).
            >>
            >>
            >
            >Currently the way PCGen chooses which kind of equipment gets listed in
            >the chooses for free clothing ist by looking at the TYPE, it lists all
            >equiupment witht the TYPE "Clothing.Resizable", and I don't really see a
            >way to do something like that differently currently.
            >
            >Also, I'm wondering, what good is the TYPE qualifier if not for linking
            >functionality to it? How else is the program supposed to differentiate
            >between different kinds of equipment items? How else would PCGen be able
            >to know that you can't use a lantern as a weapon or a sword as armor?
            >
            >Stefan.
            >
            >
            >
            I have to weigh in here, and say that I agree with Stefan. We *have* to
            refer to specific types in code, otherwise there is no way for us to
            know how this stuff can affect anything.

            Sorry, it may be ugly, but there really is no other viable way. This is
            what TYPE is *for*

            I am btw open to other suggestions, but really, any suggestion needs to
            include eliminating TYPE, because that is it's primary code function -
            to be a filter on items or other things for the code.

            Devon
          • Éric Beaudoin
            ... If there is really no other way, at least attach the functionality to a list of types that can be defined somewhere in a gameMode file. Still, I rather
            Message 5 of 13 , Nov 1, 2004
            • 0 Attachment
              At 19:08 2004.11.01, Devon Jones wrote:
              >>Éric Beaudoin wrote:
              >>
              >>
              >>
              >>>For the record, Tir talks for all the senior data monkeys on this
              >>>issue. Any functionality linked to a TYPE (especially the hardcoded
              >>>ones) should be seen as Evil(tm).
              >>>
              >>>
              >>
              >>Currently the way PCGen chooses which kind of equipment gets listed in
              >>the chooses for free clothing ist by looking at the TYPE, it lists all
              >>equiupment witht the TYPE "Clothing.Resizable", and I don't really see a
              >>way to do something like that differently currently.
              >>
              >>Also, I'm wondering, what good is the TYPE qualifier if not for linking
              >>functionality to it? How else is the program supposed to differentiate
              >>between different kinds of equipment items? How else would PCGen be able
              >>to know that you can't use a lantern as a weapon or a sword as armor?
              >>
              >>Stefan.
              >>
              >>
              >>
              >I have to weigh in here, and say that I agree with Stefan. We *have* to
              >refer to specific types in code, otherwise there is no way for us to
              >know how this stuff can affect anything.
              >
              >Sorry, it may be ugly, but there really is no other viable way. This is
              >what TYPE is *for*
              >
              >I am btw open to other suggestions, but really, any suggestion needs to
              >include eliminating TYPE, because that is it's primary code function -
              >to be a filter on items or other things for the code.
              >
              >Devon

              If there is really no other way, at least attach the functionality to a list of types that can be defined somewhere in a gameMode file.

              Still, I rather have a separated tag for this because implicit functionality is never clear. TYPE is good to select subsets of objects and should stay that way. You can then use that subset to define functionality with other tags. Attaching functionalist to some Magic TYPE instance is not good in the long run.

              What I want is to see the link between the types and the functionality in the .lst files. Having it in the gameMode is only one way removed from having it hardcoded unless we create a gameMode tag that accept a list of objects and then use the TYPE syntax to define the list.

              TYPE already has a function. Overloading that function on specific type is only asking for trouble. New function, new tag.


              -----------------------------------------------------------
              Éric "Space Monkey" Beaudoin
              Founding Member of the Hidden-in-the-Trench Club
              Release Monkey and Syntax Watchdog
              >> In space, no one can hear you sleep.
              >> Camels to can climb trees (and sometime eat them).
              <mailto:beaudoer@...>
            • Tir Gwaith
              Do you realize HOW MANY Types there are in Equipment? And while many are there for users ability to select items, many are there clogging it up for a single
              Message 6 of 13 , Nov 1, 2004
              • 0 Attachment
                Do you realize HOW MANY Types there are in Equipment? And while many are
                there for users ability to select items, many are there clogging it up for a
                single obscure purpose. I small rule (that groups I've played with have
                always ignored) in the RSRD that will require another TYPE, with potentially
                another hard-code specific TYPE, is something I really don't want to go
                into. I'd like another solution than just throwing everything and the
                kitchen sink into TYPE tags.

                I have SERIOUS reservations about endorsing another hard-coded (even in
                GameMode) TYPE to equipment.

                The other problem we have is that the object's TYPE tag is not used the same
                across all files. Or even the same way all the time in the same file. It
                is like the "Catch-all" drawer in my kitchen.

                Tir Gwaith
                LST Chimp
              • Tir Gwaith
                What Eric said. He s much clearer today than I am. :) But then, he and I are on the same page, since we ve talked about this issue many times in the past. Tir
                Message 7 of 13 , Nov 1, 2004
                • 0 Attachment
                  What Eric said. He's much clearer today than I am. :)

                  But then, he and I are on the same page, since we've talked about this issue
                  many times in the past.

                  Tir Gwaith
                  LST Chimp

                  ----- Original Message -----
                  From: "Éric Beaudoin"

                  If there is really no other way, at least attach the functionality to a list
                  of types that can be defined somewhere in a gameMode file.

                  Still, I rather have a separated tag for this because implicit functionality
                  is never clear. TYPE is good to select subsets of objects and should stay
                  that way. You can then use that subset to define functionality with other
                  tags. Attaching functionalist to some Magic TYPE instance is not good in the
                  long run.

                  What I want is to see the link between the types and the functionality in
                  the .lst files. Having it in the gameMode is only one way removed from
                  having it hardcoded unless we create a gameMode tag that accept a list of
                  objects and then use the TYPE syntax to define the list.

                  TYPE already has a function. Overloading that function on specific type is
                  only asking for trouble. New function, new tag.
                • Eddy Anthony
                  I agree with Eric and Tir on the general issue, I ve found the use of various type confusing and full of surprises. I had thought it a good idea at one time to
                  Message 8 of 13 , Nov 1, 2004
                  • 0 Attachment
                    I agree with Eric and Tir on the general issue, I've found the use of
                    various type confusing and full of surprises. I had thought it a good idea
                    at one time to document all the TYPEs and there purposes but I never got
                    very far with it because there was no way I (not being able to read the
                    code) was going to be able to find out all this stuff.

                    I would like to take this a bit further and talk a little about design
                    philosophy. The developmental changes we are adding to the program can be
                    lumped into two groups:

                    A) Additions which add functionality, these support the rules by allowing
                    players to add items to their characters and correctly track them.

                    B) Additions which add restrictions, these support the rules by enforcing
                    restrictions and limits on number of items, additions, levels etc..

                    Now I know this is a gross simplification but there are a couple of points
                    I'd like to make. In an ideal world we should strive to accomplish both
                    areas of development but in reality we are limited by the resources we have
                    available. I'm talking manpower, the number of monkeys who contribute
                    regularly and significantly is small. I'm really amazed sometimes at the
                    amount of work that does get done by this small group. When faced with this
                    limitation the objective of providing needed functionality has a much higher
                    priority then does the enforcement of restrictions put forth by the rules.
                    It is also important to remember that this program is a game aid and not the
                    game itself. There may also be restrictions in the rules that some DM's
                    would wish to ignore and if we choose to enforce them we may eventually have
                    to find a way to make them optional as well. The convoluted code we would
                    need to handle the exception might very well be greater then enforcing the
                    initial restriction.

                    Here are a couple of examples of this:

                    In Spycraft some base gadgets (Shoes, attaché cases, cars, watches) can have
                    additional gadgets built into them but they are limited to a specific number
                    of them per base item. I did actually find a way to enforce this but it was
                    extremely ugly involving a variable just to track the number of mods and a
                    crap load of PREVAR tags. Having figured it out I decided it just wasn't
                    worth it and just put a note in the help file that it is up to the user to
                    track those limits.

                    There is another example in a tracker on SF. It seems vampire clerics can
                    only choose between three specific domains (which ones escapes me ATM)
                    without additional code the only way to enforce this is to put PRETEMPLATE
                    tags in all the other domains which does not balance in the cost/benefit
                    equation. Also, what about the case of the PC who has been turned into a
                    vampire but somehow stays good, I'm sure this happens a lot ;)

                    Now I'm not suggesting that we not look for ways to do these things or that
                    we shouldn't put these restrictions in. I'm saying we should prioritize
                    development which provides new functionality and fixes bugs before we spend
                    much time on things which only restrict users choices. If we can find a way
                    to provide functionality and enforce restrictions, great! If we can provide
                    the functionality but cannot enforce restrictions we should at least provide
                    the functionality without putting the whole feature on hold.

                    I don't consider this FREQ to be that necessary for 5.8 especially
                    considering it was just recently entered.

                    Surely there are FREQs and bugs more deserving of some attention than this
                    (VISIBLE in Skills hint hint ;-)
                    --
                    ~ Eddy Anthony (MoSaT)
                    ~ PCGen Content Silverback

                    Éric Beaudoin scribed:

                    > For the record, Tir talks for all the senior data monkeys on this
                    > issue. Any functionality linked to a TYPE (especially the hardcoded
                    > ones) should be seen as Evil(tm).
                    >
                    > We've done that in the past and we are still paying (kind of like the
                    > Olympic Stadium in Montreal).
                    >
                    >
                    > On Sun, 31 Oct 2004 21:05:16 +0100, Stefan Radermacher <ml@...> wrote:
                    >>
                    >> thoron-tir-gwaith@... wrote:
                    >>
                    >>> Devon, I didn't know this FReq was on the 5.8 list. Zaister, is this
                    >>> one nearly complete? I haven't heard in a while... I'm not even
                    >>> sure if we came up with a final syntax for the new choice system. At
                    >>> least, I think I was IRCing about it with Zaister a while back....
                    >>
                    >> This would be easy, if we would introduce an TYPE for the equipment that
                    >> can be chosen, but Tir was opposed to that, so no, we haven't found a
                    >> dfinal syntax yet. However, I think it doesn't need to be a 5.8 priority.
                    >>
                    >> Stefan.
                    >> (aka Zaister)
                  • taluroniscandar
                    ... see a ... linking ... able ... *have* to ... This is ... I agree, TYPE as a function can t be removed. What about changing TYPE in items to ITEMTYPE (or
                    Message 9 of 13 , Nov 2, 2004
                    • 0 Attachment
                      --- In pcgen@yahoogroups.com, Devon Jones <soulcatcher@e...> wrote:
                      > Stefan Radermacher wrote:
                      >
                      > >Éric Beaudoin wrote:
                      > >
                      > >
                      > >
                      > >>For the record, Tir talks for all the senior data monkeys on this
                      > >>issue. Any functionality linked to a TYPE (especially the hardcoded
                      > >>ones) should be seen as Evil(tm).
                      > >>
                      > >>
                      > >
                      > >Currently the way PCGen chooses which kind of equipment gets listed in
                      > >the chooses for free clothing ist by looking at the TYPE, it lists all
                      > >equiupment witht the TYPE "Clothing.Resizable", and I don't really
                      see a
                      > >way to do something like that differently currently.
                      > >
                      > >Also, I'm wondering, what good is the TYPE qualifier if not for
                      linking
                      > >functionality to it? How else is the program supposed to differentiate
                      > >between different kinds of equipment items? How else would PCGen be
                      able
                      > >to know that you can't use a lantern as a weapon or a sword as armor?
                      > >
                      > >Stefan.
                      > >
                      > >
                      > >
                      > I have to weigh in here, and say that I agree with Stefan. We
                      *have* to
                      > refer to specific types in code, otherwise there is no way for us to
                      > know how this stuff can affect anything.
                      >
                      > Sorry, it may be ugly, but there really is no other viable way.
                      This is
                      > what TYPE is *for*
                      >
                      > I am btw open to other suggestions, but really, any suggestion needs to
                      > include eliminating TYPE, because that is it's primary code function -
                      > to be a filter on items or other things for the code.

                      I agree, TYPE as a function can't be removed.

                      What about changing TYPE in items to ITEMTYPE (or some such), TYPE in
                      feats to FEATTYPE, TYPE in classes to CLASSTYPE, etc, etc.

                      Would solve both problems (but have alot of up front costs).
                    • Devon Jones
                      ... While I understand, if the solution involves 5 lines for a new type or 500 (or more) to do it another way, sometimes this means that a new hardcoded type
                      Message 10 of 13 , Nov 3, 2004
                      • 0 Attachment
                        Tir Gwaith wrote:

                        >Do you realize HOW MANY Types there are in Equipment? And while many are
                        >there for users ability to select items, many are there clogging it up for a
                        >single obscure purpose. I small rule (that groups I've played with have
                        >always ignored) in the RSRD that will require another TYPE, with potentially
                        >another hard-code specific TYPE, is something I really don't want to go
                        >into. I'd like another solution than just throwing everything and the
                        >kitchen sink into TYPE tags.
                        >
                        >I have SERIOUS reservations about endorsing another hard-coded (even in
                        >GameMode) TYPE to equipment.
                        >
                        >The other problem we have is that the object's TYPE tag is not used the same
                        >across all files. Or even the same way all the time in the same file. It
                        >is like the "Catch-all" drawer in my kitchen.
                        >
                        >Tir Gwaith
                        >LST Chimp
                        >
                        >
                        While I understand, if the solution involves 5 lines for a new type or
                        500 (or more) to do it another way, sometimes this means that a new
                        hardcoded type is the lesser of two evils. I'll look into the issue
                        that spawned this some time later and see if there is a creative way to
                        solve it without a type.

                        Devon
                      • Eddy Anthony
                        ... I think the desire is to keep these sort of features out of the code (which are not readable to us non-programmer simians) and have it as much in the LST
                        Message 11 of 13 , Nov 4, 2004
                        • 0 Attachment
                          Devon Jones scribed:

                          > While I understand, if the solution involves 5 lines for a new type or
                          > 500 (or more) to do it another way, sometimes this means that a new
                          > hardcoded type is the lesser of two evils. I'll look into the issue
                          > that spawned this some time later and see if there is a creative way to
                          > solve it without a type.
                          >
                          > Devon

                          I think the desire is to keep these sort of features out of the code (which
                          are not readable to us non-programmer simians) and have it as much in the
                          LST files as possible. Point of fact, this feature can be done with one
                          existing tag right now, check it out:

                          ADD:EQUIP(Outfit (Artisan's),Outfit (Entertainer's),Outfit
                          (Explorer's),Outfit (Monk's),Outfit (Peasant's),Outfit (Scholar's),Outfit
                          (Traveler's))1

                          The thing we can't do in a dataset is easily attach something like this to
                          every character created. The only way I know to effect any all characters is
                          to add stuff into the stats and checks file of the gameMode and that is
                          really only good for defining variables and adding bonuses.

                          So what about this, we create a way to add feats to all characters created
                          with the dataset loaded. We can create a .pcc tag for this, FEATALL: would
                          point to a file of feats. The feats would all be applied to the character
                          after a race was chosen and the first class was selected. PRExxx tags could
                          be used in the feats and only those that the PC qualified for would be
                          added. So in this case we could have a hidden starting cloths feat with a
                          PRERULE (do we have a PRERULE tag?) and the tag listed above. It would
                          behave exactly as it does now but would only include the correct choices.
                          Best of all it there in the LST files for all to see.

                          I have seen the request for a way to add stuff to all characters come up so
                          I know there are many uses this could be applied to, I have a few in mind
                          for Spycraft.
                          --
                          ~ Eddy Anthony (MoSaT)
                          ~ PCGen Content Silverback
                        Your message has been successfully submitted and would be delivered to recipients shortly.