It’s time to highlight another week of storytelling in Voice by the staff and volunteers at the Seanchai Library. As always, all times SLT, and events are held at the Library’s home at Holly Kai Park, unless otherwise indicated.
Sunday, November 19th, 18:00: A Little bit of Pooh Bear
Caledonia Skytower presents selections of stories by A.A. Milne about everybody’s Bear of Very Little Brain in a Magicland Storytime presentation.
Monday, November 20th 19:00: The Alien Dark
Gyro Muggins reads Diana G. Gallagher’s one science-fiction novel.
Out of the darkness of interstellar space…
The ahsin bey, a race of catlike beings determined to expand their territory, launch six vessels into deep space to search for an uninhabited world suitable for colonization.
Tahl d’jehn commands the Dan tahlni on a decades long mission to explore the Chai-te system. Studies show that Chai-te’s planets are rich in the resource the ahsin bey need, but will their signal reach their home world in time to launch the colony ship. And what is Tahl to make of the startling discovery of a dead civilization on Chai-te Three?
Tuesday, November 21st, 19:00: Hold for Crap!
Crap Mariner presents originals stories for your listening pleasure.
Wednesday, November 22nd, 19:00: A Connecticut Yankee In King Arthur’s Court
Bookended by the story of a tourist in England encountering a stranger who tells him part of his story, then gives him a manuscript that tells the rest of his strange tale, Mark Twain’s 1889 novel relates how a Yankee engineer from Connecticut is transported back to the 6th century court of King Arthur. There, he uses his knowledge of engineering and munitions to present himself as a “magician” – earning Merlin’s ire in the process – and becoming Arthur’s trusted “prime minister”.
Mixing humour, the legend of King Arthur and a touch of a Batman and Robin style relationship between Hank, the Yankee, and Clarence, his protégé, Twain weaves a tale of his own around love, the Arthurian legend and Romano-British history (who actually built the early roads of Britain?). But can Hank, ultimately, save Arthur from his fate?
Join Caledonia Skytower as she presents selections from this tale. Also presented in Kitely (hop://grid.kitely.com:8002/Seanchai/108/609/1528).
Thursday, November 23rd, 10:00: Alice’s Restaurant Massacree
A Seanchai Library Thanksgiving tradition with Shandon Loring.
via Wikipedia
You can get anything that you want
At Alice’s restaurant.
You can get anything that you want
At Alice’s restaurant.
Walk right in, it’s around the back,
Just a half-a-mile from the railroad tracks, And you can get anything that you want
At Alice’s restaurant.
As Thanksgiving arrives in the United States, Shandon Loring presents singer-songwriter Arlo Guthrie’s famous 1967 musical monologue, Alice’s Restaurant Massacree (also popularly known as Alice’s Restaurant, and the inspiration of the 1969 Arthur Penn film of that name, starring Guthrie himself).
Aside from the opening and closing chorus, the song is delivered as the spoken word accompanied by a ragtime guitar. The story is based on a true incident in Guthrie’s life when, in 1965, he (then 18) and a friend were arrested for illegally dumping garbage from Alice’s restaurant after discovering that the town dump was closed for the Thanksgiving holiday.
What follows is a complicated, ironic and amusing story told in a deadpan, satirical tone, which encompasses fines, blind judges, guide dogs, 27 8×10 copiously annotated glossy photos related to the littering, frustrated police officers, the Vietnam War draft and, ultimately, the inexplicable ways in which bureaucracy moves to foil itself, just when you’ve given up hope of foiling it yourself.
Also presented in Kitely (hop://grid.kitely.com:8002/Seanchai/108/609/1528).
Saturday, November 25th: The Dickens Project
Now in its fifth year, Seanchai Library presents The Dickens Project for Christmas 2017.
Celebrating the work of one of the masters of 19th Century literature, whose humanistic voice continues to be a relevant one in our everyday culture.
Featuring a period setting, performance art, music and – of course – readings from A Christmas Carol, Dicken’s seminal tale for the time of year – and for all of us.
I’ll have a tour of the setting and a preview of the programme later this week – so stay tuned!
Please check with the Seanchai Library’s blog for updates and for additions or changes to the week’s schedule.
The featured charity for August and September is Little Kids Rock, transforming lives by restoring, expanding, and innovating music education in schools.
The following notes are taken from the TPV Developer meeting held on Friday, November 17th 2017. The video of that meeting is embedded at the end of this update, my thanks as always to North for recording and providing it.
SL Viewer
[0:50-2:22] The Alex Ivy 64-bit RC viewer, version 5.1.0.510354, has been holding up “really well” in its release cohort, although there is a start-up / benchmark crash the Lab has had difficulty reproducing, but for which they now believe they can fix in the next update, which should appear after the US Thanksgiving break (Thursday November 23rd – Sunday November 26th, 2017). If the crash is shown to be fixed, then the viewer should hopefully be in a position to move to release status in December.
[2:25-2:43] Vixox is still working on a race condition in the Voice RC viewer, version 5.0.8.328552 at the time of writing, and the Lab is hoping for an update on that either in parallel with or shortly after the Alex Ivy update.
[2:46-2:59] The current “Martini” Maintenance RC viewer updated to version 5.0.9.329906 on Friday, November 17th.
[3:00-3:28] An update to the 360 snapshot project viewer, version 5.1.0.506743 at the time of writing, is in progress, which should greatly improve image quality. If possible, this update might appear ahead of the US Thanksgiving break.
Rendering Project Viewer
[5:15-5:52] A new project viewer – Project Render, version 5.1.0.510604, dated November 14th, 2017, is available for Windows (32-bit and 64-bit) and Mac OS X. This viewer includes several fixes to the Rendering pipeline, and comes with a request that all issues are reported via JIRA.
The viewer is now built from the Alex Ivy (64-bit) branch (hence no Linux version), and all known issues for the Alex Ivy Viewer apply to it. It is intended to provide / address:
Improvement to mesh LOD calculation (account for CTRL+0).
Agents that render as jelly dolls should have their attachments render at 0 LoD to prevent loading higher LoD complexity in memory thus deterring crashes -> debug setting RenderAutoMuteByteLimit has to be > default of 0 for this feature.
Bug: Mesh avatar deforms constantly – was due to bounding box / LOD swaps.
Bug: Some mesh turned invisible when camera is moved – was caused by fix for MAINT-6125.
Bug: Setting one avatar to “Do not render” causes all avatars to become impostors.
Viewer Development Focus
Linux Viewer
[3:32-4:52 and 15:28-15:46] Currently, the Lab is aiming to get 32-bit and 64-bit Windows builds on the current viewers, together with 64-bit only Mac builds.
Once this has been done, the Lab will try again to get a 64-bit Linux build of the viewer, with the overall goal being to change the Linux build over to a Debian package without the additional libraries, allowing TPVs to add the dependencies they require for their flavour of Linux build. However, the Lab will be looking for help from TPVs and open-source developers in getting this done.
If help is given and the project is successful, the Lab will then maintain the Linux build, with the caveat that it will only be subject to cursory QA, and will continue to look to the Linux community for fixes.
General Focus
[10:10-14:35] In general, the Lab will be focusing more on current hardware (see resource usage tools, below) and operating systems over older / outdated hardware and operating system flavours. So for Windows, for example, while the Lab is not dropping support for 32-bit systems, the recommendation is that those who can upgrade to support Windows 64-bit (and particularly Windows 10 64-bit) should do so. If nothing else, this should substantially reduce viewer crash rates, particularly when used 64-bit versions of the viewer (e.g. fewer out-of-memory crashes).
Resource Usage tools
Note the following elements are discussed between 6:16-10:08 and then from 19:52-49:10.
VRAM and Texture Information
Chalice Yao has proposed a feature to the Firestorm team to allow users better understand the resources they are using, both through their avatar’s VRAM usage and the VRAM (triangles and vertices) for any selected object (see FIRE-21793).
Demonstration images (via FIRE-21793 / Arcane Portal) showing the proposed texture VRAM resource usage information on both a full avatar on the left and a specific attachment (Catwa head), on the right
Textures are a significant issue because of the widespread use of 1024×1024 textures on multiple faces of items at 4 MB a texture, whether needed or not (do buttons on a jacket really need 102×1024 textures?). This can lead to avatars using VRAM in the gigabyte ranges – simply because there is no incentive in place for creators to optimise their use of textures. so, offering a means by which users can see and understand their resource usage might encourage creators to start thinking in terms of optimising their use of the textures.
Overall, Oz is in favour of the idea, noting that it could be a good fit with the Lab’s own work in trying to make the render cost calculations for avatars and objects more accurate (allowing for the variances in handling information inherent within different types of graphics cards with different capabilities one to another). In addition, the Lab has been working on an experimental viewer which radically re-organises the texture cache to make it simpler, but this has yet to work (this includes the previously mentioned idea of storing textures already decoded).
The discussion (a fair part of which is in text) also covers the upcoming Bakes on Mesh work (see my CCUG meeting notes), the benefits of supplying users with pertinent information vs. the problems of witch-hunts, providing the means for people to be better educated and to make more informed decisions, how any additional information should be displayed etc.
Hide All Objects Outside of A Parcel
BUG-5671 outlines another idea related to data handling / viewer resource usage: offering parcel owners a setting that would effectively prevent the simulator from downloading information about objects outside of their own parcel. This would reduce simulator load, bandwidth use and mean the viewer doesn’t have to manage object data and rendering for items the parcel owner doesn’t want to see when with their parcel (although it also means their view would be reduced to looked out over “empty” land).
The feature request has been accepted by the Lab – but when or how it, or something like it, may be implemented – if it is implemented at all – has yet to be considered.
BUG-5671 another demonstration of the important difference between a JIRA being Accepted compared with being implemented. JIRAs can be Accepted for a number of reasons, but does not automatically mean it will be implemented. Reasons JIRAs might be Accepted include: it explain an issue the Lab may want to address at some point; or because it might offer a means to resolve part of a larger issue or group of issues the Lab might want to address, again at some point in the future.
RenderVolumeLODFactor
Mixed with the above discussions (again in text) is a debate on RendeVolumeLODFactor settings, with some viewers (e.g. Firestorm) defaulting to higher values than the official viewer, and the impact this may (or may not have) on content creators.
Certainly, high-end LOD settings are detrimental to viewer performance, but whether enforcing a lower LOD setting would encourage content creators to optimise their designs is questionable: “recommendations” for very high LOD settings (often much higher than the defaults used by any viewer) have been a factor in content creation for a very long time, with some creators even foregoing the use of lower LOD models (so it because an “all or nothing ” approach). As such, a more effective means of preventing this might be to penalise creators who fail to provide proper medium and low LOD versions of their creations, something the Lab is considering.
This conversation (largely in text) continues on to alpha blending / masking, etc.
Designed under the It All Starts With A Smile (IASWAS) banner, Groenland Kangamiut is a new region design by Kaelyn Alecto (TheNewKae). It is based on the physical world township of Kangamiut, located on a small island off the west coat of Greenland in the Davis Strait connecting Baffin Bay with the Labrador Strait.
“With its typical colourful houses, fishing harbour, ice landscapes, frosted atmosphere and the sound of the bitter wind,” Kaelyn says of the design, “We tried to be original and as realistic as possible, while keeping a small part of fantasy of course. Have fun!”
The village sits nestled in the arms of an inlet, almost fjord-like in its deep cut, a single channel of water pointing the way to the open sea – presumably the Davis Strait – to the west. The shops and houses rise up the lower slopes of the inlet in brightly painted tiers, crowned by a red-painted chapel. To the north, the valley wind onwards, its floor lifting above sea-level, snow-covered slopes caught between high shoulders of rock, disappearing in the distance.
The west side of the village is split between a busy group of wharves, warehouses and shops, bordered on either side by houses built out on slits over the water on either side, their large decks suggesting they might be summer holiday homes. On the north side, these give way to the spur line of a railway overlooking the frigid waters, a locomotive just emerging from a tunnel burrowing under the high cliffs behind the village.
Visitors arrive in what might be referred to as the village square – a cobbled surface in which sits a fountain. Snow swirls around the bricks of the pavement and between the painted houses on either side, as several routes of through the village offer themselves for exploration. To the north, the cobbled pavement lead to the busy waterfront. From here, where wooden walkways and stone steps climb the hill to the next level of the village, while a board walk runs along the northern shore to the little railway station.
Closer to the fountain, steps offer a short cut up to where a brick-paved footpath winds up through the houses, eventually reaching the little church up on its high look-out point. South of the landing point, meanwhile, the pavement gives way to a wooded trail. Snow-covered and winding through frosted firs trees to where a camp site looks out over cold, blue-grey waters to a cosy house sitting along on a rocky islets. A red barn-style bridge crosses a narrow stretch of water close by, a further trail on the far bank winding up the hill in an alternate route to the church.
This south path also offers one of the regions little quirks. While wolves reindeer and a polar bear – all common enough to the northern hemisphere – can be seen among the trees and out in the snow; this side of the region also has a little group of penguins sitting on an ice flow, an emperor penguin and her young watching them from the shore. Given their far more southern origins, the presences of these penguins might seem odd, but they are in keeping with the fantasy twists found in IASWAS designs. Equally, their appearance on the southern side of the region seems to be a subtle nod and wink to their more usual domain being the southern latitudes.
What I particularly like about Groenland Kangamiut is the way the east side of the region has been blended with the region surround, rather than leaving a watery gap between region and scenery. For me, blending region and backdrop in this was adds a level of depth to a design, by making them equal partners in a scene, rather than separate entities. This really gives the feel that the village is sitting on the edge of a rugged island, and thus a natural part of a greater whole.
The following notes are taken from the Content Creation User Group meeting, held on Thursday, November 16th, 2017 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.
Medhue Simoni live streamed the meeting, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. Time stamps in the body text will open the video in a separate tab for ease of reference to the relevant parts of the text. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.
Animesh (Animated Mesh)
“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “Animesh”.
Project Summary
The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.
In short, an Animesh object:
Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory (Contents tab of the Build floater) required for it to animate itself.
Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
Can use many existing animations.
However Animated objects will not (initially):
Have an avatar shape associated with them
Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
Use the avatar baking service
Will not support its own attachments in the initial release.
These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).
[0:46-2:53] The proposed scripted mod key capability to allow attachments to be made to No Mo Animesh characters has now been determined to be a much more extensive piece of work than originally thought, and so will not be implemented as a part of the initial Animesh project.
However, the Lab will be tackling it as a project in its own right “some time in the future”.
Remaining Bugs / Remaining Items
[3:32-4:55] The list of remaining bugs/ items to be looked at is summarised as:
A couple of crash bugs in the viewer to be fixed. These are related to switching between the animated and non-animated states with an Animesh object.
Code optimizations need to be completed and the Animesh code in general requires some clean-up.
LOD rendering issues on Animesh objects needs to be fixed.
Animesh imposting needs to be fixed.
Left-clicking on rigged mesh doesn’t work well, and this applies to Animesh objects as well (right-click Touch should work), so needs to be addressed.
Performance analysis needs to be carried out to determine necessary / best adjustments to costs / limitations (LI, tri count, complexity).
[4:56-5:45] Baking service updates: there is a couple of bugs in the baking service Anchor Linden is currently investigating, and which need to be resolved for Animesh. One of these can cause incorrect adjustments to be made to an avatar’s height calculation when an Animesh object is attached.
Any other issues people have noted not already filed via the JIRA (see the link to the JIRA filter, above), should be filed as bug reports ASAP.
Costs and Limits
[7:30-8:25] One of the reasons limits need to be examined is that currently, is that LI calculations are based on an object’s scale, whereas the LOD is effectively based on the rigged scale, potentially allowing the cost of the objects to be gamed between the two. This is in part the reason why the Lab has opted for tri counts being a limit with Animesh. However, Vir would like to get a fix in to prevent this kind of gaming; the problem here being the potential for breaking existing content.
[8:25-9:19] Testing will hopefully allows the cost of Animesh objects to be more defined by their complexity than on a fixed land cost, which will be a much smaller component in the overall limits than currently the case 200 LI), and will likely be a “base” LI based on the impact of the avatar skeleton.
[9:39-10:14] The eventual cost might be a combination of a base land impact and a complexity multiplier, although there are issues here with rigged objects being treated as unrigged when calculating rendering costs, which needs to be addressed.
[10:21-10:52] Vir is wary of making too many changes on impact / cost calculations just for Animesh, as there is a broader project to improve complexity cost calculations in general, which is currently on hold pending the introduction of Animesh.
[41:31-43:28] tri count vs Land Impact: in line with the above, Vir is not convinced that “just letting the Land Impact” determine if an Animesh can be rezzed is viable, as has been suggested. There are sufficient issues with the current avatar complexity calculations that, when fixed, could mean that even if a tri count is discounted as a direct Animesh constraint, avatar models converted to Animesh would still be prohibitively expensive from a complexity standpoint.
[43:47-45:16] As with mesh currently, Animesh will not bypass the accounting system if made temp-on-rez.
[45:23-54:50] More discussion on limits / costs, the need for testing, and on the Lab’s approach to preferring to apply costs over limits and the ability for users to determine what they see (as with avatar complexity / Jellydolls), balanced by a desire to get people to think more in terms of optimising their content. Part of the tension with limits / costs seems to be creators are unwilling to develop content, push at the current (arbitrary limits), etc., out of concern that the effort spent building and testing could be wasted / the Lab is hoping people will build, test (and even break) things (including the viewer) so a more accurate assessment of limits can be made prior to release, with the option of making further adjustments further down the road, if necessary.
[54:53-56:11] Would it be possible to have different tri count limits for worn Animesh vs rezzed Animesh – higher for the former compared to the latter? Possibly, but tricky.
Animesh as a Build Floater Option Discussion
[19:28-40:00] A lengthy discussion on having Animesh a toggle feature in the Build floater, rather than something set on upload, and how that might discourage makers of modifiable avatars from producing “Animesh versions” because users could in theory get a set of suitable scripts and animations and attempt to use them with the versions they already have.
The discussion is lengthy, and involves numerous issues, including the extent to which users trying to convert things themselves over buying a “dedicated” Animesh creation (would scripts and animations intended to animate an elephant really work that well in a tiger, for example?); creators’ rights vs. users’ rights with mod items; the decision process behind making the Animesh option a Build floater tool (e.g. it is in keeping with the permissions system – if an item if modifiable, it should include converting it to Animesh, if appropriate; it could help speed the adoption of Animesh – creators could release kits to convert their existing products, rather than entire new products, etc). The overall consensus appears to be having the option in the Build floater is better than trying to restrict it.
Animesh Sitting
[56:28-56:58] As discussed in past meetings, Animesh bodies will not be able to sit in the same manner as an avatar (by being made a child of the object on which it is sitting). Animesh should be able to adopt a sitting animation it contains, like a ground sit, however). The latter obviously won’t give the same flexibility as the former.
Bakes on Mesh
Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:
The current work to update the baking service to support 1024×1024 textures.
An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.
This work does not include normal or specular map support, as these are not part of the existing baking service.
[11:47-12:55] Again, this is a separate project to Animesh, and neither is contingent upon the other. However, using bakes on mesh with Animesh objects will likely come after any follow-on Animesh project to the current work, as Animesh objects will require some notion of an avatar shape to work with the baking service.
[12:56-14:22] There are no plans at present to offer LSL functions or a script API for bakes on mesh, due to the complexities of the baking service. If such a capability is seen as needed, a feature request JIRA explaining why and the benefits should be submitted.
[16:35-19:12] The goal is to have the baking service work in such a way that creators can use the Appearance floater to assign the use of baked textures to object faces which correctly correspond to the different avatar elements (so for example, an upper body composite texture is correctly applied to the upper body faces on a mesh avatar). Once this has been set, users selecting the clothing layer would then see it correctly applied to their avatar in the same way as clothing layers are applied to the system avatar.
Next Meeting
The next CCUG meeting will be on Thursday, November 30th (week #48), due to week #47 being US Thanksgiving week, and the Lab taking a holiday break on Thursday, November 23rd / Friday November 24th.
The undersea world of Blake Deeps – just a part of all there is to explore in the Hollywood estates and regions north , east and south of Blake Sea.
I’ve been a resident of Hollywood Estates, bordering Blake Sea for getting on for five years now (I think!), and while I’ve covered one or two points of interest around the estates that are open to the public, there is actually a lot to see and enjoy. This being the case, I thought I’d offer an island-hopping guide to some of the places worth a visit, particularly by boat or by air (seaplane perhaps being the best for the latter, or a helicopter with floats!).
For obvious reasons – it being something I’ve been very involved with – I’m going to start at Holly Kai Park. The home of Art at the Park (since 2008), Caitinara Bar (music Wednesdays and Fridays from 16:00 SLT), with a live events area (The Pavilion), nature trails, a permanent exhibition of art from the collection of Nber Medici, co-owner of the Hollywood Estates along with MarkTwain White, bumper boats, kayaks, as well as featuring Seanchai Library, bringing you live stories in Voice every week, Holly Kai Park has a lot to offer visitors.
The docks on the east side of the park offer 2.5 hours of mooring before auto-return kicks in, giving you plenty of time to explore, and re-rezzing of boats (or seaplanes! is possible. This also makes Holly Kai Park a good leaping-off point for travels by water. Head north and then west around Holly Kai Estate, following the waterway, and you’ll eventually come to the Tugby Arena, with matches held every Sunday at 08:00 SLT – find out more by reading my article on matches.
Just south of the Tugby arena is Dutch Harbor. While not strictly part of the Hollywood estates, it is home to Analyse Dean’s magnificent stern wheel paddle steamers. These are truly magnificent vessels, which I blogged about back in 2014. The Dixie Belle has been available for sale since around the middle of 2017 (and I’m overdue an update on the steamers and what’s been happening with them!), and you can walk across to the demo version at Dutch Harbour and try it for yourself.
Juneau Regional Airport offers a chance to explore Blake Passage by air, or to stop off on a trip and hop around the local sights.
If hiking is more your thing, you can head west-north-west from Holly Kai Park to the Columbia River. Although largely residential in nature, the hills above the southern bank of the river offer a hiking route. Marked by boot prints on the ground and yellow tour guide boxes, the trail runs westwards to Columbia Bar, and offers views out over the river valley to the north and the surrounding islands to the south.
Unfortunately, rezzing isn’t available at either end of the trail, but a short hop away by TP, is Juneau Regional Airport, offering rezzing for light aircraft, and a short distance to the north, the Hollywood Estates land office has a boat rezzing area (2 minute auto-return) at the moorings in front of it. From here you can explore the Blake Passage regions by boat. A little further to the north at Skagway, is the headquarters of the Second Life International Folkboat Fleet (SLIFF). With races held every Sunday starting at 07:00 SLT, this is a popular community, and sailing lessons can also be had here for those just getting started. If you don’t fancy walking / teleporting, you can catch the Skagway & White Pass train from the rezzing area outside the front of the airport terminal, and which will transport you to all points north in Blake Passage. You can jump off on passing the Hollywood Estates land office, or at the SLIFF centre at Skagway.
South and west of Holly Kai Park lies the famous Hollywood International Airport. With rezzing for aircraft of any size, and water rezzing for boats, it offers the perfect leaping-off point for exploring Blake Sea itself, the regions to the south, and for travelling east through the islands leading to the community of Second Norway. If flying out of a major airport like Hollywood isn’t to your liking and you have a light aircraft, you might like to try flying out of the grass strip at Foliage Airfield. This is a tight little strip, but one I like using when testing different planes, and it is ideal for single and light twin-engined aircraft and helicopters. Just across the water from Foliage sits the historic Greenhouse, a towering prim structure by Transparent Banshee celebrating a bygone building era of Second Life. The gardens and Greenhouse are both open to visitors.
Head south from Hollywood Airport, and you can find your way to the Honah Lee estate, and in particular Palomar Landing, with moorings for boats, seaplanes and helicopters (5 minute auto-return, re-rezzing permitted). This marks the start of the island circle trail and the trailway to the stars, which allow you to travel on foot or by horseback around the 6-region core of Honah Lee, ride up to the Palomar observatory, and visit the marine nursery. I last rode the trails here in 2013, so some of the article I wrote at the time might be out-of-date, but hopefully it’ll act as a primer for those visiting.
Horseshoe Park is tucked away among the islands east of Blake Sea, but makes for a pleasant stop while sailing
All of this is really just scratching the surface of everything on offer in these regions and the lands surrounding Blake Sea. Those who like sailing / boating might also like to visit Horseshoe Park (30 minute auto-return at the dock), which offers a pleasant break while exploring the surrounding waterways. There’s also the delights of underwater exploration along the regions of Blake Deeps. A good place to start these might be from the historic Freeport Township of Flotsam, and you can read more about it and the merfolk community of Fanci’s deep here and here.
There was not deployment on the Main (SLS) channel on Tuesday, November 14th, leaving servers running simulator version #17.10.06.509394.
On Wednesday, November 15th, the three RC channels should be updated with a new server maintenance package #17.11.11.510664, comprising internal fixes and a user-visible fix for BUG-139176, “Issue with OBJECT_REZZER_KEY reporting incorrectly after linking and delinking prims.”
SL Viewer
There have been no SL viewer updates since the end of week #45, leaving the current viewer pipelines as follows:
Current Release version 5.0.8.329115, dated September 22, promoted October 13 – formerly the “Moonshine” Maintenance RC.
Obsolete platform viewer version 3.7.28.300847, dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7. This viewer will remain available for as long as reasonable, but will not be updated with new features or bug fixes.
Animesh Mod Keys Proposal
One of the major subjects of discussion with Animesh is enabling attachments to be added to existing Animesh objects. In short, many pets and characters are created as No Modify objects, to help protect their capabilities. Thus, as No Mod objects, Animesh characters cannot be accessorized (the owner of an Animesh horse cannot add / remove a saddle from an Animesh horse, for example). As Piscine Mackenzie explains in the forum, with highlights by Medhue Simoni, making Animesh pets / characters Modify opens them to the risk of exploitation.
To this end, the Content Creation User Group has been a focus of discussion on overcoming this problem (see here and here). One proposal for handling the issue, which would also allow for broader capabilities, has been put forward via feature request BUG-139168. However, this could take some time to implement, delaying Animesh.
As an alternative, Vir Linden put forward the idea of a scripted mod key capability which would allow attachments to be linked and unlinked from an Animesh object, and more recently he has expanded on this idea with an outline proposal. This could provide a suitable foundation for allowing Animesh to move forward with a link / unlink capability, allowing further capabilities for a broader range of use cases to be added later.
Vir’s proposal will most likely be a core subject of discussion at the next Content Creation User Group meeting on Thursday, November 14th, 2017.
Breedable Issues
The HTTP updates earlier in 2017 resulted in issues with ABC horses being unable to give birth, which came down to the volume and timing of requests being made by the horses (see BUG-134275). The issue was eventually fixed by the horse maker making some changes in the number and timing of the requests sent by each horse, and by a server-side change in how the requests were authenticated.
However, issues have been noted on some regions breeding Stray Cats. It’s not clear if this a similar issue, or something else. Those experiencing similar issues might want to raise a JIRA so the Lab can investigate and advise whether the creators of their breedable animals need to make an adjustment to their scripting.
Gyro Muggins reads Diana G. Gallagher’s one science-fiction novel.
Bookended by the story of a tourist in England encountering a stranger who tells him part of his story, then gives him a manuscript that tells the rest of his strange tale, Mark Twain’s 1889 novel relates how a Yankee engineer from Connecticut is transported back to the 6th century court of King Arthur. There, he uses his knowledge of engineering and munitions to present himself as a “magician” – earning Merlin’s ire in the process – and becoming Arthur’s trusted “prime minister”.
Now in its fifth year, Seanchai Library presents The Dickens Project for Christmas 2017.
