Jump to content
The Dark Mod Forums
Sign in to follow this  
SteveL

Triggering func_emitters

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.


FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 


 

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?


Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

 

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 :)


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

.

Edited by Tels

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

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.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...