1.5.7 lsl changes

in and out of sl is good and should be a priority in the form of rpc, but an object to object message system would be a tremendous improvement too. Specially since rpc won't improve between object comunication. I realize that a region doesn't know where a key is if it's in another region, but there has to be a solution to this. How about a reciever registration function that adds that prims key to a database. This would not only make it possible for a message to go directly to the region and object with only a minimal database hit, it would pretty much erase the threat of any spam usage.

Actually I'm glad a workaround has been found for those who need to use it.

I've been talking to some of the other developers about this problem (until recently I was ignorant about how the llGetNextEmail() system works) and brainstorming for solutions. Mark Linden had a good idea that, had it occured to us on Tuesday would have solved this specific problem. This fix is simple enough that I'll try to get it into 1.5.8.

Hungry Linden had some other ideas about how to pull the email check completely out of the database which would allow us to push the emails rather than require the script to pull them.

Meanwhile I've been thinking about how to accelerate the XMLRPC project. It seems to me that XMLRPC might not take as long as we thought. This wouldn't allow us to put it into 1.5.8 or 1.5.9, but it could help its chances of getting into 1.6.

Woot thats great news! I'll make a Linden temple on my land and have daily mantras and hope you guys manage to make that working by v1.6 =)

Wow! That would be awesome! This would remove the unnecessary need for timers in a lot of scripts that use email.

God damnit NO. I LIKE pulling.

*cough*
I think it should be an optional feature (enabled by default) to have the email automaticaly delievered. As i'm betting Mole was using them for data storage.

I'm glad to hear that XML-RPC & email problems are being solved.

*agrees with strife*

OK, read the thread - have a big project in mind that will rely heavily on email. My question is should I wait for 1.5.8 so I don't have to code around the llGetNextEmail() delay or should I wait for 1.6 and full XML/RPC? Can you be any more specific on timing of these releases?

Either way you know we are all coding coding around the 20 second llEmail() delay. I'm curious if putting in these delays really helps when all we do is code around them and bog the system down with more scripts, link messages, timers etc... just to kludge around the limits? I'd prefer to see a post in the forums stating like 'fast polls on the llGetNextEmail() function are bogging down the database server, please try to tune back your scripts until we can get the hardware replaced'. Just a thought. I think most of us would respect that and help out. But doing it this way, we probably are putting MORE load on the system.

> I'd prefer to see a post in the forums stating like 'fast polls on the llGetNextEmail() function are bogging down the database server, please try to tune back your scripts until we can get the hardware replaced'

Yes. I'm sure I speak for many of us when I say that the first I knew that there was even any problem associated with llGetNextEmail was the patch message.

Buy-in is pretty easy since we are the only people using the email server. If we burn it up we've only got ourselves to blame really :-/

Azelda

*sings "Fire Water Burn"*

Andrew, it has been a little more than two weeks now. Can you please update on the release of 1.5.8 (AND the changes to the email handling !!)
Updating several hundred vendors manually isn't that much fun really !!

Actually, not so much "data-storage" as very well timed control mechanisms.

If anyone's been wondering at the recent flood of firebirds in Seacliff, this change is the cause.

I've got an autorezzer that (hopefully) maintains a constant level of 4 to 6 firebirds in the sim. The mechanism used is that once every 30 seconds, each firebird in the sim sends one email message to a census script, which processes those messages and determines how many birds there are. Once every 120 seconds, the rezzer asks the census script how many birds there are, and if there are fewer than five birds, it rezzes another.

This means that, in normal operation, the census script processes ten emails every minute. A timing hiccup resulting in six firebirds instead of five means that it's processing twelve every minute. But with the new delay, it is only possible to process eleven emails per minute, as the processing takes time.

This results in a backlog of emails, and causes the census script to eventually lose track of birds. As a result, the autorezzer keeps generating birds, even though there are already more than enough.

I've turned off the autorezzer and deleted the birds, but I estimate there's a backlog of between 50,000 and 100,000 emails left to be processed. At the maximum rate, the census script should clear that in three to six days.

Silly question but why not augment it with a sensor? Even better you could keep track of the keys of the birds it rezzes and then just call llKey2Name if that fails then you know they aren't in the sim but if it works then you know they are.

because hindsight is 20/20?

I mean, we could assume that all functions in SL will break at some point and code defensively by, well, re-writing SL but not everyone wants to take that route.

Azelda

1) Sensor range is insufficient to cover a sim, much less a multi-sim area.
2) The system was originally designed to work with a worldwide flock of birds. The fact that the current flock is restricted to a single sim is incidental.

The current target for 1.5.8 is next week. I haven't been able to get to the llGetNextEmail() fix yet, but I really want to get it into the next patch since I think we have come up with a simple solution.

The other stuff I was talking about won't be in 1.5.8, but I hope to work on it soon (1.6 or 1.7 if it's really as doable as I think it is).

The 1.5.8 Preview is up and I'll be leaving it up all night. The llGetNextEmail() sleep has been removed entirely, however it is currently impossible to send emails in or out of the preview grid.

Is it possible to send emails within the grid?

Not yet. To hit an object in the preview you need to send email to [email]object_uuid@lsl.colo.lindenlab.com[/email], however currently there is no email to that domain. I've asked our ops team to set this up for me so hopefully it will happen sometime today. When its working I'll post here.

That IS good news indeed !

Need to add Login Status bar has rounded edges to the Release Notes.


Seems exactly the same for cylinders.

Just FYI:
I really liked it before the restrictions on hollow were added.

If you have fixed the hollow for square shapes why not for triangles in spheres too?


Also llMinEventDelay is borked, setting it does nothing. Value is always 0.05. Also wasn't it fixed a few versions back that a script couldn't recieve it's own linked message?

list m;

default
{
    state_entry()
    {
        llMinEventDelay(1);
        llMessageLinked(0,0,"","");
        llMessageLinked(0,0,"","");
        llMessageLinked(0,0,"","");
        llSetTimerEvent(5);
        llResetTime();
    }
    link_message(integer a, integer b, string c, key d)
    {
        m+=llGetTime();
    }
    timer()
    {
        if(llGetListLength(m));
        {
            llSetTimerEvent(0);
            llSay(0,llList2CSV(m));
        }
    }
}

Could we be able to send longer messages through the report bug box?

__________________

Bamboo grows far to the north.

Emails to [email]object_id@lsl.colo.lindenlab.com[/email] now work. I'm in the process of putting up another candidate for 1.5.8 right now.


Onizuka -

Ah yes, the rounded edges on the login status bar. I'll leave that out, the release notes are limited to 32k and that one is too insignificant.



I'm not sure what that means, but I'll ask someone to translate that for me.

I'll look into the llMinEventDelay() issue. I'm unfamiliar with that call ATM but will educate myself.

I think we fixed the llLinkedMessage() issue but rolled it back because too many people were already relying on the broken behavior. That's one of the problems with having bugs in the scripting language... people will turn them into features.

We've thought about increasing the number of words in the reports. To do so would push the report beyond the contents of a single packet, and there is a advantage to giving people reasons to be brief or concise. I think someday we'll boost the size of the report, but not in 1.5.x.

If anyone had actually tested the llGetNextEmail() on the preview grid over the weekend they would have found that it was broken. I just fixed, tested, and deployed something that actually works.

I haven't been able to test llEmail() because the new installer is incompatible with Linux.