SL projects week 46/1: server, projects and general news

Server Deployments – Week 46

Deployments for the week are progressing as planned.

Main Channel

The main channel received the code which had been running on the Magnum RC channel as well as some updates.

This now means that the server-side Group Services code to improve the loading and editing of very large groups (10K+ members) is active right across the main grid – see the section on Group Services below for further information.

This roll-out restored functionality within the Estate Tools which allows region physics to be put in a condition of limited functionality, which is sometimes useful in dealing with issues and problems within a region. The capability was disabled around the time of the mesh roll-out, and has now been restored with this release. This caused some minor inconvenience on some regions (at least one), where the option has been enabled at some point, with the result that following their restart, objects within the region(s) were not functioning correctly. However, this was corrected without major incident.

Main channel release notes.

Release Candidates

Wednesday 13th November will see all three Release Candidate channel receive the same update package, including the BUG-166 update, which means that linksets with bounding boxes larger than 64m (in any dimension) are prevented from being rezzed if doing so will cause the object to collide with an avatar excluding the object owner.

Release notes:  Magnum, BlueSteel, LeTirgre.

Week 47 Deployments and Christmas Run-up

There will be no server roll-outs in week 47 (week commencing Monday 19th November) due to the forthcoming Thanksgiving weekend in the United States. There will be deployments between Thanksgiving and Christmas, but it currently looks as if these may be limited to a couple of weeks during that period according to Simon Linden (details on the likely number pending), and there will as usual be no releases over the Christmas / New Year period.

Interest List and Object Caching

Andrew Linden reports that the first phase of this work is drawing to a conclusion, and he is planning on having a possible demonstration of the capability on the beta (Aditi) grid on Thursday 15th November, most likely during the Bet Server User Group meeting.

The focus of this project is to optimise the data being sent to the viewer, information already cached on the viewer and the manner in which that data is used in order to ensure it is used more efficiently so that things rez both faster and in a more orderly manner than is currently the case.

Interest lists and object rezzing: initial srver code updates almost ready

Andrew reports that general performance on object rezzing should be improved, although the overall sorting element of the code (ensuring objects closer to an avatar’s camera position rez sooner than those further away) isn’t currently as rigorous as it could be. However, the server and viewer do now interact better, so less information is sent to the viewer relating to in-world items which are not visible within the current camera view for the viewer.

Commenting on demonstrating the capability when speaking at the Simulator User Group meeting on Tuesday 13th November, Andrew acknowledged that it may be difficult to achieve on Aditi, which is a relatively static environment (improvements will hopefully be more noticeable on regions where there is a lot of movement and activity); however, anyone interested in this work may want to try attending the Beta Server Group meeting on the 15th November, in case a demo is provided.

Currently, this represents the fist pass in Interest list improvements, and one which is liable to be heading to an RC channel in the near future – it does not require any specific viewer updates to work -, and Andrew expects to be building on this work in the future.

Group Services

As mentioned above, Baker Linden’s Group Services HTTP code is now available across the main grid. As there was some confusion evidenced on Plurk yesterday, here’s a quick re-cap on what this means:

  • The new code allows for improved loading of membership lists of very large groups, together with improved reliability in editing such groups (i.e. assigning roles, removing people, etc.), by the group moderators
  • The code requires a viewer update. At the time of writing, this is available with the official Second Life beta viewer (3.4.2.266708+), and the code will be filtering into the majority of popular TPVs as they update (and currently appears to be available in Zen (3.4.2.2+) and Niran’s Viewer (2.0.3.2262+) and Cool VL (1.26.4.38), all of which successfully loaded large group lists for me)
  • Until such time as the viewer-side code has been incorporated into TPVs, the “old” method of loading group lists into the viewer will still be available. However, viewers using the “old” method (a protocol referred to as UDP) will have group loading capped at 10K members. This means:
    • That for groups with 10K or fewer members, there will be no change regardless as to whether the viewer is using HTTP or UDP
    • But for groups large than 10K, viewers running the UDP code will be unable to load the group until such time as they have been updated to the new code
  • The code will not lead to any improvements in group chat reliability, and is not aimed at improving group chat.

Materials Processing and Avatar Baking

No news on either of these, beyond what has been previously reported in these pages. Materials processing has a test region on Aditi, but there is no timeline on when a project viewer is to be made available. For an overview of the initial capabilities for material processing, please see my project update here, and remember that the capabilities will be applicable to prims and mesh, but not directly to avatars or system layer clothing.

