Frogmore, August 2019 – click any image for full-size
Update, November 2019: Frogmore has relocated to a full region. The SLurls in this piece have therefore been updated to point to that location. A review of the new region location is available here: Frogmore: more Swedish memories in Second Life.
Frogmore – or to give it its full name, Frogmore Gamla Stan (“Frogmore Old Town”), is a homestead region designed by Terry Fotherington (of {PAPPADO} – read more here and Kekeland – read more here – fame) on behalf of region holder Bengta. The region’s design serves a very specific purpose, as Bengta explains:
Frogmore Gamla Stan is a memory of life as a child in Öregrund, Sweden. The air is filled with the scent of the sea, old fishing boats, and smoked herring. A simple life filled with love and laughter.
Frogmore, August 2019
A quick check on Öregrund reveals it to be a small town (population 1,500-ish in 2010), on the Baltic coast of Sweden’s Uppsala County. It’s apparently a place that was largely ignored by Sweden’s 19th century industrialisation; other than bar iron passing through the town’s harbour en route to places like England, the town itself largely remained centred on fishing, although in the late 19th century it did became popular as a spa resort.
It is that history as a fishing town, as Bengta notes, that Frogmore draws a part of its inspiration, together with the rugged beauty of the Scandinavian coast, to form a wonderful little fishing hamlet clinging to a rugged coastal region / group of islands. Given that it is only inspired by childhood memories as visualised through the eyes of another, direct parallels between Frogmore’s look and Öregrund perhaps shouldn’t be made.
Frogmore, August 2019
Instead, it is better to simply wander along the single, cinder-topped road, passing between brightly-painted wooden places of business and cabins (none of which are furnished within, to allow the focus to be on the landscaping and overall setting, to where steps climb upwards and more inland. The waterfront cabins and buildings are literally that: right on, and sometimes over, the water, with steps and moorings for rowing boats, nets drying as they hang from walls, and sofas and benches set on raised porches.
More houses and places of business can be found on the stepped shoulders of rock rising on the landward side of the road, and with a little care and scrambling, you can make your way to where a primitive log bridge spans a narrow watery gorge separating the two largest islands. This is worth taking, as it leads the way past a superb little rocky stream that tumbles down from one pool to another which, presumably has an opening somewhere under the cold-looking waters to allow the flow to continue on its way. Created using one of Alex Bader’s new Animated River Building Packs (see here and here), it really shows what can be achieved with what is – to me – the best mesh river system available in SL.
Frogmore, August 2019
Exploring the region can be both fun and a little frustrating. Fun, as there are little cinder trails to be found here and there, offering the way between rocks to cabins or down to little beaches and coves. Frustrating, because although there are a couple of paddle boat rezzers to be found on the different islands, the lie of the land means you can’t actually use them to get from the little town to the other islands or vice-versa, leaving flying the only alternative.
The other peculiarity I had with a visit was that on our first (exploratory) time in Frogmore, the region was backed by off-sim mountains. On my return for photos, these steadfastly refused to render (and I tried 3 different viewers and various tricks to try to force them to render). Hence why some of the shoots accompanying this article may be different to those of Frogmore you may have seen elsewhere. Chatting to a couple of other people on the region, I learned they were having similar issues between visits – sometimes the mountains would render, sometimes not.
Frogmore, August 2019
But, mountains or no mountains, there is no doubting Frogmore’s beauty or its uniqueness among public regions, not just because of its appearance, but because of its founding inspiration and the “third-party”, so to speak, interpretation of that inspiration by the designer.
Lab Gab is the title of a new live stream event being hosted by Xiola and Strawberry Linden, that commences on Wednesday, August 28th at 15:00 SLT. Initially announced in a blog post on August 23rd, Lab Gab is intended to be:
A variety show of sorts – we want to explore Second Life, answer your questions, talk to Residents from all over the world, and stream it through the internet and into your homes, phones, and wherever you get your quality entertainment.
With Xiola going on to note:
In our first show, we’ll be introducing ourselves, talking a little bit about what Lab Gab is, and interacting with you through YouTube live. In the future, we will invite special guests to come visit us on the set and talk about events and issues that impact the communities in Second Life.
For those interested, Lab Gab will initially be streamed via the official Second Life You Tube channel – although other platforms will be added in the future – with shows planned to go out every couple of weeks or so.
I confess, I’m not a great fan of live streamed events (outside of things like meetings, where there tends to be a more formalised approach to things), simply because at times things can get dragged out or take a sudden right turn away from something that might have otherwise been interesting. However, there is no denying the seat-of-the-pants sense of adventure those actively leading / participating in such events can feel, and the very unpredictable nature of where things might lead can add to the appeal for a watching audience.
At the same time, I also admit to being curious as to whether the show might at some point down the road – depending on its longevity – also occasionally “hop over the fence” into Sansar or even perhaps take some “behind the scenes” (desires for things like privacy allowing among staff) looks at the Lab itself. “Lab Gab” seems to be too broad a title to remain purely about Second Life (although there is a lot to explore on that subject alone), even allowing for it being intentioned as a “catchy” name for the show.
Certainly, dipping the occasional toe in Sansar’s waters might help dispel some of the many misconceptions that circulate among SL users concerning that platform, while taking a peek inside the Lab could also help both dispel certain myths and offer greater insight into what goes into keeping Second Life chugging along. Just a couple of ideas I’m throwing out there, LL, if you’ve not already considered them 😉 ).
In the meantime, if you are curious to see how Lab Gab sets itself up as a magazine show look at Second Life, be sure to watch tonight’s instalment via the You Tube link above, and keep an eye on the Lab’s social media and blog for updates about future shows.
There was no deployment to the SLS (Main) channel on Tuesday, August 27th, leaving it on server maintenance package 19#19.08.06.529800, containing internal fixes.
On Wednesday, August 28th, the core RC channels should be updated as follows:
Among other things, this update will see the RC channel name be removed from Help > About in the viewer (it will simply be recorded as “Second Life Server”), and the channel name will no longer be returned for LSL enquiries.
Note this is the RC channel name that will be changing – both the simhost name and the simulator version will still be visible, contrary to comments in the forums. Also, simulator version number will remain available to LSL; it is again, just the channel (sim_channel) that will always return “Second Life Server”
Magnum ad LeTigre should receive server maintenance package 19#19.08.23.530380, very helpfully referred to as “Maintenance fixes” and “Maint Train woo woo chuga chuga chuga chuga”
There will be a further small-scale RC deployment that will (if I understand things correctly) comprising the script usage improvements – the smaller deployment being cautionary after things went sideways when an attempt was made to deploy these updates to an RC channel in week #34.
SL Viewer
The Bakes on Mesh viewer was promoted to de facto release status on Monday, August 26th, with the release of version 6.3.0.530115. You can find out more here:
As a result of this promotion, the Umeshu Maintenance RC viewer updated to version 6.3.1.530411 on Tuesday, August, 27th, bringing it to parity with Bakes on Mesh. This will likely be the next viewer to be promoted to release status in around 2 weeks time.
The rest of the viewer pipelines see no change at the start of the week and remain as follows:
Project Muscadine viewer (Animesh enhancements), version 6.4.0.530100, August 19th
360 Snapshot project viewer, version 6.2.4.529111, July 16th.
Legacy Profiles viewer, version 6.2.3.527749, June 5. Covers the re-integration of Viewer Profiles.
Linux Spur viewer, version 5.0.9.329906, promoted to release status 29th November 2017 – offered pending a Linux version of the Alex Ivy viewer code.
Obsolete platform viewer, version 3.7.28.300847, May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.
In Brief
The planned changes to RC deployments (see the blog post links above) has caused some drama, partially due to people misunderstanding that the RC channel names will be less obvious, as noted above – but not the simulator / simhost names.
However, it is true that the downgrading of ready access to RC channel names will make it harder for users to recognise which channel they are on – which could made testing capabilities and features harder, given that people are not so familiar with simulator versions and simhost names.
The flip side to this is that in some respects, the Lab doesn’t want people to know which channel they are on to stop preconceptions about issues, etc., they may encounter (e.g. “I was on Magnum, which has X release on it, and I have this issue – so it MUST be X that is at fault!”) – and according to Oz Linden, they would like to see more testing of new features on Aditi ahead of any main grid RC deployment.
To help people understand what is being released, the simulator version release notes are promised to be “more informative” in future and where relevant. That said, “Maint Train woo woo chuga chuga chuga chuga” isn’t exactly setting the bar that high in terms of informative release notes.
There is a reported issue with experiences whereby any scripts compiled to an experience prior to simulator version 19.08.06.529800 will not recompile on 19.08.06.529800 or later. The issue is further described thus, following any attempt to recompile:
Checking Properties for the recompiled scripts will show no compiled experience. Plus shift-copying or using the edit menu to copy or dropping an experience script in a host, will all result in the experience being completely lost from the script compile. However, llResetScript() doesn’t trigger the loss.
A bug report has been raised on group chat lag (BUG-227477). The Lab is aware of this and has left the report open for further input from those experiencing issues. Constructive and informative feedback is clearly being sought, along the lines of the comments thus far left.
Updated with an overview of “Bakes on Mesh appliers” for Mesh bodies and head yet to be updated to support BoM.
Monday, August 26th, 2019 saw the formal release of Bakes on Mesh (BoM) for Second Life, and with it, an attempt to make system wearables (skins, tattoo and clothing layers) usable on modern mesh avatar bodies, utilising the avatar Bake Service and without the need for a dedicated applier system.
While Bakes on Mesh has been in development for over years, and much of it is known to many users, this article has been written to provide something of an introduction / overview of BoM, covering things like system wearables, the Bake Service, that changes that have been made, where to find information on using BoM, and what it may mean for Second Life users in the future, depending upon how well the capability is received by creators.
Some Basics
System Wearables and the Bake Service
System wearables as they appear in inventory
Without going too deeply into specifics for those unfamiliar with them, system wearables are a special kind of inventory asset (some of which are shown on the right) that can be directly worn / added to the system avatar to produce a “dressed” look.
These wearables come in a number of “layers”- skin (which must always be worn on the system avatar), tattoo, undershirt, shirt, and jacket.
The naming of the layers isn’t that important – a creator could be assign a bra or a shirt or a pair of pants to any one of the tattoo, undershirt, shirt and jacket layers, depending on how flexible they want their clothing to be. What is important is that the always follow an hierarchy: skin is always at the bottom and so “covered” by the other layers, which are in turn “covered” by the next (so undershirt wearables always apply “over” tattoo wearables; “shirt layers “over” undershirt wearables, etc), with the avatar able to wear up to 62 wearables in any combination of layers at one time.
This might sound very complex, but for those familiar with the system, it is very easy to grasp; however, what is important is what comes next. When an avatar’s look is complete, the information about all these wearables are sent to the simulator and then to a back-end set of servers called the Bake Service over a series of channels called the “bake channels”, which define where the layers appear on the avatar. These channels are:
BAKE_HEAD, which defines all the wearable elements that have been applied to the head (e.g. skin, and tattoo layers used for make-up)
BAKE_UPPER, which defines all the wearable elements – skin plus any tattoo, undershirt, shirt and / or jacket layer(s) that have been applied to the avatar body above the waist and below the neck (with the left arm mirrored from the right).
BAKE_LOWER, which defines all the wearable elements – skin plus any tattoo, undershirt, shirt and / or jacket layer(s) that have been applied to the avatar body from the waist to the feet (with the left leg mirrored from the right).
BAKE_EYES and BAKE_HAIR (both pretty self-explanatory).
BAKE_SKIRT, which defines skirt / dress style wearables.
The Bake Service then composites (bakes) the layers received on each of these bake channels into a single texture, and sends the results out to every viewer able to “see” the avatar. So, for example, facial / head skin and any make-up tattoo(s) received via the BAKE_HEAD channel are baked to become a texture seen on the avatar’s head, while the layers received over the Bake_Upper channel are baked into a texture seen on the avatar’s upper body, and so on, ensuring the avatar consistently appears to everyone dressed at the user intended, while also removing the need for individual viewers to manage the complex layering and rendering of all the individual wearable layers on other people’s avatars.
Mesh Bodies and Complexity
Since their introduction, mesh bodies have not been able to leverage this approach. Instead, they require a dedicated “applier” mechanism to achieve the same ends, together with the use of an alpha layer to hide the system avatar.
Further, to enable clothing items to be layered – so you can have an applied shirt / blouse appearing to be “under” a jacket, for a example, mesh bodies have had to be constructed in a complex manner, with several layers closely packed together (colloquially called “onion layers”) that effectively mimic the system wearable layers. This actually makes the avatar a lot more complex than they otherwise might be, resulting in their relatively high rendering costs.
Enter Bakes on Mesh
So, Bakes on Mesh has been developed to allow system wearable to be applied directly from inventory to worn mesh faces (e.g. avatar bodies and wearables) that have been correctly flagged by the creator to support Bakes on Mesh. Through Bakes on Mesh, Linden Lab hopes:
Users can avoid the need to use appliers, but can add wearables to their mesh avatar directly from inventory.
Creators will be able to simplify avatar mesh bodies and heads by removing the need for some of the “onion” layers. This should – if done – reduce the rendering complexity for bodies and heads, thus hopefully improving people’s SL experience (as avatars won’t be quite so resource intensive or require quite so much “assembly time” when encountering them on logging-on or after teleporting somewhere).
Notes:
As with all new features, use of Bakes on Mesh will only be apparent to those actually using viewers running the Bakes on Mesh code; anyone not on such a viewer will likely see something of a mess.And as with new features, it will take time for the Bakes on Mesh code to be implemented by all TPVs.
Bakes on Mesh does not mean user “have” to go back to using system wearables nor does it mean that applier systems can no longer be used. It is simply a means of making system wearables work with mesh bodies and heads, hopefully with the benefits given above. Those who wish to can continue to use applier-based clothing as they always have.
Bakes on Mesh adds new options for applying suitable textures to the baking channels for application on a mesh body by the Bake Service
An introduction to using BoM can be found in the Bakes on Mesh Knowledge Base article. This includes information on trying BOM using a test mesh body – the best way to do this is to use Aditi, the beta grid. I’m not going to go into specifics here, simply because there are multiple resources available to assist users and creators – some of which are noted at the end of this article, and I want to keep this as a more general, easy-to-understand primer.
When considering Bakes on Mesh it is important to remember it is not necessarily intended as an outright replacement for appliers and current mesh bodies from the get-go. Rather, it is initially an alternative – although if the popularity / take-up among creators and users are sufficient, then over time it could obviously become the system of choice over appliers and more complex mesh bodies. However, existing mesh bodies / heads and applier systems will continue to work as they always have.
Key Points of Bakes on Mesh
This list is not exhaustive, but is intended to give a feel for Bakes on Mesh and its use:
System skin layers, tattoo layers, clothing layers and alpha layers all work – the mesh just needs to be flagged by its creator as supporting Bakes on Mesh and correctly set-up for alpha layers to work as intended.
As an alternative, there are assorted “BoM appliers” designed to work with mesh bodies / heads that have not (yet) been updated with Bakes on Mesh support – see below for more.
You do not need a full body alpha to wear a Bakes on Mesh flagged mesh. If the flag is present when you wear the mesh, the body section it is flagged for disappears. So, if you wear a lower body “Bakes on Mesh ready” avatar part, then entire lower body of the system avatar will disappear.
The Bake Service has been updated to support 1024×1024 resolution textures, so it offers the same texture resolution for wearables as offered through applier systems (prior to Bakes on Mesh the maximum resolution for wearables was 512×512).
Obviously, the wearable must be made at this resolution in order to utilise it; a 512×512 wearable will not magically appear to be 1024×1024 resolution when applied.
In order to be fully effective, mesh bodies using BoM and BoM wearables should match the system avatar UV map as closely as possible.
Fortunately, most of the current range of avatar bodies sold under brands such as Maitreya, Slink etc., do tend to stay close to the system avatar UV map. So any new BoM-specific versions / updates should continue to do so.
Alpha support means that layers means that mesh bodies should no longer need to be split into multiple pieces for individual alpha-masking to prevent a body clipping through clothes. Alpha requirements are back in the hands of the clothing creator, and should be made alongside the clothing, so that when used and providing the body is correctly set-up they should just “work”. In addition, clothing makers may not longer need to include auto alpha scripts.
Changing mesh body parts should be easier, providing both bodies are flagged to use Bakes on Mesh. The body takes whatever is worn on the system body – skin and make-up instantly appear on each change of head, for example.
Skin makers will be able to offer more options by including tattoos with their skins, allowing for a variety of make-up options, whilst there will no longer be any limitation on the use of tattoos (one per zone).
Applier support will still be required for the following: nails; eyelashes; standalone ears, hands, feet, lips, bust implants, etc.; lip gloss; materials finishes (see Some Possible Points of Contention, below); neck blenders, anything not intended to look “painted” on.
New with Bakes On Mesh
To provide full “wearables” support, Bakes on Mesh introduces some new elements that will be of key import to creators:
The introduction of 5 new bake channels – LEFT_ARM_BAKED, LEFT_LEG_BAKED, AUX1_BAKED, AUX2_BAKED, AUX3_BAKED:
These can only be used with Bakes on Mesh, and are not available to the system avatar.
LEFT_ARM_BAKED and LEFT_LEG_BAKED are intended to help with making mesh avatars where the left and right limbs have different textures (and so can be asymmetric, as can currently be achieved with applier systems).
The AUX channels are general purpose, and could be used for body regions not possessed by system avatars (such as wings) or for other purposes.
This means BoM has 11 possible channels for wearables to use for textures, and for the baking service to produce.
However, the new channels listed above do not have alpha support like the other channels, and so cannot have “holes” cutting through the mesh face they are worn against.
BOM also adds a new wearable type called Universal.
While specifically added to allow the wearing items that use the new channels described above, the Universal wearable has slots corresponding to all 11 of the bake channels, offering extensive flexibility of use. In layering order, universal wearables go between the tattoo and body layers.
Note that for others to see your avatar correctly when you are using Bakes on Mesh they must also be using a Bakes on Mesh viewer. If they are not, they will see your avatar as a mesh of red, blue and yellow colours showing through your mesh parts.
Left: Bakes on Mesh when seen via a non Bakes on Mesh viewer: the system avatar will show through the mesh body parts, covered by default system-supplied BoM marker textures. Centre and Right: using a “Bakes on Mesh applier” on a non-BoM body and head and via a Bakes on Mesh capable viewer. The centre image shows the “before” avatar state: the system layer skin and clothing are worn, but do not conform to the mesh body and head (which must be worn without their corresponding alphas for this type of applier to work), and so “poke through” (highlighted in places by the red circles). The right image shows how things look after the”Bakes on Mesh” appliers have been used – the system layer clothing and skin now mostly conform to the mesh head / body, with the exception of fingers and toes (highlighted) which will generally require an additional “glove” or “mask” fix.
“Bakes on Mesh Appliers”
During the testing of Bakes on Mesh, at least two experimental applier systems were produced to allow BoM to be tested on non-BoM flagged bodies and heads. For example, Omega produced an experimental BoM applier system, with instructions here.
Since then, and given that several mesh body and head creators have yet to produce BoM flagged updates to their bodies / heads, several more such “BoM appliers” have been produced, some of which are available for free, some are provided by the mesh head / body creator, and others are available at a nominal cost, and may be for specific purposes (e.g. the Bakes on Mesh skin applier (Omega) by Conor Shostakovich at L$125).
These essentially work by allowing you to dress your system avatar with the required system wearables, then wearing your mesh body / head without their alpha masks, and then using the applier to apply the system layers to the mesh body / head in a similar manner to “traditional” appliers – but again, as a single composite layer when baked.
How effective these systems are can be variable.
Due to differences in the way skin skin textures / UV maps work and the way mesh bodies tend to be put together, such appliers may not work particularly well around feet and hands.
Note: links to products does not constitute endorsement. Always check the Marketplace for products and reviews.
Such appliers are intended as an interim “fix” for using Bakes on Mesh until such time as the major head and body creators provided full Bakes on Mesh support.
Some Possible Points of Contention
However, there are what might be regarded by some as “negatives” around Bakes on Mesh, a couple of the more prominent ones being:
The Bakes Service – and thus Bakes on Mesh – does not support materials (normal and specular maps). How much this impacts people’s acceptance of BoM is open to debate. However, when needed, materials still can be added manually (if the mesh / mesh face in question is editable) or via a suitable applier.
Appliers are convenient, as they are an all-in-one solution requiring only one or two items in inventory – the outfit applier HUD and possibly an intermediary relay tool like Omega.
With Bakes on mesh, wearables are all individual inventory assets, which could lead to inventory growth, some of which might be quite extensive as a result of creators providing multiple options / layers (although in fairness, some applier systems can be like this – I have seen a Hugo’s Design outfit with no fewer the 40 individual items, both system layer clothing and multiple applier options).
Some of the inventory “bloat” BoM might cause can potentially be managed via the use of the viewer’s Outfits capability (although this obviously also adds to bloat with inventory links) or via a new form of applier system that utilises system wearables created at 1024×1024 resolution.
How much these may impinge on consumer’s willingness to adopt BoM remains to be seen.
Closing Remarks
Like all new capabilities, Bakes on Mesh will take time to gain understanding and traction. Also like all new features, it has its outright fans, and those who have – even before really getting to work with it in earnest – decided its is bad / wrong / pointless / a step back, etc.
I’m personally sitting in the middle. If it does what is claimed on the tin, and if it gains traction among mesh body and head creators (and several have been working on BoM for the 12+ months its been in development) and clothing creators, then it could do its own little bit towards a better “optimisation” (quotes used intentionally, as there is still a lot more than can be done in terms of optimisations cross SL), and make things a little better for everyone.
But it will take time for Bakes on Mesh to mature in terms of general use – creators need to update their heads / bodies (although Slink is apparently ahead of the curve, and their new bodies are said to work with existing appliers, and other creators may also be providing products / updates, I’ve just not encountered any as yet). Those making system wearables are going to need time to update to the 1024×1024 where preferred (if they haven’t already, and so on. And, most obviously, it will take a little time for the Bakes on Mesh code to percolate out to all TPVs.
It has long been a tradition in Second Life that the main grid simulators and the regions they support are split between a number of channels:
The main channel, called Second Life Server, or SLS, which has the majority of simulators / regions running on it (roughly about 70%).
Three core release candidate (RC) channels, code-named BlueSteel, Magnum and LeTigre – each of which may account for roughly 10% of the simulators / regions.
Assorted smaller RC channels (such as Snack and Cake), that come and go according to needs – they may draw their simulators / regions from the SLS channel or the main RCs or a combination thereof.
This division is designed to allow a flexibility of approach to deploying updates, particularly those that may contain new features or have specialist updates such a new throttles or security changes, as these can be deployment to one or two of the RC channels first to test how they work under fully 2live” conditions (which the Lab, with the best will in the world cannot possibly fully test prior to deployment), and then removed with minimal grid disruption should anything untoward happen.
These RC deployments generally take place every Wednesday. If all goes well, and depending on how many different simulator updates are on the larger RCs, one will generally be “promoted” to the SLS channel the following Tuesday, having spent a week on one or more RCs. there are some variances in this, depending on what is going on (significant changes or new feature might be gradually deployed from one to two to all three RCs over a period of time, and then to the SLS channel, for example), but you should get the general idea from this, if you weren’t previously aware of how things work.
These (generally) weekly deployments are reflected in my Simulator User Group updates, where I list the deployments in terms of the SLS channel and the three core RC channels (the Lab doesn’t always acknowledge when a very small RC is being used).
However, on Monday, August 26th, Linden Lab announced upcoming changes to how simulator changes are going to be handled, and while the deployment methodology will remain the same (SLS channel deployments on Tuesdays, RC deployments on Wednesdays), there will be some differences, notably:
Starting with a deployment to one of the RC channels, the channel name will no longer be visible through the viewer (Help > About) nor will it be open to LEL query – the channel name will simply be listed as “Second Life Server”, the same as the “main” channel. Over the next couple of weeks this will be true for all RC channels.
This means that when reporting simulator issues, just referencing the channel name will no longer be sufficient – users must use the simulator version number. This is displayed in Help > About, alongside the channel name:
Going forward from week =35, simulator issues should be reported using the simulator code version number, not the channel name (“SLS”, “BlueSteel”, etc.).
The reasons for making these changes are defined as being twofold:
To provide the Lab with better data on the performance and reliability of the server updates, and allow for better monitoring (presumably via the additional tools and internal changes the Lab has been making to the simulator code for the last few months).
To avoid spurious associations between the RC channels and capabilities. For example, the idea that one RC channel runs on better (or worse) hardware than another or the SLS channel; or that issues being experienced *must* be the result of an RC deployment, purely on the basis that that was either the last deployment made, or the user happened to be on an RC channel when they encountered an issue (regardless of whether the code may actually have caused the problem or not).
It is also noted in the official blog post that while simulator code version numbers will be the preferred means of reporting issues, channel names will continue to be recognised by Support for matters of testing:
Future improvements will make each RC channel a better model of the Grid as a whole. Support will continue to be able to accommodate Region owners’ requests that a Region be in the RC for a particular feature or fix they want as soon as possible, or that it be excluded from any RC.
It’s currently not clear if these changes will also impact the channel reporting capabilities in TPVs like Firestorm (which can pop-up the name of the simulator channel when moving from one to another) or not.
A final note in the official blog indicates that simulator release notes will be moving to the same system as is now used for viewer release notes. When this happens, I can only hope it is managed better than is currently the case for viewer release notes, where updates viewers may be references on the Release Notes page OR the Alternate Viewers page OR the Available Viewers Index on what seems to be the flip of a coin.
Please refer to the official blog post for full details of the changes.
Cherishville, August 2019 – click any image for full size
Shawn Shakespeare suggested we make a further return visit to Lam Erin’s Cherishville over the weekend, noting it had been redesigned in readiness for autumn’s arrival in the northern hemisphere. So we hopped on the Second Life express and alighted at St. Bronxton Railway Station, a quaint little end-of-the-line station that is one of Cherishville’s many new features to capture the eye and the lens.
The region is now centred on a channel that cuts it neatly in two from east to north-west. With the stone-built banks topped by paved footpaths and spanned by a single bridge, the channel is bordered on either side by an assortment of buildings; so much so, that despite facing open water at either end, it has the look and feel of being the mouth of a small but navigable river, and the buildings on either side are the result of a estuary township, the people drawn here for the open seas and the opportunities for fishing and coastal commerce.
Cherishville, August 2019
This little township is distinctly of two halves. The west bank of the river, which includes the landing point and the aforementioned railway station (set back from the river’s edge) has – to me at least – a very English feel to it. With the buildings crowding the waterfront, I was immediately put in mind of a small river estuary in Cornwall or Devon; the stone-built houses and shops speaking of a place that had in the past grown up as a result of commerce along the coast. In fact, such is the look to that side of the river, I wouldn’t have been surprised if during our visits, Aram Khachaturian’s Adagio from Spartacus welled up in the background as the Charlotte Rhodes hove into view, James Onedin at the helm (Yes, a (possibly obscure) British TV series reference thrown in as well!).
Across the stone bridge, the east side of the river has a more American look and feel to it: posters advertise Connecticut and New England lobster, Martha’s Vineyard gets a mention and the fuel prices are in USD. Even the wooden buildings have the look and feel of rural Americana.
Cherishville, August 2019
But no matter what influences have been drawn into the design, both sides of the river have one thing in common – something also common to both sides of the Atlantic in the autumn: rain. To say this is coming down in buckets would be an understatement; for those so inclined, brollies, coats and wellies are the order of the day for a visit! Although truth be told, the rain (mesh elements places along the line of the river) add considerable atmosphere to the setting. It pounds the footpaths and board walks, given both a sheen that reflects lights (if you have ALM enabled!), while puddles set golden, red, orange and yellow leaves drifting under the influence of a gentle, rainy breeze.
Beyond the river and town, the land undulates in low, wooded hills or spread in flower-rich ground before dropping away to the water once more. A lighthouse raises a finger into the sky to the north-east, adding to the feel of this side of the river being more American in setting, whilst on the west side, the land is cut in part by the tracks curving out from Bronxton Railway Station, whilst also easing its way to a shingle ribbon of coast looking south and out towards two smaller islands, each topped by a cabin.
Cherishville, August 2019
These cabins appear to be open to the public – at the time of our visit, the larger was unfurnished as well. However, as there are no obvious means to reach either of them save by swimming / flying, we didn’t venture any closer than the beach to find out, as we didn’t want to invade any privacy should either be for private use.
Not that any visit really is necessary: there is more than enough to see and photograph around the river front town and immediately behind its rows of buildings without every need to cross the water to the smaller islands. There are also plenty of spots scattered around when sitting and passing the time can be enjoyed – particularly along that southern ribbon of beach.
Cherishville, August 2019
There are admittedly one or two rough elements in the design. Some of these are somewhat down to the nature of the mesh beast – it’s possible in places to find yourself walking in raindrop splashes hovering at waist level. Others may well be because Lam is still tweaking the design – on my return run for photographs, he was shuffling buildings, sorting out hovering trees and carrying out some general furnishing. Certainly, none of the is enough to completely spoil the setting or the autumnal feeling it imbues whilst wandering and exploring.
All told, another classic design from Lam, very different from its summer iteration (read here for more), but well in keeping with the upcoming seasonal change in the northern hemisphere (climate change allowing!), and very much worth the time to visit – as always, and photos welcome at the region’s Flickr group.
![][Octopussy][ goes Cuba; Inara Pey, July 2019, on Flickr](https://live.staticflickr.com/65535/48250373461_9467c8ce90_o.jpg)
Inara Pey: Living in a Modemworld 