What Is It About This Script That Makes Prims With It Disappear?

[Prokofy Neva]

What is it about this script that causes prims to disappear? (Originally scripted by Ordinal Malaprop, who is no longer inworld).

I'm forced to ask this bizarre question after a dozen or more experiences over the years where prims with this script in it disappear. For good.

Yes, they are set to the right group. No, they are not in "share". No, the sim hasn't been overfilled with prims such as to force prims back in inventory. No, it's not in Lost & Found. It's gone. And the other way you know it's gone besides looking at the empty spot where it used to be is by touching the "Request Delivery" terminal that it used to be linked to -- and no notecard is delivered.

So just today, I discovered that a client prim with this script in it which has literally sat on a sim for 10 years and functioned perfectly is *gone*. Nothing else is gone. Since I've had this experience multiple times with my rentals client and similar notecard distribution services on multiple sims, I have to ask: why is it doing this (rather than "who is doing this").

Why does it matter?

The problem is that you can't simply replace it. It works on the principle that each time you rez out a prim with it, it generates a new key. Then you have the awful chore of putting that new key in all the numerous servers out there that now have only the old key from the disappeared client -- and hence don't work.

So my real question is: is there any way to force this script not to generate a new key, but accept the key that you give it, namely, the old key -- which all those hundreds of servers have in it.

Obviously, the servers have another script in it which is called "Request Notecard" and the key is pasted into that.

If any terminology in this post is wrong, i.e. I've mixed up "client" and "server" and what they do, don't let that distract you.

You can see the issue. The prim generates a new key -- and maybe that's because every prim has to have its own unique UUID and therefore you can't change it. But for the purpose of this script functioning, I do wonder if it is possible somehow.

 

 

// ================================
// Configuration
// ================================

//Specify a name for the folder to give items in or leave empty to give items seperately.
string DELIVERY_FOLDER = ""; 

// Reporting functions added by Ordinal Malaprop 2007-05-27
// Set to the key of the av you wish to send reports to
// "" disables reports
// "owner" sends reports to the owner
string REPORT = "owner";

// ================================
// DO NOT EDIT below this point.
//
integer EMAIL_RECEIVED = -678;
string  CMD_GIVE   = "give";

integer INVENTORY_TYPES = INVENTORY_NOTECARD;

list    lItemsToGive = [];

// Added by Ordinal - this is the running report string, leave it alone
string gReport = "";

DeliverItems( key kAgent )
{
    integer iNumObjects = llGetListLength(lItemsToGive);

    if( iNumObjects > 0 )
    {
        if( DELIVERY_FOLDER != "" )
        {
            llGiveInventoryList( kAgent, DELIVERY_FOLDER, lItemsToGive);
        } else {
            string  sObjectName;
        
            integer i;
            for( i = 0; i<iNumObjects; i++ )
            {
                sObjectName = llList2String(lItemsToGive, i);
                
                string prefix = llGetSubString(sObjectName,0,1);
                
                if( prefix != "!*" )
                {
                    llGiveInventory( kAgent, sObjectName);
                }
            }
        }
    }
}

init()
{
    llOwnerSay("Initializing list of items to be given.");

    lItemsToGive = [];
        
    integer iNumObjects = llGetInventoryNumber( INVENTORY_TYPES );
    string  sObjectName;

    integer i;
    for( i = 0; i<iNumObjects; i++ )
    {
        sObjectName = llGetInventoryName( INVENTORY_TYPES, i );
        
        string prefix = llGetSubString( sObjectName, 0, 1 );
        if( prefix != "!*" )
        {
            if(llGetInventoryPermMask(sObjectName, MASK_NEXT) & PERM_COPY)
            {
                lItemsToGive += sObjectName;
            }
        }
    }

    
    if( (llGetListLength(lItemsToGive) >= 1) && (DELIVERY_FOLDER != "") )
    {
        llOwnerSay("Initialization done, the following items will be given in a folder named [" + DELIVERY_FOLDER + "]:");
        llOwnerSay( llList2CSV( lItemsToGive ) );    
    } else if( (llGetListLength(lItemsToGive) >= 1) && (DELIVERY_FOLDER == "") ) {
        llOwnerSay("Initialization done, the following items will be given:");
        llOwnerSay( llList2CSV( lItemsToGive ) );    
    } else {
        llOwnerSay("Initialization done, there are no items to give:");
    }

    // added by Ordinal
    if (REPORT == "owner") llOwnerSay("Sending reports to you");
    else if (REPORT == "") llOwnerSay("Not sending delivery reports");
    else llOwnerSay("Sending reports to the av with key " + REPORT);
}

