Sound emission by co-ordinate, remote to script source
tracked
Garden Mole
I would like to explore the feasibility of an LSL feature which allows emission of sound at an x,y,z position remote from an originating scripted source, such as :
llTriggerSoundPos(vector pos, float volume, float falloff);
'pos' would be region co-ordinates (though it could possibly obey the same situational co-ordinate frame rules for linksets as llSetPos)
The idea is to be able to cast sound emission locations away from the scripted source at defined x,y,z points with a defined volume, and (preferably) a customisable falloff to aid situational tuning.
Definition by region position is of particular interest in creating scripted solutions for region and area soundscapes from a centralised scripted orchestrator, rather than positioning a large number of fixed boxes. This opens a wide potential for automation of moving sources, sensor targeted asset-defined sound locations and reducing investment in LI budget for individual scripted sound sources.
Notes :
(1)To avoid any griefing possibilities, perhaps a limitation could be applied where sound will only emit at non-zero volume where the script owner has rez rights.
(2) Although similar results might perhaps be achieved by moving the source dynamically with llSetRegionPos, this concept would be far more robust and elegant.
Log In
Certified Lunasea
It would be nice to be able to do this kind of thing for setting up large soundscapes. Imagine the added realism provided to larger landscapes such as amusement parks, campgrounds, and zoos if there was ambient sound that was able to be differed a bit from area to area within it from a single object. It could reduce script load, land impact cost, and provide for a much more robust environment for everyone.
I am very happy to see this kind of proposal as this is something I had someone request such a setup years ago and upon looking into getting it done both of us were a bit disappointed to learn that no scripting calls existed that would do this properly. Because of this we either had to resort to using multiple sound scripts scattered across the area and remove some of the interactivity from the area to create the complex soundscape we were wanting, or keep the added interactivity and scrap the complex soundscape. In the end we decided to scrap the complex soundscape in favor of more interactivity in the area.
That all said, I also think that it would be nice to have a version of such a call that worked similarly to llTriggerSoundLimited as it would enhance the ability for sounds to be confined within pre-defined areas, though even without this it would still be a major improvement for the creation of larger soundscapes.
I can agree that the limitation of only allowing the sound to be emitted at non-zero volumes where the script owner has rez rights at a particular location is appropriate for mitigating griefing potential. That said, any implementation of such a limitation should not rely on the script owner being on the region nor should it even require for the script owner to be online. If such a limitation is put in place then the script should still be able to operate without the need for the scripted object or some scripted relay to be deeded to group so that such checks are able to work when the script owner is not on the region or online. Multiple calls in LSL already require such workarounds due to limitations imposed for the sake of mitigating griefing potential and having to do so would in this case would serve only in reducing its potential utility.
Maestro Linden
tracked
Peter Stindberg
I like that one. That would de-clutter some regions a lot. With regards to your griefing-possibilities considerations: An agent would need to be able to identify the source of a sound, it's owner, and have the ability to mute it.