Don't click here unless you want to be banned.

LSL Wiki : llParticleSystem

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are crawl338.us.archive.org
llParticleSystem(list parameters)

Makes a particle system based on the parameter list. The parameters are specified as an ordered list of parameters and values.

The following tables are valid parameters. Basically, each particle system is specified with a list consisting of the flags ORed together ([PSYS_PART_FLAGS, flag | anotherflag]) followed by the pattern ([PSYS_SRC_PATTERN, pattern]) and then pairs of parameters and their values.

Notes:

Parameter pairs (always one constant followed by parameter of specified type):
Constant Type Description Decimal
PSYS_PART_START_ALPHA float alpha of starting particle (This parameter isn't working correctly. Acts as 1 if set to value higher than 0) 2
PSYS_PART_END_ALPHA float alpha of ending particle 4
PSYS_PART_START_COLOR vector color of starting particle (for color and/or alpha to work PSYS_PART_INTERP_COLOR_MASK must be set) 1
PSYS_PART_END_COLOR vector color of ending particle 3
PSYS_PART_START_SCALE vector Starting size of particle billboard (sprite) in meters (z value is ignored). Maximum 4x4, minimum may be 0 if the same x or y value in the end scale (see below) is at least 0.03125. Using a texture with a larger masked area can give the appearance of an even smaller particle. The actual particle size is always a multiple of 0.03125. Smaller changes don't have any effect. 5
PSYS_PART_END_SCALE vector Ending size of the particle billboard in meters (z value is ignored). Maximum 4x4, minimum 0 if the same x or y value in the start scale (see above) is at least 0.03125. Using a texture with a larger masked area can give the appearance of an even smaller particle. The actual particle size is always a multiple of 0.03125. Smaller changes don't have any effect. 6
PSYS_PART_MAX_AGE float maximum age of a particle, in seconds (max 30 seconds) 7
PSYS_SRC_MAX_AGE float Length of time, in seconds, from when the source object comes into view, or the particle system's creation, that the object emits particles; after this time period no more particles are emitted. 19
PSYS_SRC_ACCEL vector particle acceleration: minimum seems to be .0078125 before any acceleration occurs (more research needed to verify); maximum seems to be 100 8
PSYS_SRC_ANGLE_BEGIN float area in radians specifying where particles will NOT be created (for ANGLE patterns) 22
PSYS_SRC_ANGLE_END float area in radians filled with particles (for ANGLE patterns) (if lower than PSYS_SRC_ANGLE_BEGIN, acts as PSYS_SRC_ANGLE_BEGIN itself, and PSYS_SRC_ANGLE_BEGIN acts as PSYS_SRC_ANGLE_END) 23
PSYS_SRC_BURST_PART_COUNT integer number of particles to release every burst 15
PSYS_SRC_BURST_RADIUS float Distance from center of source (in meters) where particles are created; only works when PSYS_PART_FOLLOW_SRC_MASK is not set. 16
PSYS_SRC_BURST_RATE float time interval (how often) to release ("burst") particles (in seconds, 0 fastest) 13
PSYS_SRC_BURST_SPEED_MIN float minimum velocity of each newly created particle; negative values act like 0 17
PSYS_SRC_BURST_SPEED_MAX float maximum velocity of each newly created particle; negative values act like 0; (if lower than PSYS_SRC_BURST_SPEED_MIN, acts as PSYS_SRC_BURST_SPEED_MIN itself, and PSYS_SRC_BURST_SPEED_MIN acts as PSYS_SRC_BURST_SPEED_MAX) 18
PSYS_SRC_INNERANGLE float deprecated, use PSYS_SRC_ANGLE_BEGIN instead. An area in radians specifying where particles will not be created. 10
PSYS_SRC_OUTERANGLE float deprecated, use PSYS_SRC_ANGLE_END instead. The area that is filled with particles, in radians. 11
PSYS_SRC_OMEGA vector rotation between bursts (in radians) (used only by SRC_PATTERN_ANGLE* patterns) 21
PSYS_SRC_TARGET_KEY key target that particles will move towards (if PSYS_PART_TARGET_POS_MASK has been set). If the key cannot be found, particles will target the emitter prim. 20
PSYS_SRC_TEXTURE string inventory item name or key of the particle texture 12
PSYS_SRC_PATTERN integer emission pattern; see pattern table below 9
PSYS_PART_FLAGS bitfield (integer) particle behavior; see flag table below 0

PSYS_PART_FLAGS followed by an integer bitfield with one or more of the following constants OR'ed together:
Constant Description Hex
PSYS_PART_BOUNCE_MASK particles bounce off object's z-axis height 0x004
PSYS_PART_EMISSIVE_MASK particles emit a glow (are prelit); otherwise reflect light 0x100
PSYS_PART_FOLLOW_SRC_MASK Particle position is relative to source object's vertical position (rotation still disperses particles); disables PSYS_SRC_BURST_RADIUS. 0x010
PSYS_PART_FOLLOW_VELOCITY_MASK rotate particles so vertical axis points towards velocity vector 0x020
PSYS_PART_INTERP_COLOR_MASK interpolate color (and alpha) from start to end 0x001
PSYS_PART_INTERP_SCALE_MASK interpolate particle scale from start to end 0x002
PSYS_PART_TARGET_LINEAR_MASK (Not listed in official documentation.) Seems to send particles in a straight line to target (cancels PSYS_SRC_ACCEL, PSYS_SRC_BURST_RADIUS, and possibly other parameters). 0x080
PSYS_PART_TARGET_POS_MASK particles move towards (target) object defined in PSYS_SRC_TARGET_KEY 0x040
PSYS_PART_WIND_MASK particle velocity is damped toward the wind 0x008
PSYS_PART_RANDOM_ACCEL_MASK unimplemented - random acceleration; use llFrand instead -
PSYS_PART_RANDOM_VEL_MASK unimplemented - random velocity; use llFrand instead -
PSYS_PART_TRAIL_MASK unimplemented - trails; emit more particles at shorter bursts instead -

PSYS_SRC_PATTERN followed by one (and only one) of the following constants:
Constant Description Hex
PSYS_SRC_PATTERN_ANGLE Shoot particles across a 2-dimensional area defined by arc radians specified in PSYS_SRC_ANGLE_END. An open area will exist in the arc defined by PSYS_SRC_ANGLE_BEGIN. 0x04
PSYS_SRC_PATTERN_ANGLE_CONE Shoot particles across a 3-dimensional cone defined by arc radians specified in PSYS_SRC_ANGLE_END. An open area will exist in the arc defined by PSYS_SRC_ANGLE_BEGIN. 0x08
PSYS_SRC_PATTERN_ANGLE_CONE_EMPTY Not listed in official documentation. Inverse of PSYS_SRC_PATTERN_ANGLE_CONE; will shoot particles everywhere except the 3-dimensional hollow cone defined by PSYS_SRC_ANGLE_END and PSYS_SRC_ANGLE_BEGIN. 0x10
PSYS_SRC_PATTERN_DROP drop particles at source position with no initial velocity 0x01
PSYS_SRC_PATTERN_EXPLODE shoot ("explode") particles out in all directions using burst parameters 0x02
Remember, like llSetText or physics, llParticleSystem is not caused by the script, which merely turns particles on and off. Simply put, particles won't stop until llParticleSystem([]) is executed, which removes the system. This means particles won't stop when moved onto no-script land. Particle systems are rendered client-side and do not contribute to server load after the initial function call.

Also particle effects don't work on HUD objects.

Example:
// This will make an explosion of red particles, which follow the wind and glow
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>]);