Avatar Baking is progressing, but without any significant update at this time, please refer to my last detailed update on this project for information.

Mesh Importer Fix

JIRA SH-3055 records a  problem with the official viewer’s mesh uploader which has been affecting people over the course of the year. The fix for this, released as a project viewer (3.4.2.266471, available for Windows, Linux and Mac OS) on November 5th, is still available for those experiencing uploader issues, although it is in the pipeline to be merged with the beta viewer now that crash issues seem to have been resolved. Bear in mind that – as Runitai states in his JIRA comment, the viewer is a pre-beat project version, and may include other bugs and problems. While reports on the JIRA seem to point to it being relatively stable, caution should still be taken if attempting to use it as a primary viewer.

Related Links

SL project news week 45/2: server news, viewer updates Steaming ahead, and surprises

Week 45 Deployments

The deployments schedule for this week (Tuesday 6th and Wednesday 7th November) went ahead as planned, namely:

  • Tuesday 6th: the Main Channel received get the code currently running on BlueSteel and LeTigre – release notes
  • Wedneday 7th:
    • Magnum received get fixes and updates to the code currently running there (including the Group Services code) – release notes
    • LeTigre and BlueSteel should get the next bug fix server in the pipeline, which includes the code currently on Magnum, and more – release notes (BS) and release notes (LT)

The main channel deployment now means that all regions are running on the same version of Havok with the exception of Magnum regions, which should be getting the update in week 46 (see below).

LeTigre and BlueSteel both have an additional “feature”: Linksets which have bounding boxes larger than 64m (in any dimension) are prevented from being rezzed if rezzing would cause the object to collide with an avatar excluding the object owner (BUG-166).

In addition, both LeTigre and BlueSteel include the following oft-requested bug fixes:

  • Script Time in the Statistics Bar now correctly shows 0ms when scripts are disabled in the sim (BUG-311)
  • Script error messages now include information about the object’s root prim, when certain operations fail due to the object’s pathfinding setting (PATHBUG-198).

A crash bug was also found in the Magnum code, and this has received attention, with the fix due to go out next week.

Week 46 Deployments

Things are gradually slowing down in preparation for the Thanksgiving code release freeze which will see a suspension of code deployments during the Thanksgiving week later in November. As it stands, the following roll-outs are planned for week 46 (week commencing Monday 12th November):

  • Main channel: should receive the code currently running on Magnum (including Baker Linden’s Group Services code – see later in this article)
  • Magnum: should receive the code currently running on BlueSteel and LeTigre, which will mean the entire main grid is now running the same version of Havok
  • BlueSteel, LeTigre and Magnum should also get the same additional updates (details yet to be specified).

Beta Viewer Update – Steaming Ahead with Project Code Merges

As indicated in Part 1 of this report, the crash issues impacting the beta viewer code have been resolved, and LL have been engaged in merging-up code into the beta and paving the way for the first of the 3.4.2 beta releases. These were always intended to have the code from some of the major SL projects which impacted the viewer, including Baker Linden’s Group Services code and Monty Linden’s HTTP texture fetch code.

The first 3.4.2 beta viewer was release on Thursday 8th November (3.4.2.266708), which includes a range of updates from the Lab as well as a number of contributed updates and improvements (see the release notes), although precisely which of the LL project elements are in the release isn’t obvious from the release notes themselves – the removal of JIRA numbers from the release note entries makes identifying updates, features and fixes that much harder, even though the JIRA items themselves are still open for public viewing.

One element that is clearly in the latest beta viewer release is the code for the steam link-up, as evidenced by the arrival of the new splash screen which I first reported on back in August 2012 – complete with a promotional piece for the Lab’s Pattern’s game.

Continue reading “SL project news week 45/2: server news, viewer updates Steaming ahead, and surprises”

SL project news week 43/2: SL viewer, mesh, and materials processing

SL Viewer News

Things are not looking good on the official viewer front. As previously reported, the crash rate for the 3.4.1.265898 beta release was unacceptably high when compared with the current release version.

A new beta candidate  – 3.4.1.266073 – was released late on Monday 20th October. As per usual, it will remain on the beta channel for a couple of days once released in order for LL to get a read on performance and crash rates. Some regression testing has started, with the beta code merged back to the viewer-development pipe, but work is really pending on confirming the beta code is relatively stable.