default
{
    state_entry()
    {
        init();
    }
    
    on_rez( integer status )
    {
        key kOwner = llGetOwner();
        
        llInstantMessage( kOwner, "My object key has likely changed.  Please make sure that all client terminals are set to access the following key:");

        // modified by Ordinal Malaprop 2007-05-27
        // as it was saying the wrong key
        llInstantMessage( kOwner, (string)llGetKey() );
        
        init();
    }

    touch_start(integer n)
    {
        // This touch event added by Ordinal Malaprop 2007-05-27
        key owner = llGetOwner();
        if (llDetectedKey(0) != llGetOwner()) return;
        llOwnerSay("My key is " + (string)llGetKey() + " - make sure this is included in every client script.");
    }

    link_message(integer sender_num, integer msg_flag, string message, key id)
    {
        if( msg_flag == EMAIL_RECEIVED )
        {
            string subject = (string)id;

            list lData = llParseString2List( message, ["|"],[""] );
            
            string sCommand = llList2String(lData, 0);
            
            if( sCommand == CMD_GIVE )
            {
                string sCategory = llList2String(lData, 1);
                key    kAgent    = llList2String(lData, 2);
                
                
                DeliverItems( kAgent );
                
                // Send report to specified agent
                // Added by Ordinal Malaprop 2007-05-27
                // This will only respond with clients that send data with name and location
                // as the fourth and fifth items of data. Older clients won't get reports.
                if (REPORT != "" && llGetListLength(lData) > 3) {
                    // Construct a readable time string and report
                    list timeBits = llParseString2List(llGetTimestamp(), ["T", "."], []);
                    string report = "[" + llList2String(timeBits, 0) + " " + llList2String(timeBits, 1) + "] " + llList2String(lData, 3) + " (" + llList2String(lData, 4) + ")";
                    // If running report is getting too long, send it then blank it.
                    // Add the latest report to the end in either case.
                    if (llStringLength(gReport + report) > 1022) {
                        if (REPORT == "owner") {
                            llInstantMessage(llGetOwner(), gReport);
                        } else {
                            llInstantMessage(REPORT, gReport);
                        }
                        gReport = report;
                    }
                    else {
                        gReport += "\n" + report;
                    }
                }
                // end of Ordinal-added bit
            }
        }
    }
    
    changed( integer change )
    {
        if( change & (CHANGED_INVENTORY | CHANGED_OWNER) )
        {
            init();
        }
    }    
    
}

[Rolig Loon]

I don't see anything in this script that would cause it to vanish.  From the way it's written, though, I assume that there is a second script in the object -- a script that receives e-mailed instructions from some distant source and then signals this one by link message to do its job.  It's possible that the clue you're looking for is in that other script, although I can't see offhand why a scripter would write that sort of behavior into a simple communication script either.  As unlikely as it may seem, I suspect that the object is being returned by parcel overload.  Don't ask me why.

[Wandering Soulstar]

 

There is nothing in the script that you posted that could make an object disapear (and next time please post in the code window .. the <> button .. makes it much easier to read). There looks to be another script in the prim though .. this script gets a link_message, which can only come from a script in the same prim or another in the linkset,. The other script seems to be receiving emails. The reason I assume this other script is in the same prim,  also means that there is not a way to force the key .. from the code above:

    on_rez( integer status )
    {
        key kOwner = llGetOwner();
        
        llInstantMessage( kOwner, "My object key has likely changed.  Please make sure that all client terminals are set to access the following key:");

        // modified by Ordinal Malaprop 2007-05-27
        // as it was saying the wrong key
        llInstantMessage( kOwner, (string)llGetKey() );
        
        init();
    }

