The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting of Thursday, October 2nd, 2025. Please note that this is not a full transcript, but a summary of key topics.
The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work.
This meeting is generally held on alternate Thursdays at Hippotropolis.
Dates and times of meetings are recorded in the SL Public Calendar, and they are conducted in a mix of Voice and text chat.
This viewer now ships as a “Universal Binary” that contains both the Intel and Apple Silicon versions of the viewer. It should give performance gains on the Apple Silicon version in particular.
Also includes various WebRTC improvements and bug and crash fixes.
Known issues:
This version does not support convex decomposition for physics meshes with Apple Silicon. This will be hopefully be corrected in a future update or release, possibly with the help of a code contribution.
Navigation buttons in the in-viewer browser are no longer present for marketplace and search – these will be restored in a future update.
Apple Silicon does not support pathfinding tools.
Subtle rendering differences might be noticed on certain configurations and EEP environments.
Second Life Project Lua Editor Alpha (Aditi only), version 7.1.12.14888088240, May 13 – No Change.
Viewer 2025.07
LL are working on implementing some bug fixes prior to offering a further beta version of this viewer.
One change with the next version will be the return of Havok convex decomposition for Mac Intel systems to enable mesh uploads under emulation Requires the enabling of Rosetta in the universal build for Mac) until such time as a an alternative can be implemented.
Work on an alternative solution is in progress via code contributions. This is likely to be included in viewer 2025.08.
In short: LL unlikely to implement any form of new / updated system avatar, preferring to focus on implementing more modern technology and capabilities that allow creators to develop more capable (and less complicated to users?) avatars.
This included a brief discussion on “open souring” the avatar system body so creators could take it and modify / improve it for themselves, with the note that technically it is, but as it misses some critical elements which tend to render doing this moot.
A potential bug with touching scripted objects was demonstrated with attachments designed to be touched (in short: a object could miss initial touches and thus fail to trigger touch_start() ). This was demonstrated at the meeting, and a Canny report was requested on the problem, together with the demo item.
This discussion also encompassed issues with fast clicking on object in-world and cursor positioning, and unexpected results (e.g. rapidly clicking on a touchable object with the mouse moving, so that a subsequent click “misses” the item, causing the server to register that in favour of the the expected return – like a dialogue box or something – from the initial click).
A discussion on setting materials / overrides on PBR vs. Blinn-Phong. In short, with Blinn-Phong, a change in texture / material can be carried out with a reset of overrides; within PBR, changing the material resets overrides. In the case of scripted items, unless the material change and new overrides are sent as a single packet, changing the material can result in the object appearing to “flash” as the material is displayed prior to the new overrides being applied.
The prompt for the question arose out of how a scripted bottle held by an avatar could change to a selected texture (to presumably represent the drink in the bottle), and how this might be better coded rather than relaying purely on texture caching, which appeared to be the root of this particular problem.
Possible solutions for this became somewhat convoluted (outside of finding a mean by which required textures could be pre-loaded), and frankly zapped right over my head. However, the conversation took up the the last part of the meeting.
A question was asked as to why sometimes trying to rez mesh items (or items onto mesh objects) results in a “Failed to place object at specified location” error message.
This can often come down to the physics shape of the surface on which an item is being rezzed, as Beq Janus explained in one of her videos.
Another cause can be a mismatch between where the viewer thinks an object is trying to be placed and where the simulator views it as being placed – which has been a long-standing problem.
A misunderstanding has apparently led to some concerns that support for sculpties is being deprecated / sculpties are being “eliminated”. Neither of these are correct; there are no plans to either deprecate or eliminate sculpties.
The following notes cover the key points from the Web User Group (WUG) meeting, held on Wednesday October 1st, 2025. These notes form a summary of the items discussed and is not intended to be a full transcript. The official video is embedded at the end of this summary.
Meeting Overview
The Web User Group exists to provide an opportunity for discussion on Second Life web properties and their related functionalities / features. This includes, but is not limited to: the Marketplace, pages surfaced through the secondlife.com dashboard; the available portals (land, support, etc), and the forums.
As a rule, these meetings are conducted:
On the first Wednesday of the month and 14:00 SLT.
Meetings are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.
Why do you make all your items no transfer? Are most items no transfer?
Most items are created No Transfer (75%-90% in estimates), although the return of Gacha might be increasing the number of transferable items.
No transfer is preferred for multiple reasons. Those cited included: complexities of customer support with transfer items then have been passed from one user to another; the risk of object loss if an item is set to No Copy as a result of being set to Transfer (e.g. through accidental deletion & trash purge). Most users prefer to have Copy / Modify items over Transfer (/ No Copy) / Modify items.
What would encourage creators to make items transferrable?
Largely a matter of personal choice, but Transfer was not seen as a popular need.
The exceptions to this were seen as items specifically designed to be gifted / intended for the Gacha units & the resale market.
How do you attract new users to your stores? Gifts? Credits? Responses included: Group gifts; store credits / discounts; sales / special offers.
Has anyone used the new Avatar Welcome Pack? Have you made items for it?
Unsurprisingly, mixed opinions on the avatars in the Welcome Pack, although it was noted that as the bodies are Legacy, many creators have clothing available for them, even if the clothing is not specifically created with the starter avatars in mind.
Complaints were raised over the fact feet are not posable (so high heel shoes won’t work with them), and the “dead face” expressions – with reminders that the Welcome Pack avatars are just that: for getting started, before moving on to more capable store-bought avatars.
This lead to a discussion on what could / might be included in the Welcome Pack – such as a limited AO system from one of the dedicated AO creators, just to again help people get started and not necessarily try to work out where they need to shop or immediately diving into the MP.
For those who have helped new users create an avatar via the Welcome Pack, what have been the common problems?
Feedback ran from lack of variety in the avatars (e.g. all of them are human); lack of contextual / explanatory information.
General feedback on bodies / heads in general was the over complexity of things and the steps a new user must go through (even after exposure to the Welcome Packs), together with easily identifying what will / won’t work with a given body type / head type if the new user is not familiar with brands, BoM, using HUDs, etc.
How long would you say an experienced user would take to create a really good avatar?
Estimates varied from “5 minutes” to “an hour”, depending on approach (e.g. having the necessary avatar parts – head, body, etc.), already in inventory and working from there, vs going out and shopping for a suitable body / head, etc., vs. using the Avatar Welcome Pack.
It was noted that helping new users build / customise avatars takes much longer, both due to the general learning curve and the need to overcome the technical / language barriers (e.g. explaining what “BoM” is, why only certain clothing will fit certain bodies, how to recognise what is needed from multi-body pack of clothing in order to wear the outfit on the avatar, etc.).
What would you say is the average cost of a good avatar?
Just for a head, body, skin, hair and initial outfit: US $50, although cost is relative depending on what is being sought.
This also folded itself into people’s expectations / desires for their avatar and its looks.
General Points
Sntax Linden noted that the Avatar Picker / Customiser found in Project Zero is now offered in the official viewer, but without the dedicated Avatar toolbar button, the Picker opening within the viewer rather than as a separate browser panel.
It was pointed out (as I’ve done previously), that the official welcome hub is out-of-step with the Avatar Welcome Pack as it only references the Senra avatars.
The Q&A session included a wide-ranging discussion on approaches to getting new users acclimatised to SL using a mix of web options / capabilities and in-world experiences.
The following notes were taken from the Tuesday, September 30th, 2025 Simulator User Group (SUG) meeting. These notes form a summary of the items discussed, and are not intended to be a full transcript. They were taken from my chat log of the meeting and the video recording by Pantera, embedded at the end of this summary – my thanks to Pantera for providing it.
Meeting Overview
The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas is held every other Tuesday at 12:00 noon, SLT (holidays, etc., allowing), per the Second Life Public Calendar.
The “SUG Leviathan Hour” meetings are held on the Tuesdays which do not have a formal SUG meeting, and are chaired by Leviathan Linden. They are more brainstorming / general discussion sessions.
Meetings are held in text in-world, at this location.
On Wednesday, October 1st, this simulator update should be deployed to the remaining RC channels. This update includes:
A new function that allows you to set a parcel for sale – this is pending a viewer-side update.
Various WebRTC updates.
More accurate CPU usage measurement; more correct live configuration file load on start; more meta data about asset upload so LL knows when people are uploading glFT assets.
SLua Updates
The LLEvents C++ implementation is basically done, and Harold Linden is testing it and integrating it with the simulator.
LLTimers is “going to be funky” because he believes that timers aren’t currently based on real time but rather frame time which is affected by time dilation in the simulator.
Basically, if a simulator is running at 70% speed and a timer is scheduled for 10 seconds later, it might actually happen in 13 seconds.
Harold notes that it’s not clear if this is the desired behaviour going forward, and so is looking for some opinions on what people actually want there.
The preference at the meeting was for real time (or both, as a primary / secondary set of options, if this could be handled tidily), although there was some discussion on event timers and frame / real time, etc.
He noted that any adjustments made would only affect users of LLTimers, not existing uses of llSetTimerEvent().
Harold has also been profiling of the script scheduling code after reports that there can be some slowdown on simulators just by virtue of having scripts that don’t really do anything. The adjustments made should mean things run 5-10% faster now on regions with lots of scripts that don’t do much, which is most of them.
The LSL compiler and runtime will be open-source (MIT licensed).
Harold Linden has tried to put most of the code in the SLua repo that is going to be open-source, so scripters can have a mostly-complete SLua implementation for local testing.
SLua Questions
Please also refer to the video.
Will the LL functions that return -1 meaning “not found” (e.g. like ll.ListFindList() ), still return -1, or will they return nil? Answer: they will continue to return -1.
Similarly, negative indices like -1 in library functions will continue to work as before.
Will the LL functions that return boolean values in a list (e.g. ll.GetPrimitiveParams{PRIM_PHYSICS}), still return number? Or will they return boolean? Answer: they will continue to return a number, unfortunately.
Will there be a llcompat library with the functions in LSL style (0-based, etc.)? Answer: yes.
Will ll functions support constant folding (such as ll.Ord(“a”) being turned into 97 at compile time without having to run the function call at runtime)? Answer: not currently, but there’s no reason that they couldn’t.
Will it be possible to use very large scripts without having to break them up? Answer: the memory limit should be at least 128kb and scripts will generally be much smaller, so technically yes.
Rider Linden additionally noted the memory requirements for the Luau VM are considerably less than the old Mono VM. So there should be some headroom on larger scripts, and LL hasn’t made a final call as yet about the memory allotment.
Additionally, script monitors should show roughly the memory you were _using_ at a recent point in time rather than when hitting the memory limit.
Is there a way to avoid stack-heap collisions (e.g. is the Lua VM armed against them)? Answer: SLua does allow you to catch failures to allocate with pcall().
Will a “shared data” system be implemented, where multiple copies of the same script reference the same instance of bytecode data? Answer: yes, that basically comes with the VM system.
What is happening with viewer-side scripting capabilities? Answer: it has been put on ice for the present.
This sparked a mini-discussion of local scripting use cases, format, security, etc.
In Brief
Rider Linden has the official native VSCode plugin for LSL and SLua “ready for feedback”. He still has some further work to do on this, but hopes to have the repo open and available “as soon as possible”.
Leviathan Linden is now working on a server-side implementation for voice moderation on WebRTC (e.g. the ability for estate owners / managers (and possibly parcel holders) to mute people’s voice).
Pepper Linden is still working on outfit support for SL Mobile, and is also working on a new viewer feature, “async inventory”:
This allows the loading of inventory asynchronously, leveraging the inventory cache after logging-in.
It should see those with very large inventories to log-in much faster than is currently the case (initial testing had 200K inventories loading in 5-10 seconds).
The work is described as currently “very rough” and not ready for inclusion in any active viewer branch.
Signal Linden has been variously involved in:
Apple Silicon support.
Working with our operational team to finish some simhost hardware configuration changes which have been in progress for a while.
Trying to help unblock Lua documentation efforts, get folks the resources they need to build a new documentation site.
Mesh faces mismatch issue: this appears to be a server-side problem rather than anything integral to the viewer. Leviathan Linden is now looking at options for correcting it – his current idea is to use the viewer request to modify a non-existent face to be a hint to the server that it maybe needs to update an asset and put it on a background queue somehow, that would essentially re-submit the asset for update in the background.
Date of Next Meetings
Leviathan Linden: Tuesday, October 7th, 2025.
Formal SUG meeting: Tuesday, October 14th, 2025.
† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a rooftop of people every week. They are taken from my list of region visits, with a link to the post for those interested.
The following notes were taken from my chat transcript + the video recording by Pantera (embedded at the end of this summary) of the Open Source User Group (OSUG) held on Friday, September 26th, 2025. My thanks to Pantera as always for providing it.
Meeting Purpose
The OSUG meeting is a combining of the former Third Party Viewer Developer meeting and the Open Source Development meetings. It is open discussion of Second Life development, including but not limited to open source contributions, third-party viewer development and policy, and current open source programs.
This meeting is generally held twice a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre.
Dates and times are recorded in the SL Public Calendar, and they are generally conducted in text chat.
The notes herein are a summary of topics discussed and are not intended to be a full transcript of the meeting.
Official Viewers
Default viewer 2025.06 7.2.1.17108480561 – August 29 – No Change.
Inventory Favourites System, plus assorted new features.
Improvements to avatar system; camera and movement; chat; voice; content creation tools.
Mesh uploader updates.
Text & UI polish.
Fixes for Environment and Rendering; stability and crashes; UI.
This viewer now ships as a “Universal Binary” that contains both the Intel and Apple Silicon versions of the viewer. It should give performance gains on the Apple Silicon version in particular.
Also includes various WebRTC improvements and bug and crash fixes.
Known issues:
This version does not support convex decomposition for physics meshes with Apple Silicon. This will be hopefully be corrected in a future update or release, possibly with the help of a code contribution.
Navigation buttons in the in-viewer browser are no longer present for marketplace and search – these will be restored in a future update.
Apple Silicon does not support pathfinding tools.
Subtle rendering differences might be noticed on certain configurations and EEP environments.
Second Life Project Lua Editor Alpha (Aditi only), version 7.1.12.14888088240, May 13 – No Change.
Viewer 2025.07
At the time of the meeting, the 2025.07 viewer was pending release.
The first part of the meeting involved discussions on potential routes to provide convex decomposition for physics meshes for this viewer version via open-source options, on both a short-term temporary basis and long-term solution.
In Brief
Please refer to the video for the following:
Appearance fixes: this is being considered for the 2025.08 viewer update, and Geenz has requested feedback / discussion on via Discord.
[Video: 13:12-19:52] A request was made to change the LOD default as a part of the work to provide convex decomposition on this viewer. This was denied, the focus being on providing a “feature complete” version of the viewer for Apple Silicon.
However, this led to a discussion on how best to handle LODs and auto LODs.
[Video: 20:20-End] A broad discussion on dressing avatars, including:
Baking clothing meshes (sort-of a-la BOM) / using mesh proxies fore clothing / layering clothing, and potential for improvement performance as a result.
Providing a scripted means to dress avatars according to the requirements of an Experience (e.g. if someone just a mech combat experience, scripts in the experience dress their avatar accordingly).
“Discouraging” overly-complex avatars.
This discussion encapsulated general ideas, feedback, etc., and also touched on things like VRAM use, etc.
The latter part of the discussion strayed into texture resolution + texture compression, licensing and libraries, etc.
† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a gathering of people every week. They are taken from my list of region visits, with a link to the post for those interested.
Campwich Forest grounds: location for the Monthly Mobile User Group (MMUG)
The following notes were taken from the Thursday, September 25th 2025 Monthly Mobile User Group (MMUG) meeting. These notes should not be taken as a full transcript of the meeting, which was largely held in Voice, but rather a summary of the key topics discussed.
The meeting was recorded by Pantera, and her video is embedded at the end of this summary – my thanks, as always to her in providing it.
The Mobile User Group provides a platform to share insights on recent mobile updates and upcoming features, and to receive feedback directly from users.
These meetings are conducted (as a rule):
The last Thursday of every month at 12:00 noon SLT.
Meetings are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.
A new Alpha build is currently available for Android, and is just waiting to be cleared by Apple (if not already available by the time the post is published).
This alpha is viewed as being “close” to being ready for a beta release “Soon™”, and includes all current work on the Mobile product, several aspects of which are outlined below.
Avatar and Character improvements
Load times: a “significant” reduction in the amount of memory required to load an avatar, allowing Mobile to both load more avatars in a scene, and do so more reliably.
Performance in environments with large numbers of avatars should also now be improved.
There are still some shape changes to be completed to allow all avatars to render correctly, but this work is progressing.
Network connection stability:
As reported in the August update, because of its dynamic nature, SL Mobile requires a constants data stream, and so is far more susceptible to signal interruptions / conflicts with other apps for bandwidth use, etc.
Work has therefore been put into making the app more robust in how it maintains network connectivity and continues to function through such interruptions, doing all that is required of it.
These improvements also feed into the avatar system as well, further helping with the speed and reliability of avatar loading.
Under-the-hood work: general optimisations such as re-targeting download orders (e.g. increasing the download priority of avatar clothing downloads to again improve avatar downloading and rendering).
This under-the-hood work also includes refining code related to the loading and unloading of in-scene objects, so when moving around the world, content should load / unload more effectively, with more content in general loading.
EEP Rendering
A first pass at implementing EEP environment settings.
This is a direct port of the sky shaders used in the viewer, so that scenes should render a lot closer to how they appear on the Desktop viewer.
The work includes all of the lighting data, fog / haze data, etc., as well as the sky shaders.
Further work is required on lighting due to differences in how the Unity engine and the SL engine respectively handle lighting.
Transparency Rendering
Due to the need for order-independent transparency, coupled with limitations within the GPUs used on most mobile devices, SL Mobile has been unable to render “true” transparency, and has had to rely on dithering to approximate transparency.
One means to get around this is to use temporal anti-aliasing, which LL has been waiting on through an update to the version on Unity they use with Mobile.
The work on this upgrade was recently completed, allowing said temporal anti-aliasing to be utilising within the app, providing better transparency rendering without any loss of performance.
Until this work is fully dialled-in, there might be some light ghosting visible when panning around transparent surfaces.
Lighting / Point Lighting
There is a “slight incongruity” between how Unity handles point lighting (lighting placed around a scene) compared to how Second Life handles the same (the Unity rendering path prefers quadratic lights – bright up close, dim at a distance; SL is more medium-bright when close, medium-dark when further away). This resulting in point lighting in Mobile to look different to the same lighting seen in the viewer.
To try to address this, the lighting calculations used for such point lights has been tweaked within SL Mobile so that such lights will be rendered more closely to how they are within the viewer.
As a general note, updates to directional lighting may allow shadows to be re-enabled in the Mobile app, although shadow rendering is expensive, and further work in this area is required.
General Improvements
Multi-threading for object and content loading has been improved, which see see more effective use of the CPU cores within a mobile device.
Streaming audio has been completely rebuilt to avoid using a now-deprecated library within the current beta streaming audio build.
Improvements made to loading the world following a rapid log-out / log back in.
General improvements and minor adjustments to the UI. Perhaps the most noticeable of these is the temporary return of the sign-out option as a button in the menu (pending further updates down the road which will likely see it return to a drop-down option once again).
Improvements to how spinning objects and target_omega are handled.
Switching to another app when using the SL Mobile app and then switching back to SL Mobile can seem to take time.
This is partially out of LL’s hands: apps not in current use can be “moved” from active memory to free-space for other apps. Changing focus can also result in the web page used to assist in rendering the UI being suspended.
Both of these factors can result in a delay in resuming a session as the focus is returned to SL Mobile.
Consideration may be given to adding a pop-up message about possible delays when switching away from SL Mobile to another app, with a possible more in-depth examination as to what might be done to be carried out at some point in the future.
Inventory access: outfit sub-folder support, etc: Inventory is something being worked on, but the work is such that no major announcements as to what is being done / what to expect could be made at this meeting.
Message caching (e.g. people can receive messages whilst on SL Mobile, but also still see them when logged in via the Desktop viewer): there has been some movement on this, and work is continuing, although complex. Further updates in due course.
Could the current SL networking calls be used with SL Mobile to save tampering with the SL infrastructure?
No, because SL mobile uses different protocols in order to handle:
Swapping between the device’s wifi and cellular connections on the fly.
Disruptive connections which could otherwise result in high packet loss – something UDP would have difficulty in managing.
The protocols used by SL Mobile also reduce the bandwidth the app uses when compared to Desktop (e.g. transmitting the scene state to SL Mobile uses 97% less bandwidth than the viewer).
Does SL Mobile run better in landscape mode or portrait? There shouldn’t be any difference.
Date of Next Meeting
12:00 SLT, Thursday, October 30th, 2025, at Campwich Forest.
The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting of Thursday, September 18th, 2025. Please note that this is not a full transcript, but a summary of key topics.
The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work.
This meeting is generally held on alternate Thursdays at Hippotropolis.
Dates and times of meetings are recorded in the SL Public Calendar, and they are conducted in a mix of Voice and text chat.
Inventory Favourites System, plus assorted new features.
Improvements to avatar system; camera and movement; chat; voice; content creation tools.
Mesh uploader updates.
Text & UI polish.
Fixes for Environment and Rendering; stability and crashes; UI.
System improvements.
Second Life Project Lua Editor Alpha (Aditi only), version 7.1.12.14888088240, May 13.
Viewer 2025.07
This is now in QA and making its way towards release candidate status (or “beta” as RC viewers seem to now be referenced).
The added native Apple Silicon support is said to deliver “pretty impressive” performance improvements for those running on that OS.
A caveat here is that for this release only, it may not be possible to upload meshes on Apple Silicon. This is due to some Havok issues and “some licensing limitations”.
These issues will likely be resolved when the open source replacement for Havok for convex hull decomposition is integrated into the viewer. This update is anticipated as being available in the upcoming 2025.08 viewer.
The above limitation is only for Apple Silicon, it should not apply to Windows or Mac systems running x86 chipsets.
For other updates likely to be included in this release, please refer to my summary of the previous CCUG meeting.
Viewers 2025.08 and 2025.09
These are liable to be the last two viewer updates from the Lab for 2025, and both are in the planning stage.
Updates under consideration for either of them include potential updates to screen space reflections (SSR), building on work carried out earlier in 2025 but which have yet to reach the viewer.
However, precise details as to what will be in either / both viewers is still subject to internal discussions and decisions within the Lab.
General Discussion – In Brief
Mesh import support – general direction:
COLLADA.DAE support will always remain and be available, even if only for legacy content that may never be updated to glTF.
.gltf /.glb is now an officially supported mesh format or both static and rigged mesh, but with some limitations (e.g. no blend shapes) – with a request that an bugs that may be discovered are reported.
It is acknowledged that currently, importing .gltf meshes is a two step process ( .gltf materials and the .gltf mesh) which have to be imported separately to one another.
There have been discussion on supporting other mesh formats – but these are only discussions at this point in time, with absolutely no guarantee or time frame that/when other formats will be supported, as the work would require further and extensive modification to the mesh import workflow and internal SL mesh support.
A request was made for Inventory Thumbnails to support aspect ratios other than just 1:1, or to include a means for images to be cropped within the viewer post-upload.
Making changes to the the image aspect ratio for Inventory thumbnails was seen as “unlikely” in the near-term, but it was suggested the idea be raised at the next Open Source User Group meeting to see if a code contribution might be made.
A general discussion on the new Inventory Favourites capability in the official viewer, including comparisons with using the Favourite Wearables option seen in some TPVs.
Whilst the latter is not necessarily as flexible in its use as the Lab’s implementation, it was seen as scoring over the latter due to a) having a dedicated floater; and b) having that floater accessible from a toolbar button.
A request was made for some form of Inventory “cold storage”, where items can be archived without having to be boxed, and which is excluded from Inventory searches.
It was suggested that the easiest way to solve for this would be to a system folder to Inventory which is pre-set so that anything placed within it does not show up during searches.
Another suggestion was to strengthen Inventory filters to allow certain exclusions or to allow filtering by new inventory capabilities (e.g. to directly filter for all folders / items tagged as a Favourite).
The above could be combined with some UX redesign to better surface filters and make their functionality clearer, and potentially allowing filters to be set as easy-to-access inventory presets to quickly allow different views of a person’s Inventory to be accessed.
This broader discussion on inventory wound through a good portion of the meeting in terms of comments from users.
The subject of allowing region-wide reflection probes was raised – and was responded to as unlikely to happen, with a not that regions already have a “void probe” which – whilst primitive in nature – already does much of what a region-wide probe would do, using some of the data from the region. This can be visualised by going to Preferences → Graphics, locating Max Reflection Probes and setting it to None.
A question was asked as to whether LL staff and contractor work full-time on their specific areas, or if some work shorter hours / get moved around projects, thus limiting the amount of time they can spend working on certain things, leading to a lengthening of time frames, etc.
The broad response was that the (approx. 30-strong) dev staff work a standard working week, and some do get moved between projects, depending on priorities.
Further, planning, complexity and prioritisation do play a role in determining what gets worked on and how resources are used, all in accordance with management, etc., focus on platform direction and development.
Also, given the overall complexity and age of SL, the need for backward compatibility, etc., a large amount of effort has to go into simply “keeping the lights on” (to use Philip Rosedale’s term), and this also impacts available resources and determining what projects and taken up and worked on at any given time.
A general discussion on versioned sky assets, weather, the old 768-metre system clouds, etc. In terms of versioning EEP assets, this is something still under discussion at the Lab, but is not something currently being targeted for implementation.
Inara Pey: Living in a Modemworld 