llParticleSystem broken ?

Wouldn't rate = 30.0 be preferable?

The llSetPrimParams addition sounds like it could work effectively at forcing a full prm update and get the 'particles are off' to the viewing client.

*Doh*

Somehow I'd got it in my head that 0 was disabled.

(runs back inworld to fix that)

I do kind of wish 'rate' were actually "Bursts per minute" not "seconds of delay per burst" so that that it didn't have that somewhat counter-intuitive inverse nature to it.

Yeah, "Higher Rate" in SL particles means "slower."
Huh? High = Slow?

It's not that, it's that "infinite rate" doesn't make sense, and in other contexts in LSL where zero is an impossible value it disables the function.

I've been noticing this problem alot now that I'm working on particles more.. it is deffinately the suck... so far though it seems to work by making the particle a transparent texture. the particles are still technically running but use a 100% alpha texture.. may be an easy fix for some

If you do that... you might want to make sure you're setting rate to 30 and count to 0.

The default only allows for 4096 particles total, from all emitters near an avatar, whether they're seen or not. No sense wasting them on those that can't be seen.

They should have called it "period", not "rate". Or they should have implemented it as a rate. Call it what it is, dammit! That kind of thing is just plain sloppy and annoying. Frankly, they should add a new parameter called "period" with the same semantics as "rate", and continue to honor "rate" but depracate usage in the documentation.

Totally off topic, but I couldn't resist.

BTW, a period of zero meaning "as fast as possible" is useful perhaps, and there are supposed to be other ways of disabling the system, so this seeming inconsistency (0 not turning it off) at least has a justification.

Cheers
Jeff

Oh, I didn't say 0 meaning as fast as possible was wrong.

Just surprising.

For what it's worth...

The below seems to work a little more reliably for me.

(Without the sleep, the count=0 seems to get stomped on before it takes effect.)

   
    llParticleSystem( [ PSYS_SRC_BURST_PART_COUNT, 0 ] );
  
   llSleep(0.5);
  
   llParticleSystem( [ ] );
    

(and, as an alternate to 'period' I'd take 'interval' or 'delay', but that's a dark road.
Once I start down it, I'll be proposing that all the PSYS_ defines be re-worded. )

Has anyone tried the llSetText (" ", <0, 0, 0>, 0.1) ; on a particle-bearing child prim to see if that forces an update? That trick used to cause a full-update on a prim...

The test case I've been using fails regardless of what I try after
llParticleSystem( [ ] );, Whether it's llSetText, llSetPrimitiveParams(), anything short of unlinking or leaving/returning or re-rezzing the object.

Though at least with the count=0, sleep, shutdown sequence, the update to make the particles "appear off" gets through to the client immediately, and the particles are "really off" as far as anyone else that arrives later is concerned.

Didnt read all posts, but did someone already post about using

llParticleSystem([PSYS_SRC_MAX_AGE, 0.05]);

to turn them off? Seems not a problem to me turning particles off, only problem is the items out there not owned by creator that look screwed now.

Problem is, that doesn't turn them off. It only makes them seem off.

The prim will continue to emit particles. If you skip everything else, read message #35 in this thread for a way that both makes the particles seem off immediately to nearby viewers and then really shuts them off as far as all future viewers are concerned.

We only get 4096 particles total (by default, 8192 max) from all particle emitters currently known by the viewer's client. No sense wasting them on particles that can't be seen just because they don't live long enough.

I'm this is a new bug and I hope that LL resolves it soon, along with the llFrand() problem that affects some particle angles and speed combinations.

You sure? That should turn the particles off after 0.05s (look at the flag it's using), then following it with an llParticleSystem([]) will keep it from turning on again for 0.05s when it comes back into view.

Argent, it depends on where the code is.

If it's on_rez, you're probably right. But it it's on some event like touch (for touch on/off control) it would just stay off.

Or am I missing your point?

Argh... yes, I read that as PSYS_PART_MAX_LIFE, not PSYS_SRC_MAX_LIFE, which is certainly preferable.


But, keep in mind that using PSYS_SRC_MAX_LIFE isn't a permanent "off". The emitter will begin emitting particles again every time timer resets everytime that prim enters a viewer's draw distance.


Few if any particles will be emitted in 0.05 seconds, so it's probably okay.


If I remember correctly (and I'll verify tonight), using this to turn off particles still leaves the particle beacon on, even after the period has expired from the client's point of view.

Also... I've always had a nagging suspicion that particles not being drawn because of PSYS_SRC_MAX_LIFE count against the 4096 default total. I haven't rigged up any tests to confirm or disprove that yet, I really should get around to that at some point.


I do, in my scripts that use PSYS_SRC_MAX_LIFE, usually have a timer come along shortly afterwards that forces the particles off with a null list, just to make sure they are really off for future passer-bys.