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

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

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