Currently open at The Eye art gallery, curated by Mona (MonaByte), is a stunning exhibition of avatar photography by Rofina Bronet. And it is a quite extraordinary collection of images.
Featuring what might be termed “traditional” style studies focusing on the head and face, these are pieces presented in the most marvellous of digital colour and backdrops: celestial skies, iridescent clouds, futuristic grids, and – in places – soft-focused “natural” backgrounds.
In addition, rather than presenting individual portraits of avatars, in places Rofina offers multiple images of the same person. These, together with the selected backdrops and digital elements against which they are posed adds considerable depth in capturing the personality of each study.
Also found within the gallery are media TV screens offering slide displays of the images on offer (click to page through the images), thought with other that may not be offered in large format on the walls. Larger, wall-mounted media screens feature You Tube recordings of some of the individuals featured within the exhibition, and offering further depth to the still images Peeter presents.
All of this makes for a remarkable and deeply engaging exhibition of art and photography, which words alone really do not do justice a visit to The Eye to see them first-hand is strongly recommended.
Logos representative only and should not be seen as an endorsement / preference / recommendation
Updates for the week ending Sunday, April 28th
This summary is generally published every Monday, and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:
It is based on my Current Viewer Releases Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware), and which are recognised as adhering to the TPV Policy. This page includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.
By its nature, this summary presented here will always be in arrears, please refer to the Current Viewer Release Page for more up-to-date information.
Note that for purposes of length, TPV test viewers, preview / beta viewers / nightly builds are generally not recorded in these summaries.
Lockheed Martin: trying to assist NASA in putting humans back on the Moon in 2024. Credit: Lockheed Martin
On Tuesday, March 26th, Vice President Mike Pence directed NASA to accelerate plans to send humans back to the Moon, moving the planned first landing from 2028 to 2024. That presents an incredibly short time frame for the US space agency, given all that needs to be done.
Rather than going to the Moon directly – as with Apollo in the 1960 through 1972 – NASA’s plans for a return to the Moon require the establishment of an orbital facility around the Moon – the Lunar Orbital Platform-Gateway – plus the development of the vehicle to get to and from it (the Orion MPCV), and a vehicle to get from it to the surface of the Moon and back. This, coupled with trying to develop a completely new and complex launch vehicle – the Space Launch System – capable of putting all this hardware where it needs to be, means NASA has a huge mountain to climb to achieve their goal and maintain things like operating the International Space Station – and will need a lot of funding to achieve it, something which doesn’t as yet seem to be forthcoming.
The Lunar Orbital Platform-Gateway is a complex idea, potentially equalling the ISS in requirements – and development / construction time frame, making it improbable that it would be ready in full for 2024 lunar landing. Credit: NASA
As it is, the SLS, as recently noted in these pages, has yet to fly, and has seen a number of programmatic changes in order to try to meet a time frame that was already tight before Pence give his March directive. Following the announcement of the shift to a 2024 landing, NASA actually wavered over using it, mulling the idea of using a commercial launch system instead (the Delta IV Heavy is capable of launching the Orion, for example) before deciding they would push to use SLS. However, in doing to, the agency then suggested they could cut the “green run” test of the SLS first stage, potentially shaving 6 months from the development / flight schedule for the first launch.
Viewed as a crucial pre-flight test, the “green run” would see the completed first stage shipped from the Michoud Assembly Facility, Louisiana, to the Stennis Space Centre, Mississippi, where its four RS-25 engines would be fired for eight minutes, simulating the actual flight of the vehicle prior to upper stage separation. It has been regarded as a crucial test, intended expose the untried first stage to the full force of a simulated launch to gather vital data on the stage performance and to see how the entire assembly stands up the rigours of launch and what might need to be re-worked, etc. The suggestion was that NASA skip it in favour of individual tests of the four RS-25 motors – potentially shaving 6 months off the SLS development schedule.
But on April 25th, the Aerospace Safety Advisory Panel (ASAP) met to discuss this idea and strongly advised NASA not to avoid the “green run”.
There is no other test approach that will gather the critical full-scale integrated propulsion system operational data required to ensure safe operations. Shorter-duration engine firings at the launch pad will not achieve an understanding of the operational margins, and could result in severe consequences. I cannot emphasize more strongly that we advise NASA to retain this test … as NASA evaluates different paths to potentially accelerate the EM-1 flight, it cannot lose sight that the ultimate objective of that flight is to mitigate risk and provide a clear understanding of the risk posture prior to the first crew flight.
– Patricia Sanders, ASAP Chair
The ASAP as recommended NASA doesn’t skip the “green run” integrated test of the SLS core stage – which adds pressure to meeting a 2024 lunar landing time frame. Credit NASA
NASA has yet to formally respond to the recommendation, but it would seem unlikely they’d go against the ASAP. This potentially means that SLS will be unlikely to make its first uncrewed flight – Exploration Mission 1 (EM-1) in 2020, and the ripples may spread further, affecting the time line for the first crewed test of SLS and Orion, and on onwards towards affecting the 2024 goal.
Another issue is that of how NASA will actually get to and from the Moon’s surface. Originally, the agency planned a “two-step” approach to lunar lander development: issue a procurement notice for the development of a lunar lander ascent vehicle, designed to lift a crew off of the Moon tat the end of their say, and a second notice for the transfer and descent stages of the vehicle – presumably allowing different companies to work on the various elements.
To assist NASA in the 2024 goal, Lockheed Martin has re-vamped its Moon lander into a two-stage vehicle, the upper ascent / command module of which will utilise elements from the Orion MPCV craft. Credit: Lockheed Martin
However, on April 26th, NASA altered the procurement notice to seek proposals for a fully integrated lander vehicle. The idea is to speed-up the lander’s design and development and potentially reduce issues of integration of elements built by different contractors.
Certainly, one company that could benefit from this switch is Lockheed Martin, prime contractors for the Orion vehicle, and potential major supplier of the Lunar Orbital Platform-Gateway (LOP-G), the lunar space station seen as a pre-requisite to any crewed landings on the Moon. They first announced their concept for a fully integrated lunar lander in October 2018, and on April 10th, 2019, the company outlined changes to both their lunar lunar and LOP-G designs in response to the push for s 2024 landing.
The revised Lockheed Martin lunar lander with the ascent / command module mated to the descent / landing stage. Credit: Lockheed Martin
Under their October 2018 plans for a lunar lander, Lockheed Martin proposed building a single, fully reusable vehicle, a 62 tonne (when fully fuelled) behemoth capable of taking 3 or 4 astronauts and a tonne of equipment to / from the lunar surface (by comparison, the Apollo lunar module weighed 16.4 tonnes fully fuelled).
This giant vehicle would support stays of up to 14 or 15 days on the lunar surface, prior to the entire vehicle returning to the LOP-G where the crew would use the Orion to fly back to Earth, while the lander refuelled itself from supplies shipped to the LOP-G and stored there.
However, such a vehicle presupposes the availability of a fully operational LOP-G, and there is simply no way such a facility could be designed, built, launched, assembled in lunar orbit and tested ready for operational use by 2024. This being the case, Lockheed Martin is now proposing a semi-reusable 2-stage lunar lander modelled along the same lines as the Apollo Lunar Excursion Module – although again, much larger.
In the revised design, the new lander would comprise a large descent and landing stage, only carrying sufficient fuel to get the complete vehicle onto the surface of the Moon and carrying various equipment lockers and bins. This would be topped by a combined command / ascent module that will would employ a modified version of the European-built Orion Service Module, complete with main motor and power generation systems, as its lower half. This would serve to propel the module and crew back up to the LOP-G at the end of a surface mission. The command section at the top of the module would include elements from the Orion vehicle for flight control, a dedicate lunar surface command deck and the necessary living space for a crew of around 3 for 14-15 days on the Moon.
Making the lander semi-re-usable means the Lockheed Martin do not need a fully operational LOP-G to support the fully re-usable version of their lander. Instead, a “bare necessities” LOP-G could be placed in orbit around the Moon – little more than a propulsion / power module and a docking adaptor – in order for lunar missions to commence. These could then proceed whilst the LOP-G is itself built-out to accommodate more advanced missions.
The following notes are taken from the TPV Developer meeting held on Friday, April 26th, 2019. A video of the meeting is embedded below, my thanks as always to North for recording and providing it. This was a relatively short meeting, with several periods of audio silence and text chat. The key points of discussion are provided below with time stamps to the relevant points in the video, which will open in a separate tab when clicked.
SL Viewer
[00:00-01:17] There have been no SL viewer updates this week, leaving the pipelines as follows:
Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
The EAM viewer is awaiting one simulator side update; the next RC viewer likely to be promoted to de facto release viewer will probably be the Teranino Maintenance RC viewer.
Major effort has been put into trying to resolve the teleport disconnect issue – hence the multiple deployments this week.
In the process of developing and deploying the fixes, the Lab has significantly improved its ability to monitor teleports.
This improved monitoring / stats gathering will help baseline teleports for future reference, should further issues crop up.
It appears to suggest teleport success rates are now significantly better than prior to the updates being deployed.
The added monitoring has no appreciable impact on performance.
Attachment Loss on Teleport
Progress has continued with fixes for the issue of attachments coming off / becoming ghosted/ etc., as a result of a teleport / region crossing.
It will likely be a couple of weeks before these are deployed server-side, as the Lab will be keeping an eye on the teleport / region crossing disconnect issue to ensure the fixes that have been deployed really do help break down the issues that have been experienced.
Snapshots: Flickr Cap Fail and Withdrawal of Facebook Support
There is an issue with the snapshots to Flickr capability failing see BUG-226826). This appears to have perhaps been an unannounced change at the Flickr / Smugmug end of things, rather than anything the Lab has done, but investigations are still ongoing.
Update April 30th: the Flickr cap fail now appears to be fixed.
Facebook Support
It was announced on Friday, April 19th, that support for uploading snapshots from the viewer to Facebook has now been completely withdrawn. As such, the viewer-side code is to be shortly removed, with the Lab noting:
Due to continued changes in the Facebook API, as of today the Second Life viewer will no longer be able to support Facebook Connect for sharing your in-world photos and posts. We apologise for this inconvenience and will be removing the UI from the viewer shortly. We will, of course, be happy to see your SL posts on Facebook going forward, and you can always say hello and check out what’s happening on our official page: https://www.facebook.com/secondlife.
Issues with script processing have been raised at a number of meetings recently, and were mentioned again at this TPVD.
Specifically, it was reported at this meeting that since the April 18th roll-back / update, some Full regions seem to have script run-time capped 12ms, so only around 60% of scripts are run, while some homesteads appear to only run around 20% of scripts..
As it was also reported that these affected regions were running OK following the initial deployment of the newer version of the OS, this issue appears to be specifically related to the changes made on April 18th.
The Lab is not aware of anything having been changed that might have impacted script run-time.
The newer version of the operating system (which is specifically required as a part of preparing the simulators to a cloud-based infrastructure) is due to be further deployed to simulators Agni (the main grid) in week #18. This should provide the Lab with a broader cross-section of simulator running both the older and newer versions of the OS, which will allow a more informed comparison of metrics from the two versions to be made, which could help determine if there is a more broad-based issue with scripts on the newer OS version.
The Lab is considering the possibility of no longer sending group notices to e-mail when a user is off-line.
Right now, if IM to e-mail is enabled for when a user is off-line from SL, it will allow both IMs and group notices to be forwarded to e-mail. This can result in message volumes / content being seen as spam.
As it is invariably the secondlife.com domain that is linked to such reports, this can lead to it being regarded as a spam site, degrading the ability for secondlife.com to deliver e-mails in general, as e-mail services mark the domain as an originator of spam.
This move is therefore intended to make e-mails from the secondlife.com domain for reliable.
Although other forms of messaging forwarded to e-mail can potentially add to the problem of spam labelling (e.g. object IMs to e-mail), group notices are seen as by far the biggest cause.
No decision on this has been taken either way, but disabling the ability for group notices to e-mail is easier than other options (such as requesting user go through all their groups and disable group notices).
Were this change to be implemented, then only IMs would be sent to e-mail; group notices received when off-line would be held until the user next logs-in, as is currently the case.
It has been suggested that increasing the limit on the number of messages that can be queued when a user is off-line might ease the blow of blocking group notices being sent to e-mail. While this idea is already under consideration, no decision has been taken either way.
[25:06-26:18] If this idea does move forward, it is hoped that changes being planned to the way SL events work will reduce the need for at least some group messages.
No specifics were available on the updates that are being planned for events, but it has already been suggested that the updates include an API to allow events to be properly listed on viewer log-in screens (see feature request BUG-226867).
In Brief
[13:58-15:00] Following the release of a video on You Tube by a Lab employee, the question was asked about the Lab’s policy on staff using TPVs. In short:
Lab staff must use the official viewer on Lab equipment and/or their official Lab accounts.
Lab staff may use any viewer of their own choosing on their own hardware and when using their personal user account.
This was actually the case with the video in question: it was filmed and released via a personal account, not an employee account.
[31:43 (text)-35:30] Questions continue concerning LL’s support of 32-bit operating systems (it was mentioned that Microsoft will apparently stop supporting 32-bit “with the next [Windows 10?] update”). However, one of the reasons for LL’s continued support of 32-bit Windows is the number of users on less capable / 32-bt specific GPUs.
[35:40-36:25] At least some of the EEP regressions witnessed following the April 18th roll-backs / redeployments should hopefully be corrected with the simulator updates due in week #18.
[39:36-40:56] It’s often asked when simulator updates aren’t “more thoroughly tested” by the Lab. Simply put, such is the number of Agni (main) grid simulators coupled with the wide variety of ways people use Second Life (think of all the different in-world scripted object, or even all the purpose-built, custom windlights, for example), that replicating it all in a comprehensive test environment simply isn’t possible. Hence why the Lab use the release candidate channels: while testing is carried out (and the Lab is constantly trying to improve its test environments), the RCs provide a further means of “testing the water” before deploying updates grid-wide.
[42:39-43:11] video playback support (MP4): work is on the roadmap for this, but the Lab has yet to get to it.
Following the launch of the new Linden Homes, those sailing around / flying over the new continent quickly ran into an issue: banlines being thrown up around parcels.
On Tuesday, April 16th, 2019, the Lab responded to this problem by disabling the use of parcel banning across the estate. At that time, and to prevent the use of overly aggressive home security systems, the Lab indicated they would be providing a dedicated security option for the new Linden Homes for those who feel security options are warranted.
This new system was officially issued on Friday, April 26th, 2019, via a forum announcement by Patch Linden. In short, the system:
Can be obtained via the House / Houseboat Content Creation Pack available through the Linden Homes selector (mail box or life buoy) outside of each type of home.
Is automatically set to give a formal 15-second warning before ejecting someone from a parcel.
This time cannot be shortened, but longer times can be set, if desired.
It is intended to give loiterers enough time to remove themselves from a parcel.
Ejection has been selected, rather than TP home, in order to allow passers-by who may have been distracted to resume their journey.
Can be used in a Linden home or any skybox placed over it. However:
The system will only operate to a maximum of 400m above/ below its current location.
The system will not work between 100m and 2,000m above sea level (2,000m being the minimum height at which skyboxes must be placed).
Includes options for Group access and for individual white listing of visitors.
The system is contained within its own box in the House / Houseboat Content Creation Pack, which contains the security unit, an instructions note card and sample configuration note card for setting your white list, if required.
Designed to be wall mounted, the system is a simple (5 land impact) panel with five buttons:
The enable / disable button and the Help button (displays brief notes in local chat) either side of the status light at the top of the panel (red = off; green=active).
Here: sets the altitude of the panel – this must be done on placing or moving the panel.
Upper Limit: sets maximum operating height above the system’s current position in which it will be effective (cannot exceed 400m).
Lower Limit: sets the maximum distance below the system’s current position in which it will be effective (cannot exceed 400m), when used in a skybox.
The Upper Limit and Lower Limit buttons display similar dialogue boxes, allowing the range of each to be increased / decreased in 50,m 100m, and 300m increments.
The new security panel (shown alongside a house control panel) and the distance dialogue boxes. In this example, the panel is set at 23.3m above sea-level and will operate up to 23.3m above and 26.6m below its current location. Click for full size, if required
At the time of the April 16th blog post, it had been indicated that all other security systems would be outlawed from use within Bellisseria. However, as Patch notes in his forum post, this is not currently the case – so long as personal security orbs and the like operate within the guidelines set above:
We feel as a compromise, at the present you may only use other security systems that conform to the same Linden Homes Security System standards (warning time no shorter than 15 seconds, no greater detection range than 400m in height; must only work within the boundaries of your parcel, and eject instead of teleport-to-home). If we incur too many issues with non-conforming security systems, we will update the policy to prohibit the use of all non-Linden provided security systems in the new Linden Homes regions.
Hopefully, the new panels will, alongside the parcel ban list (which still functions), and the house access options for all doors, meet all the security requirement people might feel they need with their Linden Home. From my perspective, they are an excellent compromise from the Lab that allow people maintain the security / privacy they might feel they require whilst still fostering freedom of movement within Bellisseria which may in turn (hopefully) encourage a greater sense of community among residents and help build friendships and community activities.
The Virtual Ability community in Second Life is hosting its eighth annual Mental Health Symposium on Friday, April 26, 2019. The theme for this years even is Mental Health in the 21st Century: Digital Destruction or Support? It features an international group of presenters will offer a wide interpretation of the theme, based on their interests and academic backgrounds.
Virtual Ability Inc (VAI) and the Virtual Ability community hosts this annual Symposium to share information about mental health and mental disabilities with the general population. Within this cross-disability community are people who deal with a variety of mental health issues. So, not only is this an opportunity for community members to learn more about topics related to mental health from experts they probably would not have an opportunity to otherwise meet, it also allows the general public to attend a professional conference for free.
08:30-09:30: Evelyn McElhinney is a Senior Lecturer at Glasgow Caledonian University (Scotland) – The importance of positive health assets from participation in 3D social virtual world communities to living and coping with long term conditions in the physical world.
10:00-10:30: Antonius (Tony) J. van Rooij is Project Leader for Gaming, Gambling and Media Literacy at the Trimbos Instituut, the Netherlands Institute of Mental Health and Addiction, Utrecht – Gaming, problem gaming, and gaming addiction in the Netherlands: An introduction.
10:45-11:45: Panel discussion – Life in a Digital Environment – with Michelle Colder Carras, Antonius (Tony) J. van Rooij, Nicholas (Nick) Bowman.
Noon-12:45: Nicholas Bowman is an associate professor at the Interaction Lab of the Department of Communication Studies, West Virginia University, US – How do I relate to me? The emotional demands of our online personae.
13:00-13:45: Michelle Colder Carras a public mental health researcher and informaticist – Video games, social interactions, and mental health: benefits and problems.
14:00-15:30: Kevin Holloway is the Director of Training and Education at the Center for Deployment Psychology (CDP) at the Uniformed Services University of the Health Sciences in Bethesda – Virtual World Training for Mental Health Providers.
16:00-17:00: Fatemeh Rezaee is a Ph.D candidate at Seoul National University – Designed Addiction.
17:00-17:45: casual mixer – an opportunity to chat about the symposium.
The Symposium takes place in Virtual Ability’s Sojourner Auditorium, on Virtual Ability island.
About Virtual Ability
Virtual Ability, Inc. is a non-profit corporation, chartered in the state of Colorado, USA. We are a non-profit tax exempt organization under section 501(c)(3) of the United States Internal Revenue Code. This means that for US citizens, contributions made are deductible as a charitable donation for federal income tax purposes.
For further information on the board of directors, please visit the Virtual Ability About Us page.
For those wishing to keep up with Virtual Ability news and updates when on the move, you can follow them on Twitter.
Inara Pey: Living in a Modemworld 