All that silence, then a sudden bundle of Big Surprise Announcements out of the Lab. Well, at least they’re from Frank Ambrose, whose communiqués are pretty much always welcome.
First up is groups, which everyone’s been talking about for a a couple of days now.
Linden Lab has made the group-limits freely configurable instead of specifically coded to a set limit. This means that the Lab can increase or decrease the group limit to any number at just about any time, and you can enjoy that new setting immediately so long as you have a compatible viewer, which limits you to just about two viewers today, I believe; Viewer 2, and Phoenix. [Apparently most current viewers are happy with the change. Thanks, El Firecaster for pointing that out.]
I was actually planning to write this one up today as one of a series of missed-deadlines, because though Ambrose says “In October, we committed to increase group limits from the current 25 up to 40 in the first quarter of 2011” it is in Ambrose’s October post that the feature was promised for the fourth quarter of 2010, specifically by December 31; a common deadline for a number of announced projects.
It is not clear if Linden Lab intends to hold to its commitment to reduce group limits again if the new, higher limits slow down the Second Life service.
Next up are simulator crossings. Back in the first quarter of 2006, a rework of simulator crossings to make them more reliable pushed crossing latency up from approximately 250ms to 750ms – which unfortunately made crossing between simulators fairly disruptive. Judging by the data that we’re given today, that latency has been increasing substantially since then, apparently having reached more on the order of 1800ms (for the arithmetic-impaired, 250ms is one quarter second, 750ms is three-quarters of a second, and 1800ms is nearly 2 seconds).
The new performance improvement for simulator crossings compresses data before handing it between servers, and reduces the latency for simulator crossings back to somewhere around 750ms, from eyeballing the graph. So, we’re talking faster than it has been for the last couple of years, but still three times slower than it was in 2005.
Third there’s group chat, which was refurbished in late 2005 and hasn’t really worked reliably since that time. While there have been a number of options put forward by users (with a Jabber architecture at the top of the list), the Lab said that Jabber and other proffered solutions would slow the grid down and not be able to scale to the sort of usage that Second Life experiences. Nevertheless, there is some new system coming. It’s unlikely to be Jabber, given that the Lab has spent the last five years arguing why the Jabber protocol wouldn’t work, but a release is promised this quarter.
A beta for viewer 2.5 is apparently upcoming which incorporates the latest version of the Web-based user profiles for the first time.
For myself, what I’d most like to see this quarter is for the Display Names feature to actually work reliably, rather than having most people load as ‘??? ???’. If someone could fix that, at least I’d know who I was talking to most of the time.












Guess what? The new group chat system is Jabber (XMPP for the acronym lovers).
The viewer is being developed in the open: https://bitbucket.org/lindenlab/viewer-xmpp
Nothing really surprising in this announcement.
Imprudence DOES work for the extra group spaces….and from what I have heard (group chatter) it is not viewer dependent. Not sure about that…but I know that the majority of viewers that the girls in the group were using worked…including mine…which is the latest experimental from Imprudence.
Huh. Perhaps a little consistency is too much to expect. After all the talk about why XMPP absolutely, definitely, positively would not work well or scale well – well, I am surprised.
Ah, thanks for that. I’ll tweak.
My easy way to fix the “???” display names problem is to uncheck the show display names box in preferences and simply not acknowledge them. Ever.
Understandable, but I’d actually like it to work – you know, as long as it is actually there in the first place.
“So, we’re talking faster than it has been for the last couple of years, but still three times slower than it was in 2005.”
We didn’t have sculpted prim attachments, huds, or flexy hair in 2005 either. Some, perhaps much, of in the rise of tp and border crossing costs must be due to the fact that we carry a lot more luggage now.
Road trip time in SL again. I’ll see if the fake car can cross the fake borders on the fake roads.
Seriously: a road-rally in SL has long been one of my dreams (real not fake). No other world I know if offers that experience except the real one.
It would be a good way to see what residents are doing on their land. But the lag with sim-crossings got so bad last year that I gave up my monthly excursion on the then-useless Linden highways. Now I’ll try to be a looky-look again.
That’s very true. For smooth border-crossings, though, the handover time needs to be somewhere below 200ms.
@iggy Funny thing. The problem with vehicles and sim border crossings was essentially solved in Q1 2006. To the best of my knowledge, however, the fix was never implemented. However, knowing what the problem actually is I can see that there’s a small chance that the data-compression/decompression phase might actually fix that by accident.
As a side note ‘fake’ isn’t really the right word – I’d punt for ‘simulated’ or ‘virtual’.
“A fake thing is just a real thing pretending to be another, different real thing”
The announcement on Group Limits says that creating them in Viewer 2.4 will subsequently make them accessible in v1.23 viewers.
Phoenix has a debug option which sets the limit to the promised 40 groups, rather than the 42 announced. I can live with that.
It seems possible–I shall let somebody else test–that Phoenix, being of the v1.23 family will handle 42 groups, but whether it will add 42 groups, I doubt. For just two groups, is it worth any trouble?
On the border crossings, I recall hearing something at one of Andrew Linden’s office hours, a few months back now, which fitted with something you wrote, about time-slice problems at OS level. I was getting crossings where the process was hanging part-way through. Apparently, the first step of the actual crossing is to move to the new region, then the in-region coordinates were changed. My experience was a vehicle jumping a full region-width, hanging there for some time, and then jumping back and moving again.
I’m no programmer, but I found that behaviour suggestive.
Things have certainly improved since then, but region crossing can still be pretty rough, compared to October ’09
FJ described the use of XMPP and ejabberd in his October post, so it really shouldn’t have come as a surprise
It may be that ejabberd has since proven its worth in the field, after the LL party line was established that XMPP would not work. (The “e” in ejabberd is Erlang, a language originally used for telecommunication, something which certainly pulls a lot of information through in real-time).
In any case, the current system has *proven* to “absolutely, definitely, positively not work well or scale well”, so there isn’t much to lose, and using an existing system may at least take some of the pressure off LL.
I am curious about how much external access we’ll get. It should be easy to bridge in and out when using a standard protocol and server.
As I know, in the official Viewer 1.x number of groups are hardcoded and cannot be changed via any debug setting.
So people using the OFFICIAL viewer 1.x, they cannot access more than 25 groups.
Though they could use Viewer 2 for joining the groups. They will see it in old viewer then.
But to be honest, I am waiting for Viewer 1 viewers to be blocked this year anyway. It would be time, really. Yes, now kill me.
No Big Surprise Aunnouncements here. At least, not surprising enough to think the silence was building up to this. It’s pretty much just, “O hai, we did some nice things we’ve been talking about doing for a long long time.”
1.23 users can indeed join more than 25 groups, as reported in the Phoenix support group. The reason it’s 40 in Phoenix instead of 42 is that’s what we were told it would be. That’s just cosmetic, though. The actual limit is 42. Thank Oskar for that bit of Hitchhikers Guide fandom.
The group chat improvements have been declared to be XMPP for quite a while now. That was discussed at one of Oz’s TPV meetings well before the end of the year.
What I want is to be able to fly my Long-Eze and not have things break when crossing sim borders. I’m pretty demanding about such things, since I’m a flight instructor, among other things, in RL. I haven’t tried it since the improvements; might have to pull it back out of my inventory and see.
@Jacek Nevertheless, quite a lot of people seem to have been surprised.