Contents

ChangeLog

Done. The script now should send money properly as well. Cleaned up the tips.

21-November-2011

llKey2Name() obviously fails when you click [ Send ] if the avatar keys in the BOOKMARK list are not all in the current region. Will be fixed soon...

About

From experience, I know (and so you should find out if you do not know), that it is most wise to create a secondary account to hold all your money. Running about in Second Life with all your cash on you is a bad idea. However, creating a secondary account is a bit cumbersome when it comes to sending money. If you run out, you will have to log-in the secondary account and transfer the money. Thanks to the feature of not have a log-out option in all the viewers, that either means you run two viewers at the same time (which is not possible on all machines), or you hotswap your accounts. This is not very convenient.

For that, I have created a bank that would allow you to link a secondary account to a primitive in world containing a script. You add yourself (hard-coded) to a list of people able to retrieve money, you grant the script permissions, you set a limit and then every time you want some money from your stash, you visit your primitive and retrieve the money.

There are also some tricks used in this script which might be interesting to developers.

Features

Set an upper limit on how much to retrieve.

Logs all the people who take money from the stash and pay money into the stash.

Edit the script and configure the parameters in the configuration section:

list STASH_USERS =["5552f71f-60c9-4564-b861-55b200e12176"];

This is a list of keys of the avatars that will be able to retrieve money from the stash. You should change this to the avatar key of your main account, for example. Or add other avatars if you wish to share the stash.

This is a list of keys to whom somebody in the STASH_USERS list will be able to send money to. For example, this could be your landlord.

Touch the primitive to start the set-up procedure (text will be displayed above the primitive to guide you).

You will be prompted to allow taking / depositing money. Accept.

Now it will ask you to pay a certain amount. Triple check that you are the owner and the creator of the primitive! If you are, then if you pay money into your own object, that money will go back to you. Why do we do this? By doing this we are setting the upper limit (explained more in developers section) of money that the avatars in your STASH_USERS will be able to retrieve. The script measures how much you paid in, hands you the money back and stores that amount as the upper limit the stash will contain.

Now the script will wait for a few seconds and go to a run state, discarding the text message above to appear inconspicuous.

These steps may be done by your alt and anybody in your STASH_USERS list:

You simply touch the object and follow the menus.

Tricks used in this Script (Developers)

There are a number of problems that I got around while writing this script:

There is no way to get the amount of L$ your avatar has on itself.

One way around that, is to pay an amount into an object and count the money using money(). Not only will the script now be aware of the money, but you can thereby implicitly set a limit. Neat!

Dang! I already used up the timer() event.

Use llSensorRepeat() with some ridiculous parameters (initially I was searching for Philip Linden's key in a 0.1 range) and a repeat time of your desired time. Since the llSensorRepeat() is crafted to fail and trigger no_sensor() all the time it runs, you can use no_sensor() as your timer() equivalent. In fact with llSensorRemove() you can have your llSetTimerEvent(0) call. However, you should keep in mind that different from llSetTimerEvent(), the llSensorRepeat() call immediately proceeds to scan which would make the no_sensor() event fire right away before it is rescheduled.

To get around that problem, just use some global variable that will make no_sensor() return just on the first entry. Something like this might be appropriate:

integer flag;
default{state_entry(){
flag =1;
llSensorRepeat("", NULL_KEY, AGENT, 0.1, 0.1, 60);
}no_sensor(){if(flag){// <--- tests flag, which will be 1 for the first run and then brings it back to 0, making it fail on the next entry of no_sensor().--flag;
return;
}// this area will be hit 60 seconds after the llSensorRepeat() has been executed.}}

Here is a equivalence table (NUMBER is the number of seconds, replace with a value):

again, keeping in mind that llSensorRepeat() will immediately trigger no_sensor().

Now you have freed up the timer() event, effectively having two timers. Neat!

Heap protection. Adding and adding stuff to lists will eventually make the stack collide with the heap.

Ideally, you could measure the amount of free memory and flush those lists when it becomes critically low. Since we are unable to do that reliably, you can just flush them after a certain period of time and size. For example, this script will check every 60 seconds if the DONORS and RETRIEVERS lists are over 25 elements and flush them if they are.

This should be kept in mind for logging scripts which continuously add to the heap. Eventually, if there is no upper limit on the data, the script will crash.