Q: How do I get my object to stop emitting particles? I removed the script, but it won't stop.
A: Call llParticleSystem again with an empty list. Particles aren't actually generated by the script; rather, the script only toggles a setting on the prim. This behavior is similar to llSetScale or llSetText--the scale or text are a part of the object, and will only be changed when a new setting is fed to them. Particles work the same way.

Example:
default {
     state_entry() 
     {
          llParticleSystem([]);
     }
}
addendum: a quick and easy way to do this while still retaining the particle parameters (in case you should wish to re-initiate the particles later) is to set the particle count (particles emitted per burst) to 0.

Q: Is it just me or is PSYS_SRC_BURST_RATE not acting at all like it should? Sometimes it emits it in the time I set, sometimes it takes 4x as long, or sometimes it emits fractions of a second after it just last emitted.
A: Check if there are other particles in-view that could be sucking up SL's particle limit set in preferences. Increase the particle limit, move to an area with less particles, and/or reduce PSYS_SRC_BURST_PART_COUNT.

Q: How do I make the rotation of the particle match the source prim with PSYS_SRC_PATTERN_DROP?
A: If you use PSYS_SRC_PATTERN_DROP then all particles are rezzed with the same orientation that ignores the source prim. You can change the rotation using PSYS_PART_FOLLOW_VELOCITY_MASK but this is a one time setting that applies to all particles. This can be faked though by using PSYS_SRC_PATTERN_ANGLE with a <0,0,0> velocity. Using PSYS_SRC_PATTERN_ANGLE causes the particles to match the orientation of the source prim.

