PnP Coins for NWN1 Released!

[Legacy_Mad.Hatter]

               After much wailing and gnashing of teeth, I released PnP Coins for NWN1. It is essentially a heavily modified C.R.A.P. coins system (continued as Accerak's coin system for NWN2) without being attached to everything else and with the ability to add encumbrance or multiple currencies within the same module on the fly.

You can find it on the Vault here: http://nwvault.ign.c....Detail&id=8038

PnP Coins for NWN1

Version 1.1

Created by: David Douglas



FEATURES:

1.) Changes the module economy from one based solely on gold coins
to one featuring five denominations (coin names are determined by the
builder).

2.) Uses any merchant in any module in which it is configured.

3.) Coins are now items in a PC's inventory and can therefore be dropped, pickpocketed, or traded as such.

4.) Builders may create several types of currency and easily
configure merchants to only take one type (each currency has five
denominations--this could be useful in large modules where PCs deal with
merchants from several nations/regions).

2.) Builders may set coins to encumber and weigh down PCs.

4.) Is CEP compatible.

5.) Does not use Heartbeat scripts.



LIMITATIONS (as of v1.1):

1.) Builders must alter their treasure scripts and quest rewards so
as not to generate default NWN gold (GiveItem rather than GiveGold).

2.) Does not offer companion support (builders need to alter their scripts accordingly--TakeItems rather than TakeGold).

3.) Has not been tested for modules in which PCs can gather vast
amounts of coin (hundreds of thousands of coins). Such modules may
experience lag during acquiring and unacquiring due to the strain of
taking and giving so many items.

4.) Is CEP dependant (if there is demand I will decouple it completely and make it an independent hak).





INSTALLATION:

1.) Create a new CEP 2.X module.

2.) Associate pnpcoinsv1_1.hak to your module and place it BEFORE
the cep2_top_v2X.hak that you are using. This hak only contains a
modified zep_inc_main and baseitems.2da**. This is necessary for the
system to function properly.

3.) Import pnpcoinsv1_1.erf. This currently contains five scripts
(coins_clstore, coins_opstore, coins_inc, coins_acqu, and coins_unacqu),
five example coin blueprints, and one weight stone item blueprint.

4.) Create five coin items using the Coins base item type. The coins
must have a resref and tag of (replace "yourcoinID" with the name of
your currency):

   coin_yourcoinID1 = 1/100 coin  (Copper)

   coin_yourcoinID2 = 1/10  coin  (Silver)

   coin_yourcoinID3 = 1/2   coin  (Electrum)

   coin_yourcoinID4 = 1     coin  (Gold)

   coin_yourcoinID5 = 10    coins (Platinum)



   Example: "coin_dollar1", "coin_dollar2"...

  To create another type of currency, simply create another set of
five coins with a new yourcoinID. For example: coin_sterling1,
coin_sterling2, etc.

4a.) Open coins_opstore and coins_clstore and edit the appropriate
lines to reflect yourcoinID. Create a new pair of scripts for each
currency type in the module (continuing my example: one for "dollar" and
one for "sterling"). Associate these scripts with each store in your
module.

5.) OPTIONAL: Add coins_onacqu and coins_onunacqu to the module's
OnAcquire and OnUnAcquire events to utilize the coin encumbrance system.
Coins weigh 1/50 a pound by default. If you have custom scripts for
these events you must merge them. The system's additions to the default
script have been clearly commented so this can be done easily.



**Changes to CEP files include: (1) adding a single line to
zep_inc_main to make the COINS base item type usable in the system
scripts; (2) changing line 203 of baseitems.2da. This line contains the
COINS base item type which has had its inherent weight reduced to zero
(from 0.1) and stacking limit raised to 50,000; (3) adding line 500 to
baseitems.2da to create a custom weight item.



SYSTEM SPECIFICS:

1.) PnP Coins works by converting coin items into NWN default gold
when a PC opens a store and re-converts this gold to custom coinage upon
closing the store.

2.) During this transaction, coin quantities are stored as local
variables on the PC. As a PC buys or sells, these quantities change to
reflect their new balance. After a sale, PCs will always receive
platinum first and gold second (they will never receive electrum,
silver, or copper during a sale). During a purchase, merchants take from
higher value denominations first. This order can be altered by the
builder by reordering lines 132-151 in the coins_inc script. The system
will not exchange lower denomination coins for higher ones during a sale
as each coin type is saved as a separate variable. Builders should feel
free to create conversation based money-changers who are more than
willing to play the currency markets.

