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

Re: My proposed feat reorganization

Expand Messages
  • merton_monk
    You re close.... what Keith suggested, and what I m fairly inclined to do at this point, is to have one file which defines the tree itself. In this file you
    Message 1 of 33 , Jul 1, 2002
    • 0 Attachment
      You're close....
      what Keith suggested, and what I'm fairly inclined to do at this
      point, is to have one file which defines the tree itself. In this
      file you could have something like the following:
      Fighter[tab]SUBTYPE:Offense|Defense
      You would only need to specify types of feats that had sub-types, so
      you wouldn't need to have a line listing Offense unless it had
      subtypes. e.g.
      Offense[tab]SUBTYPE:
      would be unnecessary.

      The above tree would form
      - Fighter
      - Defense
      - Offense

      The Feat.lst files would not need any changes. For some reason if a
      feat had TYPE:Fighter.Defense in it, then the feat tab gui logic
      would need to know to put it only in the Defense list of feats, and
      not under Fighter as well. Any types that it came across that were
      not listed in the feat-tree lst file would be assumed as Root level
      types. This way the user can define the tree as they please and it's
      open ended so feats don't need to know about the organization.

      The same organization could be applied to equipment - and would make
      a lot of sense as well.

      -Bryan

      --- In pcgen@y..., "arknathd" <gemguard@h...> wrote:
      > Ok...I understand a bit better now. However, I'm still a little
      > unconvinced about how you're going to accomplish this..
      >
      > Now, don't get me wrong, as a web programmer I LOVE style sheets
      > (makes my job a HELL of a lot easier) but I'm not sure how you are
      > planning to cover such a diverse array of feats and categories
      > without adjusting the data files. Say we create 10 main "groups"
      of
      > feats (General, fighter, class, etc) and then the subgroups within
      > each of them (defense, offense, melee, ranged, epic, etc). From a
      > style sheet point of view, how do you plan on having the app
      seperate
      > each individual feat...
      >
      > Hmmmm....I think I just answered my own question....Your assigning
      > Groups and Subgroups to the data files right? Essentially it would
      > read
      >
      > Cleave[tab]GROUP:General.Fighter[tab]SUBGROUP:Offense
      >
      > And let the user create a "style sheet" that displays the feats
      > accordingly? I came to this realization while typing my response,
      so
      > this may or may not be what you're looking to do.
      >
      > Ark
      > Feat 'tang
      > LST Henchmule
      > "Life's a hench." - Nodwick coffee mug
    • Keith Davies
      ... This is also not the nominal case. You re changing the actual classification of the feat rather than its presentation position. By using the hierarchy
      Message 33 of 33 , Jul 5, 2002
      • 0 Attachment
        On Wed, Jul 03, 2002 at 09:00:49PM +0000, cyberfunkr wrote:
        > This one I'm not going to fight too hard for. It just seemed like a
        > better solution. I'm not a .lst monkey so it won't effect me much. If
        > I don't like the way you guys arrange it I'll just list by
        > alphabetical order.
        >
        > But that is one of the points to consider. What if I don't like where
        > you put in a standard Feat? I don't want to recreate the layout,
        > just change what category a Feat is under. Take Combat Casting as an
        > example; It's currently listed as 'TYPE:General'.
        >
        > -First Run-
        > hierarchyfeats.lst method:
        > 1. Either change an existing custom.pcc file, or create a new .pcc
        > file specifically for pointing to my custom hierarchyfeats.lst
        > 2. Edit the default hierarchyfeats.lst, or copy hierarchyfeats.lst to
        > my custom directory and edit it to match the way I'm thinking. Add new
        > category to Metamagic called 'Combat'.
        > 3. Go to playeshbfeats.lst and change TYPE: to Metamagic and add a new
        > tag CATEGORY:Combat.
        >
        > new Feats.lst tag method.
        > 1. Go to playeshbfeats.lst and change TYPE: to Metamagic and add a new
        > tag CATEGORY:Combat.
        >
        > -After next PCGen update-
        > (a) If I just edited the default hierarchyfeats.lst
        > 1. Edit the default hierarchyfeats.lst. Add new category to Metamagic
        > called 'Combat'.
        > 2. Go to playeshbfeats.lst and change TYPE: to Metamagic and add a new
        > tag CATEGORY:Combat.
        > (b) If I used a custom .pcc/hierarchyfeats.lst
        > 1. Go to playeshbfeats.lst and change TYPE: to Metamagic and add a new
        > tag CATEGORY:Combat.
        >
        > new Feats.lst tag method.
        > 1. Go to playeshbfeats.lst and change TYPE: to Metamagic and add a new
        > tag CATEGORY:Combat.
        >
        > This is best-case scenarios of me changing one Feat. It's always
        > possible that until I get into the swing of it that I'll accidentally
        > name the Feats in the playershb 'Combat' but later realize that all my
        > custom Feats are under 'Fighting'.

        This is also not the nominal case. You're changing the actual
        classification of the feat rather than its presentation position.

        By using the hierarchy description, we can specify how to present *all*
        feats, by type. If we want to change the order, we change the hierarchy
        file. If we specify the presentation in the data files, if we want to
        change how the feats are displayed we have to change *every* feat. That
        would suck in a big way.

        > No matter what, there is going to be an initial investment of time to
        > add the CATEGORY tag (or whatever you plan on calling it) to all the
        > Feat lists. So that point is moot. We're strictly talking maintenance.
        > No matter what, the user would have to go in an edit the Feat itself.
        > To make the hierarchyfeats.lst work without having to touch the feats
        > would be to not only have the parent/child set up, but a delimited
        > list of what Feat goes where. That's a huge step backwards.

        Not necessarily, actually. The hierarchy method could get by with the
        current TYPE tags. If we specify that a feat appears only at the
        'highest-definition' location (leaf nodes, if possible, or higher in the
        tree if there are no matching leaf nodes along a branch), the we can
        algorithmically order the feats as they are currently defined.

        For instance, 'Combat Casting' might have type 'Wizard.Magic.Combat'.
        If the hierarchy specifies that 'Wizard' and 'Magic->Combat' exist in
        the tree, it would appear under Wizard and under Magic->Combat, but not
        under Magic directly because there is a more specific branch or leaf
        under it.

        > TYPE:Fighter[tab]CATEGORY:Offense[tab]FEATS:Cleave|Ambidexterity|Far
        > Shot|....
        >
        > So hierarchyfeats.lst will work so long as your organization methods
        > match everyone else's thinking. Personally, don't care much one way or
        > the other. I just like giving other points of view. :)

        Always worthwhile.


        Keith
        --
        Keith Davies
        keith.davies@...

        "I'm happy to do the tracker stuff since our Microsoft Poxy Server (that's
        poxy, not proxy) won't let me connect to sourcesafe's CVS..."
        -- Karianna, pcgen mailing list
      Your message has been successfully submitted and would be delivered to recipients shortly.