Oh Deer – blog post
Server Deployments for Week #41
As always, please refer to the server release thread for updates and the latest news.
- On Tuesday, October 10th, the Main (SLS) received the server maintenance package previously deployed to the RC channels. 17#17.09.29.509228, intended to address the unintended returns issue of two weeks ago – see The Return of the Living Objects: A Pre-Halloween Horror Story for more.
- On Wednesday, October 11th, the RC channels should be updated as follows:
- BlueSteel and LeTigre should be updated with a new server maintenance package, 17#17.10.06.509429, containing internal fixes
- Magnum should also receive a new server maintenance package, 17#17.10.06.509394, also containing internal fixes.
Neither of the RC updates should have user-visible changes.
SL Viewer
There have been no viewer updates thus far this week, leaving the pipelines as follows:
- Current Release version 5.0.7.328060, dated August 9th, promoted August 23rd – formerly the Maintenance RC
- Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
- Voice RC viewer, version 5.0.8.329250, dated September 29.
- Maintenance RC viewer, version 5.0.8.329115, dated September 22nd.
- Wolfpack RC viewer,version 5.0.8.329128, dated September 22nd – this viewer is functionally identical to the release viewer, but includes additional back-end logging “to help catch some squirrelly issues”
- Alex Ivy 64-bit viewer, version 5.1.0.508209, dated September 1st
- Project viewers:
- Obsolete platform viewer version 3.7.28.300847, dated May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.
Touch, Camming, Experiences, Avatars and Feedback
Note: the following is not indicative that the Lab is considering behavioural changes in Second Life at this time. The topics were simply raised with a view to generating discussion and feedback.
There are a lot of things we can do in a region which might not always be in the spirit of what is intended by the region owner, particularly if the region is designed for a specific purpose, such as an experience or game. We can, for example, cam ahead, seek out secrets, identify traps or hazards and find ways to avoid them. We can also reach across a region to touch things when perhaps it would be better if we could only do so up close.
There are various ways to limit some of this – scripts can be used to limit touch, as can RLV, for example. But for things like experiences and games, it might be better if the region owner had the option to perhaps enforce limits on how far away from their avatars people can cam or touch.
However, this has to be balanced against those situations where camera and “long-distance” touch can be essential. Shopping at a crowded event, for example can be made much less of a fight against crowds and lag by using Area Search, the camera, and far touch to obtain specific items (even flycamming and far touch can make shopping a lot easier in any situation). Ergo, there’s a risk that imposing limits on either could have a more detrimental effect on people’s willingness to shop in popular locations.
Given that crowds themselves are a problem, would it be worthwhile limiting the number of avatars seen within a region in some way? Perhaps a limit set through the estate controls, or by some method within the viewer such that avatars / imposters beyond a certain radius aren’t rendered / have updates ignored by the Interest List until they come within the specified distance – just like people can move in and out of view in a real crowd.
Again, how something like this might work – should it really be a control at estate level, or would it be better as an option users could tweak (which would get my vote) – would have to be thought through in detail. Particularly given we already do have some control over the rendering, at least, of the avatars around us through various methods (e.g. render friends only, derender selected avatars, CTRL-ALT-SHIFT-4, avatar rendering, etc.); while although each of them might not be perfect, they can give flexibility of control to individual users.
As noted, the Lab aren’t planning any changes specific to any of the above – but by throwing questions out and listening to feedback, concerns, alternative ideas, they are perhaps pulling ideas and thoughts into the melting pot on how SL might be refined and offer better controls and means to improve people’s individual and joint experiences.
Inara Pey: Living in a Modemworld 