3.) Coins are stackable to 50,000 per stack.

4.) The default exchange rate is 100 copper = 10 silver = 2 electrum
= 1 gold = 1/10 platinum. It would be possible to adjust this exchange
rate or add new denominations to the system but that is beyond the scope
of this writing.

5.) For encumbrance and weight purposes, all coins are considered to
weigh exactly 0.02 pounds (50 coins = 1 pound; this is adjustable in
coins_inc). When coin is acquired, coins_onacqu counts the number of
coins carried and divides it by 50, this is then compared to the number
of weight items carried (stackable to 9000, each weighs one pound). If
these two do not match, all weight items are destroyed and the correct
number of stones are created (in groups of 100, 10, or 1 to reduce CPU
load). These stones are then marked as cursed so that they cannot be
dropped. Should a PC drop their weight stones the OnUnAcquire script
will instantly recognize the imbalance between weight and coin items and
give them more. In other words, I am uncertain if it is even possible
for players to cheat the weight system. These weight items are not
created on DMs and NPCs. Builders should feel free to remove the IsPC?
check to coins_acqu and coins_unacqu if they want DM/NPC encumbrance due
to coins.





CREDITS:

Special thanks to Kilana Evra, Accerak, and the C.R.A.P. team for
providing the basis and model (indeed large chunks of code) to this
endeavor. My only contribution was building upon their excellent ideas
and work. Theirs is the credit.





If you have any questions, have recommendations, or find any errors
with the system please contact me at der_amerikan AT hotmail.com or send
a PM to Mad.Hatter on the Bioware Social forums.

-David Douglas





CHANGE LOG:

v1.1 -- 5/20/11 Added optional encumbrance scripts and weight item to the system.
               
               

               
            

[Legacy_Mad.Hatter]

               I released a non-CEP version this evening. I also upgraded the way coin balances are created to eliminate TMI errors when processing massive amounts of coin.
               
               

               
            

[Legacy_TSMDude]

               What is the difference between using yours vs just using the ones in the cep/crap? (Just for my own fyi.)
               
               

               
            

[Legacy_Mad.Hatter]

               Great question. I don't know the specifics of the CRAP coin system but based on my digging around in the 2das, reading the CRAP installation guide, and checking out their scripts:
Pro:
(1) This system can be used without CEP and is very lightweight.
(2) PnP Coins removes the weight from coins which means that builders have the option of encumbrance (or to not use it like default gold) and handles weight via script which allows for the correct 3e 50 coins = 1lb ratio (which could be altered within the script to be more or less according to preference).
(3) PnP Coins can handle multiple types of currency in the same module out of the box. In other words, Silverymoon could use one set of coins while Cormyr could use another entirely (see the FR 3e campaign setting book to see what I mean). You could tag them and resref them to where they are interchangeable, or create moneychanger NPCs to handle it (with a fee, of course).
(4) PnP Coins has a 50,000 stacking limit on coins rather than 100, making organization much easier. It also does not require a coin bag. I believe that having a higher stack size reduces the strain of creating a lot of coins (in a chest, suppose) because in PnP Coins, if you create 100,000 coins in a dragon's hoard, you have only created two stacks of items, whereas in CRAP you have created 1,000.
(5) From what I have seen, my system handles the coin variables more efficiently by having several if else statements per coin per function measuring coins up to 10,000 at a time, reducing CPU load especially where lots of coins are concerned.
(6) Variables are only stored temporarily as the PC talks to a merchant rather than on items or oPC. All the values are saved/loaded by reading the tags and resrefs of the coins when the PC opens a store.
CONS:
(1) PnP Coins does not yet automatically handle treasure generation like CRAP coins do. Builders will have to slightly alter their treasure scripts. Not terribly difficult but something I have not gotten around to yet. Just like CRAP, if a builder uses a custom script already, he or she will have to account for the new coins in that script.
(2) I'm sure there is something else, I was just comparing our features list.

Due to the fact that I based a lot of my work off Accerak's PnP Coins for NWN2, and he was a CRAP member iirc, my system takes all the functionality of CRAP (besides the treasure generation) and makes it more efficient and adds a few features on.
               
               

               
            

[Legacy_Taino]

               Wow sweet idea and thanks for your hard work!
               
               

               
            

[Legacy_Mad.Hatter]

               No problem! I needed this for an upcoming campaign and couldn't find a suitable system. Check it out and let me know what you think.