Lucia Nightfire

What I would like to see implemented is https://jira.secondlife.com/browse/BUG-6911 where popularity is shown in experience search and is based on the number of agents participating in the experience and to allow the option of this stat to published by the experience owner. I feel there are still plenty of users that are skeptical of the security and/or anti-abuse provisions of experiences primarily due to the the permission dialog mentioning that any number of possible permissions could be exercised by a particular application. Allowing users to see that a particular experience has hundreds, thousands if not, tens of thousands of participants can instill confidence or trust in the experience as well as the feature itself.

With a grid wide experience you wouldn't even need to bother with object keys and email anymore, just have your server update its current url in the kvp store and have your products check the kvp store for the current url and contact it directly.

My definitive solution to the problem was filed at https://jira.secondlife.com/browse/BUG-7941 Comments welcome.

I had an anomaly occur on 2014-11-26 at 22:25:58 where I suspected a successful read occurred for a key that did not exist in the kvp store instead of a failure and error code return. I believed the data returned by the data server was "1," where a success was determined but no additional data was returned. This operation typically takes a fraction of a second to run, but at that time I was getting repeated timeouts for reads for over a 15 second period of time with 3 seconds allotted for a timeout. This blank data crashed a processing script further down stream. I'm now including additional debugging and checks to look for this anomaly to occur in the future. Did anyone have any of their kvp apps behave strangely during the same time? Has anyone seen any undocumented behaviour with the kvp store functions?

I could have sworn it was mentioned a while back that after the second wave of key offerings that the first wave would get an additional key. I can't seem to find the email or blog where it was mentioned though. Still waiting on a grid-wide key myself, heh.

Sadly since there is no sorting option, by alphanumeric key name or by key value update time, you will have the most likely incude some kind of time value in the key name itself and check every single key when running a "cleanup" protocol. I made a region visitor data tracker app that uses the kvp store to save agent stats as well as day stats. Both agent and day key names contain a day number value which is looked for during the post-midnight cleanup session. I currently have it set to delete any agent data that is older than a day. This device is running in two slightly busy regions that together, typically acquire about 1500 agent data values a day. This means during the cleanup session, about 3000 key values are read, of which, half are deleted. This typically takes an average of 100 seconds to complete.

Whats the best way of having my Snack regions moved back to their original RC channels? I'm tired of having the capacities issues related to the few hosts available on the Snack channel which cause many of my regions to suffer problems together at once, not to mention a better chance of the regions coming back up on the same host after a restart. I ask because I don't think support is capable of discerning if the regions are even allowed to be moved off of Snack in the first place. Thanks.

So its been a while since I've seen or heard any updates on this project, but keep hearing about it possibly going to RC soon. I figured I'd ask a few questions about the current state of things. Where are we at with addressing the issue of the same general error message(XP_ERROR_NOT_PERMITTED) returned for so many different scenarios? Where are we at with finalizing kvp store pricing and sizing options? Where are we at with grid-wide-key availability?

Same goes for in-world product update servers that don't have a web service backend. You can have the server update the kvp store with it's current url. Products can check the kvp store for the current url and contact it directly instead of comm after email first. This means you can pack up your servers and move them to a new region without fear of losing connection to all current distro'd products which you would since the email/object key changes when rerezzing them. Lets not even get into the old way of resorting to attaching them and dropping in their new home region (not possible if they use mesh).

Issue me a grid-wide key and I'll get right on doing all the testing necessary to determine what needs addressed.

He's asking what you would do with a grid-wide experience key, which are different than non-grid-wide experience keys as they don't require the experience to be explicitly allowed over the land the scripts are used over, meaning they can be used anywhere unless the region and/or parcel explicitly has them blocked.

Of course you can. I use mine in half a dozen regions atm.

I have several HUD's that have user settings/skins/setups that can to be carried over to updated versions through some manual interfacing by the user. This usually requires both new and old version be rezzed and/or attached and in-world comm between and in a static format. Having access to the kvp store would allow these settings to be stored/accessed on the fly in whatever necessary order is required on the newest HUD version. I have a retro dungeon game system demo HUD that will later save user's character stats,equipment,inventory,game flags, etc. My applications would primarily benefit from grid-wide access to the kvp store. As far as permissions, I would use grid-wide experiences for demoing products that require attaching, mainly the applications I mentioned previously. This would be great over land I don't necessarily own such as stores or booths that I may be renting abroad.

Did you add the experience to the region trusted experience list or the parcel's allowed experience list?

You may want to add and delete with variable sized entries, ie ~128KB, ~256KB, ~512KB, etc sizes. From my testing, data placement is memory block oriented and fills the nearest available block that can contain the size of the data.

From my testing EM's don't get the dialog everytime. Not sure about people in GM though.

Without sorting, there currently is no way to cleanup an arbitrary sorted database without checking each entry. Apparently LL is concerned about the potential resource usage tied with sorting done on substantially large entry counts and/or frequency of use. IMO, they could still offer options for sorting with one of the following restrictions: - Allow sorting after a period of time that is based on the number of entries currently saved in the kvp store. - Add an additional cost for the option of sorting based on the kvp store size regardless of usage. (whenever pricing is finalized)

See the feature requests and their comments for: https://jira.secondlife.com/browse/BUG-7147 https://jira.secondlife.com/browse/BUG-6998

JJ is referring to sim bombing SEC-1352 There are several other crash/lag modes used daily in the Linden Weapons Testing region: http://maps.secondlife.com/secondlife/Sandbox%20-%20Weapons%20testing%20%28no%20damag/128/128/0 I don't think LL even monitors it to come up with fixes for said crash/lag modes though...

Waiting on a grid-wide key. Just one please, heh. I have a ton of apps and users that will thank you.

Bug fixes are of course welcome, but I don't consider those "shineys". I also don't consider infrastructure changes or improvements as "shineys" either. When I say "shineys" I mean user explicit usable features.Things that allow users do and experience new things they never were able to until now. This year has been the slowest year for such features as we've only had three of them become available. - Group bans via the viewer (several bugs still persist in the UI/server). - Materials updating by LSL. - Experience Tools (still in beta, still incomplete LSL/UI/infrastructure wise). I have a feeling SL2 has now become the boardroom focus for all future feature consideration and implementation...

Strangely Loki, you originally filed the feature request with https://jira.secondlife.com/browse/BUG-2284 That jira is not set to public viewing atm though, but you can change that if you wish.

I remember when we used to get occasional shinies.....memories.....

You can file a feature request with the Summary starting with [Experience Tools] which several have done already.

I think Oz said something a few OH's back about toasts being removed for exp teleporting, but the tp sound would still remain.