Kitty Barnett

I've only ever told people that they should not expect experiences and RLVa to work together; the fact that they do was unintentional so there's no contract or promise that things that worked in the past, or work right now, will work that way in the future. As it stands, by default, PG experiences should not ever expect to be able to attach something that then issues RLV commands. At the moment, M & A are ok, but that's not set in stone either. Like I said, moving forward there will be a way to indicate the kind of "risk" a user is willing to have. At the low end ("Casual") the combination of experiences that attach things that issue RLV commands will simply be outright blocked; in the middle things likely stay as they are and on the "hardcore" end it's just everything with "moderate" being the default. It also depends on whether LL ends up adding things that help with identifying when a script (or the object) is participating in an experience or not. If they don't, and the hacky way I have to find out right now turns out to be unreliable (KT's script works for me, but apparently not for her so) it becomes more likely that experiences would be denied the use of RLV by default unless the user enables it (or chooses hardcore).

A lot of people already have a hard enough time trusting experiences that there's no reason to make the experience permissions pop-up even scarier by adding that accepting it means you open yourself up to the entirety of what RLV can do. Especially since it only applies to a minority of all the experiences out there. And while I did still consider it, it's pointless: there's no way to store the user's choice alongside their experience since that data resides with LL and people woudldn't trust anything in FS that sends data off to a web service (and you start running into the GDRP realm with that). And even if you could, you don't have information about experiences accepted in the LL viewer or any other non-RLVa viewer or any older viewers. So all in all, allowing per-experience control of whether it can interact with RLV isn't possible. The next step up is maturity level and this one makes some sense from an expected behaviour POV: if PG is "safe" and A is "explicit" then a PG experience shouldn't be able to do anything questionable to you either (hence no RLV). If you're accepting an adult experience then if that strips you naked and chains you to a wall it's at least somewhat defensible. Between that black and white, Mature is the grey area and since there are some M experiences using RLV I decided to settle on that for a middle ground. Personally, as an individual, I'd rather ban the interaction altogether and keep the two separate since that prevents a whole lot of headaches but when it comes to picking defaults it's ultimately the average user's point of view that's relevant. Why make it a debug setting? Because especially with RLVa there's a huge disconnect between what the users on either side of the spectrum want and expect. At the one end you'll have people who turn it on because they had a scripted gadget that uses RLV but they never expect (or want to) to have anything unexpected or anything they did not consent to happen to their avatar. On the opposite side, you have the hardcore restrictions users who want the illusion of having as little control over things as possible. Most people fall somewhere in between so that's what I try to look to when making defaults, and since there are people who need more or less, I generally think at least having the debug settings available for those specific cases so that they can set their specific threshold would be helpful. Moving forward, I was working on a feature (that didn't finish in time for FS' release) that would allow people to pick their point on the spectrum (e.g. Casual / Moderate / Hardcore) and adjust the debug settings accordingly for that group of people and 'RLVaExperienceMaturityThreshold' is one part of that. The reason it's not exposed in the UI is because I can see little reason for it to be, it will be tied to the future user level and those that have a specific preference will know what to change manually on their own. You can/could already block all experiences by disabling "Temporary Attachments" in the menu and in the niche case where you'd want to allow temp attachments but not experiences it's now possible, but requires manually changing the debug setting.

That happened even when I went in an entirely different direction and added client side scripting to the viewer (so as opposed to in-world scripts, you write scripts that directly interact with parts of the viewer). Every now and then someone will always speak up and "if only we had..." or "why can't we...?" but it turns out to be a solitary voice. So client-side scripting died and is collecting dust in my piles of "unwanted try-outs".

