Writing a Redlivery terminal for MP purchases

[Vulpinus]

I have enough sales on the MP now, especially of one particular item, that manually redelivering them through the MP when I do an update is a pain. I'm not aware of any automated way to do this - is there one? Google hasn't helped so far.

So, I'm making a 'redelivery' terminal so people can come and get it themselves in-world. My plan is to make a (periodically updated) list of recipient usernames from a filtered MP report and put that list in a notecard in the terminal for the script to read.

Then, detect the UUID of who's touched the terminal, get the corresponding username with llGetUsername() and search the list for it. Giving inventory will follow if appropriate.

Sounds simple - has anyone done this before and are there any 'issues' I need to be aware of with this approach? It's my first real public interaction thing, so I'm just being cautious ;)

I wish there was an easy way to get the UUID from the username and automate the whole thing, but it seems there isn't.

[Nova Convair]

I don't see a problem.

You say you have the list of usernames on a notecard so all you have to do is.

The usual notecard stuff. Read into a list in state_entry and repeat that after the notecard has changed.

If someone touches you have the name (llDetectedName) and search for it in the list (llListFindList).

On a match send the update to the touchers uuid which you can get with llDetectedKey.

Another combo is: llDetectedKey and llKey2Name

If your notacard list has not the exact names (capitals) you can normalize all names with llToLower. And keep in mind that llKey2Name and llDetectedName adds "Resident" if they have no lastname so you need to handle that detail too.

[Vulpinus]

Thanks Nova, it does seem simple but I thought it best to check. Good point about the 'Resident' - I had temporarily forgotten that.

I've just been complicating things by starting to implement a binary search directly on the notecard (assuming I've sorted that of course).

I have about 130 sales now and still rising a few a day, so I thought that way would save script memory and speed things up.

Just trying to get my head around implementing that in conjunction with the dataserver event :confused: ... I'll figure it out though. (Recursive, thinks I)

Perhaps I'm overcomplicating things again though :smileylol:

[Sassy Romano]

Easier to populate a SQL database on a web host with a one time import from MP report.  Thereafter hook the ANS data feed from Marketplace and add to your database automatically as each sale happens.

From that the rest is straightforward.  You could even have the user interface as a web page presented via media on a prim.

(When I say the rest is straighforwards, that's because if I remember correctly, you have skills on web and database platforms and all you're doing is a bit of communications between LSL and a hosted back end, calls being made via llHttpRequest() )

 

[Vulpinus]

Ooh... it didn't occur to me that the MP had that facility (I did brielfy think about intercepting the sale emails to get the info). I've just found the thread you started on the subject.

I'll save that for a universal system that will handle everything I sell though. I just wanted something very quick and easy for now. I've already finished this one

Thanks for that info!

[Tech Robonaught]

This would be something Id buy if it would be a simple rez and go system with little or no configuration neccessary .... owner being seller of course and clicker being customer, pulling its data directly off MP would be the only way to go.

[Sassy Romano]

https://marketplace.secondlife.com/stores/95570?&search[sort]=price_desc

As far as little or no configuration, bear in mind that any inworld scripted item CANNOT trigger a marketplace redelivery, asked for... those deaf ears must be hurting by now from all the things that have been falling on them but that's another story.

Thus, to configure, you have to have an inworld "server" which contains the items that are to be delivered.  Not a difficult task really.