Jump to content

Lucia Nightfire

Resident
  • Content Count

    1,800
  • Joined

  • Last visited

Posts posted by Lucia Nightfire

  1. 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.

  2. 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?

  3. 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.

  4. 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.

  5. 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?

  6. 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).

     

  7. 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.

  8. 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)

  9. 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...

×
×
  • Create New...