2018 SL project updates 21/2: Content Creator User Group

La Clef des Champs; Inara Pey, May 2018, on FlickrLa Clef des Champsblog post

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, May 24th, 2018 at 13:00 SLT.  These meetings are chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

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.

Current Status

  • Work is continuing on moving towards a main (Agni) grid deployment of the server-side code to support Animesh.
  • Everything has been through QA, and there is a remaining issue with validating attachments. This is liable to require an additional fix.
  • It is likely that the simulator code will initially be deployed grid-wide on the beta (Aditi) grid for a shakedown period, prior to starting its deployment to the main grid through the usual process of RC deployments ahead of a full deployment.
  • There are still a number of issues that are TBD within the viewer:
    • Broken Rotations Issue: two potentially related problems.
      • In one (BUG-139251), when some static mesh objects are converted to Animesh, the visual mesh is rotated through 90 degrees when seen in the Animesh viewer, but the physics mesh isn’t, leaving it perpendicular to the model. This is possibly an orientation issue, with the viewer expecting the mesh to be aligned to +x=forward – which not all mesh modelling tools follow.
      • The second problem is that when linking a series of objects into a single Animesh, visually located where the avatar skeleton supporting it is located, but the physics shapes remain in the original location of the objects prior to linking / converting.
      • What is to be done about this still hasn’t been determined, although the Lab has been playing with playing the physics shape in the root of the object.
    • Rigged Mesh Level of Detail / Bounding Box Issues: (BUG-214736) – Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box. Graham linden has been working on some fixes for this which should improve accuracy and performance, but further work may be required. Once this has happened, there will be a further update to the project viewer.

Additional Animesh Discussions

  • Animesh Complexity: there is a further update to come to the Animesh complexity values (Advanced menu > Performance Tools > Show Avatar Complexity – applies to both avatars and Animesh objects in the project viewer). This should fix some inconsistencies in the reported values.
  • Animesh updated limits and cost formulas discussions:
    • Land Impact: streaming cost: some have questioned with some question with the 50% bounding on LODs could be more stringent. Vir’s view is that 50% is sufficient to allow for a broad range of capabilities among creators, and being more stringent could simply result in a greater addition to land impact, which could affect the use of Animesh. There is an argument that some models require 75% bounding between the high and medium models.
    • Triangle count limit: There have been requests for further changes to the triangle count limit (e.g. allowing land owners to somehow be able to change it). As the limit was raised to 100,000, it is unlikely to be changed again before Animesh is deployed, and the idea of land owners being able to adjust it is seen as potentially in inconsistencies in how Animesh works in different locations. If it is seen that there is a need to raise the tri count limit, it will be done globally.
    • Avatar attachments: due to performance concerns, the limit of only one Animesh attachment to an avatar at any given time is not going to be changed ahead of Animesh deployment, but might be revisited in the future.
  • Animesh ignores SL scale settings:  this is a result of how rigged meshes are handled – scaling doesn’t matter for worn mesh items, as other mechanisms are available for avatar scaling (e.g. the shape sliders, etc.). As these mechanisms aren’t available for Animesh in the initial release (e.g. there is no actual body shape associated with Animesh objects, ergo, no sliders), scaling is dependent upon custom joint positions.
    • Including more capabilities, such as possibly associating a body shape with an Animesh object, is seen as being a follow-on project to come some time after the initial release.

Bakes On Mesh

Project Summary

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.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Resources

Additional Bake Channels

Anchor Linden is continuing to work on adding five further channels to the Bake Service (left arm, left foot + three additional “general purpose” channels to be defined and used as required by creators) and the associated tattoo layer UI support to the viewer to allow them to be used.

This is a three-way set of updates, requiring changes to the appearance service, the simulator and the viewer. This, combined with concerns over maintaining backwards compatibility in the appearance service means that getting the work to a testable state is taking a little longer to achieve.

