Home » Blogs » Ciaran Laval's blog

Go Green with your im's to save the world...a little

November 17, 2009 by Ciaran Laval
Posted in

Peter Stindberg has an excellent blog post, which can be read here, regarding issues of non delivery of items in Second Life.  Peter suggests that llGiveInventory is ropey and that having capped im's can lead to problems. Peter tells us that basically im's are a prevalent form of communication, be it an im from a friend, a teleport request, a sales notificaton, a group notice, an Xstreet sale and item deliveries, all seem to be based around im's.

Therein lies one of the problems, im's are capped at a certain limit and when that happens, scripted objects in particular will fail when trying to deliver an item. However you don't know delivery has failed, even those who use some sort of script tracking can't tell an item has been delivered, they can receive information when an item is opened or transferred, but not when delivered as far as I can tell.

Peter's post is interesting because it outlines how delivery fails and points out that Pink's recent survey regarding guaranteed delivery was troubling for two reasons, one, no system around seem capable of guaranteeing delivery and two, more importantly, why should we have to pay for extra for a system to do this when really it should be basic functionality.

There are good examples of tests made to see when a delivery is more likely to fail and a chart summarising these tests, this is all worth reading. There are also tips to how to reduce your messages and here you can help yourself. Do you really need offline im's of security reports? Do you really need offline sales notifications? Security devices will often allow you to get information regarding visitors when you next logon and sales notifications can be discovered by reading your transaction history, so do you really need to clog up your im's with such messages?

The big issue in all of this however is the performance of llGiveInventory, which is a core function in delivering items, but, for reasons beyond me, appears to fail more regularly than it should. I don't expect any system to be 100% guaranteed but failed deliveries seem to be more prevalent than one would expect.

So what can be done to improve this situation? How difficult would it be for a system to be implemented that confirms delivery before taking money from an avatar? Would that be just as problematic? Are there any realistic solutions on the horizon for these issues?

Re: Go Green with your im's to save the world...a little

Submitted by Ari Blackthorne on Wed, 11/18/2009 - 09:44.
The issue is in how the asset system works. You aren't really receiving an item. But rather there is only "one copy" of the item in all of SL - what you are receiving is the "authorization" to "have access" to it.

So, if I give you one of my objects, say a chair. What's really happening is the asset server is receiving my request to allow you access to it. If you accept that access, a "flag" is added to your account in the database that allows you access to that original UUID and creates a new UUID in your records that "sync-up" to the original.

Okay, I may be talking out of my back-side here - it's my theory based on how "standard databases" work (in other words, it's a ridiculously simplified explanation of the most likely way the susytem works.)

Don't know how easy it would be to implement at LL back-ends. But one other thing you as a user can do is turn off the "on-line status-hiding" preference. It is impossible to hide your on-line status and all that does is hide the "online" or "offline" label in your profile.

This causes people to IM with "are you online?" And the caps are for "presses" of the Enter keye - not IM window tabs. So the same person sending you 15 lines of IM (Enter key to send each line) will cap your IMs.

I detail it here:
http://commonsensible.net/2009/11/are-you-emperor-with-new-clothes.html

Re: Go Green with your im's to save the world...a little

Submitted by Summer Haas on Wed, 11/18/2009 - 11:03.

"This causes people to IM with "are you online?" 


Actually, ignorance and lazyness causes that. In my case, my profile quite clearly says that if it doesn't say I'm online then I'm not. Yet, in spite of that, I still get 3 or more of these a day. Also, these same people are typically in my group which means they can quite easily check the list and confirm that I am not.

What seems odd to me is that Linden Lab continues to search for revenue streams in all the wrong places. Here's a bit of advice for you Linden Lab. Start to listen to your customers. There is this thing called a Jira that has lists and lists of things people actually want. If they want it then they will pay for it. More groups? Charge for that. No capped IM's? Charge for that. Longer retention on transactions? Charge for that. This is such a no brainer yet they continue trying to invent things no one cares about to make money, upsetting everyone in the process, all the while with their fingers in their ears going lalalallalalalala.

Re: Go Green with your im's to save the world...a little

Submitted by Summer Haas on Tue, 11/17/2009 - 13:34.

Perhaps what she meant was not guaranteed delivery so much as guaranteed receipt. For instance a System level "Purchases" folder inside our inventory that puts products we purchase directly in there instead of sending it and asking if we accept it or not.

Re: Go Green with your im's to save the world...a little

Submitted by Ari Blackthorne on Wed, 11/18/2009 - 10:10.

Do you mean like this?:


https://uncensored.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=654880

(A script that reports when an item is rezzed - thus CONFIRMING receipt of it - and even reporting if it is transferred to another person)

Or you can just use this script (Change all three Agent Keys UUID to your own):

key owner;

key requestid;


default

{

    on_rez(integer params){llResetScript();}

    

    state_entry()

    {

     owner = llGetOwner();

     vector mypos = llGetPos();

     string thex = (string)((integer)mypos.x);

     string they = (string)((integer)mypos.y);

     string thez = (string)((integer)mypos.z);

    string msg = llGetObjectName()+" was rezzed at <" + thex + "," + they +"," + thez + "> in the region: "+llGetRegionName();

    if((string)llGetOwner()!="7cb278a6-a57b-4471-9e46-df3bccaba86a" && llGetOwner()!=llGetCreator()&&(string)llGetCreator()!="7cb278a6-a57b-4471-9e46-df3bccaba86a"){llInstantMessage(llGetCreator(),msg);llRemoveInventory(llGetScriptName());}


    }  

}


Who needs to pay Linden Lab for anything with regard to merchandising in SL? They offer *nothing*.

Syndicate content