Inara Pey

"Second Life Server (no roll): "https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/17#17.07.11.327548" Don't you mean 17#07.27.327933? That was the last SLS deployment.

Those interested can find reviews of the major 360 pancams available in Second Life (of which I'm aware, at least!) here: Illiastra Panoramic Camera mentioned in the OP Camera Panoramic 360 mentioned in Whirly's reply VR Creations 360 Photosphere Linden Lab 360 Snapshot viewer Note the last review was written for the initial release of the Lab's 360-degree snapshot viewer; some functionality has since changed, and the viewer itself is in need of update (which it coming soonTM).

Careful, or I might send you another Tome Of Terrible Questions!

Do administrators count when it comes to being first? . I think Marianne is really first! Second is the new new first!

All you need to know should be in the Knowledge Base - try this link: https://community.secondlife.com/t5/English-Knowledge-Base/Using-voice-chat/ta-p/700169#Section_.8

Are you actually logged-in the the Places pages? From my tests, the page you describe comes up for those not actually logged-in to the SL web properties. Check the top right-hand corner and see if your name or LOGIN is displayed. If the latter, click it to log-in, and things should display OK.

You might try the Obsolete Platforms Viewer from Linden Lab: http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/3.7.28.300847 As the release notes state, this is specifically for users on XP - but keep in mind that given its age, it has none of the more recent features common to maintained viewers, and thus your experience with it is liable to be less than optimal in many cases. Also, as Qie suggests, if you have a suitable Android device, Lumiya might be a good alternative (check the Third Party Viewer list for details). This is an extraordinarily powerful client, given it is Android (check here for more), although it is without some capabilities you might need. If you can install a suitable Android emulator (assuming there is one for XP), you might be able to run Lumiya on your PC through that.

The Galaxy actually returned and opened in August 2015 . Sadly, it's not "complete" https://modemworld.me/2015/08/29/ss-galaxy-lowers-her-gangways-to-visitors-once-more/ Nor is it really used as had been indicated. There has only (to my knowledge) been one event there since the return. https://modemworld.me/2015/09/04/a-cruise-ship-a-gathering-and-a-mole-with-a-wand-in-second-life/

It's not an SL-specific issue. It is a Window 10 / OpenGL issue, which appears to be primarily related to Win 10 Cumulative update KB3176938 released at the end of August 2016. see: https://modemworld.me/2016/09/06/windows-10-opengl-issue-affecting-some-second-life-users The Lab have been in contact with Microsoft over the issue, as have many other affected by the same issue (people are experiencing the same problem on a number of games). There is an unconfirmed report that a fix is due to be forthcoming from Microsoft "soon". However, if you are on Win 10 and experiencing problems, you might also was to try these suggestions from the Firestorm team: http://wiki.phoenixviewer.com/win10 As a Windows 7 user, I cannot vouch for any of the fixes suggested, as I've never had cause to use them.

Viewer is now at RC status: Lab blog post. Download details (14th Sept 2016): Bento release candidate viewer 5.0.0.319688 (links to download options & release notes)

As others have said, how others see you is not something you can directly control. Even with well-made and optimised attachments, there is no guarantee you're not a Jelly Doll to someone who has opted to set their Max Complexity especially low. However, in the context of your role-play enironment, you could ask those around you who are seeing you as a "Jelly Doll" to right-click on your avatar and select "render fully". This will render your avatar as you wish them to see you, but will not alter their existing Max Complexity setting, and so will not impact how they see others wherever else they go. In the official viewer (and TPVs using the Avatar Complexity code unaltered from the Lab), this option will only render you fully during the other user's log-in session. The next time they log-in and see you, you'll again be Jelly Dolled, and they'll need to select "Render Fully" with you once more. In Firestorm, using this option will always render your avatar fully in the other person's view, until such time as they select "Render Normally" via the avatar context menu / pie menu when right-clicking on you (or if they right-click on you and select "Do not Render", in which case, you become a plain grey shape in their view). Hope this helps.

arabellajones wrote: I'm confused. Tbe MC and RC versions have exactly the same ID numbers now, yet one is described as a bugfix and one as security. And the release notes are identical. If they have the same build numbers and they're not the same code, something is broken. But it's a little worrying that the Lindens use different descriptions for roll-outs of the same code. It looks like the all-too-usual nerd/geek failure to communicate clearly. You might look at the differences in description this way: The RC release on Aug 3rd was to fix a bug (BUG-37573) which was (at least in part) caused by the July 27th RC deployment - hence why the Aug 3rd deployment is described as "an update of the server maintenance project from last week" (i.e. July 27th). As the bug never actually reached the Main (SLS) Channel, technically the deloyment made this week isn't a "bug fix" for it, as there is nothing to "fix". So, you might say this week's deployment to the Main Channel is more "preventative" for that channel, hence "security update". Hope that helps .

lucagrabacr wrote: I know the lindens probably don't read these forums, but like most of the younger people that I know of who never used Second Life before thinks there's something off with the default camera placement. I mean like I'm personally okay with it, used it on my first 3 years on SL until I know how to edit the camera preset on Firestorm through the developer menu. (which is tedious to do) I don't think it'd be too hard for LL or the Firestorm team to implement an easier way to change the camera preset a'la Nirans / Black Dragon Just a thought One of the best sets of camera offsets for SL were defined by Penny Patton. With her permission. I produced a tutorial on them back in 2011, and you can find here: https://modemworld.me/tutorials__trashed/camera-offsets-penny-patton/

ChinRey wrote: Nalates Urriah wrote: I don't know of anything the 32-bit Firestorm Viewer can do that the 64 bit can't... Apart from the mesh upload physics issue you mean? But that is easily overcome simply by switching to a different viewer for mesh uploads. As far as I know, there is no law against using different viewers for different purposes. And that should hopefully become a thing of the past once the Lab's onw 64 viewers are released, as they will use 64-bit Havok libraries, which all TPVs signatory to the Havok sub-license agreement (Firestorm being one) will also be able to integrate into their 64-bit offerings.

wherorangi wrote: Matrice Laville wrote: I thought it was clear what i mean when i stated that. And since nobody complained i believe that it was either irrelevant, or overlooked, or accepted and fully understood. So i had no reason to add more info at that time. You where at the meeting? You could have asked back. I would have answered right away and clarified. is that it was reported. and has now been disseminated to a wider audience other than the creatives involved. People who arent in the creative group as you are, go off what is actually said, not what was meant to be said that it was reported as said at a LL-sponsored meet, gives what is said at these meets greater credence to the wider audience, even tho was said by you and not a Linden so I came here to say what I did. Just in case a Linden also takes what was said literally, and never guessed what it was that you meant to say thanks for your since explanation tho. I much appreciative of this (: If there is fault here, it is mine, not Matrice's. I took the cooment without seeking clarification beforehands, and apologise to Matrice and to those for whom it caused upset.

For those interested in the VWBPE address, which covered both Second Life and Project Sansar: VWBPE video is available here: Transcript with audio is available here: http://modemworld.me/2016/03/11/vwbpe-2016-ebbe-altberg-transcript-with-audio/

The new banning system appears to be overly sensitive, and may be reactiing to other HUDs being worn while playing. As well as submitting a support ticket (several of which have been closed with no further action, while others have successfully had bans lifted), if you have the specifics of what you were doing / details of HUDs worn during the game as the time of the ban, and any log files from you viewer, please consider adding a comment to the following JIRA: https://jira.secondlife.com/browse/BUG-11533 - "Paleoquest anti-cheating measures are too sensitive" Remember to be concise in your explanation of what happened - time, what you were doing, notification given, etc.

The new banning system appears to be overly sensitive, and may be reactiing to other HUDs being worn while playing. As well as submitting a support ticket (several of which have been closed with no further action, while others have successfully had bans lifted), if you have the specifics of what you were doing / details of HUDs worn during the game as the time of the ban, and any log files from you viewer, please consider adding a comment to the following JIRA: https://jira.secondlife.com/browse/BUG-11533 - "Paleoquest anti-cheating measures are too sensitive" Remember to be concise in your explanation of what happened - time, what you were doing, notification given, etc.

The ban system for Paleoquest still appears to be overly sensitive at of March 7th 2016. A JIRA has been raised: https://jira.secondlife.com/browse/BUG-11533 If you are banned without reason, try gathering your viewer logs and adding specifics to the JIRA. Or at least provide details of how / when you were banned, and details of any HUDs other than the game HUD worn at the time.

Up until a few years ago, if there were serious problems occurring with any of the SL services, the Lab would issue an in-world warning to residents, advising them to refrain from actions which might result in inventory loss, account balance errors, etc., providing those logged-in with the most direct means of knowing when problems were occurring. Given the events of 9th / 10th January and similar events, could the Lab again look at re-implementing these advisories to users, rather than relying on us keeping one eye on the Grid Status Page when in-world? See: https://jira.secondlife.com/browse/VWR-20081

A couple of points vis Bright Canopy and OnLive's SL Go. SL Go was a streamed service, hosted directly by OnLive themselves, allowing them to adjust their pricing models with a lot greater flexibility than might have otherwise been the case. Nevertheless, as attractive as the pricing for their services was ($9.95 for SL Go and CloudLift, $6.95 for PlayPack, for example), the company could not generate the revenue it needed from it to remain afloat, and so it put itself up for sale as a going concern. As there were no takers, this eventually resulted in the sale of patents and IP to Sony. For more historical background see: Why SL Go won’t continue, and OnLive opted to sell . Where Bright Canopy is concerned, this is a cloud-based service hosted on secure third-party services and servers. As such, there is a lot less flexibility to be had in setting pricing points. In particular, Bright Canopy utilises Frame, who provide the underprinning support for running the viewer as a cloud based application. In turn, Frame deliver their services (and Bright Canopy) via Amazon data centres. Both of these place certain overheads on Bright Canopy which must be met in order for the serivce to exist, and these costs have to be reflected in BC's pricing if it is to be in any way viable. However, Bright Canopy is still in beta, and the current pricing is not reflective of pricing once the service is offocially launched. I'm not at liberty to disclose what this will be, but I can say that there will be a monthly plan available to users when the service officially launches in the very near future, and that to me, the amount payable under this plan appears very reasonable. The best way to keep abreast of Bright Canopy is the BC blog: http://www.brightcanopy.com/blog/

It had been a long slow day, filled with the kind of nothing when an hour crawls by like a sick cockroach. I was sharing the office with a cup of java and thinking about dropping into the liquor store downstairs to see if Jack D might fancy a little quality time with me, when the 'phone rang. That's life. Whenever you decide to do something for the better, fate sticks out a foot to trip you. I took the call. The name's Bullit. Traci Bullit. PI work is my game; you want it found, I’ll find it – for a C note a day plus expenses. Doesn't matter if its a missing alpha layer or tracking down a cube with a wish to be a torus. This time it was a call about a missing 186 G. Things didn't sound entirely copacetic, but what the heck; I figured I could use the exercise. So I grabbed my hat and coat, pausing only to slip my bosom buddy Mr. Redemption back into his holster under my right arm, and headed out into the city ...

Short answer: No, there isn't - at the moment. Longer answer: In terms of streamed solutions, the Lab experimented with a streamed service to web browsers in 2010. But it never went beyond a closed beta, as there were significant technical hurdles which couldn't be cleared. More recently, OnLive provided a steamed solution using their SL Go service. This allows high-quality SL access via a small-footprint gaming application on low-end computers or via an Android / iOS app for mobile decives. Unfortunately, that service is closed after OnLive had to put itself forward for acquisition (cutting a further long story short!). Since that time, there have been some looks at cloud-based services. I initially wrote about the possibility of using Amazon AppStream at the start of April 2015, which lead to an initial trial later that month on the part of a a couple of users. More particularly, it led to an invitation from Nikola Bozinovic, owner of cloud-based applications provider FRAME to try his service for using the viewer through the cloud. I did so for myself, running the viewer entirely unoptimised, utilising Frame's AWS presence in Ireland. However, there is currently an attempt underway to provide an optimised, streamed service using Frame's services overlaying AWS infrastructure. This is called Bright Canopy, and like the SL Go services, is a third-party service, not something being activiely pursued by Linden Lab. Bright Canopy is in its earliest days, although Tuesday, May 18th marks the service's move to a "pre-launch" test phase. One of the problems facing anyone providing a cloud-based solution for accessing SL (outside of potential technical issues such as latency, etc.), is that of pricing. SL Go, as a streamed service, was charged for at the flat rate of US $9.95 a month for unlimited access (although it initially launched with a pay-as-you-go / sliding scale payment system), and this has become something of a yardstick. However, most suppliers of cloud-based services, currently tend to charge by the hour. Amazon AppStream, for example, charges at the rate of US $0.83 per hour. Obviously, such a price point isn't attractive when it comes to an environment such as Second Life - but so long as such services do use such pricing systems, then they are very hard to avoid. For example, Bright Canopy will be operating at an hourly rate of US $0.79 during the pre-launch phase, as they have to cover their underpinnig Frame and AWS fees.It is, however, hoped that a more ameniable / flexible pricing can be introduced in future. The question is, how ameniable any price can be, given there are the underpinning costs to meet? People have pointed to SL Go's US $9.95 a month as being reasonable, as mentioned. But there's a flip side to this; and that is the fact that OnLive, as SL Go's operator had to put itself up for acquisition simply because charging that kind of rate across their core services (SL Go and CloudLift, with PlayPack offered at US $6.95 a month), left them unable to generate sufficient revenue to break even. Thus, pricing, perhaps more than technical issues, may actually prove to be the defining factor as to whether cloud-based access to SL might be supplied reasonably enough for people to use it. At least until cloud services themselves are seen to become more cost-attractive to end users.

The video of the May 1st VMM meeting is now available on - with thanks to Chakat Northspring.The video and a transcript of the Q&A session is also available on my blog: https://modemworld.wordpress.com/2015/05/02/vmm-meeting-may-1st-2015-video-and-transcript/

Bobbie Faulds wrote: Well, this defeats the idea of getting your inventory numbers down to cut down on teleport failures and lag and the time to load your inventory if you're going to have to keep the folders in your inventory now...sighs... There's an old saying, if it ain't broke, don't fix it. It doesn't say, If it ain't broke, let's play with it until it is broken. Just as a point of reference, large inventories have an almost zero performance hit on teleports or on general "lag". The major impact on teleports is running a large number of scripts on your avatar (attachments, HUDs, etc). This is because all said scripts have to be halted, serialised, sent to the receiving simulator, unserialised and resumed, which can cause a lot of issues. Where large inventories do have an impact, it is when logging-in to SL - and then then the impact only tends to occur for those with large "flat" inventories (e.g. tens of thousands of items all existing under a single folder level, rather than being split into sub-folders). This is because the system will attempt to load a folder with tens of thousands of items within it all at the same level in a single pass. As this almost always takes time, it slows the log-in process to the point where it times out, and the viewer is disconnected from the viewer, leaving the user unable to log-in. To prevent this, the Lab is in the process of deploying an inventory transform to their support team. This can be run against accounts reporting log-in issues which can be traced to the user having a large "flast" inventory structure, and it will automatically sub-divide the items within that "flat" structure by age, and place them in sub-folders - see the TPVD meeting for April 24th, commening at the 35:04 mark).So, assuming you do use a folder hierarchy within your inventory, VMM should actually make your experience with teleporting no worse than it already is.