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

RE: [PCGenListFileHelp] [Fwd: [pcgen] correct way to override default data]

Expand Messages
  • Paul Grosse
    ... AstroCat, the best way is to use .MOD. Negative out the original stat and put your new BONUS formula in. Paul G.
    Message 1 of 4 , Dec 8, 2006
    • 0 Attachment
      >
      > Moving to LFH.
      >
      > > From: astrocat01 <astrocat@...>
      > > Date: 2006/12/08 Fri AM 10:34:42 CST
      > > To: pcgen@yahoogroups.com
      > > Subject: [pcgen] correct way to override default data
      >
      > > Say I want to change the stats on a default monster or spell, or
      > > whatever. What is the best way to do this?
      > >
      > > 1. Making my own dataset and loading it in will not always
      > completely
      > > override the original data, sometimes it adds or combines them
      > > together for the entry. So this is not a dependable way. I
      > do have the
      > > newer data option selected in the preferences.
      > >
      > > 2. The default data is already RANK:1, so I can't choose a higher
      > > RANK.
      > >
      > > 3. Commenting out the default data in the original file and putting
      > > the new data in my own dataset. I have found this method works, but
      > > I'll have to redo it the next time the default datasets are updated.
      > >
      > > So, what is the correct or best way to do this?
      > >
      > > Thanks for the help!

      AstroCat, the best way is to use .MOD. Negative out the original stat
      and put your new BONUS formula in.

      Paul G.
    • Tir Gwaith
      ... Have a set that you load with a .MOD for that entry. ... Tags that are only allowed once will completely over-ride. Tags that are allowed multiple times
      Message 2 of 4 , Dec 8, 2006
      • 0 Attachment
        > > Say I want to change the stats on a default monster or spell, or
        > > whatever. What is the best way to do this?

        Have a set that you load with a .MOD for that entry.

        > > 1. Making my own dataset and loading it in will not always
        > > completely override the original data, sometimes it adds or
        > > combines them together for the entry. So this is not a dependable
        > > way. I do have the newer data option selected in the preferences.

        Tags that are only allowed once will completely over-ride. Tags that
        are allowed multiple times need to be removed/countered. That's under
        normal stuff.

        <Aside to TM>
        We could use a Documentation improvement that shows, for each tag, how
        to remove/counter it in a .MOD - .CLEAR., simple entry will over-ride,
        etc. Yeah, that's a big FReq, but I think it will go a long way to
        helping out the casual LST coder and newbie
        </Aside to TM>

        I think the New Data Option is _really_ what you want. However, to
        make it work, you need SOURCEDATE info for your objects. Best to have
        it both in your PCC and in the file/object you are putting in. I need
        to finish that LSTFileClass on SOURCExxx.

        > > 2. The default data is already RANK:1, so I can't choose a higher
        > > RANK.

        Ah I see what you are trying there... That's a bad way, and will
        cause all sorts of issues. RANK doesn't _really_ work as well as
        proported. It was great before the 'lazy .MOD was implemented'. Now
        not so much. What it really helps with is the parsing for normal new
        objects that reference core objects.

        > > 3. Commenting out the default data in the original file and
        > > putting the new data in my own dataset. I have found this method
        > > works, but I'll have to redo it the next time the default
        > > datasets are updated.

        Oh, yeah. .MOD or complete replace through SOURCEDATE and the
        preference is the way to go. This last option is _very_ agrivating.

        --
        Tir Gwaith
        PCGen LST Chimp
      • Andrew Maitland
        https://sourceforge.net/tracker/index.php?func=detail&aid=1612002&group_id=25576&atid=748235 ... [Non-text portions of this message have been removed]
        Message 3 of 4 , Dec 8, 2006
        • 0 Attachment
          https://sourceforge.net/tracker/index.php?func=detail&aid=1612002&group_id=25576&atid=748235

          Tir Gwaith wrote:
          >>> Say I want to change the stats on a default monster or spell, or
          >>> whatever. What is the best way to do this?
          >>>
          >
          > Have a set that you load with a .MOD for that entry.
          >
          >
          >>> 1. Making my own dataset and loading it in will not always
          >>> completely override the original data, sometimes it adds or
          >>> combines them together for the entry. So this is not a dependable
          >>> way. I do have the newer data option selected in the preferences.
          >>>
          >
          > Tags that are only allowed once will completely over-ride. Tags that
          > are allowed multiple times need to be removed/countered. That's under
          > normal stuff.
          >
          > <Aside to TM>
          > We could use a Documentation improvement that shows, for each tag, how
          > to remove/counter it in a .MOD - .CLEAR., simple entry will over-ride,
          > etc. Yeah, that's a big FReq, but I think it will go a long way to
          > helping out the casual LST coder and newbie
          > </Aside to TM>
          >
          > I think the New Data Option is _really_ what you want. However, to
          > make it work, you need SOURCEDATE info for your objects. Best to have
          > it both in your PCC and in the file/object you are putting in. I need
          > to finish that LSTFileClass on SOURCExxx.
          >
          >
          >>> 2. The default data is already RANK:1, so I can't choose a higher
          >>> RANK.
          >>>
          >
          > Ah I see what you are trying there... That's a bad way, and will
          > cause all sorts of issues. RANK doesn't _really_ work as well as
          > proported. It was great before the 'lazy .MOD was implemented'. Now
          > not so much. What it really helps with is the parsing for normal new
          > objects that reference core objects.
          >
          >
          >>> 3. Commenting out the default data in the original file and
          >>> putting the new data in my own dataset. I have found this method
          >>> works, but I'll have to redo it the next time the default
          >>> datasets are updated.
          >>>
          >
          > Oh, yeah. .MOD or complete replace through SOURCEDATE and the
          > preference is the way to go. This last option is _very_ agrivating.
          >
          >


          [Non-text portions of this message have been removed]
        Your message has been successfully submitted and would be delivered to recipients shortly.