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

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

Expand Messages
  • Barak
    ... As long as you don t specify a spell, it doesn t change the price. That s how I ve done it in the CMP sets. (And I just tested to verify and it s priced
    Message 1 of 11 , Dec 2, 2004
    • 0 Attachment
      > -----Original Message-----
      > From: tir_gwaith [mailto:thoron-tir-gwaith@...]
      >
      > No, that hasn't been added. Those aren't "Charges" like wands and
      > staffs have charges (the # of charges affect price via a formula for
      > stored spells). I was just looking at the Brooch of Shielding

      As long as you don't specify a spell, it doesn't change the price. That's
      how I've done it in the CMP sets. (And I just tested to verify and it's
      priced properly in the gui in 5.6.1 and displays the checkboxes for
      charges...)

      Rod of Absorption
      TYPE:Magic.Rod
      COST:50000
      WT:5
      EQMOD:CHARGES_SPELL_EFFECT|CHARGES[50]
      MODS:N
      SOURCEPAGE:
      SPROP:Captures spell energy cast at it (up to 50 levels) and storees it for
      use by wielder

      Barak
    • Paul W. King
      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
      Message 2 of 11 , Dec 2, 2004
      • 0 Attachment
        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.

        So, Tir, to answer your question, its a data bug :) . I'll get a tracker
        entered for it later today.

        Or, one of the other TMs can beat me to the punch and enter the 2 data bugs.
        :D

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

        -----Original Message-----
        From: Barak [mailto:barak@...]
        Sent: Thursday, December 02, 2004 6:10 AM
        To: pcgen@yahoogroups.com
        Subject: RE: [pcgen] Re: [TM] Chime of Opening

        As long as you don't specify a spell, it doesn't change the price. That's
        how I've done it in the CMP sets. (And I just tested to verify and it's
        priced properly in the gui in 5.6.1 and displays the checkboxes for
        charges...)

        Rod of Absorption
        TYPE:Magic.Rod
        COST:50000
        WT:5
        EQMOD:CHARGES_SPELL_EFFECT|CHARGES[50]
        MODS:N
        SOURCEPAGE:
        SPROP:Captures spell energy cast at it (up to 50 levels) and storees it for
        use by wielder
      • thoron-tir-gwaith@lycos.com
        ... Ok, once again: Data FReq. Bug for the Ring of Ram if we can figure out why, and FReq for the Chime of Openning, and I think there already is one for the
        Message 3 of 11 , Dec 2, 2004
        • 0 Attachment
          > So, Tir, to answer your question, its a data bug :) . I'll get a tracker
          > entered for it later today.
          >
          > Or, one of the other TMs can beat me to the punch and enter the 2 data bugs.
          > :D

          Ok, once again: Data FReq. Bug for the Ring of Ram if we can figure out why, and FReq for the Chime of Openning, and I think there already is one for the Brooch of Shielding.

          BUG: used to be there, but no longer works/gone missing. Incorrect numbers also falls under it (if the number is there, if not, it is a Freq)
          FReq: Never been coded for the object in the first place....

          Tir Gwaith
          LST Chimp
        • 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 4 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 5 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 6 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 7 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 8 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 9 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.