Q: When I change regions, particles that were existing in the previous region follow me and continue to live until they reach the end of their lifespan, or in the case of targeted particles, move across the grid to wherever they were supposed to go. Why is this?
A: Particles exist entirely on the clientside in Second Life, and given that they may last a maximum of thirty seconds, they are not flushed from existance on region change. This results in the client rendering them carrying out their parameters until their life is over. Only you can see the rogue particles; they are only capable of targeting something in the same region as the emitter, and any apparent exceptions are only the result of how the client deals with old particles.

See ExampleParticleScript, ExampleParticleScript1, and LibraryKeknehvParticles for better examples.


This article wasn't helpful for you? Maybe the related article at the LSL Portal is able to bring enlightenment.

Particles | Functions
Comments [Hide comments/form]
PSYS_SRC_MAX_AGE is your friend if you're using particles for display or need to manage their duration! Don't waste your life like I did trying to stop the particles in a timely fashion by passing the null list. I spent a day trying variations on the script below including sending a link message to a separate particle_stop script after the timeout. That version was particulary interesting for exhibiting quantum behavior in the sense that if I did an llWhisper in the link_message handler (observation), it would function correctly, but otherwise it would fail to stop the particles too. The particle was generated by Ama's script.

list particle = [0, 259, 1, <1.00,1.00,1.00>, 2, 1.00, 3, 
        <0.00,0.30,1.00>, 4, 0.10, 5, <0.50,0.50,0.50>, 6, 
        <1.00,0.00,1.00>, 7, 1.70, 8, <0.00,0.00,0.00>, 9, 
        8, 10, 0.00, 11, 0.10, 12, "", 13, 3.00, 
        15, 1, 16, 1.00, 17, 0.60, 18, 0.60, 19, 0.00, 21, <0.00,0.00,0.00>];

default {
    state_entry() {
        llParticleSystem([]);
    }

    touch_start(integer total_number) {
        llParticleSystem(particle);
        llSetTimerEvent(5);
    }
    
    timer() {
        llParticleSystem([]);
        llSetTimerEvent(0);
        llWhisper(0, "gone?...not!");
    }
}
-- ReadyJack (2005-08-13 04:12:21)
OK, who's bright idea was it to sort the variables by value vs name? That is just stupid. Names are used FAR more than variables! Sorting by value also screwed up the links--I went through and made sure no duplicates were present but that was based on ALPHABETICAL sorting! Resorted by name or category grouping (start/end, min/max, inner/outer, etc).
-- EepQuirk (2005-08-19 22:16:32)
wow, chill
-- SchitsoMonkey (2005-08-20 17:23:03)
Schitso, why must you incessantly sort this page by value? NO ONE USES VALUE TO FIND PARTICLE PARAMETERS! God damn, idiot-troll-vulture...
-- EepQuirk (2005-08-25 03:32:56)
We normally sort parameters by value. At liest that's how we've been doing it for the past oh... 2 years.
-- IceBrodie (2005-08-25 07:36:31)
Im going to agree with Eep on this point, sorting the constants based on how they're associated with one another (start colour with end colour, for example) provides readers with a much more intuitive browsing experiance (IMO), values assigned to constants are incredibly arbitrary, they may even change when LL decides to upgrade their effect (akin to what happened with PRIM_TYPE not too long ago). I would find it conveniant to see END_COLOR's description right after START_COLOR's, it kind of seems like a part of my subconsious is mildly suprised when I glance over the table and see START_ALPHA between START_COLOR and END_COLOR.
-- ChristopherOmega (2005-08-25 20:42:22)
Ahh, yeah, that is a good system, thanks Eep.
-- IceBrodie (2005-08-26 02:05:44)
The reason i have put the values of the constants on the wiki is to help anyone building an LSL compiler, decompiler, or interpreter. Also every now and then LL changes the values, hiding older interfaces. Without knowing the previous value it would be impossible to use them.

The main reason they were sorted by value is A) it is the order they appeared in early documentation and B) it iss the order they were added to LSL.

