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

Re: [TM] Chime of Opening

Expand Messages
  • 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 1 of 11 , Dec 2, 2004
    View Source
    • 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 2 of 11 , Dec 2, 2004
      View Source
      • 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 3 of 11 , Dec 2, 2004
        View Source
        • 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 4 of 11 , Dec 2, 2004
          View Source
          • 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 5 of 11 , Dec 2, 2004
            View Source
            • 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 6 of 11 , Dec 2, 2004
              View Source
              • 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 7 of 11 , Dec 2, 2004
                View Source
                • 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 8 of 11 , Dec 2, 2004
                  View Source
                  • 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 9 of 11 , Dec 5, 2004
                    View Source
                    • 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 10 of 11 , Dec 5, 2004
                      View Source
                      • 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.