Build Window: Particles

The Build window should have a tab for controlling a prim's particle system.

That's simple enough, yeah? But I like to hear myself type, so I'll go into more detail.

Right now, the only way to activate on deactivate particle systems on a prim is through the use of a script which calls the llParticleSystem() function. That function takes a list of many pairs of parameters, each pair describing what is being defined (e.g. PSYS_PART_START_COLOR, i.e. particle starting color) and what that thing is being defined as (e.g. <1,0,0>, i.e. pure red). Constructing such a list is a tedious and frustrating task, but fortunately there are plenty of helpful scripts which can make it a bit more convenient. But even these helper scripts must call llParticleSystem() eventually, or there will be no particles.

You might think, based on the fact that a script is the only way to activate particles, that a prim must necessarily be scripted to have particles. This is not the case: the particle system is stored with the prim itself, not the script. Consider the fact that you can stop or even delete the script which activated the particles, and the particles will continue unabated.

To summarize, particle systems can exist without scripts, but there is currently no method aside from scripts to turn them on or off. As scripts are a tedious and ultimately unnecessary way of creating, changing, and deleting a particle system, it thus stands to reason that a more convenient method should be provided as a supplement to the scripted method. The Build window's Features tab (which currently houses the settings for flexible paths and light-emission) seems to be the natural place for this. But particles have a lot of settings, and the Features tab is already a bit crowded, so, at risk of over-complicating the user interface, I recommend branching the Features tab into sub-tabs, one of which would be dedicated to particle systems.

(In fact, particle systems have such a large number of settings that two or more tabs may have to be dedicated to particle systems. An obvious but imperfect division is between PSYS_PART_* and PSYS_SRC_* flags. A more natural but less clear-cut division is between settings which define the appearance of each particle, and those which define how they are emitted and behave as a system.)

So what would we see when we look at the Particle tab(s) of the Build window? It turns out that particle system settings are represented by a handful of distinct types of data, and the proper UI widgets to control each type are already used in other places in Second Life's interface, especially in the Build window itself:

type	widget	example
bitfield	checkboxes	General tab: permissions
option	radio buttons / drop-down menu	General tab: for sale options / General tab: When Left Clicked
float	numeric control	Object tab: Revolutions
integer	numeric control	Object tab: Hollow
vector	multiple numeric controls	Object tab: Position
color	color picker	Texture tab: Color
texture	texture picker	Texture tab: Texture
object/avatar	object picker	Report Abuse window

Some notes: in the script, colors are actually the vector data type, but it is non-intuitive to select a color the same way you set e.g. size in a graphical widget. Also, a script has the advantage in selecting a client asset texture by key, whereas the graphical widget can only select from inventory. And, the object picker in the Report Abuse window can only select the root prim of an object, which would be insufficient when targetting a child prim of an object.

In addition to all the particle system attributes, one more UI element would be needed: a checkbox for whether the particle system is currently active or not. But unchecking that box should not make in impossible to change the other settings, as happens with the flexi and light features (in fact, it should not do so in those cases either!). This might require a small change to the way particle systems work, as I am not certain if non-active particle systems are saved with prims. But even if the values for the attributes of a non-active particle system were stored only client side (so that if the client crashed, they would be lost), it would still be a useful feature.

I feel compelled here to anticipate several possible arguments against this feature:

1. "Newbies and griefers will be making ugly and annoying particle systems left and right! At least now, you have to be able to script to abuse particle systems!"

   To this I have two responses. Firstly, newbies and griefers already make ugly and annoying particle systems left and right, because scripted smoke bombs etc. are already easily available. Secondly, I don't think that imagined fear of abuse is a legitimate reason to prevent progress in ease of legitimate use.

2. "This change would put the makers of particle helper scripts out of business!"

   Adapt or perish. Should we have stuck with the telehub system, because point-to-point teleporting forced vehicle makers to change their business models? Perhaps we should get rid of the Object tab, and force all changes to a prim's shape be made through scripts, to increase demand in the prim-twisting script market?

   The fact is, scripts which control particle systems will still be useful; but they will have to go beyond the basics and have more complex behavior. Some examples include particle systems which gradually rotate through all the colors with time, or particle systems which detect nearby avatars, look up their favorite color in a database, and shoot particles of that color at them.

As I see it, there are plenty of reasons to add this feature and few reasons to reject this feature, little effort required to add it and much benefit from its addition. So get it done.