Jump to content

*Purposely* calling llGetNextEmail at certain times.


Arron Rainfall
 Share

You are about to reply to a thread that has been inactive for 3608 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hi everyone. A lot of us scripters are aware that the SL email system is rather bugged, but I just wanted to say that I've had a bit of luck with implementing email in the following fashion. This is an "Email Reader" example:

 

default
{
    state_entry()
    {
        llOwnerSay("My email address is " + (string)llGetKey() + "@lsl.secondlife.com");
        llOwnerSay("Touch me to read emails.");
    }

    touch_start(integer total_number)
    {
        if(llDetectedKey(0) == llGetOwner())
        {
            llGetNextEmail("", "");
        }
    }
    
    // Possible usage: Relocating an object that uses email without having to change its key, and
    // therefore, its email address.
    // You do this by right-clicking the object, attaching it to your body, then
    // after relocating it to a different region, right-click and DROP it(do *NOT* detach it).
    // Remember to set to the appropriate group if needed, so the script can run.
    changed(integer change)
    {
        if((change & CHANGED_REGION) || (change & CHANGED_TELEPORT))
        {
            llGetNextEmail("", "");
        }
    }
    
    email(string time, string address, string subject, string message, integer num_left)
    {
        llOwnerSay(message + "\n" + (string)num_left + " left to read.");
        if(num_left)
        {
            llGetNextEmail("", "");
        }
        // You're probably thinking this next bit is redundant(since num_left is 0), but the SL email server
        // apparently can lose track of how many emails are in the email queue so...
        else
        {
            integer i;
            for(i = 0; i < 100; i++) // ... since the email queue limit is 100, demolish it ON PURPOSE.
                                     // "On purpose" being the key phrase, because again, the SL email server apparently
                                     // can lose track of how many emails are in the email queue.
                                     // The "num_left" that you are getting from the SL email server above *could* in fact be wrong.
            {
                llOwnerSay((string)i);
                llGetNextEmail("", "");
            }
            llOwnerSay("No more emails.");
        }
    }
}


 

The changed event code is primarily for when you relocate to a different region and you need a prim to keeps its key(it would then take advantage of the following...), however the MEAT of this example lies with the code shown in the email event, in particular the "else" statement.

Now normally, this "else" bit of code would appear to be redundant(after all, num_left is 0 right?), and in a bug free email system, it *would* in fact be. However, I am not so sure that the "num_left" parameter being received is in fact correct 100% of the time(there were times I would send the prim 3 emails, but num_left would be begin at 2). So instead of relying on the "num_left" parameter, I did this:

The email event documentation located at http://wiki.secondlife.com/wiki/Email states "The email queue is limited to 100 emails, any email after that is bounced", so instead of believing what happens to be the value of the "num_left" parameter, I take it upon myself to get rid of any and all emails that might happen to remain in the email by performing 100 llGetNextEmail calls.

So fellow scripters, if you could, please try implementing the code above and let me know how you fair with it.

Link to comment
Share on other sites

I also realize for the change event above(when relocating a prim to a different region), the prim will read the email then, as opposed to when you normally would, however, the attach/drop trick stated above in itself could experience yet another problem with the email queue, so I just go ahead and demolish the email queue then as well. Keep in mind though, the emails could actually be valid emails, so using this for some sort of client/server communication, you would either want to go ahead and process them, or implement some sort of retry/redo in the client.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3608 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...