On Tuesday January 7th, the Main channel received the server maintenance project that had been on the RC channels for the past few weeks. It contains a single bug fix, related to vehicles becoming stuck in the ‘sat upon’ state (which prevents parcel auto return)
On Wednesday January 8th, all three RC channels received a new server maintenance project, which contains some crash fixes and the new LSL functions for uniformly scaling linksets, all of which are immediately accessible using current viewers (see part one of this week’s report for details). This project also contains updates related to STORM-68 and STORM-1831, both of which require viewer-side updates which have yet to be released by the Lab.
LSL Syntax Highlighting Updates
Related to STORM-1831, these updates, which were deployed to the RC channels as noted above, will eventually see the viewer able to fetch LSL syntax highlighting rules directly from the simulator. However, there are currently some errors in the syntax file as deployed to the RC channels this week (repeating text, bad whitespace, or inaccurate definitions of functions), which require further corrective work. As there is currently no publicly available viewer which can use this new capability, it is unlikely this issue will prevent the server maintenance project from being promoted to the Main channel in week 3.
The file is designed to be cached by the viewer (once the viewer-side updates are released), and is around some 600KB in size. This means that the file should only ever be downloaded and updated if the LSL editor is open, and the viewer detects a version number difference between the file it has cached and the file held by the simulator to which it is connected.
It is unclear when the viewer-side updates for this work will appear. While planned to arrive in a release candidate viewer containing a number of Snowstorm updates, it appears there are still a few bugs in the STORM-1831 code, such as with function arguments being presented in an incorrect order in the tool tips, which may delay its inclusion.
Week 3 Deployments
It is likely the server project currently on the three RCs will be promoted to the Main channel in week 3 (commencing Monday January 13th). However, it is also likely there will be no RC updates for the week, as there are no server maintenance updates ready to go, and no other projects (such as group ban lists) are in a position to be deployed.
Thursday January 9th saw the PackageFix viewer (dated January 2nd, 2014) promoted to the de facto release viewer. As per pervious notes in this blog, this viewer has no SL-related functional updates. Rather, it corrects an issue introduced with the 3.6.12 code base whereby the Windows executable name was changed from “SecondLife” to “SecondLifeViewer”, without removing any executable using the “SecondLife” name from the installation folder. As a result, any shortcuts pointing to the “old” executable would allow it to run if used, thus potentially triggering further auto-updates.
With this fix, any executables using the old name (“SecondLife”) are removed from the installation folder, so any shortcuts created to them will cause Windows to display an error message, and the user can then remove them or modify them to point to the correct executable.
Fitted Mesh Progress
Oz Linden is anticipating a release candidate of the Fitted Mesh viewer Real Soon NowTM. There are currently no open issues at present, and work is underway to move it to a release candidate status. Exactly how soon “Real Soon Now” might be, however, is a little up in the air, as Oz went on to note at the Open-source Dev meeting on Wednesday January 8th, saying, “there are a bunch of steps [still to be taken] and I don’t know how long they’ll end up taking.”
On Tuesday April 2nd, the Second Life Server (SLS or Main) channel received the interest list update which has been running on the Magnum RC channel for weeks 12-13. This includes:
More correct sorting when streaming objects to viewer
More objects are categorised as cacheable by the server (improves scene loading speed when revisiting regions)
Packed full ObjectUpdate data recycled for multiple viewers (optimisation of how UDP packets are built)
Additionally, the package includes fixes for the following issues:
BUG-1779 – Updates for objects that are out of view are delayed for a maximum of 5 seconds, at which point they will be sent
BUG-1795 – “Agent appears in incorrect position to other agents after being moved by a sim teleporter”
BUG-1814 – “No object updates from vehicles after some region crossings” – yes, the vehicle region crossing bug fix reaches the Main channel (and should be on BlueSteel and LeTigre following the RC deployments on Wednesday 3rd April).
Following deployment, there have been assorted reports that:
Region crossings in vehicles are generally a lot better – although the BUG-1814 fix will not reach the entire grid until after the RC deployments for Wednesday 3rd April (see below). However, feedback is pretty much in line with my own Magnum tests in my Mark XI Spitfire
There are reports that the fix for BUG-1779 is not working in all cases – Whirly Fizzle reports that her Meeroos are still suffering the same update issue as prior to the roll-out
There are also reports of increased issues with prims / parts of linksets failing to rez until right-clicked upon – although there is some speculation that this might be worse for some TPVs as they may not have recent code updates from the Lab.
Release Candidate Channels
On Wednesday April 3rd, the Release Candidate (RC) channels should receive the following updates:
Magnum should receive Monty Linden’s new server-side HTTP updates (see below) – release notes.
The Mesh Deformer project viewer was finally updated on Tuesday March 2nd with the release of version 22.214.171.1243384. There are no changes to the deformer with the release – which does see the deformer code now merged with the CHUI codebase.
The next stage in Monty Linden’s HTTP project should reach the Magnum RC channel on Wednesday April 2nd. these updates can be briefly summarised as:
More complete and more correct headers on texture and mesh fetches – these should ensure the viewer is better able to handle objects as they are downloaded to it
Keepalive connections for some HTTP-based services
Notes on the latter point explain that:
The behavioral change for HTTP connections marks the beginning of support for persistent (keepalive) connections. Services transiting the capabilities router, at ports 12043 and 12046, may honour a request for keepalives and keep a connection open after request completion. These services may include such activities as texture and mesh fetching, event delivery to viewer, HTTP-In for LSL scripts, asset uploads and inventory operations. Benefits from keepalives include immediate and future throughput increases and less TCP connection churn (which often disrupts consumer-grade networking equipment). The exact set of services that will see this is expected to change over time.
In other words, connectivity between the viewer and the server should be somewhat more robust and, in the case of older router models, less taxing.
Server-side Baking Avatar Z-offset
I missed the Monday Content Creation meeting on April 1st due to family commitments. However, I understand from information received that the question of avatar height offsets. The solution, as currently offered by LL, is considered to be less than optimal for all situations. In replying to the question, Nyx Linden apparently indicated that the Lab do not consider the matter fix in light of further examples having been given, and that further work in correcting matters is in-hand. Whether these further fixes address all concerns remains to be seen.
Griefing was once again a subject of discussion at the Simulator User Group meeting on the 2nd April. As with the last time the recent increase in mainland griefing was raised, LL are not willing to discuss specifics in terms of what they’re aiming to do. However, Simon Linden did provide more general feedback in response to questions.
Nothing new to report about griefing tools … but it is on our radar and definitely a concern … When looking at griefing problems the most serious issues and the ones that get the fastest attention is anything that can crash a region or viewer. After that there’s a broad spectrum mostly based on the level of pain and if there are things that can or can’t be done about it already. The fight has been going on since long before I joined the Lab.
During the discussion, Simon was at pains to again point out that those Lindens attending the User Group meetings are not responsible for dealing directly with griefing accounts – that is the role of the Governance team. However, he also made it clear that there are internal LL meetings where griefing is discussed, saying:
The Lindens that come here like Andrew, Kelly and myself are server developers, so we focus on features there that can help. Dealing with accounts is outside our area and the Governance people handle that … We do regularly meet and discuss what’s going on … everyone is aware of the recent increase in griefing … It’s gotten a lot worse recently. Not due to technical failures and it becoming easier, but from more griefers.
Simon also indicated that the bug which allowed objects to get stuck in limbo at the edge of a region, where they could be exploited by griefers, now has a fix in the BlueSteel and LeTigre RC channels, and that measures to help combat particle spamming are “in the pipeline”, with the hope that a project viewer will be featuring these will be available soon.
SCR-19 – Script function to return objects remains a popular choice of handling griefing objects, and Simon – purely as a brainstorming exercise asked for feedback on region controls which could be turned off / options which could help make land more “griefer-proof”. Some of the responses included:
Having particles require group permissions
Banning individuals based on their group membership. This raised questions over privacy and usefulness / effectiveness. The former as it would require a means to discover someone’s groups, even if hidden; the latter points because it would only otherwise work on a person’s active group, it would be relatively easy to circumvent (by leaving the group, if necessary)
Blocking object rezzing based on the creator’s name
Turning off public script operation over explicit banned/no access parcels, making the return time for public rezzed objects over explicit banned/no access parcels 1 minute.
Again, none of this should be taken as an indication that any of the above will be explicitly developed by LL; rather they are likely to be added to the melting-pot at the Lab and help LL better understand where user concerns lay and what directions they should consider for further technical responses to griefing issues.
Mesh Object Physics Shape
There has been a (possibly long-standing) problem with the physics shape for some mesh objects being changed unexpectedly. Lares Carter, speaking at the Simulator User Group, described it thus:
The physics shape type for mesh objects gets changed from Prim to Convex and doesn’t change back until the object is right-clicked. This only happens for linksets that contain a prim with a target omega property. Things that can trigger the change: movement changes and rezzing the object. There also seem to be other factors as it can happen for static objects too.
The issue has been reported in BUG-2147, and differs from the problem wherein some objects / parts of builds (such as floors, walls, etc.) fail to rez until clicked upon (but can be walked on, etc.), in that the mesh object can be seen and can collided with – but the physics shape is incorrect. There are reports that analysing the physics model in the mesh uploader can be used by content creators to mitigate the issue. However, this issue is now on the Lab’s radar in terms of further investigation.
On Tuesday March 26th, the SLS (Main) channel received the maintenance package previously deployed to BlueSteel and LeTigre in week 12, which includes a fix for a crash mode – release notes.
Some issues have been reported on following the Main channel deployment. Regions have been slow to come back up, and several which have had issues with groups and display names failing to show, teleport errors, etc. However, at the current moment in time, these issues do not appear to be widespread.
On Wednesday March 27th, the RC channels should receive the following deployment packages:
BlueSteel and LeTigre: a new maintenance package, which includes:
Magnum: should receive the same update as the Main channel (i.e. the package deployed in week 12 to BlueSteeel and LeTigre), otherwise retaining the updates and fixes deployed to it in week 12 – release notes.
That the region crossing fix for BUG-1814 is not been deployed to the rest of the grid in week 13 is liable to cause some consternation.
New AO Capabilities
The new AO capabilities, due for deployment on BlueSteel and Magnum. I provided an overview for the new capabilities in week 12, and the Lab have now provided a set of wiki pages on the calls and permissions:
As recently reported, Baker Linden has started working on an update to the code for managing groups which will allow group owners / moderators to ban users who create problems (e.g. those who spam groups, people who are persistently abusive in group chat, etc.).
The work is being undertaken in response to JIRA VWR-29337, and is likely to prove very popular once available.Currently, Baker is working on the development documentation and plan for the work, and has been giving further thought on what the capability will be able to do. Speaking at the TPV Developer meeting on March 22nd, he gave a little more insight into how the capability might progress:
The initial release will at least allow group owners and moderators to ban people, a will display the names of banned individuals and the date on which they were banned (presumably to owners / moderators only)
It may include a capability to specify why a person has been banned, even if this is initially a case of selecting from a pre-defined list of reasons
A future option may be to include a time ban option (although this is potentially more useful in banning people from accessing a region / parcel)
An initial design for the viewer-side Group floater has been developed internally by LL, but Baker isn’t so concerned with how the options will be presented through the viewer until after he had defined how the code will work
Baker is not planning on adding any on the ban capabilities for group to the existing ban capabilities for regions / parcels, nor will any of the new group ban capabilities be shared with region / parcel ban capabilities, due to the complexities involved.
At the same time as working on the group ban list, Baker has also opted to correct other long-standing issues:
The ability to search for people using their user name properly (i.e. no period in between first and last names)
A fix for the disallowing of leading spaces on display names.
These fixes will also likely roll-out the same time as the first phase of the group ban list function, once Baker is able to start coding and testing the latter.
On Friday March 22nd, Monty reported that the Aditi testing had been subject to a couple of non-related hiccups (due to inventory issues), but otherwise the regions were stable and whole one significant bug within the code had been found – severe enough to take down some Apache web servers when HTTP-In was being tested, and which has now hopefully been fixed.
Load testing on Aditi has been a little light, but obviously, more practical load testing will occur when the capabilities reach a Release Candidate channel and things start to get fine-tuned.
The subject of Mainland griefing was discussed at the Simulator User Group meeting on the 26th March. There has been a noticeable rise in object griefing and spamming recently, particularly by the so-called “goonsquad”. Several options for better means of combating the problem were raised, including JIRA SCR-19 (“Script function to return objects”) for the return of griefer objects where users do not have access to estate / region tools for return objects, and possible throttling of llDialog (SVC-8080) to try to overcome the use of dialogue spamming prims.
The Lab will obviously not be drawn into discussions on their own plans for combating griefing, but Andrew Linden took a series of notes on problems which are being encountered, while Simon indicated that the Lab is looking at some options which may help with issues.
It’s a fact of life that griefing is part of the subculture of Second Life. It’s not necessarily an agreeable subculture or one we particularly want or need, but it is there all the same. I say this not to excuse what goes on, but to underline the fact that right or wrong, most of us in hearing about it tend to shrug our shoulders and then carry on with our lives.
There are times, however, when griefing – which is actually crossing the line each and every time it occurs – crosses a the line not only in terms of resigned acceptance, but also in terms of criminal behaviour.
The fashion world in SL has recently been subject to this latter situation. This saw an SL user already complicit in copying skins and shapes, and whose profile boasted they had scant regard for the ToS together with outright threats against content creators, start to use griefing as an attempt to extort money from others. They did so by crashing large fashion events and then demanding payment in order to not crash future events.
Much of what happened in this matter appeared to go unreported outside of fashion circles – few blog (this one included) reported on the matter, despite the problems apparently occurring over a span of months. The Lab also appeared unwilling to engage in the matter, despite extortion being a criminal act. In the end, many of those affected by the situation saw no other choice than to themselves disrupt in-world user group meetings in order to try to voice their concerns and frustrations directly (if unfortunately inappropriately) to the few remaining Lab employees users can actually contact nowadays.
(I say “inappropriately” not as an admonishment here, but because those who were confronted by this extortionist were demanding direct action from those Lab personnel the least well equipped to provide meaningful feedback on matters.)
In the end, the approach did appear to work, inasmuch as the account of the individual concerned was banned from Second Life and all content relating to it (apparently ripped from other merchants) was removed from the Marketplace.
Of course, in an age and situation where alt accounts are freely available, the removal of a single account is no guarantee the individual responsible has actually been removed from SL – or more particularly that their modus operandi will not be repeated elsewhere by others.
Yordie Sands brings word that the latter appears to have happened, and the use of extortion has been taken up elsewhere. Writing yesterday, she details a situation where Junkyard Blues, a renowned SL blues club run by Kiff Clutterbuck and Dina Petty, has been recently subjected to repeated griefing attacks which comprised, in Kiff and Dina’s words, “Multiple griefers with blinding graphics card attacks and sim lag/crashes … In some instances the computers of many staff and patrons actually shut down or rebooted as a result of the attacks.”
Such was the frequency of the attacks that patrons began staying away from the venue. However this was not an “innocent” (if such a term can be used with any form of griefing) attack. Junkyard Blues were contacted and informed that if they handed over cash, the attacks would stop.
This is again extortion, plain and simple.
As a result of both the threats and the attacks, Junkyard Blues has been forced to resort to restricting access to their club to “members only”, which impacts both their business and their customers.
During August / September a griefing object in the form of a “freebie gift” started circulating in-world. Called ”..::ExDepart::.. Gift Package 2012”, it is essentially a spoofing/griefing item which, when rezzed will create more items citing you as the owner, and attempt to pass them out.
Since it first appeared, the item has appeared in a number of variants, of which “-[L4L]- Gestures & Walkers (Freebies) <3” is one.
If you receive either item – do not rez it. Instead, file an abuse report, citing Governor Linden as the abuser, list any pertinent information on the object – and remember the person you received it from most likely did not create it, then delete it.
Similarly, if you receive any other item with a similar format of name, or which gives rise to suspicions on your part – particularly if the receipt of the item is unexpected – contact the person who sent it to you first and verify with them that they have legitimately sent you something before attempting to rez the item.
If you receive such an item and rez it, you will need to locate it and delete it – and you may find it has spawned several copies of itself. Typically, one rezzed, the item will move itself to around 4000m above ground, and will continue to spam you with items. To locate and delete the object(s):
Check the incoming dialogue pop-ups associated with the incoming items. These should provide the co-ordinates where the item is located. Alternatively, decline the object’s offer, and the co-ordinates should be recorded in local chat.
Position yourself on the ground using the X and Y coordinates for the object, then:
Either fly up to the Z coordinate for the object, or
Rez and cube, sit on it and use EDIT to elevate the cube to the Z coordinate, or
If you have a viewer which supports command line instructions, use gtp x y z – replacing X, Y and Z with the object’s coordinates
Once in the location, enable Beacons for Scripted Objects (CTRL-ALT-SHIFT-N). You should see a small box with crosshairs on the offending object
Go to Edit and drag a selection box around the object to select it.
Press Delete to remove the object.
Note there may be more than one copy of the object nearby, so you may have to repeat the steps above to remove all of them.
The use of the object is known to the Lab, with Simon Linden commenting at the Simulator User Group meeting on Tuesday 20th November that, “It’s pretty much an ugly social-engineering griefer ploy.”
Miro Collas, of the Phoenix / Firestorm team has put together detailed advice on the object and removing it on the Firestorm wiki, from which the instructions in this post have been drawn.
Oskar Linden has provided an update / post-mortem on the recent bout of griefing that took place across the grid as a result of person or persons unknown abusing the advanced user experience code that was released onto the Magnum Release Channel two weeks ago.
The problem hit on Monday 4th June when the advanced teleport functions released to Magnum were used to teleport individuals or groups around the grid, with some people reporting they were teleported to the likes of The Cornfield, while others found themselves unexpectedly picked up and dropped into stores or meetings.
Linden Lab reacted rapidly to the issue, determining a fix for the exploit on the afternoon of the 4th (SLT) and deployed across the entire grid in a rolling restart that affected the main channel and all release channels.
The key points relating to the issue remain:
The exploit came about due to a permissions restriction within the advanced tools not working as anticipated
To prevent further misuse of the code, the advanced tools were also removed from the Magnum RC channel
Both the code and the associated test plans have been revised and are being run through LL’s QA process to better ensure the situation of the 4th June is unlikely to be repeated when the code is rolled-out once more
Coyot Linden estimates that the advanced experience tools project has been delayed by around 2-3 weeks as a result of these events
LL are at this point in time unclear as to when the tools are likely to be rolled back out onto a Release Channel; the slot assigned to the tools on the Magnum RC has now been taken by other security issues in preparation for their roll-out to the grid.
One immediate outcome of the griefing situation is that the teleport capability has been revised so that when someone is teleported, the function will tell them the name of the owner of the object that teleported them (thus allowing any potential abuser of the system to be reported to LL via an Abuse Report).