NEEDED: Script that only turns on particles IF someone is near

Hey! I hope someone can help!

I need a script, or an option to add to a particle effect, that will listen for someone to be close, and only then turn on. I've got controls for if an owner is on, if an av sits down, all that are at the Particle Lab. But they don't have one that listens for if someone is near and only then turns on the particles.

I know it can be done, I've seen it in a plant effect where the particle field only turns on if someone is within 10 meters. The item said that it is low lag, only listening like once a second or something, instead of all the time.

Of course I wonder... which is less lag. Having something listen for a person to come close, or having the particles going all the time. Since I have about 20 particle effects around my sim, and they are spread out, I really think that the lag would be less to have them NOT running ALL THE TIME, but rather having something listen for if there is someone close before turning on.

If you figure this out, or know where I can get such a script without paying 20,000L to get someone to make it for me, please, post here or IM me in-world.

Thank you for your time.

Well, it could be a pretty simple script. It would just call llSensorRepeat(), looking for type AGENT over whatever range, and in the sensor() event call llParticleSystem() with whatever parameters to show the particles, and in no_sensor() it would call it with an empty list to turn off the particles. To make it a little less laggy, it would use a global variable flag to keep track of whether particles were currently running to know if it really needs to turn them on or off.

But the question is a really good one about whether turning them off saves any lag at all. I think not. Particles are purely client-side once they're turned on, so if they'll be turned on anytime anybody is in drawing distance, there will be no client-side savings. The script to turn them on and off is itself trivial for the sim, so it's not going to cost a lot of performance to add it, but I don't think it will really do any good.

Here is a very simple version of what you want:

float fSensorRange = 10.0;
integer bParticles = FALSE;

 
default
{
    state_entry()
    {
        llSensorRepeat("", "", AGENT, fSensorRange, PI, 1.0);
    }
    
    sensor(integer num_detected)
    {
        if (bParticles == FALSE)
        {
            llParticleSystem( 
                [PSYS_PART_FLAGS,       PSYS_PART_WIND_MASK | PSYS_PART_EMISSIVE_MASK,
                PSYS_SRC_PATTERN,      PSYS_SRC_PATTERN_EXPLODE, 
                PSYS_PART_START_COLOR, <1.0, 0.0, 0.0>
                ] );
            bParticles = TRUE;
        }
    }
    
    no_sensor()
    {
        if (bParticles == TRUE)
        {
            llParticleSystem([]);
            bParticles = FALSE; 
        }        
    }
}

I share your concerns; having the script turn particles on/off dependant upon resident proximity will ADD lag rather than reduce it.

Unless there is some particular significance to turning these on when the user becomes close, then you're better off just leaving them on all the time, the viewer will decide which particles to display, and the simulator doesn't care.

I did not address the lag issue when I gave the script earlier. But I have to agree wiht Haravikk and Qie, it will cause more lag than just leaving the particles on all the time. Adding 20 sensors to a sim is not "low lag."

Most of us have tweaked our client settings to adjust for particles and draw distances on our machines with our particular setup.

Another point I didn't see mentioned is that once you get your particles going you can set the script to not run, or even remove/delete it entirely if you wish. Hard to get less laggy than that So yeah I wouldn't bother with a switching scheme unless there's some other reason it's needed beyond maximizing performance.

Also...do note that particles are a property of the prim(unless the particles change somehow)...hence you may delete the script once you have set the particle pattern.