the important line is the one with llGetKey(), which gets the unique key of that prim, and which the serves then use as the email address to send their emails to .. from the wiki (llEmail definition):

Quote

If you are sending email to a prim within Second Life, its address is [key]@lsl.secondlife.com

 

[Wandering Soulstar]

2 minutes ago, Rolig Loon said:

although I can't see offhand why a scripter would write that sort of behavior into a simple communication script either. 

Actually Rolig, if the other script is sending emails this architecture makes sense, llEmail causes a script to sleep for 20.0 seconds

[Rolig Loon]

1 minute ago, Wandering Soulstar said:

Actually Rolig, if the other script is sending emails this architecture makes sense, llEmail causes a script to sleep for 20.0 seconds

Yes, I know.  What I meant is that I can't see any reason why a scripter would write code into a simple communication script that would cause it to disappear.  That would make no more sense in the e-mail script than it does here.  Therefore, it's not a script issue.

[Prokofy Neva]

1 hour ago, Rolig Loon said:

I don't see anything in this script that would cause it to vanish.  From the way it's written, though, I assume that there is a second script in the object -- a script that receives e-mailed instructions from some distant source and then signals this one by link message to do its job.  It's possible that the clue you're looking for is in that other script, although I can't see offhand why a scripter would write that sort of behavior into a simple communication script either.  As unlikely as it may seem, I suspect that the object is being returned by parcel overload.  Don't ask me why.

Thanks.

Well, as I wrote, "Obviously, the servers have another script in it which is called "Request Notecard" and the key is pasted into that."

So below is that script in case it's relevant, but it's not (they go in two separate prims).

So then the operative question is, again, how can you force the script to accept a key?

See the key you have to insert on this "Request Notecard" script? At the top?

That comes from the prim in which the first script is located - it generates automatically each time you rez it.

So the question is: can you get the first script to use that key?

 

string SERVER_KEY = "8bcd0fd5-9f08-d6e6-ef11-86fcb3c1ffb9";
string CMD_GIVE   = "give";

default
{
    touch_start(integer num_agents)
    {
        string subject = "Notecard Request";
        string body    = CMD_GIVE + "|News";
        string address = SERVER_KEY + "@lsl.secondlife.com";
 
        integer i;
        for( i = 0; i<num_agents; i++ )
        {
            key kAgent = llDetectedKey( i );
 
            body += "|" + (string)kAgent + "|" + llDetectedName(i) + "|" + llGetRegionName();
                       
            llInstantMessage( kAgent, "Request submitted");
            
            llSetText("Busy",<1,1,1>,1);
            llEmail( address, subject, body );
            llSetText("",<1,1,1>,1);
        }
    }
}
 

 

[Prokofy Neva]

1 hour ago, Rolig Loon said:

Yes, I know.  What I meant is that I can't see any reason why a scripter would write code into a simple communication script that would cause it to disappear.  That would make no more sense in the e-mail script than it does here.  Therefore, it's not a script issue.

No, it makes no sense. But since it has repeatedly happened, I have to ask the question.

[Prokofy Neva]

2 hours ago, Wandering Soulstar said:

 

There is nothing in the script that you posted that could make an object disapear (and next time please post in the code window .. the <> button .. makes it much easier to read). There looks to be another script in the prim though .. this script gets a link_message, which can only come from a script in the same prim or another in the linkset,. The other script seems to be receiving emails. The reason I assume this other script is in the same prim,  also means that there is not a way to force the key .. from the code above:

    on_rez( integer status )
    {
        key kOwner = llGetOwner();
        
        llInstantMessage( kOwner, "My object key has likely changed.  Please make sure that all client terminals are set to access the following key:");

        // modified by Ordinal Malaprop 2007-05-27
        // as it was saying the wrong key
        llInstantMessage( kOwner, (string)llGetKey() );
        
        init();
    }

the important line is the one with llGetKey(), which gets the unique key of that prim, and which the serves then use as the email address to send their emails to .. from the wiki (llEmail definition):

 

