Linden Lab has released a new Second Life viewer release candidate, specifically, 1.18.4(RC2). This fixes a number of issues with since the last release. There's a list of those changes below the fold.

The viewer is available from the optional downloads page as usual, and we suspect that this one might just be a little more plausible as a release candidate than the last one.

• Fixed several UI elements
• Fixed new group not appearing in group window until relog
• Fixed Trash folders in user inventory
• Fixed missing line of information on land sales
• Fixed parcel listings showing [AREA] instead of parcel size
• Fixed bad teleports from landmarks
• Fixed up/down arrows for Repeats Per Face
• Fixed a viewer nested message crash
• Fixed a viewer crash with editing classifieds
• Fixed a viewer crash when pressing Ctrl-F with a minimized Search window
• Fixed secondlife.log spam when group info window opens
• Fixed Publish on Web not saving for parcels
• Fixed missing dialog for Publish in Classifieds
• Fixed updates for Land and L$

There's a new release candidate available on the optional downloads page. It's one with known problems and it isn't actually a candidate for release. The previous release candidate turned out to have some pretty severe problems, and it seems some people just won't quit using it anyway. So this release is a roundup of fixes for the folks out there who are eating bees.

So, we get the impression that, esssentially, bee-eaters this release is for you. Not eating bees? Give it a miss, and wait for the next release candidate, which might actually be a release candidate.

Sidewinder Linden reports that the beta grid (Aditi) has been updated with a new version of the Havok 4.6 code, fixing a dozen issues. We're told this will take about 24 hours.

We're also cautioned that the beta grid database will be refreshed from the main grid. Make offline copies of any scripts you have in beta, because everything in your beta inventory will be replaced by early next week.

Resolved issues:

• DEV-4118 sim crash by sitting on an object
• SVC-856: Havok4 - Rez from Inv with Edit on create invisible object in 1.18.3.72037
• SVC-802: Havok 4: Rezzing a tree from inventory causes log out
• SVC-828: llCreateLink () can link to an AGENT! Doing so crashes causes viewer crash
• DEV-4008: llSetPos fails in touch events in root prims
• SVC-768: llCreateLink(target, TRUE) inserts child prim in wrong place in linkset
• DEV-444: Failed link operations should have an error message
• SVC-821: llGroundRepel using top of bounding box, not middle, also attracts downward
• SVC-857: Unable to rez some old content
• SVC-54: llTargetOmega doesn't update unless object is interacted with by an AV
• DEV-3477: VEHICLE_FLAG_HOVER_GLOBAL_HEIGHT severely gimped in current limitations
• SVC-860: Physical objects linked, set static then unlinked become physical again

Linden Lab and Vivox are taking the voice system down for maintenance tomorrow morning (Wednesday, 24 October) between 2AM and 3AM SLT (US Pacific) for unspecified improvements.

Could this have anything to do with the projected influx of CSI:NY fans tomorrow? It would be too coincidental to suggest otherwise. Apparently Linden Lab has been robustifying a number of subsystems, particularly the user-registration system.

Linden Lab's user-experience designer, Benjamin Linden (aka Ben Glenn), has just announced the release of a visual viewer update preview. A part of the aim is to modernize the look of the Second Life viewer by reskinning it. [Click on the image to the right for a larger version]

The listed goals are:

• Improve visual appearance with modern UI graphics and icons.
• Improve discoverability through expanded use of iconography.
• Improve approachability with a lighter, friendlier color scheme.
• Improve legibility by using dark text on light backgrounds.
• Document technical limitations of current skinning capabilities.

There are a number of those technical limitations lurking in the viewer source that need to be addressed. You can download and try out the preview package (for viewer version 1.18.3(5) only at the present time) from Amazon S3.

More project details are available on the Viewer Visual Update page on the Second Life Wiki, and discussion and feedback are invited.

Sidewinder Linden has updated us on the status of the Havok 4.6 physics test on the Second Life Beta Grid (Aditi). Included is the news that Aditi has been updated today with a fresh code drop.

We've listed the changes below the fold, linked to their JIRA entries, where possible. The public JIRA has been having some difficulties this evening, however, so be prepared to be patient.

Resolved Issues:

