Group Services Project
As noted in the section on server deployments, major issues this week with the LeTigre RC channel meant that the server-side code for this project again did not make it to an RC channel in a meaningful way. There are currently no plans to deploy the code in week 41 (week commencing Monday 8th October).
In the meantime, Baker linden has updated the project viewer for this project, which includes a capability to allow for fetching the group list via UDP if the new 10K cap on the UDP service isn’t detected in the server-side code, so that viewers on simulators which are not running the new Group Services code can continue to access large groups during the transitional phase of the project.
Interest Lists and Object Caching
The server code for this project has been deployed to the Ahern, Balkanski and Beirne regions on Aditi. however, speaking at the Server / Sim User Group meeting on Friday 5th October, Andrew Linden indicated that the first cut of his code “Just wasn’t any faster than the old system,” and he’s therefore embarked on cleaning-up the initial code and fixing elements of it in preparation to have another try.
The aim of the project is to both optimise the data being sent to the viewer and the information already cached on the viewer, with the aim of significantly improving object rezzing times in terms of speed and order (so objects closer to you rez before those further away, for example).
As an aside to this project, Andrew is going through the server-side code and removing the last remnants of the old particle cloud system (the clouds that used to be around the 300m altitude mark). These all but vanished when region Windlight settings were introduced, but there is apparently still some code remaining on the server side, so Andrew is taking an opportunity to clean it up.
SL Issues
Linkability Bug
While not strictly a project, there is currently a bug which is allowing linking of prims over distances greater than the theoretical maximum distance for a set of prims. This is known to Linden Lab and is under investigation by Andrew Linden. In the meantime, Simon Linden recommends people do not exploit the bug to make very large linksets, as the fix is liable to be rolled out in the next couple of weeks.
Speaking at the Server / Sim User Group meeting on Friday 5th October, Simon Linden explained the reasons for keeping the linking limit to 54m when it is now possible to rez prims up to 64 metres on a side / in diameter is that large linksets could:
- Could interfere with interest list / object rezzing (particularly relevant given the work being put into improving these), as visibility is based on the root prim in a linkset. So if very large link distances are allowed, the root prim may be outside someone’s draw distance, but still be affecting interest list calculations, etc. This is particularly relevant given the work being put-in to improving the interest lists code (which has been described as “fragile”, and “hard to modify”)
- There is a risk that very large linksets could cause conflicts with parcel encroachment, etc., as it could cause large linksets to overlap parcels without being return (presumably because the root prim of the linkset is sufficiently well inside the offending parcel’s boundary, even if prims in the linkset are encroaching neighbouring parcels.
Related Links
With thanks to Baz deSantis
Inara Pey: Living in a Modemworld 
Having commented on “Black Wednesday” on an earlier post, I won’t repeat myself. However, this news from Simon Linden puzzles and worries me.
Yes, the “convex hull” breakage resulted in a lot of prims being returned on sims that were close to or at their theoretical limits. My experience, on a sim that is nowhere near its prim-allocation limit, is quite different. I and my partner both had mutliprim objects “returned” (eventually) despite our sim’s allocation limit not being exceeded. All returned items were scripted, and many scripted objects appeared “broken” under the first code roll. This physics- or script-breakage does not seem to feature in Simon’s triage of the debacle. I have to hope that this was NOT connected with the “physics update”. If it was, I foresee another sorry situation next Wednesday which will require rollbacks if massive asset damage is not to ensue.
I am beginning to wonder if The Lab really does understand fully what carnage they created on LeTigre last Wednesday.
LikeLike
Sadly, I wasn’t at the Friday meeting (SLurl) in order to raise your comments (and I actually would have, had I been there). It’s held at midnight UK time, and I’m reliant on the largesse of a couple of friends to send me transcripts.
If you can make the meeting next Tuesday, 8:00 UK time (same SLurl as above, meetings are held twice a week), you can raise concerns with Simon and Andrew, et al.
There is also Oskar’s Beta server meeting (Aditi SLurl) at 23:00 UK on Thursdays (which is also an awkward one for me to make).
LikeLike
As I understand it, there were two problems with the LeTigre update. One was the massive return of objects noted here — and, yeah, it very definitely affected regions and parcels that were nowhere near their limits. Whatever went wrong with the land impact accounting, it went very, very wrong.
I had a bunch of content returned from relatively prim-sparse land, but most of it was not scripted. One _possible_ reason that scripted items might be more subject to being returned would be if more such items belonged to an account other than the landowner, compared to unscripted items. (This was suggested as one reason that group-owned land was particularly hard-hit.)
The other problem was that the LSL function llGetPos() always returned in the updated sims. This may have been what caused the reported script breakage. I believe that the Lab is aware of that problem, too, but it wouldn’t hurt to confirm it.
Regarding the post-mortem, I hope they not only consider what needs to change to make sure no deployment ever goes so wrong again, but also some tools for Operations to detect much sooner that something is going wrong. Clearly, during the roll out, the affected sims were doing very strange things; a massive drop in total number of objects would be a big red flag, if the sims were instrumented for such things. A valuable risk containment step would be to automatically monitor not just one specific metric like that, but any large deviation from normal conditions that coincide with Operations activity.
LikeLike
(Hmmm. Apparently WordPress eats angle-bracketed expressions. I’ll try a different way of saying it: llGetPos() always returned ZERO_VECTOR in the updated sims.)
LikeLike
WordPress is doing some bizarre things right now, both on displayed pages and within the inbuilt editor. Most of the issues I’ve encountered have occurred since my switch to a new layout template. This might be a placebo observation (and certainly doesn’t explain the problems I’m witnessing when using the inbuilt editor), but is certainly curious. Apologies for the problem you had.
LikeLike
I’d love to go to one of these almost mythical Linden Office Hours that LL hold, but 8:00am BST is before my medications kick in and I am even more witless that usual. 12midnight is offlimits for much thse same reason, except by then the meds are wearing off!
If I sent Simon a notecard to his inworld account, do you think he would read it?
LikeLike
Sorry, my fault not 8:00am 20:00 (8:00pm). I broke my usual rule and used 12-hour notation instead of 24, which I use to avoid this kind of confusion. Clearly, not enough coffee in my bloodstream today…
LikeLike
Once again I build to a new, if unannounced, “feature” only to discover that it is a bug! Lately we have been building walls and fences. I noticed that longer linksets were possible and took advantage of it.
I will wait and see what happens 🙂
LikeLike