Lucia Nightfire

When will we be back to regularly scheduled shineys? Cause this well has run dry.

When I went to Skinny Dip Inn and noticed that with 60 agents in the region, there was no spare time left. The total average script timing of all agents in the region consumed 3.5ms - 4.0ms of timing the rest most likely are being consumed by all the vendors in the region. There may even be a few that are using excessive script timing. A look at Top Scripts will show this info. What stood out though was the number of active scripts in the region, which was over 14000. The average script count of all guests was under 4000 leaving 10000 for everything rezzed in the region. This is an excessive amount and should really should be less than half that value. There are many events going on in the background that are not reported to sim stats. Some of the top events that have the most severe impact the sim are script loading/unloading and mesh physics data caching. The former occurs with scripted attachments entering and leaving the region as well as with rezzing. The latter occurs with any mesh object whose physics data doesn't exist on the server. The server downloads and caches this data before the entire object is released to the server for rendering, whether it be a rezzed or attached mesh object. While this data is being requested and is caching, the entire asset handling thread is waiting on this caching to finish before another mesh's physics data can be cached. This blocks other events on the same thread and causes major region FPS fluxuation, delayed rezzing, delayed attaching and a delay for attachments to appear on guests entering a region. See https://jira.secondlife.com/browse/BUG-8946

For a security update, I'm surprised 16.05.19.315570 only went out to LeTigre and not all servers last week.

Why was LeTigre rolled to 16.05.19.315570? There is no info anywhere about it. I did notice certain code that is on 16.05.12.315246 is not present on 16.05.19.315570.

So I'm looking for some new shinys. Know when they're coming? heh

Why are the RC channel regions rolling to main channel? My home region, a frequented sandbox, even Magnum Sandbox 3 was just rolled to main channel.

Goodbye sim bomb & blocked asset detection. It was nice knowing you. Too bad LL won't actually fix those vectors, heh.

Unscheduled maintenance was just announced. http://status.secondlifegrid.net/

This issue is filed under https://jira.secondlife.com/browse/BUG-9725

Gestures would have to be given their own chat type for the suggestion to work, but this could be circumvented by existing illegal tpv's. Alternatively, parcels could be given a setting that blocks chat on the parcel and a setting that blocks chat originating from other parcels from being seen. These could be setup at the public and/or group owner level like rezzing, object entry, scripting. Currently, parcel privacy and bans result in the same effects, but at the cost of no visibility or no access. Theres also the bug https://jira.secondlife.com/browse/SVC-7790 that allows attached sounds on parcels to play despite the parcel not allowing sounds. Theres also a request for a parcel setting to block shouting at the public and group level with https://jira.secondlife.com/browse/BUG-3854 along with resource control. Sadly, we may have to wait for project Sansar with its prestige-for-privilege system to come first before we get access to better land controls.

https://jira.secondlife.com/browse/BUG-6455 may be of interest

Actually "agent_limit" for llGetEnv() was also included in the code rolled out today.

Did you forget "agent_limit" for llGetEnv() or was that shelved at the last minute?

I had another successful read with blank data occurred again at 2015/03/27 23:26:10 in the region, Shiromani. "1," was returned instead of including the data from the key. A second read attempt returned data. So everyone should be aware that it is possible for a successful read to return no data for a key value that is not an actual null string.

The permissions dialog looks the same for both Land Scope and Grid Scope experiences. I have received several concerns from users about the nature of the permissions dialog and how it lists all possible permissions an application can exercise even if only one is actually used. I could only direct them to blog and wiki info on experiences and tell them it was out of my hands. In a related note, I did file https://jira.secondlife.com/browse/BUG-8044 in hopes that behavior with llAgentInExperience() in Land Scope keys can be changed to that of Grid Scope keys so no false negative cases occur.

I was not aware that my Land Scope key would be upgraded to a Grid Scope key. I thought I would be issued a separate Grid Scope key. I have applications using my current key that I do not want to operate grid wide, only over land the users have the right to allow experiences over. Could I have my key reverted back to Land Scope and a separate Grid Scope key issued? I will take one with no KVP store size if necessary. Thanks in advance.

Another question. Will all keys issued, both land and grid scope, be ours to keep once beta testing has officially ended and Experiences are on the standard release viewer? I'd hate to have in-world applications using an experience with over a thousand participants suddenly yanked out from under them.

I think there are some changes to grid-wide key usage & ownership that have to be made before we will get them.

From my testing it seems the issues could be mainly local, primarily in the design setup. Some areas or concern: Negotiating permissions across repeated multi-environment conditions such as rapid collision, rapid attach and rapid teleport attempts with insufficient checks to prevent repeated failures and/or unwanted repeated actions. Another issue could be agents who have no attach slots available causing https://jira.secondlife.com/browse/BUG-7702 Another issue could be the short time the permission dialog appears on screen before minimizing.

Also, is a Grid Scope key the same thing as a grid-wide key or are there limitations?

I sent an email but got some strange error flash on my screen that didn't last long. Please let me know if my email was received. Thanks.

I've heard pricing has been finalized, but isn't ready to be published yet. I look foward to seeing it soon so I can see how feasible my ideas will be versus cost. In regards to the questions: 1) I have many applications that would use it. Some have yet to be created as they will require grid-wide keys and I don't want to give away too many ideas at this time as I'd like to be the first out the gate with those products when experiences are finally available to everyone. 2) Variable due to cost, application and/or popularity. 3) My primary application that doesn't use the KVP store is a region teleporter system. 4) What I hope comes into fruition later is a means of "partitioning" the KVP store under an experience. This may be possible with child experiences and allow quicker and easier KVP store maintenance with a particular application instead of having to check every single key of an overall potentially huge KVP store. It will also be a more attractive alternative to purchasing an additional entire experience as well.

I had two times during Jan 4th where I got back to back "key-value store communication failed" with write attempts, one in the afternoon and one at 18:15:39. I had another on Jan 5th between 09:32:14 - 09:32:28 No other errors detected. I would have reported it sooner had I thought anyone still looked at this forum, heh.

Hopefully this year we will get more than one LSL feature implemented.

Glad to see a few of the experience bugs are getting fixed. Nothing is more of a turn off than a new feature released full of bugs, heh.