It does seem a bit better then sorting by value...
-- BlindWanderer (2005-08-31 00:53:37)
Until this wiki supports tabular column sorting where people can sort them however they want (client-side, not in the code itself), let's keep it sorted by usage.
-- EepQuirk (2005-09-03 20:43:49)
I agree that sorting by value is pointless. Programmers should not be looking at the value (unless they are doing something very unusual) , and therefore they would rarely ever be looking up the name given the value, so why sort by value? That applies to most of the other tables.

In fact, looking up a name that you already know is also relatively rare. You might do that to look up the meaning of the name, but it would be far better to find the meaning in relation to that of other names (e.g. START_COLOR and END_COLOR). In other words, grouping by concept is they best way to organize documentation. The only reason for an alphabetical sort is if it *also* groups things conceptually because related things have the same prefix.
-- ZenoConcord (2005-09-10 16:43:23)
In the interest of making the tables look tidier, moving the value fields to different columns, and converting the 'bitfield' masks to hexadecimal representation per the usual approach elsewhere on the wiki. Also removing non-existant types and replaced with the 'standard' Q/A blocks explaining lacking functionality.
-- WolfWings (2005-09-27 05:31:16)
Scratch that... didn't look right. Left the unimplemented stuff in the table, but bottom-sorted those so the 'unimplemented' stuff is a block at the very end of the table instead of interspersed throughout it.
-- WolfWings (2005-09-27 05:40:24)
How do the variables of the old depreciated functions like llMakeSmoke and llMakeExplosion compare and convert to the Particle System? I know that some are fairly straight forward, but there are a few others that are confusing to me, such as lifetime and arc. What would their closest equivalent under the Particle System be?
-- BondHarrrington (2005-10-02 01:13:23)
The lifetime of a particle is set with PSYS_PART_MAX_AGE, and the amount of time the particles are emmited is set with PSYS_SRC_MAX_AGE.
The closest thing to arc is PSYS_SRC_INNERANGLE and PSYS_SRC_OUTERANGLE
-- SchitsoMonkey (2005-10-02 17:47:06)
Catherine, your dictatoral removal of italics is getting annoying. I italisized "source" in PSYS_SRC_MAX_AGE to differentiate it from PSYS_PART_MAX_AGE right above it. Leave it alone!
-- EepQuirk (2005-12-11 22:17:16)
As is your rebellious know-it-all behaviour that now includes namecalling, Eep. (...not to suggest I find Catherine at all annoying.)

I though I'd clear up the argument which seemed a little moot to me as the entry was confusing to start with. 'The age of a source' seems a less useful concept (since it seems to refer to the existance of a prim) than the (to me more intuitive, and probably more implementationally accurate) 'the lifespan of the particle generator', wouldn't you say?
A few other descriptions could use a little clarification. Is there a point for me to make the effort or should I just do so later when you're not trying to make a point?
-- IoneLameth (2005-12-13 10:36:03)
Eep if you change it back you will be removing pertinent information.
-- BlindWanderer (2005-12-13 13:01:44)
Edited the descriptions in To use PSYS_SRC_ANGLE_BEGIND/PSYS_SRC_ANGLE_END instead of the depreciated PSYS_SRC_INNERANGLE/PSYS_SRC_OUTERANGLE.
-- NepenthesIxchel (2005-12-21 00:32:36)
Who came up with the smart idea of making hexadecimal values out of the decimal once? If somone wants to add up they need a hexadecimal calulator.
For me it doesn't make sense and sutch i added decimal values aswell. I want to be able to add em together on my calculater. Because i am doing something unusual.
Reason i added values was because i was making a interpreter ;)
-- JiffiesManimal (2005-12-30 02:45:03)
"Who came up with the smart idea of making hexadecimal values out of the decimal once?"

this is usually done with bitfields to help visualize the bits easier. each hexedecimal digit is 4 bits, so if you have some familiarity with hexedecimal - and chances are you do if you are working with bitfields - this puts them in manageable chunks for you. see the page on bitfields for more :)

of course you don't need to know the values in either hex or decimal to use the particle system, but that's the explanation for why you'd see hex rather than decimal, if anything at all
-- WikiSpoon (2006-01-09 08:40:02)
...also I changed the column heading "INTEGER value" to "DECIMAL value" because it makes more sense; the corresponding hexadecimal values are integers too
-- WikiSpoon (2006-01-09 08:56:58)
I'm finding that the Angle Begin/End descriptions are not accurate. The particles will be created starting at Angle Begin and ending at Angle End. If End < Begin, area = (End - Begin)*2, otherwise area = (Begin - End)*2. The multiplier is to account for both arcs starting from the top center. The only range of values needed for Begin and End should be from 0 to PI, but values outside of that are still accurate.