• DEV-448 can set grass physical (which must have been amusing)
• DEV-1775 SVC-775: VEHICLE_REFERENCE_FRAME broken on preview
• DEV-2573 Object mass updates are a step behind
• SL-57425 SVC-771: (Havok4) llSetBuoyancy maxes out at 1.0
• SVC-54 llTargetOmega doesn't update unless object is interacted with by an AV (A much older bug and glad to see this finally sorted)
• SVC-727 Objects with llVolumeDetect(TRUE) don't fall through ground
• SVC-745 llGetStatus(STATUS_PHYSICS) does not work in child prims
• SVC-753 Het Grid - Attachments, animations/AOs screw up on sim handover between different versions (ouch! But important to fix!)
• SVC-763 All scripted physics calls fail a "physics deactivated" avatar

Known Open Issues:

• DEV-457/3873 havok4 - llSetPos no longer works on attachments (this affects several vehicles we have tested, resulting in problems with the position of parts of the vehicle when rezzed in-world)
• DEV-3882 Hover vehicle does not turn while coasting
• DEV-3889 Some content seems to be rotated inappropriately in-world

Today's release candidate doesn't seem to be winning a lot of hearts and minds out there today. The public JIRA issue tracker is accumulating problem reports, many of which seem - just darn peculiar.

Aside from crashes, virtually all of them seem to be related to the user-interface, and new ways in which it behaves (or misbehaves). On the Second Life development mailing list of late, there has increasing discussion of scrapping the existing user-interface code (which is tangled up in, well, everything) and changing to something more modular and discrete.

At present, as the complaints go, the user-interface code and some of the back-end code have become such an organic tangle that it is difficult to change one without affecting the other, and that some theoretically simple user-facing changes have become monstrously involved.

That appears to be the sort of thing we are seeing here. Changes that should be quite straightforward causing an extensive tangle of dependencies and concomitant unexpected issues.

Tomorrow (Thursday October 18) Linden Lab is staging a rolling restart some time in the AM hours SLT (US Pacific time), but quite likely crossing over into the afternoon, as the full restart takes around 5 hours or so.

We're told that the restart fixes viewer metrics gathering (but aren't told what about viewer metrics gathering is broken), and the behavior of "standby" simulators (we're not sure what one is, or quite what it was doing wrong).

We've also not been told whether this is an old-style (North-to-South) restart, or a new recipe (all over the place) restart. Either way, [Tateru screws up! Sorry, folks. It's a traditional North-to-South rolling restart. Mea culpa]. Here's hoping it doesn't mess with your plans in Second Life too badly.

Every MMO/NGO/VW has bugs. Every patch, every update for every one of them brings a slew of fresh bugs, glitches, imbalances and lost property. Dealing with those bugs, glitches and whatnot can be a pain in the ass quite frankly, but in Second Life, we're not just dealing with peoples' fun. We're also dealing with their revenue.

While Ginsu Linden made quite an effort to make everyone understand that Linden Lab understands the position that it is in, relative to the users, it's obvious enough from reading the comments that many of the users themselves either do not understand Linden Lab's position, or do not think Linden Lab understands it. Pick one.

Part of that position involves a bug. Technically, you'd call it an exploit. That being, a bug which (if you know how to use it) allows you to profit in a way that is unintentional or accomplish some task that is not normally permitted. We're not talking about cheating your cash balance, or purchasing land that isn't for sale, or making prims that are larger than the system nominally permits.

We're talking about the issue with llSetLinkPrimitiveParams(). A sitting avatar becomes a part of a set of linked prims. Until this function came along the fact that a sitting avatar was just another (temporary) member of the linkset wasn't really all that relevant, as there wasn't really anything you could do to the sitting avatar as a member of the linkset that wasn't already able to be done.

With llSetLinkPrimitiveParams() however, the avatar appeared (to this function) to be an additional prim, and that meant it could be manipulated. Those manipulations were pretty much limited to two things: Repositioning the avatar relative to the object, and certain other manipulations that would crash the simulator.

The repositioning tasks were all able to be accomplished by other means, though you needed extra prims to do the job. Being able to handle it directly was a time-saver, although apparently an unintentional one. Yes, it was a bug - or an exploit if you prefer. It was also a superior solution to a common scripting task. It made all sorts of furniture and multi-pose systems more efficient - at the risk of intentionally or unintentionally causing simulators to crash.

