Dolphin Linden

Thanks for taking the time (and not being afraid to make changes)!

Best recommendation I can offer is to make a feature request through JIRA. Any new functionality, Experience Tools related or not, will have to go through normal channels.

The data store treats it as a binary blob of data, so it should be safe to use anything.

Search is something we would definitely like to support, but there are heavy considerations to how we can make it useable, but protect different experiences from interfering with eachother due to long running queries.

llAttachToAvatar detaching is a bug, it is not inteded to auto detach. This was introduced fairly late in the cycle while working on a long standing bug which caused attachments to be ghosted on some people's viewers if they detached during a region crossing event. We are working on getting a fix through the sim pipeline.

I am a little confused as to what behavior is in question here. Can you give me a little bit more explanation? The thing that is really missing, in my opinion, is a parcel changed event, so you can know when to try to re-request permissions. As it stands, the only thing you can really do is periodically check to see if you have changed parcels, and then re-request permissions then.

That would be a bug The intent is that an unchecked update will create keys which do not exist.

That looks pretty yucky Unfortunately I have nothing in the way of helpful suggestions.

Currently, the only action you can take is you disable the Experience (the setting is available on the profile editing page). This can be used for shutting down the Experience temporarily for damage control or other reasons, but there isn't any way to find or get rid of bad scripts after they are out there.

Let's say, hypothetically, you end up with a rogue contributor who makes a bunch of abusive scripts for your experience.  Is there any way to do damage control for something like that?  Or once those scripts are out are you doomed and you need to reset your experience?

The other side of the coin is that restrictions can always be lessened or removed. Adding them or tightening them however is very hard to do without making people angry, even if they themselves are not personally affected. The experience db is a new feature that will have to be evaluated in an ongoing manner. Changing the limits is easy, but making the decision to do so is complex as the effects it has on a large, (nearly) always-on, distributed system must be considered.

The real problem here is that there is no way for the sim to determine the scripter's intent if no experience is sent with a script when it is compiled. Do they mean remove the experience or do they want to keep it the same? Making one decision over the other will incovienience different people. It is also an intentional decision to fail to save a script if you try to use an experience you do not have rights to. With your suggestion, in this case the script could not be saved by someone not in the experience and there would be no way for them to fix it (i.e. they could not change or remove the experience even if they had modify rights on the script). I cannot speak to the schedules of the TPVs but the script signing is not terribly detailed (one call to get a list of ids and then you put one of those ids in the save request).

1) Is defintely a governance issue. 2) You will want to separate experiences where it makes sense. One is to limit the fallout for an AR, but also to keep people from being confused about what they are participating in. 3) Yes

We have a fix for this. it should be in the next update.

While I agree with the sentiment, but I have a different view on the roles. In this case Linden is more like Amazon Web Services and the experience owner is the MMO developer. If an MMO developer wishes to retain content for old users they need to manage the data and pay for the storage.

A grid-wide experience is one that doesn't need to be explicitly allowed. It is allowed by default, but can be specifically blocked.

The main place where you are likely to see a fee is if you need to make use of a lot of persistent storage. Every experience will have a set amount (the beta experiences are set at 128MB) that is included, but if you are going to need more we might have to charge for that based on usage. If/When we introduce grid wide experiences, they may very likely have a more expensive price associated with them.

I am not really involved with viewer development so I cannot say what sorts of feature requests will be accepted. That said, if you think you need something, and it will be helpful to others, then go ahead and make the request. Your chances are going to be better if the request is detailed and considers as many scenarios as possible, the edge cases as well as the normal use case.

From another thead I think you already answered your question, but yes, the kv functions only work where the xp works.

I would strongly suggest that any configuration data for your Experience be kept in the kv system. LR uses a script which reads all the settings from a notecard and updates the db appropriately. Things like messaging channels and script load pins are very important to keep secret, so if you put them in the kv storage they are not leaked even if the script is leaked.

The easiest way any resident can get the key is by right clicking on an Experience profile link and selecting copy slurl to clipboard. This slurl has the key in it.

I am not aware of a good solution that will work in all cases (teleport to no-script/non-xp region, logout, disconnect, etc.). The best be is probably a combination of the suggestions above. A HUD can send messages or update the db while it is active, with a timestamp. It can also send messages to an object in the region which can do this on its behalf. A monitor script can use something like llGetAgentList as well. If you think it might be useful, you might add a feature request to add flags to that function to get a list of people either in or not in the experience.

It is probably heavy in programmer speak, but the json docs are http://wiki.secondlife.com/wiki/Json_usage_in_LSL The short version is that you can use it to save information is a safer manner than using strided lists or other methods. A lot of old code will make lists like: [resident1name,resident1score,resident1level, resident2name,resident2score,resident3level] or a separate list for name, score and level. With json you can use names and indices for everything: string res1score = llJsonGetValue(players, [0,"score"]); //i.e. get the first player record, then get its scoreAs for your last question, nothing happens to the db automagically, any changes to it must be done by a script. The db doesn't know anything about users, it just knows key and value strings for the experience, there is no per user storage. This also means that it is probably a good idea to store the last accessed date for some things so you can purge or compress old user data to keep the db size down.

I dont know if it helps, but you can think of it as a table with two columns of strings: key |value--------|------bob |hudkelly |nohudfred |hudpat |hud llReadKeyValue("bob") would raise a dataserver event with "1,hud" as the value llReadKeyValue("bobo") would raise a dataserver event with "0,14" as the value ("key doesn't exist") llCreateKeyValue("mona", "nohud") would add another row llUpdateKeyValue("bob", "nohud", TRUE, "hud") would update bob to "nohud" All that being said, if you want per person data you should use their key, as display names are not fixed or unique. If you have multiple bits of data to store per person, the best bet is to put it under a single key and then have the value be everything you know about that person (a json string is perfect for this).

Actually, the moles really wanted something like this for the cornfield as well. Anything on the viewer side isn't really enforceable so even with this feature added to the official viewer, you could not count on it applying to everyone.