The reason I didn't put the script in the code window is because when I try that, it says "your browser does not suppor that" (I use Opera) and it's just a nuisance to go find Google and download it and make it do all this now. But I'll try to remember next time.

As I explained in my original post, these are " notecard distribution services". 

Once again -- there are two scripts, "deliver" and "request". I just put the first one because THAT is the one that I want to change. 

It sounds like you're saying that you have to live with this problem of getting the unique key.

So again, I hope you can see the problem:

The first prim with the delivery script in it is LOST. This keeps happening. Why, I don't know.

BECAUSE it happens, I'm stuck with a huge annoyance. The *second* prim -- separate from the first -- has a *Request Notecard" script. On that script, you put the key. Now imagine that you copy and distribute that second prim -- there are hundreds of these scattered all over -- people get them so they can keep getting updates.

Now, when that first client -- delivery -- script inside a prim is lost, you are stuck. You can't -- apparently -- create a new prim and make the delivery script in that prim have the OLD key number, such as to be able to keep talking to all those hundreds of other prims out there with the "request notecard".

It's a real weakness of this system. How can it be changed?

Yes, it spits out this message -- because it's in the script: "

My object key has likely changed.  Please make sure that all client terminals are set to access the following key"

Now envision what is involved in "making sure all the client terminals are set to access the following key". That means going all over 50 sims, hundreds of people etc etc and issuing an entirely new delivery prim and script with a new key -- because of this nuisance -- so they can get the updates.

So naturally I'm wondering how can we get rid of its "need" to have an object key generated from a new prim? How can we put in the script THE OLD KEY from the original prim, now lost?

Edited January 30, 2019 by Prokofy Neva

[Rolig Loon]

Thanks for posting that second script.  It's interesting, but there's still something missing.  This script doesn't communicate with the first one that you posted.  The first script is receiving a link message from somewhere.  Wandering and I were both assuming that the "somewhere" must be a second script in the same prim, although  it could be in a linked prim.  That's the script we were curious about.  This new script sends its own message by e-mail, apparently to that missing script.  If there's a way to do what you want, it will have to be in the communication between this script you just posted and the missing one.

[Innula Zenovka]

@Prokofy Neva  Just to clarify... you're using the correct term for the remote "server" prim that delivers the notecard.  

However, as Rolig suggests, the local "client" prim that's vanished, and that contains the first script you posted, should contain at least one other script to send it a link message to cause it to request a notecard.

The second script you posted doesn't look like anything I'd expect to find in a remote server, though.  That script is also one for a "client" prim, though I don't think it can have been written to work alongside the first script you posted.

The server script will contain an email event, which looks something like this:

	email(string time, string address, string subject, string body, integer remaining)
	{
		
	}

The UUID of the client prim -- the one sending the request for the notecard -- doesn't matter.  The remote server prim is the one to worry about.   Re-rezzing the server would break everything, since the clients need to know the server prim's uuid, which your scripts will expect to be hard-coded, in order to send a message to the server, but the server doesn't need to know the client prim's uuid in order to receive messages from it.

 

Edited January 30, 2019 by Innula Zenovka

[Rolig Loon]

As you deduced correctly, from what Wandering wrote, there's really nothing to be done about the fact that the key has changed.  The e-mail address for the object is based upon that key, so once the key has changed it will no longer be able to receive messages sent to the old address.  The way around the problem is cumbersome.  It ultimately involves saving the UUID of each of your 50+ receiving objects in a database somewhere, and updating that database every time a new receiving object is created.  That means having a "server" somewhere whose UUID (and therefore whose own e-mail address) never changes.  That has always been the weak link in the system.  As Innula just wrote while I was typing this, it's that server that you have to focus on, cumbersome though the process may be.

Nowadays, people use the Experience system's KVP capability to save all those UUIDs, in affect acting like a grid-wide server in Linden Lab's basement. That's fine if all your receiving objects are scripted to operate within an Experience and if that Experience is available on every single region where the receiving objects are likely to be.  For the moment, that's improbable.

