Jump to content

Kitty Barnett

Resident
  • Content Count

    208
  • Joined

  • Last visited

Community Reputation

38 Excellent

1 Follower

About Kitty Barnett

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. It's the proper emoji Unicode characters so really all any viewer (including LL's) needs to do is put the proper emoji font in its font folder. They will show as black/white emoji's but everyone will see them fine. Even without doing anything some of them will show up on all existing viewers (smiley face, sad face, etc) just because they're already in the current fallback fonts. My guess would be that if we release with it and it's actually popular then I'll probably just get poked to put it into Firestorm and then LL might poke to get it into the official viewer. Or it might fail and that's fine too 😃. Just using other chat proggies makes SL feel very old-fashioned with having to click imgur and gyazo links to see what they are in a program that isn't SL which is always disconcerting rather than just hovering over it and seeing it right there in the chat window.
  2. You mean bringing SL communication up to semi-modern standards? It's already been done (or will be once the new Catznip releases) :). First was to just have proper link previews like anything else you use to communicate with (with the proper options to not have it on in groups and all that): And obviously, emoji's are a big thing (the current implementation looks a lot better than this - it was the original proof of concept from last year): And the only part that requires (new) viewer code is actually the colour emoji's (and having a way to look them up), you can do black and white emoji fonts right now just by dropping the font in the viewer's folder.
  3. Heyyyyyyyyyyyyyyy! I take offense to that! It looks great and pretty *pouts*
  4. And it's been removed; if you made/sell something based on this I suggest you refund your customers or you'll have some very angry people after the next RLVa release.
  5. They aren't changing the active group, but rather changing the active role within the currently active group to get a different group title. That part is new since the last RLVa release; the ability to change the active group (without control over the active role) has been part of general RLV for many years now. As an aside, changing your active group shouldn't make that much of a difference. Access is independent of active group, placing prims is viewer dependent (which is how viewers can have a "rez under land group", etc. Changing the role shouldn't do anything except broadcast the title string to everyone that has you on their interest list; which is less impact than a titler that keeps cycling its letters. --- That said, I've had some people poke with concerns; if I see things go out of control then I'll slap a throttle on it or remove it entirely as a failed experiment of introducing more "fun" things to play with.
  6. In addition to that RLVaEnableTemporaryAttachments setting has been around for a long while now precisely to limit the scope to only attachments you choose to wear yourself; which as a side-effect blocks all experiences related things too (since they're all temp prims). But that's really just intended to remove the surprise/undesired factor of having temp attached prims interacting with your RLV(a) when you know you never want them to. If someone is using an experience to grief, or step out of line, then the experience >creator< is ultimately responsible for how they allow their experience to be used and do abuse report that.
  7. Yes, exactly, nothing about the experience is affected in any way. The viewer will simply add the object to the blocked list and not process its RLV commands, for example with KT's script I see: [09:15] Object: failed: @setrot:3.14=force (blocked object)
  8. 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).
  9. 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.
  10. 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".
  11. 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>
  12. 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)
  13. 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).
  14. 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 .
×
×
  • Create New...