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

Re: [TM] Chime of Opening

Expand Messages
  • 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 1 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 2 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 3 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 4 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.