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

RE: [pcgen] Re: [TM] Chime of Opening

Expand Messages
  • Chris
    Well Duh, says Barak in enlightenment... That s why it works... the CASTERLEVEL in the COST:CASTERLEVEL*0 (or however we do that cost formula in the EQMOD) is
    Message 1 of 11 , Dec 2, 2004
    • 0 Attachment
      Well Duh, says Barak in enlightenment...

      That's why it works... the CASTERLEVEL in the COST:CASTERLEVEL*0 (or
      however we do that cost formula in the EQMOD) is 0 if you don't provide
      it, so there is no addition to the item cost.

      It's always good to figure out WHY something works. :)

      Barak

      PS: So if my speculation is correct, the following should work for the
      ring...

      Ring (Ram)
      OUTPUTNAME:Ring of [NAME]
      TYPE:Magic.Ring
      COST:8600
      WT:0
      EQMOD:SPL_CHRG|CHARGES[50]
      SOURCEPAGE:srdmagicitemsrings.rtf

      or (if CASTERLEVEL *has* to be there)

      Ring (Ram)
      OUTPUTNAME:Ring of [NAME]
      TYPE:Magic.Ring
      COST:8600
      WT:0
      EQMOD:SPL_CHRG|CASTERLEVEL[0]CHARGES[50]
      SOURCEPAGE:srdmagicitemsrings.rtf


      > To further expand upon this, the SRD Ring of Ram has its cost
      slightly off
      > (I'll enter a tracker for that later) and it has:
      >
      > Ring (Ram)
      > OUTPUTNAME:Ring of [NAME]
      > TYPE:Magic.Ring
      > COST:5225
      > WT:0
      > EQMOD:SPL_CHRG|CASTERLEVEL[9]CHARGES[50]
      > SOURCEPAGE:srdmagicitemsrings.rtf
      >
      > The cost should be 8600, PCGen shows 8850. However, it does shows 50
      > charges.
    • Eddy Anthony
      ... Would this suggest the need for a Charged Item EQMOD which does not include CASTERLEVEL in its cost formula? -- ~ Eddy Anthony (MoSaT) ~ PCGen Content
      Message 2 of 11 , Dec 2, 2004
      • 0 Attachment
        On 12/2/04 7:55 AM, "Chris" <barak@...> wrote:

        > That's why it works... the CASTERLEVEL in the COST:CASTERLEVEL*0 (or
        > however we do that cost formula in the EQMOD) is 0 if you don't provide
        > it, so there is no addition to the item cost.
        >
        > It's always good to figure out WHY something works. :)
        >
        > Barak

        Would this suggest the need for a Charged Item EQMOD which does not include
        CASTERLEVEL in its cost formula?
        --
        ~ Eddy Anthony (MoSaT)
        ~ PCGen Content Silverback
      • taluroniscandar
        ... provide ... include ... At one point there was such an eqmod. It and a couple of others got removed awhile back. That s why the charge eqmod has so many
        Message 3 of 11 , Dec 2, 2004
        • 0 Attachment
          --- In pcgen@yahoogroups.com, Eddy Anthony <eddyba@m...> wrote:
          > On 12/2/04 7:55 AM, "Chris" <barak@v...> wrote:
          >
          > > That's why it works... the CASTERLEVEL in the COST:CASTERLEVEL*0 (or
          > > however we do that cost formula in the EQMOD) is 0 if you don't
          provide
          > > it, so there is no addition to the item cost.
          > >
          > > It's always good to figure out WHY something works. :)
          > >
          > > Barak
          >
          > Would this suggest the need for a Charged Item EQMOD which does not
          include
          > CASTERLEVEL in its cost formula?

          At one point there was such an eqmod. It and a couple of others got
          removed awhile back. That's why the charge eqmod has so many items
          types it's valid for.
        • Eddy Anthony
          ... Just tried this out and I got an incorrect price each time (8860 without CASTERLEVEL 0 and 9350 with). Rather than mucking about with the existing EQMODs I
          Message 4 of 11 , Dec 2, 2004
          • 0 Attachment
            Chris scribed:

            > PS: So if my speculation is correct, the following should work for the
            > ring...
            >
            > Ring (Ram)
            > COST:8600
            > EQMOD:SPL_CHRG|CHARGES[50]

            > or (if CASTERLEVEL *has* to be there)
            >
            > Ring (Ram)
            > COST:8600
            > EQMOD:SPL_CHRG|CASTERLEVEL[0]CHARGES[50]

            Just tried this out and I got an incorrect price each time (8860 without
            CASTERLEVEL 0 and 9350 with).

            Rather than mucking about with the existing EQMODs I think a new one for
            this purpose is in order, here's what I came up with after some
            experimentation:

            Charges
            KEY:CHARGED_ITEM_10
            VISIBLE:NO
            CHOOSE:CHARGES|1
            CHARGES:1|10
            NAMEOPT:SPELL

            Its set to VISIBLE:NO because this would only be called from an item and so
            should not be available in the customizer. Because there is no cost tag no
            cost is added. There is a CHOOSE tag in the line because I found that the
            checkboxes would not display on the OS unless its there. The NAMEOPT:SPELL
            prevents the number of charges from being tacked on to the name of the item.
            With this EQMOD in place one only needs to add this line to any item which
            needs 10 charges:

            EQMOD:CHARGED_ITEM_10|CHARGES[10]

            We need several of these, one for each commonly used number, I've seen 3, 5,
            10 and 50. You could add EQMOD:CHARGED_ITEM_10|CHARGES[3] for an item with 3
            charges but the user could manually add up to 10 charges in the GUI.

            I've trackered this as a data FReq:
            [ 1078091 ] EQMOD for charges items

            Provided this is acceptable this could fix the bugs which have been pointed
            out in this thread.
            --
            ~ Eddy Anthony (MoSaT)
            ~ PCGen Content Silverback
          • Truth
            ... I argee something is needed here, but wouldn t we better with a generic tag that allows the data monkey to specify how many charges the max is? That way if
            Message 5 of 11 , Dec 5, 2004
            • 0 Attachment
              On Thu, 02 Dec 2004 21:40:38 -0500, Eddy Anthony <eddyba@...> wrote:
              > Rather than mucking about with the existing EQMODs I think a new one for
              > this purpose is in order, here's what I came up with after some
              > experimentation:
              >
              > Charges
              > KEY:CHARGED_ITEM_10
              > VISIBLE:NO
              > CHOOSE:CHARGES|1
              > CHARGES:1|10
              > NAMEOPT:SPELL
              >
              > Its set to VISIBLE:NO because this would only be called from an item and so
              > should not be available in the customizer. Because there is no cost tag no
              > cost is added. There is a CHOOSE tag in the line because I found that the
              > checkboxes would not display on the OS unless its there. The NAMEOPT:SPELL
              > prevents the number of charges from being tacked on to the name of the item.
              > With this EQMOD in place one only needs to add this line to any item which
              > needs 10 charges:
              >
              > EQMOD:CHARGED_ITEM_10|CHARGES[10]
              >
              > We need several of these, one for each commonly used number, I've seen 3, 5,
              > 10 and 50. You could add EQMOD:CHARGED_ITEM_10|CHARGES[3] for an item with 3
              > charges but the user could manually add up to 10 charges in the GUI.
              >
              > I've trackered this as a data FReq:
              > [ 1078091 ] EQMOD for charges items
              >
              > Provided this is acceptable this could fix the bugs which have been pointed
              > out in this thread.

              I argee something is needed here, but wouldn't we better with a
              generic tag that allows the data monkey to specify how many charges
              the max is?
              That way if new items are added with different max amounts that tag
              can just be reused.


              --
              Truth.
              There is no religion higher than the Truth.
            • Eddy Anthony
              ... I agree it would be more convenient to have a single tag which would provide this function and I would be the first to use it should it be made available
              Message 6 of 11 , Dec 5, 2004
              • 0 Attachment
                Truth scribed:

                > I argee something is needed here, but wouldn't we better with a
                > generic tag that allows the data monkey to specify how many charges
                > the max is?
                > That way if new items are added with different max amounts that tag
                > can just be reused.

                I agree it would be more convenient to have a single tag which would provide
                this function and I would be the first to use it should it be made available
                but its not something I'm going to push for, and here's why: First, it would
                require a code FReq and given that the function can already be done in data
                it would be given a low priority and it would be a long while if ever before
                we saw it. Second, I believe I've presented a complete workable solution
                here. If someone is coding an item which has a different number of charges
                than any of these EQMODs they have two options: 1) they can use one of the
                EQMODs with more charges than they need an set the initial value at less
                than the max to match the item in their source or 2) they could make a new
                EQMOD with the max value they need.
                --
                ~ Eddy Anthony (MoSaT)
                ~ PCGen Content Silverback
              Your message has been successfully submitted and would be delivered to recipients shortly.