Triggering func_emitters

[SteveL]

I have a tracker action to make one-shot particles controllable by triggering ( previous discussion ). I want to check briefly how people think they should work.

Particles that cycle for ever can be turned on and off by triggering the func_emitter. When you restart them by triggering, they start up again with random timing so that you can trigger two or more of the same type at the same time, and the particles won't look identical or move in sync with one another. What you can't do using the current system is trigger one-shot particles, because the random timing usually means they don't show up at all (see prev discussion for details). So you can't have a puff of smoke come out of a sewer when the door is opened, or a bunch of sparks shoot out of a rusty lever or button when used. Not easily, anyway.

I've fixed that up in my test build so that when triggered "off" the particle does nothing, when triggered "on" it fires. But after trying it in a test map, I think the better way to handle one-shot particles would be to have them always fire when triggered. After all, once they've fired they stop doing anything and they look "off" anyway. I can't think of any reasons we'd want to distinguish between "on" and "off" for particles that don't carry on puffing away forever. The only possible reason I can think of is, if the particle lasts a long time before stopping, you might want to trigger it off before it finishes. I haven't thought of any realistic situations though.

 

Does anyone think that it needs a spawnarg? Or should we just have one-shotters always fire when triggered?

[Bikerdude]

I think the better way to handle one-shot particles would be to have them always fire when triggered. After all, once they've fired they stop doing anything and they look "off" anyway.

+1

[SteveL]

One scenario to consider is that func_emitters can apparently have more than one particle attached to them, using "model1", "model2" etc spawnargs. That's supported in the code (if it works), but no published maps do it (I just did a quick check). Someone might want to attach both one-shot and cycling particles and have the cycling one turn on and off but the one-shotter always fire. But that would be very complicated to set up and the mapper would have an easy workaround, i.e. use two func emitters like everyone has until this point, so I'm still liking the simple option.

[Obsttorte]

For one-shot particles there is the spawnarg cycleTrigger. This will reset the particle timer to zero upon triggering. The only downside is that upon map start each partice fires once. This may be circumventable by using startoff, but I can't remember if triggering it will turn it on then if cycleTrigger is used. Would have to test it.

[SteveL]

I don't think cycletrigger will work for one-shots, although I didn't test it. What it does is change the behaviour of triggering so that triggering means always on, not on/off, which covers my question here now I come to think about it. It'll still need the fix for one-shots though, because it doesn't override the random time offset that stops them being seen. But it's an alternative to the fix I had in mind, which was to automatically detect non cycling particles and make activation work differently.

[SteveL]

For one-shot particles there is the spawnarg cycleTrigger. This will reset the particle timer to zero upon triggering.

 

Thanks for this, I have changed the plan since checking it out. "cycleTrigger" was clearly the original solution to this problem, and fixing it has resulted in far simpler code than the fix I tested yesterday evening.

 

"cycleTrigger" got broken when someone gave func_emitters the ability to use multiple particle models. They also introduced a random time offset to make the particles look different. That overrode what cycleTrigger does, and broke the ability to trigger one-shot particles. Every other particle effect uses a "diversity" shaderparm instead of a time offset. Replacing the time offset with the standard diversity setting makes it all work again, and without the need for the func_emitter code to work out whether the particle is cycling or not (which is what I coded up yesterday).

 

The one extra change I'll make is to add some DR documentation for "cycleTrigger" because its purpose isn't at all clear from its name. I'd have changed the name, but it's been used in a published map, so I'll just add DR help notes and make sure it shows up in the default spawnargs.

[nbohr1more]

 

 

when someone gave func_emitters the ability to use multiple particle models

 

 

Tels did this to allow SEED to randomize particle distribution. If I understand the fix correctly, this shouldn't

break that functionality... Tels?

[Tels]

 

Tels did this to allow SEED to randomize particle distribution. If I understand the fix correctly, this shouldn't

break that functionality... Tels?

 

I have no idea without delving into that code again - which I'd rather avoid at this time

[Tels]

.

Edited March 21, 2015 by Tels

[Tels]

Oops, that one was probably me: Mea culpa!

 

"cycleTrigger" got broken when someone gave func_emitters the ability to use multiple particle models. They also introduced a random time offset to make the particles look different. That overrode what cycleTrigger does, and broke the ability to trigger one-shot particles.

[SteveL]

Np, it's fixed now and won't break seeded particles.