The community took to it like wildfire, as it was discovered, and almost all the new creations used the new function to perform tasks that had previously been performed in less efficient ways. Many creators retrofit their old gadgets to work the new way too.

And then, at the beginning of the month, Linden Lab found the simulator crash problem and fixed it. They fixed it by making sure the function did what it was supposed to do - that is, not allow the manipulation of avatars.

Then the screaming began. The use of the function in this way was nearly universal by this time, and the people at Linden Lab who worked on this code were - essentially - completely unaware of that fact. To them, it was a bug - an exploit, even. The code was permitting something that they had not intended to permit, and worse, people were using it to crash simulators.

So they fixed it in the simplest possible way. Hide the avatars from the function. Done.

Did I mention the screaming?

Intentional or not, the use of this exploit was widespread. It was everywhere. It was a part of people's play. A part of their businesses. The fix went in, and everything, everywhere in Second Life that used it stopped working, all at once.

Hastily (it took several days), Linden Lab responded to the huge quantity of broken product and refixed the function. This isn't actually the first time something like this has happened, where an unintentional glitch that has been fixed has caused widespread problems, breakage, or breakdown in user experience. It's probably not going to be the last, either. Sometimes those fixes mess up resident work, and sometimes they mess up the work of other staff at Linden Lab itself, even.

Whether it is intentional, or unintentional, anything that is perceived as a feature quickly becomes widespread. Look at megaprims. They're everywhere these days. Take a tour of the Linden inworld offices and you'll see quite a few megaprims in the construction of some of them.

The problem is one of communication, certainly. In each case, where these fixes went in, the people doing the fixing were simply unaware of the impact of the changes they were making. While I know it is not their policy to discuss exploits, perhaps Linden Lab really needs to bring some of their own bugs and bugfixes to their bug triage sessions for other eyes to look at.

Following on my reviews of the Nicholaz editions, I'm happy to announce that the -s version has been released on all platforms.

I've not tried it yet, but you can find the Mac version here and windows and Linux versions via Nicholaz' blog. Nicholaz himself regards this as a milestone version, and warns there may not be any new versions for a while, as trivial things like his RL job exert their influence over him!

Tomorrow morning, Wednesday 10 October at 9AM SLT (US Pacific), there will be a rolling restart across the Second Life grid to deploy new code. This will be a traditional north-to-south rolling update, and not one of them new-fangled ones that leaves shoals of dead and disconnected simulators in its wake.

The goal of the update is to deploy code to gather information about teleport failures, presumably both rates of incidence and information as to types of causes. With luck, this information will ultimately lead to more reliable teleports.

It seems there's some issues with simulator data getting messed up by Havok 4.6 on the beta grid (Aditi). Sidewinder Linden (Program Manager for the Havok implementation project) has announced that Havok 4.6 is being yanked from the beta grid until at least Monday while they look for the cause and possible remedies.

We now return you to your regularly scheduled physics engine.

Angry and upset furniture makers/consumers of Second Life, breathe a sigh of relief. At 9AM SLT (US Pacific Time) Thursday, Linden Lab will commence a rolling restart that fixes the breakage that hath ailed ye.

There's also a security hole getting fixed, but no word on what it is. Linden Lab does not discuss the nature of exploits or the measures performed to fix them as a matter of policy.

A new viewer (version 1.18.3(5) apparently) is available as the official viewer release now, although there are a number of known problems with the operation of the viewer software.

There are 66 listed bug fixes in this release. A full list of the known issues, changes and fixes is included after the fold.

Changes:

• Changed Bug Reporting links to http:// instead of https://
• Build mode no longer automatically turns on beacons
• Removed 'Ping User' in statistics window (was returning 0, as userserver no longer exists)
• Removed 'Open' menu option when clothing is selected (as 'Wear' is available)
• Added minimize button to Inventory
• Updated voice components to improve quality and address VWR-1532
• Added name of viewer release channel to embedded browser agent ID string
• Reverted map beacon behavior (per VWR-2270)

Known issues:

• Sculpted prims with alpha in the sculpted texture are invisible
• The command line option "-drop" does not work on Linux or OSX clients.
• VWR-2268: Role Description causes Apply Changes, Ignore Changes, Cancel alert even if you don't have rights to change
• VWR-2551: Error in macview.xcodeproj -- invalid dependencies
• VWR-2404: lossless texture compression on small textures not lossless
• VWR-2552: Telehub gui very broken in RC

