Lucia Nightfire

File a feature request jira.

llSit() was discussed in the server OH yesterday. Sadly Simon hasn't been posting transcripts in awhile. It was agreed that it would have to have the same owner restriction as PERMISSION_TELEPORT unless used in an experience. Additionally I think llUnsit() could be tied in to work on non-owner/land owner objects as well if inside an experience.

I went to the location posted, clicked the arcade machine and got a dialog request when using the latest Firestorm viewer. http://imgur.com/9gOr5er I repeatedly denied the request and reclicked the arcade machine to continue getting the dialog request. Linden Realms is the only experience that comes to mind that auto-grants the permissions for the first time. Sadly you cannot Forget the experience either, heh.

What about grid-wide experience keys? I have at least 3 products I'm envisioning that would require access the kvp store from anywhere on the grid, all of them HUDs. I'm willing to pay a significant purchase price for one as I think the cost is worth the benefits for the kvp store access alone. Hopefully they will be included in the future pricing/availability options.

Sort of dangerous as it could be abused as conventional perms could be exchanged and kept. See https://jira.secondlife.com/browse/VWR-13228 Maybe in SL2 we'll finally have the option of blocking perms permanently as the current revoke system only works once per "saved" asset.

The wiki says look_at is in local coordinates, but I only have success using region coordinates. Something I noticed with experience based teleporting is that lookat seems to be broken as I always face east after an experience based tp intra region whether or not its on my own land or on group owned land or if a landing point is present or not. I do not have this problem using my own tp HUD that uses llTeleportAgentGlobalCoords(), but doesn't use experiences.

Are there any characters that shouldn't be used as keys or are ignored? Hopefully there are no magical combinations of unicode chars that could have malicious affects on the kvp store.

Have features such as value search options and key renaming been discussed already?

Temp attaching itself prevents inventory clutter. The auto-detach behaviour which only occurs from experience based attaching whether it is by llAttachToAvatar() or llAttachToAvatarTemp() forces content to only be usable over the experience based land it was attached on. This is why it hinders product potential as it forcibly localizes any use case for experience based attached products.

See https://jira.secondlife.com/browse/BUG-6858 The auto-detaching behaviour hinders content creation. Experiences initially seemed to have been envisioned to be solely used in one region, one estate or same land owner parcels, which is strange considering grid-wide experiences were also created. Experiences have more use cases and potential other than gaming applications. In fact, I believe once experiences are released to the public, they will be used primarily to temp attach demo products, teleporting systems and database storage capability. In regard to temp attach products, the experience will mainly be used in a secondary script that upon attach, will be disgarded and/or no longer be used. A primary script that allows interfacing will then auto-grant conventional detach/controls/animation/etc. perms. This will allow the demo product to be worn and interfaced with when the owner leaves the parcel. Currently with the auto-detach behaviour, customers using the experience to temp attach products are restricted to the store/mall the product was attached at. They cannot go to a friend's home or info hub or hangout to show off the product or to ask opinions on it from anyone outside of the location it was attached at. Let's even forget about experience based temp attached hunt HUDs or vehicle shells/HUDs or pets, mesh bodies and so many more attach based products that aren't localized in nature.

Unless you grant perms conventionally upon attach, you will have to request exp perms for each perms based operation. You will still get legacy errors though while you are over parcels/regions that have the experience blocked or not allowed. Interestingly, you can place an experience based scripted object over a parcel that has the experience blocked or not allowed and it will still be able to affect agents on parcels that do. I never could think of how that could be abused, but I'm sure there are more creative minds out there that could, heh.

IMO, we're certainly not emulating SQL with KVP, but that depends on what DBA you ask, heh.

Governance is capable of blacklisting any scripts. Since experiences are compiled components of scripts, maybe SOP's could be revised to allow governance to honor requests from experience owners to blacklist a script in the rare event of abuse from third parties. This would be favorable especially if the creator already has an entire product line devoted to the experience or a significant amount of user data assigned to the associated database or if the experience has quite a following of users as well. Without this option, there would be no temporary damage control with the rare event of bugs, exploits or rouge contributors as the risk would always be present if the scripts were still available and/or active.

The unlimited inventory issue will no doubt be addressed in SL2, heh.

