llParticleSystem broken ?

Hello, I noticed that llParticleSystem([]) doesn't work anymore to stop any particle systems since last update.

Was it intended ?

Are you using that inside of a timer?
Ya I have been having this problem too in the child objects. I have to do something like use.

llParticleSystem([PSYS_PART_MAX_AGE, 0.0, PSYS_SRC_BURST_RATE, 30.0]);

to stop them.

Have you tried it multiple times? I've always had issues with it sometimes taking multiple attempts to stop it.
Is this client-side only? If you using llParticleSystem([]) then log-out and back in again are the particles still present?

well if you log out then back int that tells me it is not client side. I will check on it more tonight. off to work now.

Yes, I used it inside a timer but I also tried with a more basic script (to sum up, a default state with an on_rez event) and the behavior was the same. I'll try your trick though.

> Are you using that inside of a timer?
> Ya I have been having this problem too in the child objects. I have to do something like use.
> llParticleSystem([PSYS_PART_MAX_AGE, 0.0, PSYS_SRC_BURST_RATE, 30.0]);
>to stop them.


I also tried multiple times, without any success. I didn't try by logging off/on, but anyway, that would be a real pain, in long term.

> Have you tried it multiple times? I've always had issues with it sometimes taking multiple attempts to stop it.
>Is this client-side only? If you using llParticleSystem([]) then log-out and back in again are the particles still present?



I also found a trick that works pretty well (it's not perfect but still works), using a PSYS_PART_MAX_AGE set to 0.01, with a classical particle behavior.

I noticed too (and I'm not alone) that more and more bling effects can't be stopped anymore (I suppose the ones which use an empty list to pause the bling effect).

i notived the behavior was different if you where editing the prim or not during the primitive update, wich makes me think there is something wrong with the primitive partial or full update.

I've had detector-based particle scripts stop functioning since the yesterday update.

Ones that started the particles up when you were flying, and turned off when you landed. They turn on, but now they don't turn off when you land any more.

Will try the expanded llParticleSystem([]); when I get home from work....

And yes, it's only timerbased it seems, as my manually-toggled particle scripts still work fine.

Edit: Changing the particlesystem lines did function. I'm making that a fix in the affected avatars.

from what I have seen if a particle system is suppose to be off. fly out of range then back in range. Then the system will be off. So the client is not being updated.

Also try this right click and select edit like you would for editing then keep it selected have it turn on and off. It seem to turn off for some reason with no problem. Also my alt sees the same thing. But as soon as the object is not selected and I have it turn on and off, it does not work 100% of the time. and both account may see it differently. one sees it on and the other may see it off.

Is it really a good idea to use that in place of something that is supposed to shut the particle engine off completely? I don't know a lot of detail about the inner workings of particles from the server side, but it seems like what you're doing there is just stopping the particles from being visible, as opposed to actually switching them off. Which could mean that they're still impacting sim resources at some level since the particle engine is still technically running in that prim. It probably depends if the particle engine is clever enough to realize that an age of zero means the particles won't be seen, so it switches the engine off anyway.

Particles are not server side and do not impact the resources of the sim. They are client side only the only information it has to dish out is the prims properties which was set by the Script in the first place. This is also why a prims can still emit particles even after a script is removed. from them.

still it keeps the client side particle engine "on"

I seem to notice a lot more particle systems failing to turn off when packet loss is higher.

It's just a guess, but I suspect the prim update that's being sent to the client to turn off particles is being lost/corrupted... and not retransmitted.

I tend to put llParticleSystem( [ ] ); in state_entry() AND prior to an llResetScript(); now. More often than not one of the two of them seems to take effect. :-/

I've had to use a similar hack, set the particle system to something that doesn't emit particles. A better hack I'll try when I get inworld next might be to use that, then clear the particle system on the next timer event.

It seems to happen most of the particle system is not in the root prim of an object, and I never saw it before the last update. It's as if llParticleSystem([]); is being "optimized out"... even multiple calls to it don't help. Yesterday I had it in state_entry() and reset the script five times in a row and it still stubbornly kept emitting particles... but it never happened in a root prim.

Particles are a property of the prim like llSetText(), that is once you start a particle system you can delete the script and they continue.

Just as the way to clear a SetText is to llSetText("", the proper way to clear particles in llParticleSystem([]). It would not surprise me that these have the same problem as - for example - texture "snap-back" where you have to do mutiple commits before the texture sticks.

Thus, it would seem that

reallyStopParticles() {
     integer i;
  	 for(i = 0; i < 100; i++) {
  	   llParticleSystem([]);
  	   sleep(1);
  	 }
     llRemoveInventory(llGetScriptName());
   }

might be the pragmatic way to turn off particles now. I wish I were kidding.

I notice it happens quite often not only with my root prims... but with unlinked prims as well.

Is anyone still noticing this problem regularly?

I've been trying to duplicate for the last two days and have only had a very small percentage of effects fail to turn off properly (like 3 in a few hundred on/off tests, which, honestly, is a ratio that I think has always been with us)

I was getting it Monday, reliably, in an area with a lot of particle effects running. I don't recall ever having a problem getting particle effects to turn off before.

yes still very much a problem. The one thing I can make it do reduce particle count and set the size to 0.0. The whole empty list thing just does not work like it should any more.

I have an IM in my email today about particles not switching off on my fireplaces.

The customer said when they TP'd away and back the particles were off when they got back.

there seems to be two issues with llParticleSystem not shutting off as expected.

One is particles not turning off in general, which is a relatively rare and an intermittant problem that has been around a long time. I suspect that packet loss and/or distance from the emitter are factors, but can't reproduce it reliably.

The other problem is more recent and quite reproducible: Particles on child prims don't turn off, at least from the client's view.

The sim and prim both know the particles have been turned off, but the client didn't get the memo and the client won't... until a 'full update' from the prim is re-sent to the client, which means: until the avatar leaves and returns, crosses a sim boundary, the object gets linked/unlinked, llSetPrimParams causes something to change on the prim... etc.

In child prims, try turning particles off with:Updates seem to make it through to the client (if it's not lost in packet-loss), so this will make the particles 'seem off' to the client, and then really turn off for the next person that sees the prim for the first time.

Note: Successful deactivation with an [empty list] will remove the particle "beacon" (see: View -> Beacons ), but setting burst particle count to 0 will leave the particle beacon on.

Hopefully the two bugs affecting llParticleSystem() will be fixed soon. (the other is related to llFrand( - n), which breaks angle patterns and some uses of min/max speed, in scripts that set inner>outer, angle_begin>angle_end or speed_min>speed_max.

I guess if we set the particles to 0 and immediately after, do llParticleSystem( [ ] ), that would be both belt and braces? It will deactivate particles properly when they fix whatever is broken, and will keep particles effectively invisible until then/if they never do.

That's what I'm doing. that way when they fix the problem it'll stay fixed.

Bleh.

I put

llParticleSystem( [ PSYS_SRC_BURST_PART_COUNT, 0 ] );

In the lines befor my [] ones, and it made no difference. Stuff still spews out until re-entering the sim.

I'm actually setting the rate to 0, particle size to 0, and Alpha to 0, then deleting the particle system. Try that.

I put a pointless llSetPrimitiveParams to set flexi as false right after. that did it.