This Friday was the Third Party Developer’s Meeting. Oz Linden and other Lindens spoke for about 26 minutes telling us what was coming and where things are in the release pipeline.
Today the main viewer remains 3.7.18-295539.
Friday saw the Lindens putting out a new Benchmark and HTTP RC Viewers.
Benchmark Viewer version 220.127.116.115759 – This is the viewer that does away with the GPU Table. Note, Today (10/25) the Alternate Viewers page is showing this as a new RC and an older version as a Project Viewer. Get the newer one. It has all the updates from the default viewer.
HTTP Viewer version 18.104.22.1685700 – This adds HTTP Pipelining to the viewer. It has been updated to have all the default viewer changes.
Oz says they are getting good results from both. Neither was showing any blocking issues. So, one or the other will likely be promoted to the default viewer. Oz’s guess is the HTTP viewer will promote first. He is thinking toward the end of next week (44).
XP Tools is finishing up. There will be no RC version until XP Tools server side is rolled out. Until then it will remain a Project Viewer, which means no possibility of promotion to default viewer. While release is not imminent, it is near ready.
Experience Tools Viewer version 22.214.171.1243901 – There is not much news on this viewer or project, other than they are near completing the project. This version does not seem to have been updated lately.
Oculus being updated and kept current with other viewer changes, but we are not likely to see an RC viewer until Oculus Rift hardware goes retail.
Oculus Rift Viewer version 126.96.36.1995296 – This iteration of the viewer appears to have most recent changes added.
My speculation is now that the Oculus Rift HMD developers have unlimited funding, time is not going to be such an issue for them. So, previous projected Oculus Rift release dates may slide. It is hard to guess this one in as there are competitive pressures to get HMD out. But, if Facebook (FB) doesn’t have their product ready then releasing the hardware gives their VR-world competitors an advantage. Guessing how that should work out is a matter of knowing or guessing how the various decision makes will see and weight the pro’s and con’s. Impossible to know.
Viewer Managed Market Place
Brooke Linden starts giving information on this project at the 03:10 time mark in Chatak’s video. She introduces one of the developers, Skylar Linden. He points us to the new wiki section on Viewer Managed Market Place API. This is the API specification, not something most users will care to read.
However, developers can make use of the API. I haven’t read the code, so I don’t know how open the API is. If it can only be used by a viewer with a logged in user or if it is open to developers building web sites for working with the SL Market Place.
If it requires a login, it probably does, then we may only see third party developers modifying the User Interface (UI) to provide a better experience in their viewers.
From 5:00 to 9:00 Skyar is describing how the API works. Most of us will find this horribly boring, nothing against Skylar.
The API is a subset of the functions used by the market place. This documentation only covers those functions they have exposed for the viewer to use.
Brooke confuses the issue of deleting listings. (9:00 – 10:00) Seems they are never deleted, just hidden. But, the Lab is not going to be undeleting ‘deleted listings’… So, I suppose while there is some way to get them back, that ain’t gonna happen. So, from a user perspective a listing will be deleted by the ‘delete’ API function.
I suppose to keep the purchase history working, they can’t totally delete a listing. But, the listing will no longer appear in your Market Place Inventory of listings. That should be good enough.
For testing the new system, they are close. If all goes well, the testing will be up in ADITI in 2 to 4 weeks.
The Lindens have been rolling out changes to the chat system. Results so far look good. People are noticing. There are a few more changes to come. But, Oz thinks the big changes are out. Coming changes will not make as much noticeable difference. Also, there is some cleanup work to do… I suppose that is removing data collection code that is no longer needed and extra error trapping.
The Lindens are still watching performance. They may find other bottlenecks they can remove.
14:50 – As previously announced, that rolled out to ALL the server RC channels. All is looking good. Oz tells us that load on the regions servers is way down. This means they have more time to handle region crossings and other things.
There is a difference in how the viewer and SL servers handle texture fetches and how the viewer and CDN servers handle them. The viewer first requests texture information, it gets the JPEG2000 header to learn how many levels of image are available. It then requests the level needed for the current display need. The SL server sends the header information, how many levels and etc. Then when requested sends the level of data requested.
The CDN server pulls the entire texture file when the header is requested and depending on the viewer being used, sends just the header, until the level request is received.
This means the header request from a CDN server will be slower than the one to a SL server. The CDN server is taking time to download the whole texture file. But, the slowdown is a onetime thing and only for the first person that requests a specific texture from that CDN server. All subsequent requests of that texture are faster.
Oz says in weeks the CDN servers will have the majority of the textures we run into on their cache. So, everything will be faster. That initial, very limited slow down, is only for the first call that loads the CDN cache.
Oz also says that in his testing of CDN he has come to think the viewer’s cache is not working as well as it might… shock of shocks… Many people have commented on the effectiveness or lack of of the viewer’s caching system. While it has gotten better over my time in SL (2008), I have never thought it worked all that well.
Whatever the case, Oz is going to have Lindens looking at the code to see if it can be improved. HALaaaLOOOO Yaaaa!
Not much has happened lately. Oz was diverted to another subject before he could say much. We know from past discussion they have run into so complex problems and are doing work-around things.
These are the issues that third party developers feel are holding them back from merging AISv3 into their viewers.
Believed fixed by https://bitbucket.org/lindenlab/viewer-lion/commits/4c15a35af034
- BUG-6908 MAINT-4350 Attachments scripted to llDetachFromAvatar on region change show as “Worn on invalid attachment point” in inventory after region change’
may be fixed by the above – not yet tested
- BUG-7131 MAINT-4409 Unexpected behavior of on_rez event and llDetachFromAvatar()’
- BUG-6925 MAINT-4351 HUDs and attachments intermittently and randomly detach after teleports, sometimes reattaching on their own shortly after, sometimes staying detached completely, or showing as “worn on Invalid Attachment Point” while still detached’
The statements with ‘believed fixed’ means the fix has not been completely tested as of now. That work is in progress.
There is a maintenance release viewer with some of these changes. It is not in RC as there is a ‘show stopper’ bug in it. The bug is unrelated to the AIS changes. So, we will see the RC Viewer as soon as the bug fixes pass Linden QA. Other fixes are coming in a second maintenance release.
Bugs 5 & 6 may not be bugs but timing issues, race conditions. The Linens are still trying to figure them out. Bug-6925 is one the Lindens cannot reproduce. That may because they are on the local network and never hit the timing issue. They plan to have someone far away from the Linden servers help them with testing. Whirly in the UK consistently sees the problem. But, to test they have to build a viewer to capture useful debugging information about the problem.
While the Lindens have not given up on the bug, there is little hope for a quick fix.
Voice Breaking Up
There is a bug report about Vivox voice breaking up that was prepared by third party developers. The Lindens were impressed by it. Unfortunately the Lindens can’t do much about the problem. But, they passed the report along to Vivox, which was really impressed with the report. They are thrilled to have gotten it and are working on fixing it.
There is speculation on the idea of changing voice from a separate executable to a DLL file that is packaged with the viewer. That would be good in many ways but a serious complication for 64-bit versions of the viewer. Whatever the case, any decision is a ways down the road, for now it is only long range speculation on the part of the Lab.
Large Frame Drop
There is a large difference in frames rates between Mavericks and Yosemite (Mac machines). The Lindens are aware of the problem. But, until they have their automated build system working they can’t do much about it.