The lost city of Ravenport in Second Life

Ravenport Reclaimed, February 2022 – click any image for full size

Ravenport Reclaimed occupies half of a Full region with the additional private island Land Impact bonus. Designed by Raven Banrion (RavenStarr), it presents a city in decay, a place overcome by time and falling into collapse and nature reclaims it.

Post-apocalyptic region designs are not exactly uncommon in Second Life – I’ve covered more than a few in these pages – but Ravenport offers something that is just a little bit different. Exactly where it might be or what happened goes unmentioned; instead, it is left to the imaginations of those who visit to reach a conclusion as to what may have happened; all we are told is that it is a place that is “wiped out of human life”.

Ravenport Reclaimed, February 2022

These are words that can be interpreted a number of ways, from humans having been somehow eliminated from the city as a result of physical elimination in some way, through to the inhabitants having been forced to flee the city due to natural or other disaster. But whatever the cause, it is clear that human life departed the setting in a hurry and has been gone a while: Broken buildings and roads are well on the way to being lost amidst the returning greenery, vehicles have long since become rusting hulks and the harbour has been deserted for so long that the waters there are choked by vegetation, one of the remaining vessels within it listing to the point where it is no longer seaworthy, and another other fast becoming a home to vines and greenery and a home for waterfowl.

Greetings, survivor. If you are receiving this message, all human life in Ravenport is gone….

– The greeting given to visitors arriving at Ravenport

Ravenport Reclaimed, February 2022

The waterfowl are not the only wildlife to be found within the setting; while humans may appear to have deserted Ravenport, animals have not. They roam almost every street and road, their mix suggesting that they may have all once been gathered within a local zoo:  elephant and rhino from Africa mix with North American jaguar and black bear, while Australian kangaroo can also be found and seals occupy the docks, keeping away from the sharks in the water.

As deer, raccoon, squirrel and even turkey can also be found, together with the styling of the vehicles, there is a hint this might be a place somewhere in the North Americas – but again, I’ll leave that up to you to decide.

However, the animals are not alone in the city. Despite the landing point greeting not everyone has completely deserted Ravenport. Within the ruins of the city’s theatre lie signs that humans still gather on occasion and an attempt has been made to supply electrical power for a DJ’s deck and lighting – so someone appears to be prepared to party on from time to time. Outside of the theatre sits what might at first seem to be a hint as to what might have befallen the city to cause its desertion.

This comes in the form of a Fat Man nuclear bomb that has partially cratered itself directly outside the front of the theatre – although the fact it has not detonated indicates it is not itself responsible for the city’s condition. Nor, given the healthy presence of the wildlife and greenery, would it seem that a nuclear disaster has been directly responsible for the situation; so perhaps the “bomb” is merely an artistic statement.

Those exploring the city will find other possible explanations for the city being left to its own decay. The fence outside of one of the buildings, for example, has a biohazard warning hanging from it. Inside another building sits a figure in a hazmat, a bleak warning painted on the wall over it. These and other elements both add to the mystery of Ravenport and allow visitors add to their own stories around what may have happened here.

Ravenport Reclaimed, February 2022

Rich in detail and finished with a soundscape that reflects the wildlife that wait the cameras of photographers, Ravenport Reclaimed makes of an engaging photo-rich visit. My thanks to Shawn for the landmark.

SLurl Details

2022 CCUG and TPVD meetings week #5 summary

Carrowmore, January 2022 – blog post

The following notes were taken from:

  • My audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, February 3rd 2022 at 13:00 SLT. These meetings are chaired by Vir Linden, and meeting dates can be obtained from the SL Public Calendar.
  • My audio recording and the Video recording by Pantera (embedded at the end of this piece) from the Third-Party Viewer Developer (TPVD) meeting on Friday, February 4th, 2022.

So this document forms a summary of the key topics discussed, and in the case of the TPVD meeting, timestamps to the relevant point of the video are included.

Available Viewers

[Video: 0:19-0:52 + notes from CCUG]

This list reflects the currently available official Second Life viewers.

  • Release viewer: version version – Mac Voice hotfix viewer, January 13 – no change.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself).
    • Maintenance RC viewer, version, issued on January 20th, combining the Jenever and Koaliang Maintenance viewers.
    • The Tracy Integration RC viewer version (dated Friday, November 5) issued Tuesday, November 9.
  • Project viewers:
    • Performance Improvements project viewer version, dated January 24.
    • Mesh Optimizer project viewer, version, dated January 5, issued after January 10.
    • Performance Floater project viewer, version, issued September 2.
    • Legacy Profiles viewer, version, dated October 26, 2020.
    • Copy / Paste viewer, version, dated December 9, 2019.

General Viewer Notes

  • The Maintenance J&K RC viewer is likely the next viewer to gain promotion as the de facto release viewer.
  • The Performance Improvements viewer is close to being ready for promotion to RC status, and is just pending some remaining bug fixes.
    • This viewer did have changes to alpha sorting for rigged attachment, but following reports of content breakage as a result of this change, which was more a technical change than a performance enhancement, it has now been reverted to expected alpha sorting behaviour to avoid the breakage issue. Instead, possible alternative approaches will be looked at in the future.
    • A future version of this viewer is to include a new UI element intended to help make adjustments to some of the high-impact graphics settings to help improve frame rates,
  • LL is also completing work to switch the viewer over to using Python 3.