In the meantime, feature changes to the official viewer remain frozen, and even should the new beta release prove stable enough, it is going to take some time for LL to prioritize all of the pending updates (both their own project work such as the Steam updates, HTTP project, Group Services, etc., and contributed updates), start merging them into the code, testing them, and then releasing updates once more.

With regards to overall viewer stability, A series of crash fixes from Firestorm (officially viewed by Linden Lab as the most stable viewer connecting to SL) have been contributed to LL and are awaiting regression testing in order to confirm their effectiveness with the LL code.

Mesh Deformer

A new version of the Mesh Deformer project viewer appeared over the weekend – 3.4.1.266081, dated October 20th. This has the revisions Darien Caldwell has made to the uploader and custom shapes, although she is still waiting on feedback from Qarl on the matter of the sliders / bone armatures which are deformed by both the viewer and the deformer, as mentioned in part 2 of my week 42 update.

The new version should hopefully include a small bug fix when selecting the Default Male shape (which would act as if the Default female shape were selected).

Materials Processing

Materials processing: using a normal and diffuse (texture) map to generate a 3D effect on an in-world wall – coming to SL in the near future

Speaking at the OpenDev meeting on Monday 22nd October, Oz Linden indicated that the specification for the revised build floater in the viewer – needed to handle picking, rotating and offsetting normal and specular maps in the same way as can be done with textures (diffuse maps) at present.

The specification for the floater has been written in-house at LL, but the work is being undertaken for LL by a third-party viewer developer who volunteered to carry out the required work on LL’s behalf. This work will initially focus on getting a shell for the floater built, as there are a number of things that are being worked on within the viewer with regards to making parameters actually visible on surfaces.

Discussing progress at the Content Creation Improvement Informal User Group on Tuesday 23rd October, Geenz Spad outlined some more of the upcoming capabilities, as defined by the initial release specification document.

“We have normal maps with specular exponent stored in their alpha channel, specular maps will have environment masks stored in their alpha channel [so, for example, mesh won’t require seperate faces in order to have different levels of shininess on different parts of it], and for diffuse maps you’ll be able to select to some limited degree what its alpha represents (currently, none, alpha blending, alpha masking, and emissive mask).” He went on, “There’s a few additional knobs people will be able to mess with as well, such as specular exponent (combines with the normal map’s exponent map in its alpha), specular color (combines with the specular map’s color), and environment intensity (combines with the specular map’s alpha).”

However, custom environment maps – such as used with custom reflections – won’t initially be supported, as has been previously indicated. With the initial release specification now locked – but not currently open to public reading, that will occur nearer the time LL are ready to make a further announcement on materials – any additional functionality is being looked upon as being either for a further release or requiring a programmable system to implement.

Whether there will be further updates to the system remains to be seen, but it appears those involved in the project, both inside and outside of LL are reasonably confident there will be. “Materials is something that you can likely expect to receive several updates over time,” Geenz commented. “It’s something that’ll evolve from a fixed system into something a fair bit more sophisticated eventually.”

Related Links

SL projects update week 42 / 1

Server Updates

The main channel deployment took place as planned on Tuesday 16th October. As previously indicated, this was the code deployed to the BlueSteel RC channel in week 41 (essentially an improved database query that should help with the back-end system load).

Of the Release Candidate channels, these are due to be updated on Wednesday 17th October as follows:

  • Magnum – will not receive an update, but will continue to run with the code deployed in week 41, probably in the same configuration
  • BlueSteel – will get code that’s almost the same as the main channel, with some OS-level configuration changes that shouldn’t be visible to anyone
  • LeTigre – will be getting a minor update to the Havok library which is mostly about getting our servers to build under Visual Studio 2010 on Windows and autobuild on Linux.

The LeTigre update will use “slightly newer” versions of the Havok libraries, so concerns were raised at the Server  / Sim meeting on Tuesday 16th October as to whether this may lead to a resumption of the problem with mesh vehicles being unable to travel between regions running different versions of Havok.Andrew Linden confirmed this might well be the case for mesh vehicles moving between LeTigre regions and other regions following the deployment.

To help reduce issues with situations like this arise, it was suggested that areas such as the Blake Sea regions are either removed from the RC channels, or placed on the same channel. While this would not solve the problem grid-wide, it would reduce the impact somewhat for people using mesh vehicles in these regions. A query was put to the LL deployment team on this by Andrew Linden, and they  agreed to try to make the Blake Sea regions more homogenous by ensuring they are all on the same channel.

SL Viewer

