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

Chime of Opening

Expand Messages
  • Michael Lenehan
    I dont know if anyone got this fixed yet, but in 5.6.1 the Chime of Opening does not show up as a charged item in the OS. After 10 uses the Chime cracks and
    Message 1 of 11 , Dec 1, 2004
    • 0 Attachment
      I dont know if anyone got this fixed yet, but in 5.6.1 the Chime of
      Opening does not show up as a charged item in the OS. After 10 uses
      the Chime cracks and becomes useless.
      I know there was someone who was asking about items other than wands
      that use charges, and I'm not sure anyone mentioned this
    • 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
      Message 2 of 11 , Dec 2, 2004
      • 0 Attachment
        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
        recently, and I couldn't figure out the best way to display that.
        When we get CDOM and some sort of equipment "local define" this will
        be easier, but I'm not certain how that would then communicate to the
        OS tokens to help in the check boxes..

        TM's, I don't know where this one goes....

        Tir Gwaith
        LST Chimp


        > I dont know if anyone got this fixed yet, but in 5.6.1 the Chime of
        > Opening does not show up as a charged item in the OS. After 10
        uses
        > the Chime cracks and becomes useless.
        > I know there was someone who was asking about items other than
        wands
        > that use charges, and I'm not sure anyone mentioned this
      • 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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.