Jack Abraham

...I don't have the time to fill out forms... Then you don't get your bug fixed. If you can't be bothered to do things right, don't expect Oskar to do them for you. His job is running QA, not doing bug reports that would take less time than the forum posts you just did.

Oskar, I suspect SCR-243, which doesn't manifest as long as the region is restarted weekly. It reappared on my region on Monday, I restarted it, and it went away until next week. This happens any time there's not a weekly rollout. I believe the JIRA already documents this.

Thank you to everyone involved, Oz, Brooke, and those behind the scenes, and to Marine for identifying the bug early. This is starting to become a trend, and it's a good one.

Seems to me the most important issue is that people with access to the experience tools be accountable. I think even a L$10 fee to register an experience would discourage a lot of griefing. But it's not up to me. The Lab has a history of hitting their feet no matter what they aim at, but the last few weeks have seen some noticable improvement; I'm trying not to get my hopes up, lest they be dashed again.

/me wishes he had a "Like" button here.

Ela, you misunderstand: My system failed when the communications hub was derezed, but returned to operation as soon as a new copy of it was rezzed. It can be done; I've done it, and I'm considering open-sourcing the scripts.

#2 is not trivial at all. Staff members could be in another sim. There is no inter-sim communiations between objects except for email. Object email requires knowledge of objects keys (uuids). As an object key, in difference with an avatar key, is not static and changes with each rez a totally in-world reliable handshake protocol cannot be implemented. Ela, I have a reliable inter-sim inter-object communication setup built for just this sort of use. The worn device registers a HTTP-in URL with the central server (also an in-world object) and receives messages relayed through that central server. It's absolutely doable without having to have the object keys. I've not had it fail once in two years so long as the central server remained rezzed.

Expectations: It has never been expected that this flag would control online visibility to scripts and while it might be reasonable to extend it's features in this way changing the meaning of any long-standing feature should be undertaken with great care. Kelly, while that may be the expectation of long-time users and developers, my anecdotal experience is that everyone is surprised to find it to be true when they discover it. Perhaps this could be addressed from both viewer and server sides, with the viewer-side switch for the current flag renamed to "only scripts can see my presence" and introduce a new flag for "appear offline" that gets around the code complexity issues. From a privacy standpoint, I'd like to have the option to: Appear online to everyone (independent of whether I appear in Search) Appear online only to people and objects to whom I've granted permission to see my online status; groups see me as offline; inventory offers, IMs, teleport offers, etc. from people who can't see I'm online are treated as though I'm offline. Appear offline to anyone not in a position to render my avatar; local chat, sensors, etc. work as usual, but anything non-local shows me as offline. I'd like to be able to set this state prior to logging in, so that I don't appear to go online and then offline immediately. To get to this ideal state, scripts need a new permission to determine whether they can see my online state. For lots of the legitimate use cases, they need to be able to maintain this permission for an arbitrarilly large number of avatars, so it will probably have to be handled outside of the current permissions system. Could a whitelist version of the block list be implemented to handle this? I'd certainly want the permission to be revokable, and since it only has to be checked if I'm actually online but not appearing so to people, the viewer could handle the query rather than the central database. So... is_online( avatar ) { if ( is_really_online() ) { if ( !viewer_says_is_online() ) { return FALSE; } return TRUE; // Handle legacy Viewers that say WTF when asked } return FALSE; }

If the sim owner's willing to reset the sim, you could always ask the sim owner to return the offending objects.

Dale I'm sure that typing in BOLD will help fix the problem. Seriously, if you want information about what's happening with bugs, look at the bug database: http://jira.secondlife.com/ . Yelling at Oskar won't help.

Lindal, I suspect Frank meant to type "reply" rather than "rely". I loathe the format as well. I'm the scripter on the device in question. What it's reporting is that either it can't confirm that it can rez, or it can't confirm that scripts can run after the object's rezzed. Without visiting the parcel, I can't tell what's going on. What I advised Frank to do was reattach the HUD while he had he land group active, so that the HUD would have its active group set to the land group; my theory was that the land group always allowed rezzing whether active or not, a condition the HUD can't detect. The HUD relies on either the resident or the HUD's active group having build permission on the parcel. If the resident is not the landowner, build & scripts are not enabled for the HUD's active group, and build & scripts not turned on for all residents, it will abort creating constructs with the error message specified. Frank, I'm still willing to come look at the problem when inworld. Send me a SLURL.

Ayesha, if I'm reading Oskar's update right, the code with the ghosting problem will be pulled back and a different one, "maint-server", will be deployed to all the RC channels.

Hang in there, Oskar. The IT operations pros among us appreciate your professionalism. And Kelly, thanks for killing inventory spam. To paraphrase the meme, spammers gonna hate. I look forward to not having to relog and then dump a few score items from my inventory.

Ayesha, if I'm recalling the explanation correctly, trying to implement mega regions would probably make sim crossings even worse. They've improved dramatically in the last few years, and I expect they'll continue to do so. We all want things perfect right now, but I take the view that SL is like a dancing octopus. You may may think the octopus dances poorly, but I marvel that it dances at all.

When I raised this with a former Linden a few years ago, his explanation was that there are a large number of places in the simulator code that assume a region is 256m x 256m, and that it would be a staggeringly large project to track them all down and change them to allow for megaregions (or microregions). OpenSim obviously didn't make the same assumption, but we are where we are with SL.

By that logic, web profiles, your profile's inbox, its feed, etc., are also bad for business. I happen to think they're a bad idea too, but that didn't stop the Lab from implementing them. I know this has been requested more than once, but SVC-6325 appears to be the current incarnation.

Oskar, if you are considering this, it's a mistake. You guys are doing the best you can with the resources you have. Since you can't get a decent test on the beta grid, release candidates, and expeditious handling of real issues, is all you can do. You're doing both. Ignore the whiney ones.

Vampires have been shoving whiners into portals into Linden Realms?

TriJin, that truly made me laugh out loud. Now everyone's looking at me funny...

Zena, have you filed a JIRA for it?

For a lot of reasons, not just SL, I'm about ready to give up on Lion and roll back to Snow Leopard. I'm getting the idea Lion just wasn't quite fully baked. Apple should not be having hardware compatibility issues since they control the whole stack, but my wifi and suspend functionality has been flaky since I converted.

Oskar, release notes appear to be messed up. The notes for Magnum (11.09.20.241144) don't mention the fix for SVC-7283, but it appears to be there from my testing; the notes for BlueSteel (11.09.15.240906) do mention it. I haven't checked to see if SVC-7283 is fixed on BlueSteel and LeTigre.

You're taunting me, Oskar. I've been salivating for llCastRay for over a year, and now... SVC-7283 means I can't work on the stuff that would use it! You meanie! Still... Wahooo!

Void Singer wrote: the only instance of a (non RLV) hud that cannot be rezzed is one that self destructs when you do so. I have zero sympathy for any creator who does that, and recommend user avoid their products like the plague that they are While ours can be rezzed, Void, it won't work. It needs to handshake with another worn object, and it is all but impossible to manipulate the controls (try hitting a 0.015m cube that's invisible on five sides and partially transparent on the sixth, embedded with 102 other prims never intended to be seen any way other than end-on). If rezzed on the ground, it basically says "don't do that" and shuts down until taken back into inventory and worn. And inventory transfer is part, not of its updating, but of its normal functioning. Not to say I don't think a SEC fix shouldn't take priority. Just to point out you haven't thought of all use cases.

Sounds like the revenge of zFire Xue. For reasons I can't discuss on a Linden forum, I'd recommend avoiding his products with the same vigor you avoid giving your credit card to random people with whom you don't do business.