Particles affected by today's update?

I just literally got finished last week perfecting, photographing and boxing up two fountains.
Today, following the update.. the top spray on both these fountains is now completely altered to what it looked when I put them in the boxes.
Anybody else observing alterations of this kind in your particle effects?

I swear, update days are the worst. I invariably have to rush around to see which of my products has been rendered kablooie by LL's tinkering..and try to fix the bloody things to make them work or look right again.

I haven't noticed any particle issues (probably because I haven't been looking), but I did have a few cut prims end up with their cut values changed. Now I have to go check every other build that has cuts (which is basically all of them), and see if they were affected as well. SUCK!

Yes it did. Totally messed up some clouds I made, but not put up for sale yet. Seems particular to the inner and outer angle settings, almost like they are reversed...

Definitely a change in behavior today.

ANGLE and ANGLE_CONE patterns are affected.

This problem occurs when:
PSYS_SRC_ANGLE_BEGIN > PSYS_SRC_ANGLE_END or PSYS_SRC_INNERANGLE > PSYS_SRC_OUTERANGLE.

The old behavior generated particles spread out in an arc between the endpoints of the two angles.

The new behavior only generates particles on the outer edge of the arc defined by the difference in the angles. (or, in otherwords, OUTERANGLE and ANGLE_END are ignored when INNERANGLE or ANGLE_BEGIN are greater).

This most definitely breaks *many* particle displays in SecondLife and will hopefully be reverted back to it's previous behavior....

I've sent in a bug report. =)

Thank you Jopsy... was hoping you were on to this!

My question is, WHO is diddling with the particle system code, and WHY are they breaking it more rather than fixing it?

Must be part of the render pipeline "improvements".

Actually, as a friend of mine pointed out last night, this seems very much related to the llFrand( - (value) ); bug mentioned in the blog.

Which led me to test:PSYS_SRC_BURST_SPEED_MIN greater than PSYS_SRC_BURST_SPEED_MAX behavior. It is also broken. (Before MIN and MAX were interchangable).

Clearly the particle system's "randomizer" uses the same internal code that llFrand() does... which is having a problem with negative values now.

Great I thought this was just my imagination. Definitely something weird with particles. Send in those bug reports!!!

So, should we just re-work the particle settings and accept this as the new standard, or is this something that might actually get repaired by LL? I have a store opening coming up, but don't want to offer something that will inevitably be broken at the next "upgrade."

I have already given up on being able to script my items to turn particles on or off, because that is just a crap shoot these days...

According to the blog:

"Also, this release made some changes to the results of llfrand(). Per LSL reference: llfrand returns a pseudo random number in range [0.0, mag) or (mag, 0.0], depending upon the sign of mag. This change caused a negative mag to be clamped to zero, hence the function will always return zero if a negative range is passed. The fix will require a patch to the simulator and the simulators to be restarted. A temporary workaround is to change calls to llFrand( -mag ) to 0 - llFrand( mag )."


Hopefully, by calling it a "temporary workaround" they mean that they acknowledge that this is a bug that will be fixed, hopefully in the next update.