A further stability test build for the beta viewer was made on Friday October 12th, and reached the download page on Tuesday 16th (3.4.1.265898release notes) after being cleared by QA. This should be the last stability test release and should see the OK for code merges to resume. Merges and release priorities are still being looked at, and speaking at the Open Dev meeting on Monday 15th October, Oz indicated that there are “a few open source contributions in the pipeline that are in the mix”, as well as the anticipated LL merges such as the Steam code, Monty Linden’s HTTP library updates, Baker Linden’s Group Services project code, Apple OSX Mountain Lion support (including gatekeeper compatibility), etc.

Kelly Linden reports fixing SVC-7870 (Edit Linked Parts isn’t returning creator/owner), but given the current backlog, it may be a while before this makes it through to a beta  / release viewer.

Avatar Baking

The aim of this work (Project Sunshine) is to improve issues around avatar baking and to eliminate bake fail issues. It will primarily focus on moving the emphasis for the baking process from the viewer to a new Texture Compositing server. The viewer will retain some elements involved in avatar baking – the actual baking of the avatar shape (i.e. shape values and IDs) will still take place on the viewer side, for example.

As of Monday 15th October, no major news. Commenting at the Content Creation / Mesh Import meeting, Nyx Linden said, “Still plugging along at it :). It’s a complex project with many moving pieces, we’ll let you know when there are updates, and I will definitely be asking for beta testers here when we’re ready for feedback”.

Interest Lists and Object Caching

The focus of this project is to optimise the data being sent to the viewer, information already cached on the viewer and the manner in which that data is used in order to ensure it is used more efficiently so that things rez both faster and in a more orderly manner than is currently the case.

Interest lists and object rezzing: ironing-out the bugs, wherever they are

Andrew Linden continues to iron-out the bugs in the interests lists project, including one in the main viewer codebase wherein after crossing a region boundary the connection to the region you were just in will get reset after about 60 seconds. This is impacting the interest lists work and requires resolving, so Andrew is currently focused on trying to sort it out. A problem has also been reported with objects rezzing in the test regions on Aditi (e.g. Ahern) when moving through them in a vehicle, and will be looked into.

Pathfinding

A question was raised at the Content Creation / Mesh Import meeting on the 15th October as to why a 1-prim pathfinding character  has a land impact of 15. The reason for this is due to the increase physics load on the character. As previously covered, while this may seem harsh, it actually means that characters with a much higher prim count will also have a land impact of 15 (for example, a 30-prim character will still only have a land impact of 15), unless other factors (such as streaming cost) come into effect.

There are a couple of other issues with pathfinding characters which are being (or are about to be) looking at:

  • A bug whereby copies of single-prim characters only have a land impact of one (not 15). This problem is being addressed under PATHBUG-194.
  • A problem wherebypathfinding characters suddenly appear to “fly away” when adjusting your camera position, almost as if they are suffering from lag, and then reappearing there they should actually be (I gather this tends to happen when looking at a pathfinding character, which is following a set path then turning the camera away and then back again). Andrew Linden believes the problem is related to interest list updates, and will be looking into it.

Mesh

The patch to enhance the mesh uploader when dealing with rigged mesh items was discussed at the Content Creation Mesh Import group meeting on October 15th, with Nyx expressing interest in the idea, and agreeing with a suggestion that the patch needs to be formally submitted to LL’s bit bucket repo applied to a cloned version of the development viewer, supported by a JIRA outlining the patch and with a link to the repro.

Mesh uploda enhancement: suggested that it is submitted as a patch to LL

SH-3055 is a bug relating to mesh uploads which has been around for a while, but which appears to be affecting more people of late. With it, mesh uploads fail without any error message or warning on clicking CALCULATE or UPLOAD on the mesh upload floater. The issue is hard to track down (or even reproduce) as it doesn’t occur with any consistency. Either the upload works, or it simply sits as if waiting for something – whether it is waiting for data to be returned by the server, or whether it is receiving information and failing to action upon it.

Darien Caldwell and Nicky Dasmijn have been working with a debug viewer in an attempt to pin the problem down, but so far without success. One school of thought they are pursuing is that it is a problem with the viewer’s cURL wrapper (which is also thought to have been responsible for the recent crash issues being experienced in the beta viewer). The thinking behind this is that the problem appeared to come about with the introduction of a multi-threaded cURL in v3.2.5 of the viewer – with 3.2.4 having exhibited no major issues with uploading.Nyx Linden has stated he’ll take the problem to the team work on cURL to see if they can identify anything.

