|
Tillu Bomazi
Where did he go?
Join date: 26 Oct 2004
Posts: 8
|
11-24-2004 12:25
Hello, I've gotten into the habit of attending a popular Bingo event on weekends. For the past couple of events, however, the hostess and her regulars have been annoyed by the repeated triggering of some fairly obnoxious WAV files. Repeated pleas by the hostess and other attendees have netted no mercy from the griefers. Attempts to locate the culprits by simply walking the area and triangulating on the audio fade have also been inadequate, since the venue is so thickly populated during the games. The repeated griefing is beginning to take its toll on the hostess's rather remarkable patience and good humor. I'm presently learning LSL, and don't consider myself competent to critique the language's overall feature set. However, it does occur to me that a reasonable design goal for the language might be to make scripted objects potentially sensitive to anything which can directly impact an avatar's in-game sense-analogs. For that reason, I would like to suggest augmenting the sensor suite to permit basic data collection on any WAV files playing within sensor range. Another example, not directly related to the problem which prompted me to post, but nonetheless in-line with my ideal of LSL: Perhaps sensors could also collect general information about active particle systems? I know a great deal of design can go into tuning particles, so the information collected for this event would need to be very general, I suppose...just a location vector, owner, and perhaps a current emission frequency? Certainly not enough to pirate a particle designer's hard work, but enough to provide a reasonable "radar" into something which directly impacts avatars' "senses" for better or worse. (This latter request is more an exercise in orthogonality...since particle sources are generally self-evident, I'd say WAV-wareness is the more pressing issue  Thanks for reading! - tillu
|
|
Alexander Daguerre
Junior Birdman
Join date: 9 Jun 2004
Posts: 32
|
11-26-2004 02:08
From: Tillu Bomazi Attempts to locate the culprits by simply walking the area and triangulating on the audio fade have also been inadequate, since the venue is so thickly populated during the games. Try this: go into the VIEW menu and enable OBJECT BEACONS. "Interesting" objects will get an unmissably huge marker coloured according to the reason they are interesting. Most of the beacons will be red; ignore those. An object that is making a noise will get a yellow beacon. This is true for an attached object as well as for a separate object. Don't jump on the first person showing a yellow beacon, though, as for example you'll see yellow beacons corresponding to footsteps when someone walks around. Similarly the "bump" sounds when things collide show up in the same way. Wait until you see a yellow beacon appearing when the sound clip starts, disappearing when it ends.
|
|
Gwyneth Llewelyn
Winking Loudmouth
Join date: 31 Jul 2004
Posts: 1,336
|
11-26-2004 06:18
The only reason I see for "WAV-awareness" is to deal with culprits, erm, "candidates for abuse report". The marvellous suggestion by Alexander should be more than enough to deal with them.
I don't envision having "voice-activated" objects for the moment, so there is no particular reason to have sensors detect sound. If it's for some "cool" purpose - like sensors reacting to people yelling or so - you can "trick" your object by sending it a message on a private channel at the same time as a "wav" for sound. There is no need to check for sound specifically.
As to sensing particles, your idea is interesting, but unfortunately, particles are rendered client-side, and (thankfully!) not server-side. So there is no way that you can get that information! The best you could do is having a sensor detecting for "particle emittors" (but not for the particles themselves...).
|