As usual, please refer to the server deployment thread for the latest updates / news.
- On Tuesday, December 15th, the Main (SLS) channel received the server maintenance package previously deployed to all three RC channels. This package comprises simulator crash fixes (including one for the issue found during the original final testing of the package in week #49) and implements feature request BUG-10192: adding constant OBJECT_OMEGA to llGetObjectDetails(), so that it can return a vector matching what is returned with llGetOmega(), allowing applications to determine an object’s rate and axis of rotation.
- On Wednesday, December 16th the three RC channels should all receive the same new server maintenance package, comprising:
- A simulator crash fix and internal fixes
- LSL HTTP requests can access data sources that require non-text Accept headers (such as the Destination Guide)
- Some of the group member counts as reported in the viewer will now be larger. These member counts will include inactive users, and will only updated on a daily basis. This change is to help with some of the problems we have encountered recently with group functions.
This last item is intended to help with the group database issues I reported on in my last project updates report.
There have been no updates within the viewer release channel, leaving things as they were in the latter half of week #50:
- Release viewer: 22.214.171.1245981, dated October 26 and formally the Notifications RC viewer
- Valhalla RC viewer, version 126.96.36.1998641 and dated December 7th, comprising the Chromium embedded Framework updates to replace LLQTwebit
- Maintenance RC viewer, version 188.8.131.528556 and dated December 3rd, comprising over 30 fixes, updates and enhancements
- Azumarill RC viewer, version 184.108.40.2068134 and dated November 25th. comprising a complete replacement of the under the hood HTTP infrastructure within the viewer
- Vivox RC viewer, version 220.127.116.117744 and dated November 17th, comprising a number of Voice quality and connection issues on both Windows and the Mac
- Quick Graphics RC viewer, version 18.104.22.1686758 and dated November 12th, containing the new Avatar complexity code and the ability to create, save and load graphics presets – see here for more.
As there has not been any TPV Developer meeting in the last three weeks, it is hard to determine the overall status of these viewers, or what (if any) the delay is in promoting one of those which had looked set to become the de facto release viewer (the Maintenance viewer looked most likely, following recent issues with the HTTP RC viewer).
BUG-7729 is the latest iteration in a long-standing request related to syncing animations, the idea to be to present a consistent view of animations, rather than having animations (e.g. couples dances, etc), either start out of sync or drift out of sync. Commenting on the idea at the Simulator User Group meeting on Tuesday, December 15th, Simon Linden said:
[It’s] part of a list of script feature requests we’ve looked at and said “that’s a good idea and would be nice to do someday”, and it probably involves a new message between the server and viewer. But I totally agree that it would be nice … I’ve seen way too many funky animations glitches due to them being out of sync.
There is certain information that the viewer has which should allow it to more easily track animations and help to maintain sync being avatars using them; however, things get complicated when the user is camming around, which can cause Interest list updates to come into play, or the arrival / departure of other avatars can have an impact, all of which can cause animations to drift out of sync.
One of the concerns with BUG-7729 is that it could evolve into a fairly major project, involving both server and viewer updates and the potential need for new messages, as Simon notes above, hence why he stated on leading-in to the discussion:
When we pick what to work on, the obvious high priority things are stuff where the grid is breaking (like the group db problems) or crashes or exploits, then it’s a matter of figuring out the best thing for a limited effort .. some projects are just too big.
As such, it would seem that a more economic solution in terms of scale possibly using what information the viewer already has, or what it might do, might be a preferable approach.
Firestorm, for example, already has a Resync Animations button, which can be a one-stop means for someone to resync the animations in their personal view should they show signs of drifting. The suggestion is that something like this, or a simple timed adjustment to sync animations might stand a better chance of implementation, were it to be contributed to the Lab for implementation into the viewer.