Materials Processing

No further updates. When talking to Geenz Spad and Oz Linden on Tuesday 16th October, Geenz could only say, “There’s not much to really report on materials for the time being unfortunately, but when there is something I’ll be more than happy to tell everyone.” Oz then added, “We’ll do more than tell you – we’ll give you something to play with :-)”.

Network Pile-on Test Update

Commenting on the thread for the pile-on test, Oskar Linden said: “All of the tests passed and the code will be going to RC next week. Thank you all for your help!”

With thanks to Baz deSantis for information on the Sim / server Group meeting.

SL projects update week 41 / 1

Server Deploys

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.

 

SL projects update: week 40 / 1

Update 3rd October: The RC roll-outs were somewhat different than indicated by Simon. Magnum apparently received the back-end configuration work for new and future hardware, and BlueSteel received the maintenance update. The Group Services code & maintenance release was targeted at LeTigre, however a showstopper issue means that these regions are now in a state of flux. A comment from Oskar Linden reads: “LeTigre regions exhibited issues that necessitated a rollback. The regions were rolled forward and are on the same code that is on BlueSteel. Affected regions are getting a simstate rollback” . 

Server Deploys

There was no main channel roll-out this week, as expected, following the cancellation of last week’s RC channel deploys.

Wednesday 3rd October will see the three RC channel deploys originally planned for last week:

  • Back-end configuration work designed to help SL run better on new and future hardware – this should be deployed to BlueSteel
  • A maintenance release, which includes has Baker Linden’s Group Services project – this will be deployed to Magnum
  • The third is described by Simon Linden as being, “Very similar to what we have today, with a fix for some future compatibility coming down the pipe. It’s nothing really exciting, but required so things won’t break.” – this should be deployed to LeTigre.

The order of the releases is not clear at the time of writing, and is based on Simon Linden’s comments at the Simulator User Group.Confirmation / updates to the plan should be made available via the Server Deployment thread in the forums.

SL Viewer Releases

Things remain slow due to on-going crash / possible memory leak issues, as reported in my last mini-update.

Group Services Project

The Group Services project is an attempt to improve the management and editing of large SL groups by replacing the current UDP-based service (which has capacity issues with the size of group lists it can comfortably handle) with a new HTTP-based service. The project viewer for this is already available (for Windows, Linux and OSX.). It had been hoped that the viewer code might reach a 3.4.2 beta release during this week, however due to continuing issues with the current beta viewer code, this now seems unlikely.

The initial server code for this will be deployed to the Magnum RC channel, as mentioned above, on Wednesday 3rd October.

Materials Processing

The final feature set for the first release of materials processing is now more-or-less complete, and it should hopefully be announced nearer the time for beta testing. A number of regions on Aditi have been prepared for beta testing, and details on these will be released when the initial project viewer is ready for release.

Options to be used by Normal and Specular Maps, which will need to be provisioned in the Build floater

The initial feature set will include the ability to set parameters (rotation, offset, etc.), for normal and specular maps as well as diffuse (texture) maps. Oz originally hinted this was the aim a few weeks ago, although Geenz indicated it was only hoped these capabilities would be included, rather than it being definite at that time. This means that the build floater for the project viewer will be somewhat different from most people who build are familiar with, as it must include a number of additional options (see right). However, what is being considered is not a complete rebuild of the Build floater.

Commenting on this aspect of the work at the Content Creators’ Improvement Informal User Group, Oz Linden said, “We’ve got a strawman design in internal review… will have a version to look at soon, I think.”

The design has had input from a number of builders. Some of these are from within LL, some of them users, and will probably be left unchanged until further experience is gained in its use. Whether this means the viewer remaining unchanged between the beta programme and the release of materials processing on Agni, or whether changes are made between the beta and the release, remains to be seen. As Oz went on to comment, “It’s a very difficult problem, and we tried to meet three sometimes-conflicting goals: do what needs to be done; keep things familiar; make the things you have to change better in the process. I think we did pretty well…”

Obviously, TPVs will have access to the build UI code once it is available in LL’s accessible repositories, and they’ll doubtless look at the code in terms of how best to integrate it into the look and feel of their own viewers.

There are still no firm dates for the project in terms of beta commencement, etc., but Oz reiterated that the project will follow the familiar course, with an Aditi beta, followed by a release to one of the RC channels on Agni, prior to an eventual full roll-out.

Related Links

With thanks to JayR for the simulator UG meeting transcript.