I would hope governance has been trained correctly to identify abuse of experiences at the correct level of use case & ownership like they do with existing distributed third party content, of which, I think they are since I haven't heard of them blacklisting products outside of those that infringe on copyrights or those that impair region stability such as sim crashers. There is still quite a lot of distro'd spam, laggers and copybotted content so I wouldn't worry too much yet on third party abuse of experiences. I would, though, take extra care in setting up experience based scripts to prevent such scenarios. Secure your scripts so they can't be interfaced with by means other than originally intended, keeping in mind that some users may disassemble your product, removing your scripts and placing them in their own objects or adding their own scripts to your product if able. Once experience purchasing becomes available you can assign a different experience to a different product if necessary such as if one product is themed differently than the other or is rated differently. You don't have to have land powers to rez an experience based scripted object, but the parcel/region would have to allow the experience for the script to operate. When requesting experience permissions from an agent, they must be in a region or over a parcel that allows the experience or you will get a experience_permissions_denied() event return. This is all for non-grid-wide experiences though, which is what we have access to atm. Grid-wide experiences are the opposite, which will work in a region or over a parcel unless explicitly blocked.

Its not a hack, its simply an additional data point sent with the compile data that currently no other viewer sends. Server side checks still occur to see if the compiler has the right to attach the experience with the compile(expereince owner/contributor).

Judging from the response to that feature request, you'll probably have to wait it out for experiences to be released grid-wide first before tpv's are allowed to pick up the same script compile procedure and UI as the project viewer. It is a little annoying as I deal with the same thing. I just stay logged on the project viewer when I'm working on experience based script compiling then switch over to the tpv when I'm done. The priviledge to be able to work with experiences early is worth the gripes, especially dealing with the UI and lack of tpv goodies.

My experience will not be complete for quite some time as I've recently decided to attach my Experience to an old retro dungeon game concept I made over a year ago that I haven't touched since. I will be working to complete a fully playable game over the next few months. The current demo doesn't even display 1% of the game's capabilities, just the proof of concept which was a non-MOAP based faux 3D dungeon crawler emulation similar to the ones that were popular in the 80's & 90's. I do have a bare bones demo at http://maps.secondlife.com/secondlife/Mauve/79/80/34 if anyone wants to see it in its extreme infancy. Just click the box with sword icon and make sure you're operating params match those required by the game.

If you are allocating db(key value store) space, you'd may want to include some form of timestamp with the data upon read,create,update activity so that you can perform periodic maintenance and old entries be removed. In fact, that gives me an idea to file a feature request to get the last created,accessed,modified times for an entry. I'll wait on people's opinions first before I jump on it though as those values may only be available for the whole db instead of per entry.

If you absolutely need to use the experience's db to keep track if the HUD is worn, then maybe include the HUD's key in the data. That way if they leave the area into a no script region and return wearing the HUD or if you're using a multi-region setup, you can check if they have it attached already by key with either llGetOwnerKey() or llGetObjectDetails() & OBJECT_ATTACHED_POINT.

Didn't see it mentioned in the release notes but https://jira.secondlife.com/browse/SVC-7858 should be fixed grid wide as of today.

Every single region on the grid apparently just got a 10 minute restart notice for maintenance.

Funny how the LeTigre Sandbox 1 - 4 regions aren't on that list, lol. And also funny how this reply is on a different page, heh.

Had that happen this week in a Bluesteel region when it came back up after it's roll to the latest version. Support said something generic such as it didn't restart properly. A restart fixed the issue.

I emphasized the problem in https://jira.secondlife.com/browse/SVC-7959 last year. The region restart queue process needs some work. Judging from the data I see with restarts over the last year, it does seem that sim state saves do play some factor, but if there is a considerable amount of time left before the next state save this is ignored and the region is scheduled for the queue without any early/forced save. This is probably to prevent a possible surge of regions entering the queue since state saves are not all synchronized to any global timeframe. Still, I think there could be some tolerance of time left for next state save where an early state save could occur given a query for timing from the queue scheduler, anywhere from 30 minutes to an hour. This range of time should be a enough range to populate a proper queue without worry of any surge and in-turn reduce downtime for each region as well. It just isn't happening, lol.