Edited January 30, 2019 by Rolig Loon

[Qie Niangao]

I guess the least disruptive solution might be to find a hosting provider willing to let emails forward through it. That way all the request notecard scripts could direct their requests to that external email relay, which could then forward it to whatever the current notecard-sending prim's UUID might be, where now there's just that one place to update whenever the UUID changes. Two problems, though: this introduces another point of failure in the system (like, what if that hosting provider goes away?), and it may not be so easy to find a provider willing to host an email relay (but maybe it is, I just never tried).

Well, three problems: even when the email target prim doesn't mysteriously go missing, there's a very old, very intermittent bug in the sim server's email implementation that will eventually cause an object to just stop getting any emails. There's a workaround to restart that object's email queue without needing to rez out a new copy with a new UUID, but still it means SL object email is inherently unreliable.

So, to do much better, there would need to be a substantial re-write to use either the Experience system's KVP as Rolig suggested or an external server over HTTP rather than email. FWIW, we've been expecting "grid-scope" Experiences "real soon now" for a while, and if / when they arrive, they could make the Experience KVP approach a lot more practical than it is now for this application.

[Innula Zenovka]

13 minutes ago, Qie Niangao said:

So, to do much better, there would need to be a substantial re-write to use either the Experience system's KVP as Rolig suggested or an external server over HTTP rather than email. FWIW, we've been expecting "grid-scope" Experiences "real soon now" for a while, and if / when they arrive, they could make the Experience KVP approach a lot more practical than it is now for this application.

Though in this particular use case, I'm assuming that Prok wants to use the boxes for his rental properties on his own land, so a "grid-scope" experience probably wouldn't be necessary.   

That's if, I stress, the client scripts are to be used only on Prok's land rather than in advertising boards all over the grid.

[steph Arnott]

That was an LSO script, if it is converted to mono it will cause issues. Certain LSO scripts can not be converted.

[Prokofy Neva]

On 1/30/2019 at 3:46 PM, Qie Niangao said:

I guess the least disruptive solution might be to find a hosting provider willing to let emails forward through it. That way all the request notecard scripts could direct their requests to that external email relay, which could then forward it to whatever the current notecard-sending prim's UUID might be, where now there's just that one place to update whenever the UUID changes. Two problems, though: this introduces another point of failure in the system (like, what if that hosting provider goes away?), and it may not be so easy to find a provider willing to host an email relay (but maybe it is, I just never tried).

Well, three problems: even when the email target prim doesn't mysteriously go missing, there's a very old, very intermittent bug in the sim server's email implementation that will eventually cause an object to just stop getting any emails. There's a workaround to restart that object's email queue without needing to rez out a new copy with a new UUID, but still it means SL object email is inherently unreliable.

So, to do much better, there would need to be a substantial re-write to use either the Experience system's KVP as Rolig suggested or an external server over HTTP rather than email. FWIW, we've been expecting "grid-scope" Experiences "real soon now" for a while, and if / when they arrive, they could make the Experience KVP approach a lot more practical than it is now for this application.

What I can't help wondering, however, is why this notecard delivery system *has* to work on the principle

I'm thinking, for example of systems like the Paskis key, which enable you to lock doors with one prim that is a "key" and has a certain code you yourself devise within a range of numbers, and a config card inside a door prim, into which you insert the same key you've devised.

If you can do this with a "key" and a door, why not a notecard server? The server has a key of 1234, and all the terminals have 1234 in their scripts.

Is it because it wouldn't work outside the same sim? Or?

Edited February 5, 2019 by Prokofy Neva

[Prokofy Neva]

On 1/30/2019 at 4:03 PM, Innula Zenovka said:

Though in this particular use case, I'm assuming that Prok wants to use the boxes for his rental properties on his own land, so a "grid-scope" experience probably wouldn't be necessary.   

That's if, I stress, the client scripts are to be used only on Prok's land rather than in advertising boards all over the grid.

It's not about rental boxes and not about my own land.

It's a notecard delivery system that people can use by putting the terminal -- an object themselves buy or receive and become the owner of -- out on their own land, set to their own land or group. That was indicated in the original post.

 

