Vendor Questions, Email questions

I've seen sample vendor code that keeps statistics on top sells, etc. It has a list and it increments when someone purchases an object. Where is this data stored longer term? Just in global variables? What happens to the values if the sim crashes or reboots or they update the sim software? Is there implementation for reliable longer term storage. Can I use a notecard and have the script update the notecard, so that it can retain the data? Or is this virtuallly what is happening with global variables? What is the reliability?

So what if I needed to keep information about the transaction for longer term records? Like who bought what and for how much? And what about across multiple vendors across multiple sims? Can I use the internal email system to send the information from all my vendors to a central location, to say a "central processing unit" script that holds the data for me or relays it to the outside world? How reliable is email?

I know i've asked about 20 questions.. but I think it's really just one or two concept questions.

Thanks for your help.

Without knowing exactly what vendor your speaking about, it is hard to fully answer, but in world only vendors would typically store data in global variables, although perhaps in parallel running scripts opposed to the "main" logic script.



Scripts seem fairly resilient to sim crashes. While I would not store anything of huge worth in global variables (like account information for an ATM like thing), I would think marketing data that is not mission critical in nature would be safe enough. A script cannot, nor in anytime in the near future, write to a notecard. The main way for mass in world only data storage is multiple scripts running in tandem, some which just are mainly used to store data and have a simple routine retrive/set this data via linked messages.



If your trying to store a large amount of data on a semi-perminent basis, I would recommend you look into purchasing an external server. Most basic (and cheap) web hosts have everything you'd need to setup data transfer from the server to SL as well as a MySQL or other database to store the data. Internal email can send data between items, and thus could be utilized to create a "cental processing unit" that has an array of memory scripts or a general gateway to the external world, as well as in charge of updating the other vendors. Reliability is fairly decent, especially with internal email. External email, while messages usually get through, sometimes can be delay pretty dramatically (I have seen emails take hours to deliver to an external source, however this is atypical).



Hope I answered everything.

You did good, thanks...

In my theoretical application, there are multiple vendors collecting data as people purchase the items, but let's say the data is more important than the item being sold, or maybe equally as important, like in the case of an ATM.

(it's not an ATM, but since you mentioned it, I'll use it as the example)

I do have an external server I can use. So let's say I use RPC to send data to an outside database for secure storage. Oh wait.. from my research it looks like that is not working yet. But I can send data as an email. Set up a special email account to send the data to.. then parse the emails and compile the data.. sounds complicated. How does having an external server help without being able to remotesend?

So my original idea of the central processing unit.. an object running a script that communicates with all the vendor machines and collects the data using internal email (since they'd be all over the grid), could work and would not require each vendor to store any data. Then the "cpu" could email the data in blocks to the outside world for long term storage.

To avoid potiential data loss, it should email the data immediately, but then why not just have the individual vendors do that? I hate lag and don't want to create laggy scripts either. Maybe there's an acceptable risk of storing 5 or 10 records at a time before emailing the block. Or maybe an email an hour?

BTW: How are these people doing ATM machines? That's a lot of important data to rely on volitle global variables. You mentioned multiple scripts running in tandem to replicate the data on different servers? Or do they have a little help from the Linden's.


Quick new question.. sorry. I'm full of them:

Money is paid to the owner of an object... I wanted to allow other people to 'own' my vending machines, get a % of the revenue created by that machine, but the rest goes to someone else (say the creator of the object being sold =ie= me). But it looks like, without owning the machine, there's no way to get the money paid to me first, instead of the current owner. I have to allow the user to pay the owner, and then use the script to immediately pay me my cut, rather than the other way around. Is there an exploit in there somewhere? I guess if the owner was just paid, say 100L, they should be able to afford to pay me a cut of that.

Make sure that the PERMISSION_DEBIT is given by the owner, and if they don't give permission, reset the script. This is an important thing for all vendors and especially casino games. They need to be able to pay refunds and in the case of casino games, winnings. With the permission to take money from the owner ensured, and no-modify on the script there really isn't a way for the owner to short-change you, unless they have a script running constantly to push money to an alt account.. which to me would constitute fraud.

I don't use RPC, but there are ways to get it to respond and send externally in the wiki.

That said the parsing email option works well for some too. I don't use it for this sort of thing, but I do use it quite happily. A quick scan through this forum will reveal various people who parse their emails quite happily and might share tips, as well as people talking about using RPC.

It sounds like someone is getting into a form of market research. Good for you. As the SL market matures, there is definately room for such things.

Personally, I would have each vendor just email the data off world immediately, instead of dealing with sending an email to a central processing bit and then in turn, having the central processing email it off world. I don't think I'd worry too much about llEmail causing lag - I have not experienced it having any large effect on a sim, even at much more fierce rates than whenever someone buys something.

Depending on your skills in another programming language, setting up the backend email parser is fairly simplistic. If you currently lack the skill, quickly read up on some form of what would typically be a CGI language, such as Perl, Python, PHP, or Ruby. I am sure with a little reading you would be able to write it or alternative I am sure there are many (myself included) whom could be contracted to write the backend code for you. The process of storing and retrieving data from a database is fairly easy in these language also, as most have pre-written modules for handling such tasks. I am confident that all of the ATMs store their data externally, and most likely send the data immediately. IMHO, for storing mission critical data, the most reliable route is to immediately send the data off world for storage, however have some sort of routine to verify the data has been recieved before the in world object forgets the data.

Gaz's sediments about the money issue are sound. I seriously doubt anyone is really having running a constant script to push money to an alt, although I could be surprised I suppose. I don't think I would worry too much about it though.

Sounds good.. and then I just saw a message about a sim not sending email for 90 minutes. So that would seriously mess up, say an ATM. I guess at that point you have the My Account -> Transactions database to use as a backup, but that only works if you own the vending machine and the money is being paid to you, and I wanted to allow other people to own the vending machines.