Having opted to get out on the water recently, and following Indigo Mertel’s suggestion that sailing is one of the best ways to explore SL, this week I set out to navigate the further reaches of Blake Sea and the surrounding regions. Along the way I discovered Second Norway, a group of around 17 regions which celebrate life in Norway, providing both a themed environment for people living there and a wide range of public spaces which can be enjoyed by residents and visitors alike, all of which can be explored by road, water and air.
While not attempting to be a representation of any single place in Norway, Second Norway does include several features from its real-life namesake, and offers up much which is representative of the Norwegian countryside and Norwegian heritage, all of which combine to make it a fascinating visit.
Arriving in Second Norway via Blake Sea
My first encounter with the SL / rl cross-over came on sailing into the main harbour area, which features a recreation of a row of multi-hued buildings on the waterfront in Bergen. This is forms one of the social hubs in the regions, hosting a range of events as well as being within easy reach of a number of nearby attractions.
One of these, on the hill overlooking the quayside and colourful shops, is a replica of the triple nave stave church at Borgund, which is believed to be one of the best-preserved examples of a stave church in Norway, having been originally built some time between 1180 and 1250. The church in Second Norway is the very first build undertaken by Ey Ren, one of the co-founders of the modern Second Norway community, and a leading figure therein along with Mialinn Telling.
It is a fabulous build, and provides a wonderful focal-point for visits and for SL photographers, and appears to be used for special ceremonies such as weddings. The attention to detail, both outside and in is a delight, and I found myself drawn back to it several times during my visit. I love the alter, and the traditional bell structure located outside.
A short walk from the church and bell, shaded by trees, is a memorial installed by residents of Second Norway to remember the 77 people who lost their lives in the terrible events of 22 July 2011, in both Oslo and on the island of Utøya. It is a simple affair, and all the more moving for being so, bearing an inscription of a quote from one of the survivors of that black day.
Just down the hill from the church is another point of historical interest – part of a traditional viking village, a virtual living museum, the long house of which is used to host both events and exhibitions.
The viking village in Second Norway
From here I opted to take to the road to continue my explorations. Second Norway includes a comprehensive road system which goes both overland and underwater, thanks to a tunnel system. A section of the roads is modelled on Norway’s Atlantic Sea Road, and is a great drive to take. I initially started out using my ubiquitous Neuspa, partially because I felt its amphibious capabilities would be useful if I happened to fall off the road into the neighbouring waterways, and partially because some of those involved in Second Norway are into biking, and I wanted to share something of their experience when out on the open road. I did, however, also take my Autoworks 43S GT for a spin (which did encounter a few issues with road section seams).
Please use the page numbers below right to continue reading this article
Thursday October 11th saw a huge response to Oskar Linden’s request for assistance with network optimisation tests, with many people logging-in to Aditi to join is Beta User Group meeting (I actually made it for the first time myself, the time of his meeting is generally a little awkward for me). More were available on the IRC channel established for the test as well.
Oskar’s meeting place at Morris on Aditi.
Things got off to a rocky start; mid-way through the Beta UG meeting everyone received the royal order of the boot, and problems occurred attempting to log back in. It transpired that an SSL certificate had expired at LL’s end and had to be renewed (through until 2015). Even so, not everyone appeared to make it back (or at least, not with their primary accounts!). Maestro Linden did make it back with the rest of us, and immediately sought protection in a state-of-the-art anti-crash system from Ordinal Malaprop* created (or is that crated?). No amount of coaxing could get him out, either:
Darien Caldwell: you can come out of the box now Maestro. Crash is over ;p
Mæstro Linden (maestro.linden): I’ll come out when I feel safe 🙂
People getting back after the crash and finding we have a Maestro Linden-in the-box
The meeting also had some disruption from an unhappy camper or two complaining about bans. One of them made it back following the initial forced log-out, and as final preparations were made for the test, appeared to successfully crash the region. Shortly before this happened, concerns were raised that this individual may have been trying to disrupt the IRC test channel, as they appeared to be passing commands aimed at IRC in local chat (at one point a little later, a similar command appeared in the IRC channel, and I and a number of others were, coincidentally or otherwise, disconnected).
The testing itself proceeded pretty much as planned, with everyone logging-in to a specified region at more-or-less the same time, testing the network capabilities in handling a large number of log-in updates in a single region. From my perspective, this went well, and as one of the initial people to log-in, I didn’t appear to suffer from the kind of lag usually associated with moving around in a region where there are a large number of people arriving.
Following the en-masse arrival, we dispersed to two regions for a group chat load test. I cannot actually say how this went, as I arrived at my designated region, only to take three steps and crash (an issue at my end of the SL equation rather than anything else).
I made it back to participate in the IM tests, which comprised piling-on a mass of IMs to targeted avatars and then awaiting their reply. I think I was one of the first to IM and one of the last to get a reply, Again, not through any failure in the system, but simply because Pey’s Law affected the tester I was IMing – he replied on receiving my first message, but forgot to press ENTER to send :).
The final part of the test was a mass teleport to a specified region, again presumably to test how the network handled a large number of arrivials within a region. While this may have been a placebo effect from being on Aditi, the teleport itself seemed to me to be somewhat faster than is usual, with the progress bar merely flicking up on the screen and then vanishing as I arrived. Once, there I also found walking around with people people teleporting-in also did seem to be as prone to mini-freezes or stutters as can be the case. However, the load on the target region (selected at the last-minute due to problems with the intended destination) may have been lighter than hoped, as it had a cap of 21 on the number of avatars allowed into it, and a number of people did report they were unable to teleport-in as a result (there were probably around 40-50 listed on the IRC chat page).
Pile-on Test Medal
Overall the tests made for a fun social gathering, with a lot of good humour all around, and Oskar and his team apparently gathering the data they wanted.
Hopefully, there will be further follow-up on the overall intent of the tests and the results in an upcoming Sim / Server UG meeting. Oskar certainly appeared pleased with the outcome, and was on the main grid after the tests to hand out medals to the participants (providing they knew the sekrit password! 🙂 ).
* With thanks to DD Ra for pointing this out; I missed checking the creator details earlier.
This item is a follow-on from part one, published earlier this week.
More Server News
At the Thursday Beta Grid User Group meeting (Thursday October 11th), and prior to the network optimisation tests, Oskar gave further news in the serve deploys for week 41. On Tuesday 9th October, the main channel received code previously on BlueSteel, which in keeping with Simon Linden’s comments at the Monday Sim / Server UG meeting, Oskar referred to as being, “A pretty small release, just some server crash mode fixes; stability ++.”
On Wednesday October 10th, BlueSteel and LeTigre received a fix to some database queries that were really slow when accessing really large groups (note these were not Baker Linden’s Group Services code, that is being looked at as a deployment in week 42).
Monday 16th October may see some restarts on the grid in order to shuffle some regions onto new hardware, with the servers having more and faster CPU cores, which will increase the number of simulators running on the new servers, but they’ll be running on faster CPU cores.
Interest Lists and Object Caching
The short-version update for this comes from Andrew Linden, speaking at the Server Group meeting on Friday 12th October, “I thought I’d have something working this week… it isn’t quite working right. You can see it not working on Ahern on Aditi…” (!)
Interest list changes: easing the pain of random rezzing
He went on more seriously to explain that while the new code is working correctly for the most part, and that rezzing orders should be improved / faster, there are some problems with objects which should be in view of an avatar not showing up and a major issue around teleporting into high ground.
When the latter happens, you effectively arrive “underground” (presumably at the default “ground level” for the simulator – 21 metres in the case of unterraformed land). The simulator then calculates where you should be and moves your avatar appropriately. With the new code, this has the effect of breaking the server’s notion of the camera – where it is and what it can see – which is used to figure out what objects to send to the viewer. This means that the camera itself cannot be moved or updated.
There have been some performance tests on an older version of the code, which have been mixed, as Andrew also explained, “here were two performance tests run on an earlier version. One test (mostly empty region with about 30 avatars running around) showed a slight decrease in performance… about 5% worse. Another test (crowd of avatars NOT looking at a pile of dynamic objects behind them) showed about 40% improvement (less time spent running the interest list). So I went back to the code to try to fix the first test, and I think I’ve got something that will be as good or better all around.”
The code will also see changes as to how the camera behaves and in the resultant level of detail. Andrew is currently working on limiting the distance the camera cam be moved away from the avatar. Note this is not limiting Draw Distance, but limiting the distance the camera can be freely moved independently of the avatar. He’s considering 128 metres to be the likely range. There are two reasons for this.One is to prevent the camera wandering into regions which are more than one neighbouring region away, the other is because as the camera moves laterally, detail levels degrade, because object detail is tied to the avatar’s position (hence why, when you zoom a great distance, buildings and objects may only appear to partially rez, etc.). Under the new system, object detail will be tied to the camera, so that little degradation is experienced. However, in order for this to work, the camera must be kept within a reasonable distance of the avatar; if it is moved too far, the detail will start to degrade once more (presumably because of the volume of data the viewer is trying to handle).
Mesh Deformer
On Thursday 11th October at the Open/Dev meeting, Darien Caldwell outlined her ideas for using base shape info exported from Second Life when uploading rigged meshes.
If this works, it will essentially mean that rather than being restricted to using a default base female or male shape when uploading rigged meshes, creators will be able to download a human shape as an XML file (permissions allowing), and then specify this shape when uploading rigged meshes. The basic code for handling the upload with specific avatar shape information has already been added to the deformer by Qarl Fizz, so Darien is focusing on the best way to use it, her work going into a fork of the existing Mesh Defromer project viewer.
Avatar shapes can currently be exported from a viewer via DEVELOP -> AVATAR -> APPEARANCE TO XML (again subject to the permissions system). This saves the avatar shape data as an XML file, which contains the settings from the appearance sliders, and which is automatically saved to your computer (generally to C:\Users[USERNAME]\AppData\Roaming\SecondLife\user_settings for Windows).
To associate an avatar shape .XML file with a mesh, Darien is proposing a further revision to the mesh uploader floater, and has provided an early mock-up as to how it might look.
New option to associate an avatar shape XML file with a mesh on upload (image courtesy of Darien Caldwell)
More work is required the flesh-out this idea, including, as Oz noted at the Open/Dev meeting, making the shape export option more obvious for people to use, which will more than likely see it moved out of the Develop menu, wherein it is currently nested. The .XML file itself is not suitable for use directly in most 3D modelling programmes, so how the exported data might be used with these when creating mesh items remains to be seen. nevertheless, if successful, Darien’s approach may offer a more fine-tuned solution to developing mesh clothing to a range of shapes.
Other items
Viewer and FMOD
The use of FMOD has been the subject of much discussion within the TPV/Dev meetings of late. FMOD is used within the sound system for the Viewer, and until now, Linden Lab has provided a script which pulls library files from an FMOD repository for use in viewer builds. However, following what appears to have been a clean-up of their archives, FMOD have removed the some of the legacy files required for this, as reported in JIRA OPEN-150.
Some viewer developers have already started using FMODex within their builds (e.g Singularity 1.7.0+), which also addresses issues with sound quality as well. Other TPVs are looking at possibly integrating this work into their builds.
It currently appears as though Linden Lab themselves are looking to integrate FMODex, as they see this very much as something which needs to be addressed. Speaking at the TPV/Dev meeting on Friday 5th October, Oz Linden stated: “I got around to forwarding the JIRA on that to our engineering manager for Second Life, and he agreed with me that it is something we should definitely do something about. I’m not sure what the time-table on that will be, it’s going to go into the hopper for the next ‘Things we should do something about, what priority are they compared to all the other things we should do something about’ meeting, which happens weekly.” While openAL has also been suggested as an alternative, it does seem more likely that FMODex will be adopted, something which was hinted at by Oz when talking at the Open/Dev meeting on Thursday 11th October.
Teleport Timeouts
Baker Linden has been looking into the issue of teleport timeouts, and has managed to pin down one cause as a reproducible bug. He’s not sure as to whether it can be fixed, and is currently investigating further as to why it is happening.
Talking to Giant Bomb, Rod Humble has revealed more about the Lab’s upcoming new products, all of which appear set for launch in October.
We already know about Patterns, which is already available in its Genesis Release, and which has had something of a positive response among those in the gaming community who have tried it.
Patterns: generally positive reception to initial Genesis Release
We also know that Creatorverse will also be appearing shortly, and will initially be aimed at the iPad (but is currently still awaiting Apple’s approval), although it appears it will eventually be available for the PC and Mac as well going by comments in the article. The description of a demonstration of Creatorverse given by Humble is somewhat amusing:
Humble loaded up the app, which starts with a white screen. First, he drew a box, colored it in and tried to convince me it was a car. He made a better argument when two circles were underneath it, but when he clicked “play,” everything fell apart. By tapping the left side of the screen and pulling up his toolbox, Humble added joints that merged the “wheels” with the “car,” and gave the wheels a movement ability. Finally, he added a squiggly green line beneath everything, and clicked play again. The car roared to life…and then quickly fell off, tumbling into oblivion.
Probably not the intended result, but it does raise a smile. However, the really interesting part of the news about Creatorverse is in the paragraph which follows:
Each creation can be uploaded into the cloud, and both played and edited by anybody. The goal is to bring some Second Life sensibilities to Creatorverse eventually, too, such as giving users the ability to charge for them. (That can’t happen on iOS, though.) One of the more ambitious toys created by pre-release users was a pinball machine.
So not only would shared creative spaces appear to be a concept being carried forward from SL into their new endeavours by LL, but also the opportunity for users to monetize their creations…
Creatorverse: shared creative space and monetization? (copyright Linden Lab)
Of the remaining two products up for launch, one is Dio, which has been known about in essence, if not in content for a while. It is described as a “room creator, in which players can do everything from construct a choose-your-own adventure to develop an interactive wedding album.” This had been thought to be a product arising from the acquisition of Little Text People earlier this year. However, the fruits of that collaboration would appear to be in the fourth product in the lie-up.
Dio: to appear in October as well
This fourth product is to be called Versu, and is described as a storytelling toolset, in which players assign characters a set of motivations. The characters react to the actions of the player based on these motivations, and the story is procedurally generated. The first release is aimed at murder mystery and romance stories.
The timing of the launches so close to one another is intentional, with Humble hoping that the close proximity of the launches to one another will change people’s perception of Linden Lab, and encourage those who wrote it off as “just the Second Life company” to come back and have another look.
Hopefully, if successful, this may encourage people to take a look at Second Life as well…
Linden Lab are in the process of changing the manner in which network traffic is handled within Second Life, and require assistance in testing the changes made to date in order to ensure various services are functioning correctly prior to rolling-out the changes to the grid as a whole.
To this end, Oskar Linden posted the following request in the Server forum late on Wednesday 10th October:
Linden Lab has made some changes to the way regions handle network traffic. We need your help to test. This will help us insure that regions are communicating appropriately over the network. Mainly we are concerned with agents entering via direct login, teleport, and region crossing. As well as other functions such as IMs, Voice, and Group chat.
Tomorrow, October 11th, at 4PM Pacific time (right after the server beta user group) we will conduct these tests with as many people as we have. Testing will take place on ADITI and require out of world communication we will be coordinating via IRC. This will require an IRC client connected to EFNET in the channel #sltest. If you don’t know how to do that you have until tomorrow afternoon to figure it out. 🙂
Note that Voice is also indicated as one of the services to be tested, but no details on what this will entail have as yet been included in the test notes – please check both the note and Oskar’s forum thread for possible updates on this ahead of testing.
Those wishing to take part in the tests will need to:
Be members of the Second Life Beta in-world group
Be able to log-in to the Aditi beta grid
The tests will be coordinated on IRC using the EFnet channel #sltest, and those involved in the tests will need to be able to access this channel either via the EFnet website or through an IRC client.
Accessing the #sltest channel on the EFnet website – note you do not require a registered account; you can access the channel using any suitable nickname
The main channel today received the same maintenance release made last week to BlueSteel (and which was used to help fix the LeTigre problems). speaking at the Server / Simulator User Group, Simon Linden described the deployment as, “A very minor change … from one of the RCs. It’s really not any functional change but was needed to go grid-wide before another one goes into RC.”
Following week 40’s issues with LeTigre, the three primary Release Candidate channels will be getting updated as follows:
Magnum, which has code to help sims run better on new hardware, will be getting the same change that went to the main channel
BlueSteel and LeTigre will get the same update, which is described as “pretty minor but important”, being a back-end query optimisation designed to assist with database loads.
Currently, the prim accounting issue is still being worked on, which affecting scheduling what will be available in deployments. Passing comment on how deployment packages are put together, Simon explained that, as a rule, bug fixes tend to be put together as far as possible, prior to going to QA and then to an RC channel. He went on to say that what goes into other releases can be variable, “There’s a judgement call on how much gets bundled together, and a bunch of things go into the decision, like how overloaded the QA guys are, how many other things are trying to get to RC, risks of one part blocking it (like now), stuff like that”. In the meantime, LL are actively looking at ways to both prevent a recurrence of this problem and to improve the RC channel deployments as a whole.
SL Viewer
The promised new beta release (3.4.1.265642) reached the release point on Monday October 8th. This release sees tcmalloc disabled once more, but otherwise appears to be the same code as the previous beta. It is intended to be a further stability testing / confirmation release, and as such will remain available for the next couple of days as Linden Lab gather data on its performance.Tcmalloc has been disabled, rather than removed, as it has apparently been useful in helping to trace issues within the viewer code, and LL wished to retain the ability to re-enable it in case they needed to re-enable it to help identify problems within the viewer in future.
Assuming this release proves stable, and assuming that plans outlined by Oz Linden have not undergone significant change, it should clear the way for the unblocking of various code merges that have been awaiting the stability / memory leak issue to be resolved. As previously reported, the precise order in which code merges will be made / released is unclear, but Linden Lab have a significant amount of updates waiting in the wings, including Steam support changes, Monty Linden’s HTTP library updates, Baker Linden’s Group Services project code, Apple OSX Mountain Lion support (including gatekeeper compatibility), and more.
Steam updates – one of the viewer merges waiting to be released
Under the original plans for the beta viewer, project viewer code was to start merging into the viewer with the 3.4.2 release code. As there was no OpenDev meeting on Monday 8th October, it is assumed this is still the case, however, the precise order of the merges is due for discussion this week within the Lab, and a clearer indication of the order may be available by the Thursday OpenDev meeting, and will be given in part 2 of this report, if that is the case.
Group Services Project
Due to the problems experienced with the leTigre deployment in week 40, Baker Linden’s Group Services code did not receive a proper deployment to a Release Channel. It is not due to be released this week, but should be in an RC deployment aimed at week 42, although as it has been bundled with the LeTigre deployment which had problems, this may be delayed further while the prim accounting error is looked into.
It is currently unclear as to whether the delay with the RC roll-out will influence when the Group Service viewer code (currently available in a dedicated project viewer) will be merged into the development / beta branches of the SL viewer code; again more should be known on this following Thursday’s OpenDev meeting.
Materials Processing
Continues to progress, with little to report at this time. The feature set for the initial release still has yet to be published, and the wiki page for materials processing is due for further update. Concerns were raised over one statement relating to the use of colour, to whit:
“Color a solid color for the surface; not used if a Texture is also specified.”
The concern was that whereas it is currently possible to specify both a texture and a colour for a given object or object face, the wiki implies that under material processing, it will become either / or. However, this appears to be an error in the wiki, and both options will remain available.
Linkability Bug
As reported in my last update, and while not strictly a project, the bug which is currently allowing prims to be linked over distances greater than 54m has been investigated, and a fix is expected to be rolled-out to the RC channels for this in week 42.
Inara Pey: Living in a Modemworld 