It seems that rules for pops are global,
for example:
place a location pop,
connect a group node and set its rule to $VY < 0,
set the group node to select itself,
connect a wind pop and set its wind Y value to -0.1,

the selection will encompass almost the entire particle
system, effectively applying the group's rule and selection
to the displayed node, wherever it is in the network.
This then may exclude the use of further nodes that may
contradict the rule, for example if you wanted to kill
some particles based on the $VY rule and then intend to
apply a wind node set to a negative Y value on the
remainder of the particles.
Any workarounds?

-cpb

What do you mean by “rules”? Are you using events or do you mean using expressions to derive particle groups in a group POP?

What do you mean by “set the group node to select itself”?

I am confused otherwise. A group is just a collection of particles. You mainly use groups to put in the “Source Group” fields of other POPs to work only on those groups. You do not mention this in the wind POP. Of course a negative wind with no other forces in the system will eventually place all the particles in that group. Apply another random upward force and some of the particles will leave the group.

I don't see any problem here.

Using a rule to define a group is fine. They are dynamic unless you check the “Preserve Group” option. Then the particle will remain in the group even if the rule subseuently is false for that particular particle.

Nothing is stopping you from defining another group based on another rule. Each particle can belong to as many groups as you wish to define.

a rule is the expression you enter under the
'rule' field within some pops, if i'm not mistaken.

anyway, what I'm trying to do is kill the particles
with a Y velocity of less than zero, then push the
remaining particles downwards with the wind pop.

-cpb

Yes, the kill POP has a rules option as do a couple others, like the group POP.

The “dead” state of a particle introduced by a Kill POP can be changed up to the last POP in the chain with a State POP. POPs are order dependent. Putting a kill POP that kills all the particles followed by a state POP that sets Dead to 0 will negate the kill POP's effect.

It seems that rules for pops are global,

Not necessarily but yes in your case. It depends on your approach. By using Group POPs, you can create simple to complex groupings of particles to apply your conditions. Instead of using the Kill POP to derive the rule, use a Group POP and use that group reference in your Kill POP. You could create a group of particles that would place the particles if they are past the $AGE of 2 seconds. You could then only affect the wind on those particles by specifying that group pushing them downward and eventually killing them with the kill POP. Then you could have a mercy option with a Group POP setting random groups fed in to a suppress rule POP that randomly reversed death to some particles that were about to die and subsequently use this group the next time around in a
Group SOP combine option and omit them from the next round through the kill using Group POPs to set up the conditions. Whatever you want, really.

The Group POP can use any or all combinations of the different options in the Create folder. You can build other groups using boolean rules in the Combine folder. You can see what points in a particular group in the Select folder. Using several Group POPs to control the behaviour is quite common. I name them very expressively so that I can clearly see what they are doing.

Other POPs that have the ability to change the state of particles are the suppress POP and the property POP. The suppress POP can be used to great effect. If you want to stop particles dead but have their upvector and velocities affected, just use the suppress POP and suppress the velocity. Use a group to control this or an event POP following this guy to release all particles based on a collision (a particle hit is common).

The property POP can be used to globally set particle properties. The fields should be self-explanatory.

Then there is the event POP. The collison POP can send a global event broadcast to all the POPs. An event POP listens for these events and can stop or start all particles or in a case like yours $DEAD == 0.

so it is completely normal behaviour for a
pop node with rules and an explicit wire or group
input to be able to operate upon any subsequent
node that meets its rule (as in the example: location,
group by $VY < 0, kill group, wind to Y -0.1)?

-cpb

POPs only executle linearly down the chain so I think the answer to your question is no, not before the curent timestep. A POP that initially set's a rule followed by another POP that unsets the rule is fine. Any POPs added after the first rule was defined that work based on that specific rule will work as planned but must be before the second POP that unsets the rule.

You have to keep in mind that all the timestep cares about is the particles' current position and the accumulated velocity and acceleration. From that, the particle is moved then the particles are fed back through the POP network with all the accumulated variables intact as time marches on as defined by the oversampling parameter. This is important to remember as some POPs like to reset attributes, like the upvector and rotate POPs.

The timestep is the part of the POPs engine that moves the particles after all the POPs are evaluated.

It is best to work on specific particle problems to see how best to approach a particle problem. What is the effect you are trying to achieve?

uh, it evaluates per frame, gotcha.

I've been testing pops against other new options
such as pflow for future reference via various
experiments and picking at anything that seems
illogical. My thanks to Jeff, and my colleague
Alex McLeod for explaining the apparent global
node effect.
now, that creep thread looks interesting…

-cpb