In the meantime, the changes to the appearance service seem to have caused a glitch which can make some avatars appear to be wear “black skirts” when seen on the Animesh test regions Aditi. This will hopefully be corrected soon.

In Brief

Transparency shadow casting from rigged items: there is an issue with rigged / static meshes using transparencies (blended or masked), which causes shadows cast by them to render incorrectly (shadow rendering conforms only to the geometry silhouette).

Graham Linden is now looking at the issue, however, the release of Animesh is not contingency on the basis of any fix, which will probably be part of the ongoing rendering updates Graham is working on.

Rigged / static meshes using transparencies (blended or masked) tend to cast an incorrect shadow

Imposter Clipping: imposter avatars can appear “clipped”. This appears to be related to the problem of not having a good real-time bounding box associated with rigged meshes (which can result in some meshes appearing clipped as well). This is being looked at, and the hope is that if a better means of defining the bounding box for rigged meshes can be found, it will resolve the importer issue. However, the release of things like Animesh are again not contingent on a fix for this issue being implemented.

 

Advertisements

2018 SL project updates 21/1: Simulator User Group meeting

The Shire; Inara Pey, May 2018, on FlickrThe Shireblog post

It’s a quiet start to the week.

Server Deployments for week #21

There are no server deployments planned for week #21! To quote Mazidox Linden in the server deployment thread:

Hey everyone! We’ve got a bunch of things we’re still testing this week and don’t have any rolls for any channels (Second Life Server, RC Bluesteel, RC LeTigre, RC Magnum, or RC Cruller), and we don’t anticipate any rolling restarts. We’re aiming to have at least one new server version through testing by next week, and hopefully we’ll have a better view of that by Thursday. If you’re interested please join us at the SBUG meeting on Aditi.

RC Cruller is likely one of the smaller RC selections (like Snack and Cake), and is apparently named for the small cake made of rich dough twisted or curled and fried in deep fat (I can feel my arteries hardening just typing that!).

SL Viewer

The Ouzo Maintenance viewer, version 5.1.4.515016, was promoted to the de facto release viewer in week #20. As a result:

  • The Love Me Render RC viewer containing rendering fixes and improvements updated to version 5.1.5.515528 on May 22nd, 2018.
  • A new Maintenance RC viewer, code-named Pálinka, after the traditional fruit brandy popular in Central Europe, was release on May 21st, 2018. Maintenance RC 5.1.5.515527 contains some 36 fixes and improvements, as specified in the release notes.

Outside of these updates, the viewer pipelines are as follows:

  • Current Release version 5.1.4.515016, dated May 7, promoted May 16 – formerly the Ouzo Release Candidate.
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

2018 SL project updates 20/2: Content Creator User Group w/audio

Bay of Dreams; Inara Pey, April 2018, on FlickrBay of Dreams – Blog post

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, May 17th, 2018 at 13:00 SLT.  The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Audio extracts from the meeting are included, where relevant. Please note, however, that Vir’s microphone occasionally seemed to cut out while I was recording, so some of his comments may sound a little choppy.

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.

Project Viewer

The Animesh project viewer was updated on Tuesday, May 15th to version 5.1.4.515420. This update comprises:

  • Bug fixes, including improved handling of animation notifications which should result in fewer cases of animations failing to display for some Animesh objects.
  • New checks on when a skeleton is needed for a nominally Animesh object  – now one should be present only when the linkset contains at least one rigged mesh, and this should update correctly when link/unlink operations take place, or other state changes.
  • The ARC calculations for animesh objects has also been updated based on some feedback with the previous build.

Alongside of this there has been a simulator update in support of some of the changes in the viewer (e.g. with regard to animation notifications and updates). Also, to help with persistent across things like region crossings and region restarts, animation information is now stored in the state of the Animesh object itself, when it gets serialised. However, there are reports the animation data is lost on a SHIFT-copy action.

Server-Side Work