LSL changes:

• Ability to get details about an object by object key:
• list llGetObjectDetails(key id, list params)
• id = the key of the object to get info about.
• params = a list of the object details requested: [OBJECT_NAME, OBJECT_OWNER]
• returns a list of values in the order requested: [ "Object_Name", <the UUID key of the owner>]
• OBJECT_UNKNOWN_DETAIL Returned by llGetObjectDetails when passed an invalid object parameter type.
• OBJECT_NAME Used with llGetObjectDetails to get an object's name.
• OBJECT_DESC Used with llGetObjectDetails to get an object's description.
• OBJECT_POS Used with llGetObjectDetails to get an object's position.
• OBJECT_ROT Used with llGetObjectDetails to get an object's rotation.
• OBJECT_VELOCITY Used with llGetObjectDetails to get an object's velocity.
• OBJECT_OWNER Used with llGetObjectDetails to get an object's owner's key. Will be NULL_KEY if group owned.
• OBJECT_GROUP Used with llGetObjectDetails to get an object's group's key.
• OBJECT_CREATOR Used with llGetObjectDetails to get an object's creator's key.

Bug fixes:

• Fixed default eyes appearing gray
• Fixed viewer source linking error
• Enrollment fees are no longer displayed with decimals
• Fixed inworld map region search failing if a space is included after the region name
• Fixed Appearance editor preview squares after changing tabs
• Fixed a bug with LODs for sculpted prims
• Fixed flexy causes llTargetOmega child objects to not rotate
• Fixed an incorrect Support link
• Fixed clipboard capture on login screen's config info
• Fixed web browser widget shows up blank when connecting via https
• Fixed doubleclicking text entry fields should select a single word first, then the entire field
• Fixed items renamed from Recent Items not displaying the correct name in All Items
• Fixed physical memory calls with more than 4GB of memory
• Fixed viewer crash by clicking Connect button repeatedly
• Fixed crash in viewer when receiving bad HUD Effects
• Fixed a Linux client crash
• Fixed client on 64-bit Linux systems that cannot find their GL drivers
• Improved Linux client threading
• Improved client performance after closing an inventory folder with a large number of items
• VWR-2487: Covenant Details between live version and release candidate version
• VWR-2275: Linux 1.18.3 Won't Link
• VWR-2152: Possible crash in llviewerobjectlist
• VWR-2144: Client crashes when deleting unsaved gestures
• VWR-2036: Build tools floater does not remember its position on restart
• VWR-1987: Segfault on startup if audio doesn't initialize.
• VWR-1976: Solaris' fprintf segfaults on NULL arguments
• VWR-1968: Possible crash in llmultigesture.cpp
• VWR-1951: Hide Particles is not working from the View > Beacons menu item
• VWR-1942: An error in the do-while example of the LSL Scripting Guide could cause infinite looping.
• VWR-1892: Use pkgconfig for more libraries in the standalone build
• VWR-1891: Detect a Debian bulid-host, as is done for Fedora
• VWR-1880: Modify "Ctrl-F" to call Search/Replace Dialog when invoked inside Script Window
• VWR-1872: An attempt to fix the "empty inventory trash" crashes
• VWR-1861: Renaming items in inventory folders does not update item sort order
• VWR-1823: Bad typecast for 64 bit systems, llagent llfloatercustomize
• VWR-1808: Possible crash in llviewerobjectlist
• VWR-1761: Group Invite Suggestion--add 'view group info' to invite dialog box
• VWR-1743: LLFloaterGroups source code inconsistencies
• VWR-1736: Add a Invite to Group option to the Avatar Pie Menu
• VWR-1722: Profiles are editable in two places (including Search browser)
• VWR-1721: GUI quirk in groups
• VWR-1714: Folders flashing in Inventory window with Filters and 'Always show folders' checked
• VWR-1699: Sculpt map preview inaccurate
• VWR-1647: "Show end of last IM conversation" in Preferences/Communication automatically remains checked after OK-ing unchecked
• VWR-1640: login retires cause LLFrameStatView::setup() to seg fault
• VWR-1638: confused viewer - displays login and regular menus and buttons
• VWR-1567: Change the default item name for "snapshot to inventory" to something more usefull than "snapshot"
• VWR-1566: An attempt to fix the glDrawRangeElements crashes (refcount LLDrawInfo )
• VWR-1564: Viewer crashes when started with the "-local" argument.
• VWR-1460: Can not see permissions of objects in Buy Contents window when item has long name
• VWR-1398: Appearance editor's previews do not render correctly (1.17.2)
• VWR-1372: Sculpt prim topology reverts to sphere unexpectedly
• VWR-1230: Text highlighting in Chat History window is cancelled when history scrolls
• VWR-1225: Embedded notecards not functioning
• VWR-1187: Profile > Classifieds tab shows confirmation dialog when no changes are made
• VWR-1079: Group Notice dialog: message text can't be copied and pasted
• VWR-942: logRanOffEndOfPacket is too terse when it logs packet data, add some more info
• VWR-866: Sculpties suffer HORRIBLY from JPEG artifacts
• VWR-819: Open the "More>>" section of the edit tools by default and persist it across sessions
• VWR-749: Bandwidth indicator: Kbps, should not have capital k
• VWR-493: Statistics bar, Packet Loss: % sign is doubled
• VWR-493: Objects with "Linden" in their name can't be muted
• VWR-423: Selecting group charter text causes Apply/Ignore/Cancel popup even if the text wasn't changed
• VWR-240: Cannot input Japanese characters from keyboard on Linux
• SVC-300: Spam upon TP out of Help Island Public, per calling card and landmark

