Jump to content

FJ Linden

Retired Linden
  • Posts

    57
  • Joined

Blog Comments posted by FJ Linden

  1. 
    

    I have just recently finished 5 months of trying to give the viewer 2 interface an exclusive try, during which I used only it. The last straw for me was at the end of December, when anything I clicked on to edit turned all invisible on me under 2.4, and I could no longer see what I was working on. I re-downloaded viewer 1.x, fired it up, finished my chore for the client that day, got paid, and haven't looked back. My productivity shot back up to where it was before I determined to master viewer 2.x at the start of those 5 months.

    So, I don't suppose there's a way of offering a choice of viewer interfaces: 1.x for advanced users, content creators, and 2.x for regular users, both just pasted on as skins to codebase 2.x? I've never tried a third-party viewer, but I'm given to understand that the Phoenix people are essentially doing it, or trying to....

    Lots of softwares offer two versions, end-user and developer versions....

    I suggest this because I totally agree, FJ, that it would be a pain in the butt to support two different codebases and really in the long run a bad use of resources that are ever more scarce, and I certainly wouldn't want to be in your shoes having to do it! Ugh.

    Maybe we certify something like Phoenix (caveat as I say, I've not tried it, just an example) as the developer version, though Lord knows what the politics and legalities would be behind a word such as "certify."

    Its pretty clear that a single UI to serve all residents doesn't work.  You are thinking in the right direction here, as we need to be optimizing for classes of resdients with our UI.  The underlying codebase needs to be unified, but that does not imply forcing residents to an experience that does not work for them.  This is part of what the Snowstorm team is working through and has received tons of great feedback from the resident community.  This is also where TPV's can really help to extend and customize experiences.  Content creators will have very different interface and tools capability requirements than a resident who just wants to explore and experience Second Life's content.

  2. 
    

    Fantastic news.  I'm glad to see some improvements in the grid.  We've been struggling with these problems for a long time.

    And those of you complaining that new improvements aren't being reflected in 1.23 viewers -- deal with it and move to a 2.4 or newer viewer if you want the new tech.  1.23 is obsolete and slowly disappearing, just like the Pontiac Fiero.  And while you may insist upon driving the Fiero, as time moves on you'll have more and more trouble with it.  At some point you have no choice but to retire the old vehicle and get a new one if you want the improvements of a new vehicle.  If you insist on using old stuff then you resign yourself to that level of tech and no better.  And that's nobody's fault but yours.

    Just take a day and get used to the new 2.4.  It's not the piece of bovine excrement that 2.0 was, and if you have 22" or bigger monitors the sidebar isn't even an issue.

    Thanks for the comments here Shockwave...

    I realize that as we make improvements to the grid there will be controversy regarding client version support.  I also know that some residents will feel like this is a calculated move to force people to adopt viewer 2, but it truely is not.  However, the viewer 2 codebase (I'm not speaking about the UI) is certainly where I want us to be heading down the road, and the amount of time and effort that we decide to apply to make new feature work with the viewer 1 codebase will continue to be a challenge.

    This situation (support for both codebses) will also come up with the new XMPP chat system and is something we are still deciding how to address.  Backporting this capability to viewer 1 will require development of a shim or bridge and more opportunity for bugs and performance problems.  Our direction needs to continue to be simplifying our codebase, not adding even more complexity.

  3. 
    

    The real test of sim crossings is high speed high prim vehicle crossings. I took one of my rideable sailboats out last night at high speed, notice little bumps at sim crossings but only one occasion where the boat flew up for a while.

    Any reports from pilots?

    This is good to hear.  I will be looking for other feedback on sim crossings.  So far this seems to be a tangible resident improvement, as opposed to foundational work that isn't directly seen by the community.

  4. 
    

    FJ, while I realize that it isn't a top priority in the chat project, I am curios:

    With the use of standard protocol and server, are there any plans for allowing external acces, i.e. chatting between SL and a "normal" XMPP client?

    Yes, this would certainly be part of what we would do to extend this capability.  I expect it will show up on a chat system roadmap at some stage.

  5. Responding to a couple of comments.

    Lag is not "fixed."  I don't think I ever implied that in the post. I spoke of a single pain point (among many pain points) that comprise "lag."  (For Nimh20 Vandeverre: I actually received feedback from Simon before posting this update, and he indicated that I might find lots of pushback, specific to that part of the blog, however I still believed it was important to call out this work.)  There are plenty of areas that need to be fixed to help kill lag, I was just discussing one of them.  Having a good set of sim performance profiling tools was also important to point out.  Those tools will help us find the biggest contributors to lag and attack them in priority.

    On the group limits increase, the number 40 was not just arbitrary.  We've done some testing and profiling to deterime how high we feel that number can be increased without reducing performance.  I certainly don't want to be in a position to have to roll back to a smaller number (its not lost on me the disruption that causes residents), but changes to these limits require us to touch both viewer and server code (not simple nor quick).  If we could just do a quick configuration change, then gradually moving the group limit number higher would have made sense.

×
×
  • Create New...