As well as the simulator updates for Animesh mentioned above, the Lab is continuing with QA work on server-side support for Animesh to prepare it for deployment to the main (Agni) grid. However, no ETA as yet for the server-side code.

Remaining Major Issues

Rigged Mesh Level of Detail / Bounding Box Issues:This has been the subject of several recent CCUG report in these pages, and is the subject of BUG-214736. Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box. For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily.

Investigations had led to questions in the Lab of how to get things to behave correctly while recognising there may be broader performance issue that need to be addressed. So Graham Linden has been trying to make sense of what might be pulled into the current Animesh project to improve things and what might require a deeper dive into performance in general as a separate piece of work. So at present this remains in the category of “to be determined” in terms of moving to making Animesh available on the main grid.

Joint Offset Constraints: It’s been noted that setting (deliberately or accidentally) a bad joint offset with something like the mPelvis bound can result in undesired results (the cited example is an Animesh test bear on Aditi appearing to stand 75 metres off the ground when not animating). This has led the Lab to consider constraining he distance a joint can be offset to no more than 5 metres for Animesh objects. However, as this is recognised that doing so could break existing content, a more elaborate solution is still being investigated by the Lab.

Adjacent Regions and Animesh Animations: There is an issue where Animesh objects in adjacent regions fail to animate from a avatar’s perspective when someone logs-in. This is thought to be a handshaking / viewer update issue. Essentially, it can take up to a minute for adjacent regions to understand an agent (avatar) in another region can “see” objects within it, and needs to start sending animation updates to the viewer controlling that avatar.

90-degree Rotation Issue: It’s been noted that when converting some static mesh objects to Animesh, the visual mesh appears rotated through 90 degrees when seen in the Animesh viewer. However, the physics mesh doesn’t have the same rotation applied, leaving it perpendicular to the visible mesh – see BUG-139251.

This appears to be related to the fact that the viewer expects the mesh to be aligned to +x=forward – whereas mesh creation tools such as Blender and Maya don’t – by default – use the same orientation. As the issue only affects some mesh (and in theory could be corrected by setting the required rotation in mesh building tools), Vir asked the question if this is something that should be addressed in the viewer.

  • If this issue isn’t addressed in the viewer (which is where it manifests), it potentially means a good proportion of existing content which might otherwise be converted to Animesh will exhibit the same issue when associated with an avatar skeleton, possibly eliminating it from use as Animesh.
  • If the issue is to be addressed in the viewer, the problem is how to apply the logic to ensure mesh items which don’t exhibit the physics rotation issue don’t end up exhibiting the issue as a result of the fix being incorrectly applied.

Z-Axis offset un the Mesh Uploader: This currently doesn’t work when a  skeleton is applied to a mesh object.

Bakes On Mesh

Project Summary

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.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Resources

Additional Bake Channels

Anchor Linden is investigating adding further channels to the Bake Service in addition to those recently added, again specifically for use with Bakes on Meshes (they will not work with the system avatar). These will hopefully comprise:

  • Separate channels for the left arm and left (currently these are mirrored from the avatar’s right side) to allow for asymmetrical avatar options.
  • Three additional “general purpose” channels to be defined and used as required by creators.

These channels will eventually be surfaced as tattoo layers in the viewer, which will have an updated UI for creating new layers.

Injecting Texture Information into the Bake Stack

There has been a request to allow applier creators to use a scripted means to “inject” textures into the Bake Service via a script (see BUG-216137).

It has arisen out of concern that Bakes on Mesh a) won’t offer the same ease-of-use as HUD-based appliers many users are familiar with; b) it could make the majority of existing applier systems obsolete as mesh head / body creators move towards less complex “onion layer” designs, requiring applier makers to completely re-work all of their existing clothing options. Offering a means to provide Bakes on Mesh with a similar capability as applier systems and allow applier makers to more easily update their existing systems. However:

  • The proposed solution is a non-starter, as the Outfit system on which the Bake Service relies, has no notion of textures. Thus, offering a means to “inject” textures into the bake stack essentially creates a separate (and potentially conflicting) representation of the bake stack.
  • If it is seen that a more applier-like approach to Bakes on Mesh, any solution will form part of a follow-up project, rather than being part of the initial implementation.

 

