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

Default Monster treasure

Expand Messages
  • Eddy Anthony
    All this talk of random number generators got me thinking, we might be able to use this to add treasure to the Default Monster kits. So I did some experiments:
    Message 1 of 39 , Oct 4, 2005
    • 0 Attachment
      All this talk of random number generators got me thinking, we might be able
      to use this to add treasure to the Default Monster kits. So I did some
      experiments:

      GEAR:Coin (Gold) QTY:100 PREVARGT:roll("1d6"),3

      Believe it or not this PREVARGT actually works, the kit grants 100 gold
      coins about half the time it is applied :D. Then I tried:

      GEAR:Coin (Gold) QTY:roll("1d6")*10

      This does not work, it appears that QTY in GEAR lines only takes integers,
      not formulas nor JEP operators. If QTY for GEAR could be adjusted to use JEP
      we could implement a default monsters treasure at least partially, the coins
      would be no problem at all. For more specific items for which you need to
      roll on another table we could create some place holder items like:

      Treasure (Art object)
      Treasure (Gem)
      Treasure (Mundane item)
      Treasure (Minor magic item)
      Treasure (Medium magic item)
      Treasure (Major magic item)

      The places holder items would be an aid to the DM who would then roll on the
      specific table to determine what they are. Maybe a way can be found to get
      specific items.

      Here's another idea: could a kit be made to grant another kit? If so then
      the standard treasure tables could be done up as hidden kits and the default
      monster kit could simply add the appropriate treasure kit in one line
      instead of as a whole treasure GEAR list, it would cut down on replication.
      We could even add a PRERULE the line and add a House Rule to let the DM
      decide if he wants the treasure added or not when applying a default monster
      kit.

      Thoughts?
      --
      ~ Eddy Anthony (MoSaT)
      ~ PCGen Content Silverback
    • Devon Jones
      ... Absolutly, I took a hands off approach for most of this thread, because I want to see a lot of ideas fielded, and wether or not we go with a table or a
      Message 39 of 39 , Oct 10, 2005
      • 0 Attachment
        boomer70 wrote:

        >Specifically related to Andrew's proposal you are not
        >really talking about a true one-dimensional table. To
        >use a relational database analogy what he is proposing
        >is a table that has one column that has a foreign key
        >reference to another table, in his case the treasure
        >item table. That table has both rows (the items in
        >question) and columns (equipment type, eqmods, etc.).
        >So what have we lost. You cannot index a selection of
        >tables. So for example I can't say that I want to use
        >a give CR +/- 2 because each CR level is its own
        >table. We now also have to hardcode the new
        >treasure_item table and have to come up with new table
        >definitions (files) to extend the concept beyond
        >treasure. This can also lead to duplication of data.
        >In this case why do we need a specific file to define
        >what a treasure item is. We already have many
        >different ways of representing a piece (or pieces) of
        >equipment.
        >
        >All that being said I think Andrew's idea will work. I
        >just want to point out the drawbacks as I see them to
        >the approach.
        >
        >
        Absolutly, I took a hands off approach for most of this thread, because
        I want to see a lot of ideas fielded, and wether or not we go with a
        table or a list, the majority of your initial recomendation was spot on.

        Devon
      Your message has been successfully submitted and would be delivered to recipients shortly.