Home
Creators
Search Recent Missing Random
Posts
Search DMs Popular Hash Lookup Tags Random
Importer
Import FAQ
Register Favorites Keys Review DMs Logout
Community
Telegram ThePornDude
Home Creators Posts Import Register Favorites Logout

So I tried experience keys (rant) (Patreon)

Published:
2016-06-18 15:23:58
Imported:
2026-06

Content

So I decided to get myself a premium account, which I will be changing back to a free one again. The reason I got it was to try the SL experience keys where you can create an experience to be granted permissions. The main goal was to be able to grab permissions once an avatar attaches a HUD, and then not have to bother with permissions again. The system is so restricted that it's practically useless, and I wonder what they were smoking when they designed it?

Here's a comparison for force-attachments:


Cost

Experience Keys: Premium Account

RLV: Free

This is the first major advantage RLV has. If you get banned or quit SL, RLV will continue working regardless. If you use an experience, everything breaks and there's nothing the consumer can really do about it.


Region

Experience Keys: Land-locked

RLV: Grid-wide

This was the deal-breaker for me. Even if you get a premium account, you have to own land (which is ludicrously expensive) and then your game would only work on that land. Imagine if game of thongs ONLY worked on Quiddity. That would severely handicap the game. There is a grid-wide key you can obtain, but there's no information about it. I've sent a support ticket to LL and will update once I get a response.


Availability

Experience Keys: All viewers

RLV: Third party

This is one of the places where experience keys wins. Though not by far considering that third party viewers are far more used than the official one.


Open Source

Experience Keys: Limited support

RLV: Full support

This is another dealbreaker. You need to be granted permissions to compile scripts for the experience. This makes the experience permissions more secure than using RLVs @accepermissions for forced-attachments. However, it also means that only a select few will be able to work on the project, which essentially DESTROYS the idea of open sourcing and allowing anyone to mod the code. I know you could theoretically give experience permissions to everyone in the group, but that would make the system even LESS secure than RLV as you'd be able to force-attach temp attachments even when you're not wearing the HUD.


Security

Experience Keys: Good when closed source, nonexistent when open source.

RLV: Decent

An issue with temp attachments is that with RLV you might receive some with exploits, which then stay on your avatar and can do things like track you without your knowledge. With experience keys you can blacklist certain experiences, but experience keys can be exploited as well unless you make the item closed source and the HUD no mod.


Functionality

Experience Keys: Flawless.

RLV: Buggy

This is the main reason why I wanted to use experience keys in the first place. Some times @acceptpermissions will be ignored by the viewer, and you will still get attach permission request popups.


In conclusion I'd say the way they implemented experience keys was a massive waste of time. I can only hope that Linden Labs go back and revise it completely (make it pay per experience like Groups), or just leave it dead in the water where it's currently floating.


Update1:

I've filed some JIRAs to hopefully help improve security without removing the RLV attachment feature. Feel free to go and comment!


Firestorm (improve security): http://jira.phoenixviewer.com/browse/FIRE-19492

SL (temp attachment lists): https://jira.secondlife.com/browse/BUG-20047

Comments

Anonymous

What a fantastic writeup. I had no idea that the experience system was so utterly useless. I'd been considering giving it a shot with my own work, but now I know that I'm better off just sticking with a free, imperfect RLV. Thanks so very much for sharing!

Kadah

The attachment popups seem to happen most when the viewer is minimized. Not sure if that is a bug or intentional.

jasx_games
>>1996824

I spoke to Kitty today. The most likely reason is the fact that firestorm DOES limit to owner. And if the script loads before the client loads it, it will start requesting permissions manually. This might also be an issue if objects don't load in the viewer until they enter your FOV (though it has to be tested). Let me know if you do any experiments with it. I will at some point.

Anonymous
>>1995859

Well the video for it back when it was beta and you had to send support tickets just to get even the personal experiences keys and only for large already made games had it hyped up so nicely, looked like full permissions over avatar after the initial request with all the needed permissions mixed together and then the big thing interested me was the key-store database. They saw too many exploits even then I guess, so they went with the split idea, and then reduced it more and more. I mean this is what they had before they even announced it it was secret compiled flags in the experiences for the linden mini games like the realms and field games.

Anonymous

I didn't know how they released it, after the closed quiet beta they were doing, I hadn't heard any more news of it, and only they used it themselves in those halloween haunted ride trip, and the corn maze, and other minigames. I didn't know they decided on making it paid premium only instead of just signing up with some form and review process (which is still in place for the global keys, yeah you have to mail them, I think there was a special email though for it same as back when it was quiet beta). You've been working on the XOBJ intercommunication stuff, couldn't you have a small closed source script hook all the required functionality and then people would be able to send inter-script communication for events to trigger? The experiences require the permission to compile but then couldn't that compiled script be dragged in and out without modify permissions and still work? Since if you don't modify a script or notecard, even if it has a different uuid in inventory it's more like a symlink/shortcut uuid to the real already compiled AND uncompiled versions on the server. So if you edit, then it makes a new script and tries to compile, but if you don't tamper, you drag a copy from inventory it should stay the same compiled asset on the server side (the whole point of going mono was for this purpose of using a single copy in memory with only separate variable heap and cache a single file). As far as the out of focus/minimized issue, RLV isn't the only thing affected by it, I find all kinds of weird packet loss when minimized, which is silly because minimized and out of focus should both use the same throttling you would think. I've found though that dual screen, up, but out of focus while I'm on other screen with browser or something, it will frame-limit-sleep so fast flipbook effect, which is fine, and still slowly loads mesh and textures if they're forward in camera aim. When minimized though, group notices ding-ding but then never get received sometimes, the existing people and objects stay loaded but the new people and loaded things will build up in a pending queue but never download in background, when that fills up it just stops attempting to load anything. If you leave it like that, you stay logged in for hours, but as soon as you try to unminimize it starts to try to catch up and you either do manage to and end up with invisible avatars or every idle animation/deformer all broken and squished, or it just logs you out after a minute (while you were still definitely connected because you can send and get recent messages and chat and still lets you walk around until it just decides to ding and force you to close the program). So there is certainly something (likely everything, the sleep is probably in main loop) that just gets skipped in the main loop along with the rendering pipeline.