2018 SL project updates 20/1: Simulator User Group meeting

The Apothecary; Inara Pey, April 2018, on FlickrThe Apothecaryblog post

Server Deployments

As always, please refer to the server deployment thread for the latest updates.

  • On Tuesday, May 15th, the Main (SLS) channel received server maintenance package 18#18.05.07.515224, which includes two new LSL functions: llRequestUserKey and llName2Key –  see below for more.
  • On Wednesday, May 16th, the Release Candidate channels were currently marked as TBD at the time of writing. However, during the Simulator User Group meeting on Tuesday, May 15th, Rider Linden indicated there would be two RC deployments:
    • The BlueSteel and LeTigre deployment should comprise internal fixes, together with simulator-side updates for better management of estate level ban lists – although these will require a viewer update to be visible.
    • The Magnum RC update should comprise the same internal fixes, together with the simulator-side updates for abuse report categories.

llRequestUserKey and llName2Key

llRequestUserKey and llNameToKey, both of which will be across all RC channels following the Wednesday deployment, are in connection with the upcoming return of Last Names (see this blog post and this blog post for more). These functions can be summarised as:

  • llRequestUserKey:
    • Requests the Agent ID for the agent identified by name from the dataserver. The name given may be either the current name of an avatar or a historical name that has been used in the past. If no agent can be found with the supplied name this function returns the value NULL_KEY.
    • It returns a handle (a key) that can be used to identify the request when the dataserver event is raised.
    • Note that agent being searched for with this function does not need to be signed on to Second Life.
    • See the llRequestRequestUserKey wiki page for more.
  • llName2Key:
    • Returns a key the Agent ID for the named agent in the region. If there is no agent with the specified name currently signed onto the region, this function returns the value NULL_KEY. Names are always provided in the form “First[ Last]” or “first[.last]” (first name with an optional last name.)
    • If the last name is omitted a last name of “Resident” is assumed. Case is not considered when resolving agent names.
    • Uses a different mechanism to look up agent information to the older llKey2Name().
    • See the llName2Key wiki page for more.

Abuse Report Category Capability

As I’ve noted in my TPV Developer meeting updates, a new capability is being introduced that will allow the viewer to call abuse report categories from the simulator, rather than having them hard-cored into the viewer itself. This will help ensure abuse reports are filed using valid AR categories, while at the same time making it easier for the Lab to maintain the AR categories.

The deployment to the Magnum RC is the first phase of this work to be made to the grid. Once the simulator changes are available grid-wide, a viewer with the new capability should be made available, with a request that TPVs adopt the updates as soon as they can in their own release cycles.

SL Viewer