Hey Dakota, I don't mean to pounce on you but someone was a bit perplexed by your post and asked me to have a look as a TPV dev. Most TPVs let you search in the Received Items folder for a while now, but even the official viewer will let you search it as well (it just won't include the folder with the others like TPVs do, but you can search and it will filter the Received Items panel). I'll have to admit that I also don't understand why (from the viewer's point of view) having many items in any given folder would cause "lag"; all inventory is a lookup table the difference is traversing a list of 5,000 vs a list of 150,000 total. There's some back end issues from having too many folders (which can - and did in the past - cause some problems logging in) and there was the issue that huge folders (most notably the trash) cause back end issues too but that's hardly what anyone would describe as "lag". Again, sorry for seemingly pouncing, but there's already a myriad of myths on inventory management that users end up with. --- <on-topic> Sort sentimental things vs non-sentimental things; if it's older then a couple of years, toss it, especially if you didn't ever even bother to unpack it. Yes, you paid money for it, and it might feel bad, but chances are that you'll never ever use it simply because it's no longer relevant (system clothing layers) or looks bad/dated (prim-based furniture). Also, even if they can pry your insert-your-favourite-viewer-here from your cold dead hands, some of them are aimed at letting your search your inventory better, or to keep it organized better so you can use those to your advantage to get the sorting out of the way and then just relog back as you were. Example: I used to keep a shopping bag folder around but then my root folder would fill up with 500 million demo folders (that I would never end up cleaning up). I'm also mildly OCD about hopping to each and every event I can which means stuff piles in at 10 times the rate that I could ever hope to sort it in (yes, shopping addict, *hangs head*). Which gave way to this: As soon I buy/receive/anything something there's a drop-down to let/force me to at least semi-sort it on the spot (and as you can tell, I can make any old folder look/feel like a system folder. The next step was to unpack things into the folder the prim is in rather than somewhere at the root: Both those features were made with the intent that in spite of the best intentions, most people won't organize their inventory (or keep it organized), but these two working together let you unclutter it without spending any time on it and while it might be a bit of a bump, I've received nothing but very positive feedback. Then finally, searching for inventory was improved, because just organized or not, you'd rather just type something in quickly if you know what you want than having to hunt for it, so there's a new inventory finder: The big difference being that you can search for an exact (which is how we were all searching), but additionally "contains ALL of these wprds" or "contains ANY of these words" which is really powerful since most of the time you'll vaguely remember something "it was a companion, ... or an animal, ..., or a plushy. (For the crazy people you can use regular expressions as well but there's no UI for that) Finally, an old-time feature, but something people sorting their inventory love (adding inventory tabs at will): TLDR - There's a lot the viewer can do for you too, if your inventory ended up disorganized then chances are it will always be to some extent or another so the viewer should be helping you organize it at least a little, and allowing you to find things easier and it's something that's been getting little to no attention (so feel free to nag to have it - or things like it - included because the response I got was that it was too complicated for the official viewer). </on-topic>

It's odd that the blog post only obscurely hints at what lays ahead: the current SL profiles system is being thrown out the window in favour of web profiles à la AU; much like the old search system was thrown out the window in favour of a web-only viewer 2 search. Erica Linden added a comment - 10/Sep/10 2:54 PM Hey guys - This issue isn't being ignored - it actually has a team assigned and is making good progress. The Profiles team is working on pulling profiles out of the sidetray and viewer XUI entirely and turning them into web assets that can either be viewed/edited from the viewer or from your dashboard. This means that when you search for someone and click on their name, that persons profile will open in the search floater, or you will be able to open it in a new floater (just like opening a link in a new window in a web browser). Opening a profile from your friends list, or chat, or another area will pop the profile open in a larger, resizable webkit floater in the middle of your screen. Opening multiple profiles can open multiple floaters, and each floater will allow you to drag-and-drop an inventory offer. The first project deliverable is to provide parity between current profile features, with a bit of a style refresh. After profiles become web data (instead of stuff embedded in the viewer) we'll be able to more quickly provide new profile features, allow new ways to access and edit your profile, and generally make them more useful. So, as you think about tear-off sidetray tabs, please keep in mind that the "my profile" tab will be going away entirely, and that others' profiles will no longer be displayed in the sidetray. ("Viewing multiple profiles" - https://jira.secondlife.com/browse/VWR-17005)

Boroondas.Gupte wrote: No-modify items Calling Cards Links to other items (as they appear in the Viewer 2 outfits) Calling cards can be renamed since they're M/C/NT. (Inventory links are NM/NC/NT just for the record) --- As an aside, if someone *really* wanted to then they could "fake rename" system folders in 2.0 by tricking the UI translation (ie "Clothing" would still be named "Cothing" but it could appear as "Things to Wear" for instance).

This shouldn't be that new: someone could put the URL in their profile, a prim with a llLoadURL, or in their web tab, or put a link on the forums here, etc... Even though the content is hosted outside of LL's reach, the originating "link" is still located somewhere inside of SL (or the site) so it "should" stay AR'able (and actionable) all the same in my opinion. --- If someone decorated the outside of their house in a PG sim with web-porn-on-a-prim the "but it's on the web and not in SL!" wouldn't make any difference either .

The values seem to be hard-coded so changing them to user preference would involve a new feature JIRA request .

http://jira.secondlife.com/browse/VWR-17028 The comment from Yoz isn't encouraging though, I think it's "expected behaviour" .

Irene.Muni wrote: In the Map I can write and search the name of a region. But how/where can I write a specific coordinates for that region? You can't. --- Clumsy work-around: open the Map and search for the region you want click the copy SLurl button close the map and click in the navigation/URL bar paste the SLurl and adjust the coordinates there hit <enter> to teleport

The following should work: Artwork http://automated-builds-secondlife-com.s3.amazonaws.com/viewer-rc-frozen/slviewer-artwork-viewer-rc-frozen-1.23.5.136274.zip Libs http://automated-builds-secondlife-com.s3.amazonaws.com/viewer-rc-frozen/slviewer-darwin-libs-viewer-rc-frozen-1.23.5.136274.tar.gz http://automated-builds-secondlife-com.s3.amazonaws.com/viewer-rc-frozen/slviewer-linux-libs-viewer-rc-frozen-1.23.5.136274.tar.gz http://automated-builds-secondlife-com.s3.amazonaws.com/viewer-rc-frozen/slviewer-win32-libs-viewer-rc-frozen-1.23.5.136274.zip Source tarballs (zip or gz) http://automated-builds-secondlife-com.s3.amazonaws.com/viewer-rc-frozen/slviewer-src-viewer-rc-frozen-1.23.5.136274.tar.gz http://automated-builds-secondlife-com.s3.amazonaws.com/viewer-rc-frozen/slviewer-src-viewer-rc-frozen-1.23.5.136274.zip

I wouldn't buy anything from wherever you got that rate from . 1€ = $1.36US LindeX limit buy rate of L$268/$1 would correspond to L$364/1€. --- If they're offering a lowly L$315/1€ *and* additionally take 16% VAT then they have quite a profitable little "scam" going on...

LL used to release that metric (along with a bunch of other useful ones) but switched over to only graphs at some point. You can look at https://blogs.secondlife.com/community/features/blog/2008/02/22/key-economic-metrics-through-january-2008 for an example of what used to be published (the links to the Excel file still work at least). Meta's office hour (if it still exists) would be the best place to ask why all that was discontinued.

Jas.Siamendes wrote: Ahh...I just tried that, but because it is a cube that is path cut (perhaps?) I found that I need to half the dimension eg: I have a 10m cube, hollowed to 95% using the 5% theory the wall should be 0.5m - but in actual fact it needs to be 0.25m! - So it becomes 2.5% of the original prim width. Hollow originates from the center so when you take out 95% (9.5m) you take out 4.75m to the left of the center and 4.75m to the right center (and up and down) and the 0.5m you are left with is the thickness of *both* sides added together so each side is 0.25m thick .