a tree falling in the woods

hi all,

if i have a lot of different sound events scripted on my land using LlTriggerSoundLimited and a loop to trigger the sounds, does the simulator use up processing power "playing" the sound to no-one when there is nobody in the "limited" audio zone? ie: does the sound play (and use up system resources) even though there is nobody to hear it?

the script i have made is as follows if this helps. ( i want to have about 250 individual sounds running like this, and do not want to lag the sim if there is a better way)

cheers
nonnatus




default
{
state_entry()
{
state play;
}

}


state play
{
state_entry()
{
llTriggerSoundLimited("sound", 1.0, llGetPos() + <5,5,5>, llGetPos() - <5,5,5>;
llSleep(10.0 );
state default;
}
}

Well, the sim doesn't use CPU to play a sound, per se, but when there's somebody "in the forest" to hear it, then there's time spent downloading the sound clip. And there's the fact that the scripts themselves will use CPU every 10 seconds just to make the function call (which wouldn't be incurred with llLoopSound, but that would preclude accurately controlling the envelope of audibility).

Unless the area is gonna be really heavily attended all the time, my hunch is that it would be more efficient to have llSensorRepeat() determine if there's anybody around, and trigger the sounds only if there is.

(Apropos the posted script, the state-to-state transition with a sleep seems like more overhead than using a timer, but that's just a guess.)

I agree that the state change is not needed; in fact llSensorRepeat makes a dandy timer that only fires when someone is around Note: It will still be checking every 10 seconds when no one is around.

default
{
    state_entry()
    {
        llSensorRepeat("", "", AGENT, PI, llVecDist(ZERO_VECTOR, <5,5,5>), 10.0);
    }

    sensor(integer count)
    {
        llTriggerSoundLimited("sound", 1.0, llGetPos() + <5,5,5>, llGetPos() - <5,5,5>);
    }

}

thanks heaps for the tips..

nonnatus

Just for completeness, what I intended to suggest was a more-or-less centralized llSensorRepeat()--not 250 of them. So each script that was going to llTriggerSoundLimited() would listen to the one script with the sensor to know when to turn on and off, and still use an internal timer to loop the sound.

Now, what I'm not sure about is the extent of "ventriloquism" that's possible with llTriggerSoundLimited(). It may be that a single script can control all 250 sounds, which would obviate the need for any listens at all, but I *think* the sound will seem to be localized at the scripted prim rather than the center of the specified envelope. So I'm thinking those 250 sounds may each need to be in a separate prim for the desired effect--and 250 llListen()s on an obscure channel is surely cheaper than 250 llSensorRepeat()s even with tight ranges.