From this, I now can see why the variables were renamed from PSYS_SRC_INNERANGLE / PSYS_SRC_OUTERANGLE to PSYS_SRC_ANGLE_BEGIN / PSYS_SRC_ANGLE_END. Either of the two could be the inner / outer angle depending on the values passed.
-- DedricMauriac (2006-01-09 22:45:23)
For PSYS_SRC_OMEGA, spin rate appears to be 0.25 in comparisson to llTargetOmega
-- DedricMauriac (2006-01-14 00:53:07)
Hmm.. Can someone create a visual example 3D in flash for angle's and all that?
It would help a lot figuring out how the heck it works.
-- KairaOverdrive (2006-01-14 03:53:14)
I'm working on something in-game for that.
-- DedricMauriac (2006-01-14 11:37:19)
"If the key cannot be found, particles will target the emitter prim. Targets seem to have no distance limit (up to 739,104m tested so far)--even across sims.
(Target key object needs to have been rezzed in-world by the client, else it acts as not found--thus distance is limited to each client's capabilities.) --Jiffies "

In the course of playing around with PSYS_SRC_TARGET_KEY... I think I have figured out the sim-across issue. I have had particles "rezzed" and moved very quickly into the next sim (or further), and had both targeted and NON-TARGETED particles following me into the next sim. The particle-target then takes over and they move towards me. I am guessing, as particles are handled by the client, they are remaining "rezzed" even though the rest of the local map has changed dramatically. Ghost particles remain, but only for that client. So the dramatic figure 739,104m might overkill. :) What client2 sees is that as soon as person moves out of range, the particles stop and retarget emitter.
-- DoLpHpUn (2006-02-05 22:50:52)
Is it just me or is PSYS_SRC_BURST_RATE not acting at all like it should. Sometimes it emits it in the time I set sometime it takes 4x as long or sometimes it emits fractions of a second after it just last emitted...
-- MoldRat (2006-03-20 10:30:52)
Have the same problem, the intervals arnt equal, dunno if it relates to lag, coz particles as we all know are client side :/
-- MeLightKorvin (2006-04-20 17:40:42)
The client can still lag...
-- EepQuirk (2006-04-20 19:15:19)
He's aware of this, Eep.

I think the reason for this is that PSYS_SRC_BURST_RATE is affected by server-side lag (because the server has to figure out how often to emit particles).

Or else it's just done poorly.
-- DolusNaumova (2006-04-21 18:03:58)
What part of "client-side" don't you understand, Dolus? THE SERVER DOES NOT FIGURE OUT ANYTHING HAVING TO DO WITH PARTICLES. Particles lag because the client lags. Get some particles going and right-click SL's titlebar. Note how particles freeze. Cancel the context menu. Note how particles resume. Wow.
-- EepQuirk (2006-04-22 12:32:29)
Is it just me, or does LSL not allowing reverse alpha interpolation like:
PSYS_PART_START_ALPHA,0.0,
PSYS_PART_END_ALPHA,1.0
It seems stuck one way...
-- KitsuNico (2006-05-19 09:47:15)
Yeah, it's done that for as long as I can remember... at least since SL 1.6. It's probably always been that way.
-- ZodiakosAbsolute (2006-05-25 01:59:21)
Burnman, the LOD settings are specific for small prims and particles--leave it in.
-- EepQuirk (2006-06-20 19:45:26)
The second half of the sentence explains the effect the LOD configuration has on small prim particle emitters. I was attempting to reduce redundancy and improve readability.
-- BurnmanBedlam (2006-06-20 21:17:19)
Well, you failed. Don't remove relevant info next time. How is it redundant?
-- EepQuirk (2006-06-20 21:51:50)
Well, the second portion of the sentence makes it obvious that the LOD application being referenced here is for small prims/particles. If you want to provide more information about how the LOD configuration effects detail, wouldn't it be more prudent to put that on the LOD page so that other pages referencing the LOD page have the benefit of said information?

