Also coming is more of the HTTP Protocol update. There is more work being done on the HTTP library, viewer changes, and more to be done server side. All of these new features will mean new problems for the FS Team and other Third Party Viewer (TPV) Dev’s.
Jessica’s point is ALL the TPV Dev’s and LL will see lots of problems over the next 3 to 6 months. The basic state of things will be: Fubar.
The benefits in the long run will be Avatars rezzing faster, from SSAB. The improved HTTP protocol will reduce tp failures and make for faster texture and mesh rez.The plan is all the changes will be improvements and hopefully worth the coming months of problems. So, it is going to be a shaky start, but hopefully have a good ending in midyear.
So, you have been updated and warned.
New Stuff
There are cool features coming to the next release of FS. One new feature is from an effort to avoid having to clear viewer settings with each new install of the FS viewer. It is a drag changing all the setting back to your personal preferences. So, the Team has added a settings export and import. Jessica hopes this is the end of the settings corruption on new version install. This feature may not be ready for the next release, but certainly for the one after.
New Settings Export/Import Feature
The Team is working on an import/export of prims feature. The FS Team hopes this import/export format becomes the OpenSim/SL standard. It will work in OpenSim.
There is also a new version of the Quick Preferences panel coming. The Team tried to get the prefs most people wanted in the panel in past versions. But, that didn’t work for everyone. So, the new Quick Prefs will let you add and remove preferences of your choice. My understanding is that if it is a Debug Setting you can add it as a Quick Preference, which will make for some interesting support problems. However, your Quick Preferences will save in the viewer settings export.
There is not as much new stuff as Jessica would like in the likely next release. That is because of the work load from LL changes. There priority effort is directed at getting the Lab’s changes working well in FS. So, new features that offer any problem will likely be dropped to get a SSAB cable version out.
Jessica wanted to be clear that not all the bugs they are running into are the Lab’s bugs or fault. Some are made by the FS Team.
Chiclets – you are going to be able hide most of them in one of the next versions of FS. The original idea was to turn off all the chiclets and have the notices appear in the V1 style. Chiclets for inventory offers and group stuff will remain as it seems there is no easy way to revert them back to a V1 style. The changes to turn off chiclets are proving to be technically challenging. The FS Team is working on it.
V1 Search Panel
V1 search – The Team has built in a V! Search feature. However, when the Lab turns off the servers that provide the service, V1 search is gone. But, V1 Search will remain in operation on OpenSim grids.
I missed part of this, but there is something about more floaters being added for for block-mute, groups, more… which are little UI changes but big changes for usability.
Jessica’s belief is that while the Lab is flexible on the SSAB rollout date,the Lab is pushing developers to get SSAB support out. Jessica believes they can push the Lab a bit to allow the Team to get things working well. But, there will be a point where the Lab says enough is an enough and sets a hard roll date.
The Lab has been offering lots of help to TPV Dev’s. Nyx and Oz have both been there for the Dev’s. But, there are things the Lab cannot help with, things like RLV and features unique to FS or other TPV’s.
Stable or not stable SSAB in FS will come out at some point. The push is to get things working well. But, perfection is NOT the goal.
An interesting aspect of SSAB will be breaking copyboting, at least for a time.
Singularity has a SSAB viewer, but rumor is that version of the viewer is broken. So, as far as I know there is no working SSAB enabled viewer. The Lab has an internal project viewer for SSAB and some people have links to it. But, it is not ready for massive testing, so those are mostly being kept private.
A question came up on the problem of having both of the two versions of FS (SL and OS) installed at the same time. By default the OpenSim and SL versions install to the same directory and the last installed wins. The fix is to install one, change the desktop icon name, change the Start Menu item’s name, THEN install the ‘other’ version into a folder other than the default. Then yu ave both copies and use them in SL and OpenSim.
If you don’t need to use the Navmesh editor for Pathfinding just install the OpenSim version. Much easier.
A question came up about whether two versions of the viewer will be needed for OpenSim and SL because of the SSAB code. The answer is no. This can sound confusing, so follow closely. We currently have the Viewer Side Avatar Bake (VSAB) in the viewers, all makes. That is going to stay in some form. The SSAB is being added. So, both processes will be available in the viewer. Depending on what the region server tells the viewer, either VSAB or SSAB will used.
Over time some part of the VSAB system may be removed from the SL viewer. BUT… the VSAB code is used when you change appearance. It provides you a quick update of your avatar’s appearance without having to wait for the SSAB servers to respond. It also saves the SSAB service having to bake every little change you make. Sometime after you stop changing appearance, a signal is sent to the SSAB servers and they update based on the content of your Current Outfit Folder (COF).
So, mot of the VSAB code is going to stay. In viewers that are to be used on other grids, the older VSAB code will be used. So, for TPV’s most of the code will remain. They will just add the SSAB code. So, there will be no need for special versions of the viewer for OpenSim and SL because of SSAB.
There is a media streaming problem in FS– Someone in the team said it is fixed and will be in next release.
Like I’ve said before, while I appreciate what the FS team has done for SL, not having a business model will eventually kill the viewer. Making money is not evil. It makes things sustainable. Plus, I’m sure FS could show LL how to make money with a viewer. I’m not saying charge people for using it. I’m saying charge for advertising in an exclusive FS feature. Possibly a working search engine. I’d pay for that. Yeah, I already pay LL for that, but they obviously have no idea what the purpose of a search engine is.
A viewer with pop-up ads? Or taking up space inserting ads into specific features of the UI? Gick! What a horrid idea! Whatever the feature was that the ads were associated with would be the LAST feature I’d use. That idea needs to be killed with fire!
Viewers are made by people who do not like the limitations of a vanilla browser/client/etc. If they no longer enjoy SL and prefer to stop playing, then they should stop bothering with said client. However, if they still enjoy their game then they will likely continue to work on a viewer that meets the needs they’ve set for themselves.
But Advertising and charging? GFYS. Advertising is the Devil and I’d like to eventually have one thing that I don’t have to deal with ads or the effort involved in blocking ads across the board.
And further suggesting that FS could teach LL how to make MORE MONEY? It’s about time we stop giving LL any money at all. All they’ve done is break shit each and every time. I think I’m still waiting for Havok to be fully functional and even after 11 years they STILL CAN’T FIX random crashes or my personal favourite; crashing TPing elsewhere.
So… if everyone stops paying the Lab any money… how do you propose we pay the developers to move the platform forward?
Do you really think they are breaking Second Life? I think they are proceeding down the normal path of human powered advancement. SL has advanced considerably since I joined.
If you stop advertising, advertisers will stop paying for the things we enjoy. Then how will you obtain those things they have paid for? Would you perfer to pay for them yourself? And how will you even know about them?
I am amazed you think the tp-crash problem is caused by the same software problems as 11 years ago. You probably don’t know you only ever have a flu once. From that time you are immune to that specific virus. But, the same symptoms we label flu are cause by a new virus the next year. It isn’t that we cannot cure a specific flu, we can. But, we cannot cure the next one we don’t know about. Software is the same as it develops and changes.
Plenty of food for the wackadoodles for the next few months. They have been quiet of late 🙂
The wackadooles have been quiet lately. Or I just don’t hang where they do…
the meeting
http://www.youtube.com/watch?v=8_B8iWQ46Wg&w=560&h=315]
I’m quite a bit surprised by the argument following which RLVa would be an issue with the server side baking code !… While it is true that you must make sure that RestrainedLove restrictions are not in force when removing or wearing clothing items, it is trivial to implement the corresponding checking functions as callbacks pointers used by the llappearance library and initialized by the RestrainedLove core; this is how the Cool VL Viewer has been doing it for weeks in its server-side baking enabled branch.
As for stability, the current sunshine-external code (with this week’s latest commits) has been largely improved and is proving quite stable (currently testing Cool VL Viewer v1.26.7.11 that is based on it and will be released today or tomorrow). As a TPV developer, I’m ready for the roll-out of the server side baking code on the main grid.
I haven’t been interested in viewer code for anything more than animations… and that code has been/is difficult for me to understand. I also have not looked through the FS code or tried to compile it. So, I am clueless as to what is actually going on.
That said, I’ll suggest what was said at the meeting was a combination of actual tech and team politics mixed with Jessica’s understanding of what is happening. She doesn’t claim to be a techie, so I assume she is doing some interpreting of what the programmers are saying. Plus there is the need to placate the user base, which Jessica seems sensitive to. I imagine there is concern that when people react to what she says, it gets taken out on support people. As people’s responsibility for others increases they tend to be cautious.
Thanks for mentioning that Sunshine code is now more stable. Jessica tends to see things as a bit dark. I too expect to see problems as new software tries to carry the load of the main channels. But, whether it is going really bad, just bad, not so bad, or just your normal SL is all opinion.
Two things I’ve learned over the years is that **nothing is trivial when making changes to viewer code**… and stability is a matter of being able to run, reliably, with very few crashes, across many platforms, many hardware differences, and many variations to the options built into the viewer (and Firestorm has a ponderous number of possible options). What is stable on my computer with the options I choose may be wholly unstable on another person’s computer or even on my computer with different options chosen.
All that said I’m sure they’ll work it out in the end.
The Firestorm team has done an amazing job over the years. I expect they will continue to. I probably feel more appreciation and respect for the team than I do gratitude, but only because I am not a big Firestorm user.
They do draw their share of haters. While it is possible to criticizer the team in constructive ways, self centered haters have made it hard for the team and the Lab and I believe slown the advancement of SL. I see no reason to even attempt to be PC about such people. That these idiots exist makes it that much more important that we thank the FS team and express our gratitude and thanks.
Thanks for what you do FS Team.
Pingback: Q&A Results « Firestorm Viewer – The Phoenix Firestorm Project Inc.
Pingback: Buckle-up, it’s going to be a bumpy ride | Rambling with Shug
Hey all! I hate to read all this slamming of the FS team. They are doing an amazing job of bringing *the best SL viewer in existence* to your doorstep ,and asking nothing in return except an occasional “thank you.” I think we owe it to them to support them, especially through these more difficult times when LL makes major changes to the SL architecture. Ed, Jessica, and the whole dev team do what they do out of love for this medium. Please.. take it easy on them, huh?
For me, all I can say is THANK YOU to the entire team. I would probably not still be on SL were it not for Phoenix/Firestorm. I, like many others, really hated the V2 viewer.. and these guys gave us workable alternatives. Thanks again, FS team!
Pingback: SSB: What Happens Now? | Being Yordie Sands