This week in The Server Beta User Group we have some social issues mixed in with the technical issues. At least the roll out for this week went well. But, the blow back from the RC KT channel started to get out of hand. Olie’s made a another fine mess that can’t be blamed on the Lindens.
The main grid gets the roll out from the Magnum Release Channel. This upgrade changes the Mute features to use the new People API. This means a mute in world is respected in your Feed and on the web site. It is unclear whether this includes the Market Place.
Don’t expect to see this working on the web sites for some time. The feature has to be rolled to all the simulators and then enabled on all of them before it can be enabled on the web sites. I am guessing we may see it working in January.
This RC got a set of tools from diagnosing voice problems. In Andrew’s Friday meeting word came that fixes for some voice problems are in the update. It seems in the process of creating the tools it was possible to find some issues and deal with them. Rolling these tools to the grid will make it possible to more easily find voice problems.
Le Tigre and Magnum
Both of these channels will run the server maintenance upgrade running on Le Tigre last week. This is the release that caused all the trouble last week. It has lots of new bug fixes. See the release notes in the wiki for a huge list of fixes.
Simon Linden thinks this upgrade will likely make it to the main grid next week, week 50. That, of course, depends on no problems showing up between now and then.
TriJin Bade posted a Christmas poem for the Lindens working on server code on the forum. Pretty neat.
No Change Windows
The roll out on 12/13 and 14 will be the last planed roll outs until 1/3/2012. From about 12/16 until 1/2/2012 SL will effectively be in a no change window. Because a good percentage of staff will be on holiday no new code changes will be rolled out. This means no new SL world and SL web sites updates.
I assume the kernel upgrades will continue, since they are planed to complete by 12/25.
This is the Release Channel Kernel Test. This channel is made up of regions running the main trunk simulator code with the kernel upgrade. The metrics for the regions look good but Oskar says they are getting lots of reports. Those attending the meeting with regions in RC KT were not seeing problems. But, lots of people were blaming the RC KT change for problems, which are unlikely caused by the kernel change. So, the noise is clouding what the case really is and is possibly hiding problems. It certainly slows the analysis process.
Those residents that have been specifically testing RC KT are finding it is working well. SVC-5040 has been regression tested and appears to remain fixed.
RC KT Reaction
The release channels in general have drawn negative reaction and comment. Most complaining users are not software developers nor are they familiar with software debugging and testing practices. So, they misdiagnose problems and erroneously assign blame for their problems to the release channels. The blow back has the Lindens looking for some way to turn the heat down and get more useful information.
As we have learned from politics, human nature seems to be if there is a problem without an easy (or at least popular) solution to avoid giving people a target at which to direct complaints. Basically, don’t tell them what is happening and they can’t complain about it. So, in this phase of the Lab’s attempt to shape their image it should be no surprise they are considering how to hide sever channel information from the users.
In essence what has started to happen is people complain about the channel rather than the actual problem. As a Linden trying to solve the problem this is not productive and the complaint is often presented in an unpleasant manner. Try reading some of rants in Second Life RC KT info. I found them particularly uninformed and annoying.
The result is we are seeing more and more information channels from the Lindens to the users closing. We are now down to seven user groups. The Community Tools User Group was recently suspended and has now been removed from the User Groups listing. In the Adult Content UG we are seeing the user’s ability to directly connect with Lindens being reduced. More and more the users are being pushed to the forums where Lab staff can ignore users and avoid dealing with them.
In many ways this makes sense for the Lab. As an employer I would not want to force employees to deal with unreasonable and outrageous customers. Doing so increases employee turnover. As an owner (management) I would need some way to reduce the problem. Plus the Lab needs some way to get actionable information not just complaints.
Tateru Nino in her article User experience is problematic points out her experience and reaction to a moron in APB Reloaded. I think hers is a natural reaction. When one can avoid a problem they do not have to solve it. I think the Lindens tend to react in a similar way with users.
From what I can gather, the Linden-User communication balance is a pendulum. Phillip gave it a push toward more open communication. We thought Lab staff and management had learned something from the Viewer 2.0 debacle. With Rod we have seen the pendulum swinging toward less and less communication, which in many ways is understandable.
We may see this happen with the testing process. The channel designators may be removed from the viewer. At least the easily identified names like Blue Steel may disappear to be replaced by build numbers or other designators only meaningful to the Lindens. Innula Zenovka has posted about this in the SL Forum: Please don’t hide the channel we’re on.
I doubt we will see any change before next year. Also, this is just something the Lindens are thinking about. They are looking for a way to reduce the negative blowback from the channels concept. So, hiding the channel ID is just one of the ideas.
Following along in testing problem, Oskar is trying to get more people to test llTransferLindenDollars(). I think the little testing that the function is getting in ADITI will mean it has to be tested on a RC in the main grid. If one writes that sentence to avoid the testing concept: Since few people are testing llTransferLindenDollars() in ADITI it is likely the feature will be broken and hidden bugs will be revealed when it rolls to the main channel. The wording changes the perception of RC and I think it shows the problem of no RC.
If you build vendors, test it. If you use vendors made by others, contact them and ask them about how llTransferLindenDollars() works and if they will be upgrading their vendors to use it.
RC Sandboxes in ADITI
One of the ideas to get more testing and avoid the RC’s bad image in main grid issues is to add RC Sandboxes to ADITI. The idea is the update scheduled for roll to an RC would roll out in ADITI before rolling to the main grid RC. The idea is it would be up in ADITI by End of Day Friday.
There are some problems, like how to update the release notes and not confuse people. We would have release notes for versions not yet in use on AGNI. Historically release notes are about what is running on the main channel. So, it could get confusing. Oskar suggested and I suspect we will see a Beta release notes page.
Another problem that comes up is in finding the regions running the version one wants to test. Several ideas have been suggested. Most are labor intense. It is unlikely labor intense solutions will be implemented. We’ll have to wait to see what is decided on.
In any event this seems to be in a planning and feasibility stage for now.
The Le Tigre problems that rolled to the main channel caused some content to break. Unfortunately it permanently broke.
One of the things that can happen is No Mod scripts can break. If the creator did not place a llResetScript() command in an On-Rez event a script failure can permanently doom a script. There is no way to reset it. The viewer’s Reset Scripts has no effect on no-mod scripts. Taking them into inventory and rerezzing them does not resolve the problem. Only if you have a copy in inventory that is not broken can you recover.
This is one of the problems with user created content made by novice SL scripters.
Simon Linden says it is a timing problem with newly rezzed scripts. It is all about how events are timed. Simon sees it as rather scary how no-mod/no-copy scripts can break. I suppose that is one of the reasons the Lindens spend so much time worrying about backwards compatibility.
The Lindens are looking at possibly releasing the new LR tools piecemeal. Release some as soon as possible rather than wait to get some of tools with more complex griefer implications figured out. Whatever they decide it sounds like some kind of plan is in the works.
8 Neighbor Connection
You may not realize that regions are only connected to the surrounding 4 regions, i.e., north, east, west, and south. The other four corner regions are not currently connected. So, you can’t walk southeast out of a region into the region to the southeast. Trying it you will see that it is slower than just crossing into the region to either the south or east. This is because the system has to perform two hand offs. One to the east or south region and then a second one to the corner region you were walking into.
Andrew Linden as a sort of side project has been working on creating the code to allow a full 8 neighbor connection. He says it will allow corner crossings and allow corner encroachment returns.
I was surprised to learn that encroachment removal is not enabled on the main channel. I guess that is still pending.
255 Prim Vehicles
I had not heard of 255 prim vehicles. But, it seems someone has found a way to make them. If I understood them correctly, they work with physics enabled. While these had been working, recent changes now unseat the avatar when crossing region boundaries.
I suppose this is an anomaly and will eventually not be possible. However, it was of interest to the Lindens. I suppose a sort of, how did you do that? But, I suppose if it works well it could be added to SL.
For now those that figured out how to build 255 prim vehicles aren’t talking.
llSetPos() and WarpPos()
A new function to work around llSetPos() and WarpPos() limits was being discussed. One of the points I found interesting is that movement within SL can be jerky because movement positions are calculated too quickly. Position is only updated at frame edges. This means if one calculates multiple positions within a frame, fast script, the objects jumps to the last position calculated. Or probably more accurately, we only see it in the last position as our viewer only renders the last position calc’d in the frame. To get smooth motions one needs to be able to assure that each position in a movement is displayed, meaning one position per frame.
Special precautions have to be taken to prevent over calculating positions within a frame. But, one also has to deal with lag to compensate for variable frame times. Calculating for 5 FPS and 45 FPS makes for complications as lag can change quickly. A new function could greatly improve animated motion and simplify scripting.
llSetLinkPrimitiveParameters() has a 10m limit on movement. Andrew said many of the motions limits were created long ago before they had implemented prim parcel limits, grey goo fences, and other throttles. With other limits in place it may be possible to improve vehicle motion.
Because changing the limit on llSetPos() could break existing content, it may be easier to create a new function without the same limits.
There are no promises as to what may change or when. But, at least the Lindens are thinking about it.
Currently the best motion is obtained with the new llSetKeyframedMotion().
Falcon Linden still wants to provide Havok vehicles. I’m not sure exactly what that means… but I have seen far better vehicle action in games that use Havok than I see in Second Life. So, I assume that would mean better vehicles. Supposedly they could cross region boundaries 50x faster.
Summing It Up
I expect we will see some changes in the testing process to move some of the heat off the release channels PR. I think there is a good chance we will see RC channel prerelease code appearing in ADITI, at least I hope so.
I doubt release channel ID’s will disappear. But, they may well be changed into something that only advanced users recognize.
We have seen bugs can still make it through the testing process. Last week’s Le Tirgre fail hurt. Residents miss understanding about the testing process has brought lots of heat on RC KT. Enough so that the Lindens are considering how the channel process may be changed, which is regrettable as it is far better than prior processes… at least in my limited experience.