NOTE: Eep, there wouldn't be a petition to get you removed if you could simply leave out the sarcasm when discussing page edits. Don't take edits so personally... you're going to give yourself an ulcer.
-- BurnmanBedlam (2006-06-21 06:51:34)
Er, I don't know how you learned to write, but I learned that you put a brief summary and then expand on those points. Granted, it's only a single sentence but I don't see how the second portion of the sentence makes an obvious reference to LOD for small prims/particles. LOD is only mentioned once in the sentence. Yes, "prim" and "particles" are repeated but that's because they are expanded on. Why is such a minor wording such an issue to you? I agree this info should go on the LOD page but I'm not the one who decided to mention it here in the first place. ;)

Tell you what: I'll leave out sarcasm when you (and others) stop arguing such stupidity. :P Oh and I haven't had an ulcer in about 14 years (at least I think it was an ulcer anyway). <shrug>
-- EepQuirk (2006-06-21 12:58:18)
Eep, I wasn't trying to start an issue with you by changing the wording. I was looking to improve the flow of the sentence, providing the necessary information within the context. It wasn't a big issue for me, I was simply attempting to discuss with you why I made the change and see what you thought. Writing a brief summary and expanding on the point is great... but a little unwieldly for a single sentence, at least in my opinion.

You have argued some pretty pointless edits in the past, and that's fine. What I think of as pointless to argue might be important to you, and that's no issue. It's how you present your argument that is in question. I would much rather you and I work out a way to get along and coexist on the wiki than throw words back and forth like fists.
-- BurnmanBedlam (2006-06-21 13:22:06)
Is there any way to bounce particles on the bottom side of the Z-axis? I think that that might be about as useful as the top. I tried putting a minus before it, but, naturally, that did nothing.
-- VirusCollector (2006-11-06 17:36:52)
Is there a way to shoot particles straight ahead relative to the position of the prim emitting them? I've been working at this stupid thing for three hours and nothing. When it finally does shoot out in front of it, it also shoots BEHIND it. I'm using the PSYS_SRC_PATTERN_ANGLE pattern and this is the closest I've come to anything remotely useful.
-- HawksterWestmoreland (2006-11-08 01:09:52)
HawkSterWestmoreland, I personally end up using a PSYS_SRC_PATTERN_ANGLE_CONE with PSYS_SRC_ANGLE_BEGIN and PSYS_SRC_ANGLE_END both set to zero.

Anyway, anyone know what kind of effect using the alpha gradient (The thing that is used for invis prims, key e97cf410-8e61-7005-ec06-629eba4cd1fb) for hiding particles in a attempt to reduce lag? (Rather, does it stop them from being rendered or does it simply hide them?)
-- LyndynT (2006-11-10 15:56:51)
Has anyone else noticed since this last update (1.13.whatever) that particles don't fire as often or properly? I've noticed that a lot of devices that used to have nice clean particle effects now look extremely choppy, like full of holes.
-- SpiritfireMusketeer (2006-12-02 05:30:51)
I've been getting really ugly behavior relating to PSYS_SRC_MAX_AGE. Particles restarting after a teleport or crossing sims, particles starting while in no-script zones, etc... If you're using PSYS_SRC_MAX_AGE to limit the lifetime of your particles, back it up with a timer or llSleep() followed by a llParticleSystem([]).
-- StormThunders (2007-01-05 11:51:32)
We now can thank LL for yet another wonderous contribution...

I had a particle effect generator that would make smoke particles roll along the ground and create a pretty decent fog effect. It would shoot it out in a nice, flat manner and the particles wouldn't really move upwards whatsoever, just create them and send them out and forward and fill in 360 degrees around the emitter. Right after this last update (1.14.0(1)), the effect is now strikingly (and unfortunately) different. I didn't change the script whatsoever but PSYS_SRC_PATTERN_ANGLE_CONE is now behaving like PSYS_SRC_PATTERN_EXPLODE in the object and particles are just flying everywhere.

For reference, the beginning angle was PI_BY_TWO and the ending angle was 0.0. It made a nice, flat effect all around the emitter and now it just looks terrible.

I just hope that PSYS_SRC_PATTERN_ANGLE_CONE isn't broken, as I really liked the effects I was getting before the update...

UPDATE ON ISSUE: Apparently, setting both the beginning and end angles as PI_BY_TWO produces my original desired effect, and there was also some kind of bug going on with the ANGLE and ANGLE_CONE patterns according to the Particle Laboratory in Teal. An ANGLE_BEGIN of PI_BY_TWO and an ANGLE_END of 0.0 no longer produces my original effect.
-- HawksterWestmoreland (2007-04-02 16:55:41)
Attach a comment to this page: