Sol Farm – blog post
The following notes are taken from the TPV Developer meeting held on Friday, March 29, 2019. A video of the meeting is embedded below, my thanks as always to North for recording and providing it. Time stamps are provided to the major topics of discussion, which will open the video in a new tab for ease of reference.
There have been no updates to any viewers since my Simulator User Group summary. The viewer pipelines there remain as follows:
- Current Release version 184.108.40.2064670, formerly the BugSplat RC viewer February 13, promoted February 28 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):
- Project viewers:
- Linux Spur viewer, version 220.127.116.119906, 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 18.104.22.1680847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
- The hope is the EEP RC viewer will be eligible for promotion to de facto release status “pretty soon”. However, as per my CCUG summary, both the EEP viewer and the new-to-RC-status Bakes on Mesh viewer are awaiting some fixes.
- The Estate Access Management viewer is good-to-go, but is awaiting some simulator update with a new capability, which is likely to be another couple of weeks, before it can be promoted.
- All of this means that the next viewer liable to be promoted will be Love Me Render viewer.
[7:24-25:00] There are also a couple of user-identified issues with EEP that are being considered:
The first is that EEP doesn’t play well with RLV and RLVa capabilities that use Windlight settings. LL have offered to help see what LSL abilities within EEP might be used to overcome the issues.
The second is potentially more disruptive: the ability to locally change an environment for the purposes of photography is somewhat limited.
Currently, with Windlight, it is possible for a photographer to tweak the local environment in their own viewer (e.g. move the Sun to provide better lighting / shadows, alter the cloud and haze density / colour, etc.).
Within EPP, this ability is limited to only those settings a user has a right to alter, make such minor adjusts potentially impossible to achieve. This is related to the EEP permissions system that has been set to allow EEP assets to be sold by creators.
The only options are either a): completely replace the location environment with one attached to their avatar; or b) trying to build a personal “copy” of the location environment just to adjust the Sun position, etc., or c) trying to employ LSL to make the necessary changes, with b) and c) clearly being hard for most people to achieve.
Whirly Fizzle has raised a feature request (BUG-225921) to bring the matter to LL’s attention, and it is being examined. However, whether or not an alternative means to make such localised (/ personal) tweaks to an environment will make the initial EEP release or be held over to “EEP 2.0” has not been decided.
One suggestion put forward at the meeting allowing such minor tweaks might be to allow make changes without exposing the associated underlying values for the settings (thus avoiding people being able to copy / rip EEP assets that they would otherwise have to buy), and to have the Save options disabled when doing so. Rider Linden indicated this is one of the approaches he was considering looking at.
Reminder: the EEP simulator code is now grid-wide. This means certain render feature – such as the stars – appear to be “broken” on non-EEP viewers (e.g. black “stars” can appear in daytime skies as square blotches, and at night white stars appear decidedly square. This is because the sky (including the stars) is rendered differently with EEP, but an attempt is made to convert things like stars back to a windlight setting for rendering by non-EEP viewers, which doesn’t entirely work.
This issue will obviously be fixed when the EEP viewer code is available in all viewers.
[6:56-7:20] Simulator releases have been fairly quiet of late, with some weeks seeing no roles on either the SLS (Main) channel or one or more of the RCs. However, there are a number of simulator projects in flight which mean things are liable to be busy with simulator releasing over the coming weeks.
- It’s been widely noted that there has been a sharp up-tick in teleport failures & viewer disconnections (with physical region crossings also causing similar issues).
- This problem appeared to start with a server deployment, but the root cause(s) is / are proving hard to identify.
- It took the Lab a while to realise there was a problem, as the tool they use to monitor the success / failure rate of teleports was not showing any significant issues, and Lindens in-world assumed that when they encountered the problem, it was an issue with their own connection.
- Investigations are now in progress, but identifying a root cause is difficult, as it is proving hard to get a consistent set of circumstances by which the disconnects can be reproduced.
- If anyone can determine a means to repro the issue, or determine the conditions under which the problem is more / less likely to happen, they are asked to put it in a Jira for the Lab.
- Some changes have been made to the simulator code in the hope that they might either a) help alleviate the problem, or b) at least provide more data when teleport disconnects do occur, and some of these changes are likely to be deployed in week #14.
Attachment Loss on Teleport
- This is another issue that has been of increasing notice for a while now (e.g. inventory being actually detached; attachments being ghosted in your local view whilst others still see them attached; experience-controlled temporary attachments becoming ghosted, etc.).
- The Lab does not have a solution for the problem as yet. However, via testing, they have found a number of issues that contribute to worn inventory being detached as a result of the teleport (/ region crossing).
- Fixes for these issues are being developed, and more news on these should be available once the Lab has some definitive testing results.
- The hope is that the Lab will able to resolve most of the issues – or at least make things behave more correctly – just through changes on the server-side, rather than the fixes being heavily biased towards the viewer.
- Any viewer-side changes that might be required will be highlighted at future TPVD meetings do that other viewers can take and merge them as required.
Adult Rated In-Viewer Web Searches
Despite certain pundits claiming otherwise, the Adult rating is not all about “extreme sex and violence” (there are numerous residential, art, photographic, and role-play regions for example, that err on the side of caution and opt for an adult rating). However, a problem that does exist is that the web search in the viewer currently opens on the Events tab, and with the Adult search parameter enabled, this can result in sexually explicit adverts being displayed, which some who might otherwise be using Adult to rating simply to find the type of location noted above to be uncomfortable.
- Unchecking the Adult search option isn’t a solution, as disables Adult searching in other categories thus preventing the art galleries, etc., mentioned above being listed in results.
- One way to lessen this impact might be to make the Destinations tab the default tab on opening the web search panel. While this still has Adult destinations in the banner ads, these are more mixed with ads for destinations with other ratings, and potentially less noticeable.
- Another suggestion offered is to possibly sub-categorise Adult search results between sexual / non-sexual (although this could be hard to achieve in avoiding issues of gaming).
- The suggestion made for this issue to also be raised at the next Web User Group meeting.