Jenni Darkwatch

Thank you for the update. I'm wondering if testing on Aditi will be sufficient, considering that groups on Agni are probably much, much larger. Of course, I might be talking out of my ass as usual, since I haven't got the foggiest what testing procedures you have in place. Large group chat is a tough nut to crack, though I'd guess if you'd lay out where your specific bottlenecks are there'll probably be a few constructive and useful ideas from the community. There do seem to be a few knowledgeable and experienced geeks in the audience.

Simple solution: Ignore Phoenix users (or any other v1.x users) unless you give a damn about how others see you. I obviously don't.

Sounds like a DNS error. You didn't provide enough info to provide any pointers or assistance though: What operating system do you use? What viewer do you use? In this specific case: What ISP do you use?

There are scrubber scripts out there that remove all scripts in any object. They only work in mod objects though. There is one for L$1 on the marketplace, or you can simply use the more comprehensive script for free from here: http://forums-archive.secondlife.com/54/97/331118/1.html That latter script will also kill bling and such, so beware. Also sent you a scrubber script in-world.

XMPP has its own set of problems, many of which are reasonably well known by anyone running a large XMPP server. To me, it would have brought interop to the table, though I never saw it as a straight solution to group chat. Historically, there's never been any group chat solution able to handle truly large groups. IRC didn't, instant messengers didn't, XMPP doesn't. Even MMO group chat suffers similar problems - lag being the prime problem. Without knowing how LL handles chat server-side I won't bother to even come up with any suggestions myself. Right now I suspect(!) things might be especially sucky simply because of futzing with chat code. I do wholeheartedly agree that group chat is for all practical purposes unuseable right now. I'm guessing it'll improve in a year or two, simply because that particular issue does not seem to be easy to solve.

Simply put, the key needs to listen on a specific channel. The door needs to send a request to the key, and the key needs to respond with a passphrase the door recognizes. Now that there's llRegionSayTo() it's actually fairly trivial. Step by step: 1. Avi touches door/chest 2. Door/chest sends llRegionSayTo(llDetectedKey(0),...) 3. Worn key gets the message and replies directly to the prim with llRegionSayTo(kDoor,...) If you need it more secure, you'll need a password/passkey scheme.

In that case: http://wiki.secondlife.com/wiki/On_rez (triggers when you log in, among other things) Or alternatively: http://wiki.secondlife.com/wiki/Attach (same, sortof)

Looky here: http://wiki.secondlife.com/wiki/LlRequestAgentData (especially the online query)

Killing just the gesture sounds is easy and exists in every viewer (see previous post). What sucks is the gesturbating chat spam that makes local chat useless in most venues.

Neat trick, Void. Thanks for sharing.

Temp has no grace period... the timer counts down even if the avi sits on it, meaning if they stand up a minute later the object will immediately disappear. Removing and re-applying the temp property also does not reset that temp timer. I guess you'll have to go with a timer.

Thanks for the heads-up

InventoryLinking = TRUE ToastGap = 0 Both are, I think, Viewer 2 specific.

RedZone got banned, but other such tools still exist in-world and are "functioning"... well, as much as they can with asshats like me deliberately feeding totally bogus info into their databases.

Just ditch the HUD, I believe, and optionally use the garlic necklace so they leave you alone.

It was akin to dropping a nuke on a city to eliminate a bank robber. _IF_ they wanted to stop abuse there would have been better ways. IMO they just didn't want educational or non-profit organizations on the grid.

For many things it actually is. For me anyway. Inter-region, sure, it won't do any good, but for inter-region I use an offworld server anyway.

Damn that's one useful function! I'll have to mess with it, but it seems like this will make secure inter-prim communication much, MUCH easier. Goodbye HTTP, welcome llRegionSayTo. Thanks for the heads-up.

Wildcat Furse wrote: Woot, that looks amazing Jenni ..... and the horse is cool :smileywink: *meows* That horse is me ~winks~

True. I think it's the deceptively easy scripting that's both the boon and bane of SL.

All good points, and IMO all true. Scripts in SL are, mostly, atrocities as it is.

Not enough info to even guess what the problem is. What is your connection speed? What viewer are you using? What OS? etc.pp.... there's basically everything missing to help you out.

Very lovely thread! The ground level of our land is a ~50000sqm public park with access to protected water for boating. There's a huge build platform in the sky for private (group) use, though every once in a while I have to evict strangers from it. For my own purposes I assembled this little 32x32m skybox: The whole skybox is built so it gives a permanent impression of nighttime, even during a normal SL daytime cycle. In addition it is purpose-built for shadow-enabled viewers, using it as a learning experience. It's build like an old ruined temple/fort, dark though not evil.

Ze Marabana wrote: bin/do-not-directly-run-secondlife-bin: error while loading shared libraries: libSDL-1.2.so.0: cannot open shared object file: No such file or directory *** Bad shutdown. *** Well, there's your problem. You're missing some libraries, in this case the SDL library.

Simple question, not sure it's the entirely right forum: 1. If I upload an image, grab the UUID and apply it via script to a prim (using the UUID) and then delete the image from my inventory... the image on the prim seems to persist indefinitely. Is that indeed correct or is there some kind of periodic garbage collection running on the asset system? My current gut feeling is that the asset persists _at_least_ as long as the texture is in use _somewhere_. 2. Whether I copy a texture or pass it around, the UUID seems to stay the same. Correct? I tried giving it to a friend and then receiving it back, putting it into a prim inventory and reading the UUID and simply copying the assed in my inventory.