The promised rolling restart is underway - though still not reported as complete. This rolls out a bunch of bug-fixes, but apparently no full list is available at the present time, so you'll probably have to guess at any behavioural changes.

This restart is described as 'aggressive', which apparently means that more sims are being restarted per iteration, and that's putting quite a heavy load on things, as judged by the uncharacteristically steep fall in concurrency through the process (dropping 15,000 users).

With Havok 4 now live in beta on the beta-grid (actually it's Havok 4.6), Andrew Linden scheduled a session yesterday to talk about the deployment and testing process for the new physics engine.

Unfortunately, due to unforeseen family commitments, Andrew could not be there, but Program Manager Sidewinder Linden took his place. Thanks to Pavig Lok for providing us with a transcript of the session, we've summarized the key items for you below the fold.

"As you probably are well aware this is a project that's been in motion for a long time, with a variety of issues holding it back, so part of this was figuring out how to clear the roadblocks, help people focus and figure out which features should be taken off the map to get here."

Sidewinder Linden outlined the basic goals for the current Havok 4 beta. "First is to see how many crash modes are left in the current build. We have tried 'a number of interesting toys' and haven't seen much that can crash the current sim, which is hopefully good news. frankly, i'd like to know if there are any 'kill modes' left for these sims ... With that said, please do NOT go trouncing through the beta world and kill off all the sims if you find one, ok? that's not too nice to everyone else :)"

"Second is to try to make sure that we don't break existing content. As much as possible, we'd like for things that used to work on havok1 to continue to work with havok4. I know, and we know, that you will find things that don't work the same in havok4, whether in products or behavior - if you find products and scripts that don't seem to work right, or the same, please post a JIRA [issue] with the specifics so that we can take a look at it, ok?"

How soon can we expect Havok 4?

"Rollout is as soon as possible," says Sidewinder, "but how [soon] that will happen depends on this beta, and how many bugs there are to clear. I'm sure we will have some real work to do as a result of the beta, so we won't be going to the main grid right away. We will likely do another beta round (or more although i hope to have it go two cycles)."

The actual rollout on the main grid will most likely be staged, Sidewinder said. "We will be using hetgrid to start with havok4 on a very few regions in a "corner" of the world, and then expand from there as it looks like we're ready."

On testing, "The trick to 'testing physics' in an environment like second life is that there are also a lot of interactions between av's and objects, so the full test model is a many sided beast ... one thing i've been working on is expanding our testing models to work through these issues."

"This is not expected to be a super fast cycle beta because it is a highly complex replacement for everybody. There are lots of reasons to push this quickly and lots not to. The more [information] we have reported in terms of items that don't work, the more we can look at fixing."

Sidewinder is maintaining a Wiki page on the Havok beta here.