Edited February 5, 2019 by Prokofy Neva

[Prokofy Neva]

On 1/30/2019 at 3:22 PM, Innula Zenovka said:

@Prokofy Neva  Just to clarify... you're using the correct term for the remote "server" prim that delivers the notecard.  

However, as Rolig suggests, the local "client" prim that's vanished, and that contains the first script you posted, should contain at least one other script to send it a link message to cause it to request a notecard.

The second script you posted doesn't look like anything I'd expect to find in a remote server, though.  That script is also one for a "client" prim, though I don't think it can have been written to work alongside the first script you posted.

The server script will contain an email event, which looks something like this:

	email(string time, string address, string subject, string body, integer remaining)
	{
		
	}

The UUID of the client prim -- the one sending the request for the notecard -- doesn't matter.  The remote server prim is the one to worry about.   Re-rezzing the server would break everything, since the clients need to know the server prim's uuid, which your scripts will expect to be hard-coded, in order to send a message to the server, but the server doesn't need to know the client prim's uuid in order to receive messages from it.

 

It is not the local client that has vanished. It's the server -- the prim that delivers the notecard -- that has vanished. That's why a whole new key is needed, which is an annoyance because then all those terminals/clients locally that used to receive that notecard must now update the script with the new generated key, or get a whole new terminal prim if they can't figure that out. 

And as I keep asking, why is a delivery system contingent on the prim it is in, and not the script that runs it? Why can't the script just have any number in it, and the prims that receive it have a script with that same number? Then if the delivery prim is lost, you just put the same number in a new script, regardless of the prim.

[Rolig Loon]

14 minutes ago, Prokofy Neva said:

And as I keep asking, why is a delivery system contingent on the prim it is in, and not the script that runs it? Why can't the script just have any number in it, and the prims that receive it have a script with that same number? Then if the delivery prim is lost, you just put the same number in a new script, regardless of the prim.

Because, as we have explained, you are sending instructions to the server -- your delivery system -- by e-mail, and the e-mail address of any object in SL is based on its key.  When you lose the prim and replace it with another one, the new prim cannot receive e-mails intended for the original prim.  The new prim has its own unique e-mail address.  Therefore, there are only two ways around the problem. 

1. One is the method you are already using: update the key (and thus e-mail address) is every single object that will be needing to communicate with your server.  This method is frustrating to say the least, as you already know.

2. The other way is to give up on e-mail entirely.  That involves either communicating by HTTP with a server outside of SL that has a "permanent" URL or using HTTP and the KVP system that is part of the Experience protocol in world.  This way means doing a significant rewrite of the scripts you are currently using.

[Qie Niangao]

32 minutes ago, Prokofy Neva said:

... If you can do this with a "key" and a door, why not a notecard server? The server has a key of 1234, and all the terminals have 1234 in their scripts.

Is it because it wouldn't work outside the same sim? Or?

You're quite right to put scare quotes around "'key'" because it's unfortunate nomenclature for the unique identifier of prims (and of everything else in SL). It's true that one wants to match a message and the prim to which it's addressed (as a key fits a lock), but one also needs to address that message to that prim in a way that the message delivery service (llEmail in this case) can locate it and route the message to that fixed "key" address. And yes, because the message may be sent and received on different sims, there are only certain ways of doing it, llEmail being the oldest and having the problems discussed in this thread. Unfortunately, the other options have the other problems also discussed in this thread.

[Wandering Soulstar]

 .. to add to the above, whilst your system is for delivery of notecards from the server to the terminals, the initial communication is from the terminals to the Server. They 'register' with the server (via email) as the server will need their 'keys' to be able to send them the notecards. 

[Estelle Pienaar]

When I learned to script prim servers in SL that are connected with clients via PHP, I found it really tiresome. I prefer concrete examples to get my head around things and at the time I have not found one single working example, only code snippets. So I thought this is a moment to give something back to the community, by posting a very basic proof of concept for the discussed use case. You find it here:

 

Edited February 7, 2019 by Estelle Pienaar