Jump to content
Sign in to follow this  
Arron Rainfall

*Purposely* calling llGetNextEmail at certain times.

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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

Well I renamed the thread since this isn't exactly a cure for the bugged email system. However, I still believe the SL email server doesn't correctly manage emails in the email queue and doesn't always report the correct value in the num_left parameter.

Share this post


Link to post
Share on other sites

Email is something I mostly been experiementing with. I've been reluctant to use it. But if any of you know of any "ideal workarounds", I'd appreciate the feedback.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...