Viewer Multi-Factor Authentication Support – TPVD

[Video: 0:53-23:00]


  • In September 2021, Linden Lab introduced multi-factor authentication (MFA) utilising either a QA code + mobile device or a key number, for those pages of the SL website that provide access to users’ account information (see: Second Life Multi-Factor Authentication: the what and how, September 2021).
  • When introduced, it was indicated that over time, the use of MFA would be expanded and improved, and would eventually include the viewer as well.
  • Brad Linden is now working on implementing MFA for the viewer.

What This Means

  • The work has reached a point where LL is close to having a viewer with MFA support ready for initial testing (as defined by  see: SL Wiki: Login MFA), together with updates to the back-end log-in service to support it.
  • Viewer MFA will be based on users opting in to the capability via the dashboard, as described in the blog posted linked to above.
  • It is  recognised that TPVs will need time to integrate the necessary viewer-side code into their offerings, therefore:
    • There will be a grace period between the initial introduction of the code in the official viewer and a time when all viewers / clients access Second Life will be required to support MFA to allow users who have opted-in to MFA to continue logging-in to SL.
    • During this grace period, all users on a TPV will be able to access Second Life, regardless of whether or not they have opted into MFA.
    • After the grace period has expired, all TPVs will be expected to support MFA, and those users on them who have opted in to MFA will be required to authenticate themselves when using the viewer to log-in to Second Life (with the use 30-day period of valid authentication, as per MFA).
    • During the grace period, users on TPVs that switch to support MFA will likewise need to start authenticating themselves when logging-in to SL.
  • Again, this will only affect users who have opted into MFA (unless LL at some point decides all user must use MFA to access SL).
  • MFA on the viewer will be a blanket action – there will be no additional MFA authentication for actions such as buying Linden Dollars through the viewer.
  • Using MFA when logging-in to the viewer will not automatically also authenticate you on or vice-versa.

There was a broader discussion on providing alternative mechanisms by which users can opt-in and use MFA – such as e-mail – rather than relating on a mobile device and authenticator software. Such decisions fall outside the realm of the viewer development team, and so could not be answered directly (however LL have stated  additional / alternate methods of authentication will be added to the system at some point in the future).

In Brief

Content Creation Meeting

  • BUG-231731 “Script text quality and performance” prompted questions on how it might be implemented given it has been accepted. Vir pointed out that “Accepted” does not necessarily mean it a Feature Request will be implemented forthwith, and as such, it will be raised for discussion once it has reached a point where LL is considering working on it.
  • BUG-229205 “Re-enable PRIM_CAST_SHADOWS” came up for discussion, it is believed that the viewer-side code for it has been deprecated / removed, and the server also no longer recognises the function.
    • Runitai Linden suggested it is something that should be re-enabled on the grounds that it is “something that most graphics engines let you do.”
    • However, any final decision will be subject to further internal discussions within LL.
  • Request: allow seated avatars to temporarily have a physics shape of none if explicitly set by script (potential use-case: an in-world game uses tiny vehicles in a scaled environment to simulate a larger playing field, but as the drivers are normal-sized avatars, they cause collisions between one another, impairing gameplay; disabling the avatar physics would  in theory prevent this, although it is not clear if such a change would be recognised by the simulator, where it is believed the expectation of avatar physics is  assumed throughout the code).
    • The discussion encapsulated requests such as BUG-5538, the need for an overhaul of the camera control system & better LSL access to same; better joystick control options, and better support for alternative input types.
    • The latter point in turn led to a discussion on wider HID support and even the potential for MIDI (Musical Instrument Digital Interface) support (having been a means to provide remote control and synchronisation prior to HID design becoming the “standard”) as a means to transport and synchronise joystick inputs from the viewer to the simulator in a generic, open manner.
    • All of this was spitballing, rather than the formulation of an actual project.

TPV Developer Meeting

  • [Video 26:10-53:10] Animation Override Discussion – TPVD
    • This follows-on from the week #3 TPVD meeting.
    • Essentially what is being sought is a solution similar to the Firestorm AO (but without the apparent overheads) that effectively allows viewer-side replacement of animation states sent by the server with local animations, avoiding the need for scripted HUDS / attachments.
    • Much of the discussion at this meeting is clarifying the original request for Vir Linden’s benefit, although the consensus is that official a cap replacement for llSetAnimationOverride and allowing TPVs to implement their own viewer-side AO UI elements would be a good start.
    • Once this has been done, then discussion can turn to the more complex issue of adding further animation states.
    • A Cap and viewer-side controls will not fully eliminate scripted AOs (particularly in the case of non-human AO walks, sits stands, for example), but this shouldn’t negate the provisioning of a Cap.
    • Please refer to the video for the discussion – much of which is in text chat.