The Ouzo Maintenance viewer has updated to version 5.1.4.515016 (dated May 7th, but the update wasn’t listed in the Alternate Viewers page until week #20).

The Animesh viewer updated to version 5.1.4.515420 on May 15th.

The rest of the viewer pipelines remain as:

  • Current Release version 5.1.3.513644, dated March 27, promoted April 13 – formerly the media update RC.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Other Items

Mesh Pivot Points and the Uploader

A long-time problem with the mesh uploader is that it ignores pivot points set within tools like Blender when a model is uploaded to SL. This means, for example, that doors set with a pivot point in Blender won’t work using that pivot when uploaded to SL. A feature request to enable the uploader to recognised pre-set pivot points in mesh objects was raised in 2015 – see BUG-37617 –  and more recently, Beq Janus has been looking to add further information to it.

Region Crossing Updates

Code to improve communications during region crossings went grid-wide in week #19. A further round of simulator-side updates is likely to be deployed in the next few weeks. In the meantime, Joe Magarac (animats) believes most of the minor issues relating to “partial unsits” can be handled with changes to scripting / the viewer – see BUG-214653. He’s offered to rally support to help the Lab dig more deeply into this issue, by arrange group tests, etc., if the Lab can made simulator-side changes to help improve things.

Three major issues for vehicles are No Script parcels / regions, ban lines and scripted security systems. The  former can be harder to deal with, as there is no advanced warning that scripts are disabled until the boundary is crossed. Scripted security systems tend to provide some warning which can generally allow those straying into a private area time to get out (unless the delay time has been set ridiculously short). Ban lines are somewhat insidious, however, as they can physically “snag” a vehicle whilst ejecting the occupants – with the vehicle often remaining in place with no auto-return.

There has been a feature request to handle ban lines better (BUG-216276), with another request for ban-lines to “deflect” vehicles, rather than allowing vehicle to cross them and becoming snagged when the occupants are ejected. It’s not clear if the Lab will adopt these ideas.

2018 SL project updates 19/2: TPVD meeting

Maison de L’amitie: Salar de Uyuni – blog post

The following notes are taken from the TPV Developer meeting held on Friday, May 11th 2018. A video of the meeting is embedded below, my thanks as always to North for recording and providing it.

This was another short meeting – around 30 minutes, with about half of that covering SL projects, which are noted below. The rest of the meeting was more general conversation, and I’ll leave it to the video to cover them. As always, time stamps in the text below will jump you to the relevant points in the video.

SL Viewer

There have been no updates to the current crop of official viewers during week #19. This leaves the pipelines as:

  • Current Release version 5.1.3.513644, dated March 27th, promoted April 13th – formerly the media update RC.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17th, 2017 and promoted to release status 29 November – 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. This viewer will remain available for as long as reasonable, but will not be updated with new features or bug fixes.

[1:53 -2:45] Currently, the Ouzo Maintenance RC has a slightly lower crash rate than the Love Me Render RC, and so at this point in time looks like the more likely of the two to gain promotion to de facto release status.

Forthcoming Updates

[2:46-3:28] There are a number of viewer-visible updates which will be surfacing in upcoming viewers in the near future. These include (and in no particular order):

  • Updates to the estate management tools for better management and update of ban lists, etc.
  • Changes to viewer texture caching.
  • Further SL Voice improvements.
  • [24:43-25:39] New capability for abuse reports to be called from the simulator by the viewer, rather than being hard-coded into the viewer. This work had some delays while the AR categories were translated into other languages for display by the viewer. However both the simulator and viewer updates are now progressing
  • [30:45-31:35] New capability for receiving off-line IMs to avoid loss of IMs on logging-in. This capability is also now in testing.

GDPR and the Viewer

[5:25-7:17] The Lab recently offered an initial blog post on the upcoming European Union General Data Protection Regulation (GDPR – also see my blog post on the subject as well). Subject to further updates on the matter from the Lab, it would appear that the view being taken that data gathered by the viewer which is used in-world will not be subject to any requirements defined by the GDPR. A benefit the Lab has had in terms of GDPR compliance, is that the company has never viewed users’ personal data as a potential asset for revenue generation.

Other Items in Brief

  • [8:03-10:35] Texture Copying: There have been requests for the Lab to make texture copying “harder”. Given that texture data is held on a local computer, and UUIDs are trivial to capture, and the data they point to can also be obtained, this is no easy task. The Lab therefore finds itself caught between trying to offer better protection for textures and risking giving the impression they can prevent all texture copying, although they do look at ways to at least deter it.
  • [11:18-12:42 (mainly text chat) and 14:28-16:50 (with text chat)] Parcel Banning and Object Information: there appears to have been a recent change that means if an individual is banned from a region, they no longer receive information about objects on that parcel. The change, if made, may have been with good intent but is possibly having unwanted side effects. A JIRA is to be raised on the issue.
  • [12:43-14:20] BUG-216032: A recent back-end security change made to PRIM_MEDIA_CURRENT_URL reportedly broke a lot of content. Following initial complaints, the Lab offered to help those experiencing problems as a result of the change if they got in contact with the Lab. Some are reportedly still having issues, however, the Lab do not appear to have been contacted for assistance. so if assistance is required – contact Oz Linden.

2018 SL project updates 19/1: Simulator User Group meeting

Luane's World; Inara Pey, April 2018, on FlickrLuane’s Worldblog post

The following notes have been taken from the Simulator User Group, held on Tuesday, May 1st, 2018.

Server Deployments

As always, please refer to the server deployment thread for the latest updates.

  • On Tuesday, May 8th, the Main (SLS) channel received server maintenance package 18#18.04.30.515008, which includes updates to simulator communication protocols aimed at improving region crossings and teleports.
  • On Wednesday, May 9th, all three main RC channels should receive server maintenance package 18#18.05.07.515224, which includes two new LSL functions: llRequestUserKey and llName2Key –  see below for more.

Region Crossing Updates

Commenting on the region crossing updates, Simon Linden revealed he’d be out of the office for next week, but:

After I’m back I expect to continue region crossing work … the servers are now doing a better job tracking all the attachments and objects you may be sitting on. The goal is to know when the region thinks that’s all done, and the viewer acknowledges it. If that doesn’t happen, it can do better fixing it.

llRequestUserKey and llName2Key

llRequestUserKey and llNameToKey, both of which will be across all RC channels following the Wednesday deployment, are in connection with the upcoming return of Last Names (see this blog post and this blog post for more). These functions can be summarised as:

  • llRequestUserKey:
    • Requests the Agent ID for the agent identified by name from the dataserver. The name given may be either the current name of an avatar or a historical name that has been used in the past. If no agent can be found with the supplied name this function returns the value NULL_KEY.
    • It returns a handle (a key) that can be used to identify the request when the dataserver event is raised.
    • Note that agent being searched for with this function does not need to be signed on to Second Life.
    • See the llRequestRequestUserKey wiki page for more.
  • llName2Key:
    • Returns a key the Agent ID for the named agent in the region. If there is no agent with the specified name currently signed onto the region, this function returns the value NULL_KEY. Names are always provided in the form “First[ Last]” or “first[.last]” (first name with an optional last name.)
    • If the last name is omitted a last name of “Resident” is assumed. Case is not considered when resolving agent names.
    • Uses a different mechanism to look up agent information to the older llKey2Name().
    • See the llName2Key wiki page for more.

SL Viewer

There have been no SL viewer updates for the start of the week, leaving the current pipeline as:

  • Current Release version 5.1.3.513644, dated March 27, promoted April 13 – formerly the media update RC.
  • Release channel cohorts:
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Other Items

Region Restarts and Server Moves

Once upon a time, the Lab used to put effort into trying to ensure adjacent regions in the same server or nearby server. This was most notably done through server re-balancing exercises (see my notes on one of them here, for example), carried out a couple of times a year and which could take some 6 weeks to complete. These operations generally required additional restarts for the regions being moved, and were thought to bring improvements to teleports and physical region crossings.

With hardware and infrastructure improvements over the years, coupled with other sets taken to improve overall grid performance, these operations are no longer carried out – although efforts are taken to ensure multi-region events are placed on simulators all located on the same or adjacent servers. However, nowadays, for the majority of region, they are moved purely as a part of the weekly rolling restarts.

Those wishing to know which regions might be sharing a server with their own can use Tyche Shepherd’s Grid Survey (use the region search and then click the region name link in the results). However, keep in mind not all the result may be up-to-date.

Next Meeting

As noted above, Simon Linden, who usually leads the Simulator User Group meeting will be out of the office in week #20. However, the meeting for the week will still go ahead as scheduled.