Hello!
I have an emitter launching missile particles. AWESOME!
I’d like to attach one of the smoke emitters from the lib_particleEffects_01.lua file to each missile in the emitter.
Yeah, it can get outta hand pretty quick if I’m not careful as far as performance goes, but there’s only going to be a couple missile on-screen at any one time. Any clues?
I’d appreciate any help as always.
Best,
Mario [import]uid: 11636 topic_id: 11570 reply_id: 311570[/import]
I am not sure what you mean exactly. Could you send in a small sample to demonstrate what kind of effect you’d like to achieve?
[import]uid: 10504 topic_id: 11570 reply_id: 42461[/import]
I think he’s trying to attach an emitter to each particle emitted from another emitter. I, too, am wondering if that is currently possible, aside from the obvious performance issues that could introduce. [import]uid: 9422 topic_id: 11570 reply_id: 42465[/import]
@Xenon Yeah thats exactly what Im trying to do. I want to make the particles from a particular emitter emitters themselves!!
I know about the ‘attachEmitter’ to a sprite object, but the reason I want to keep them all as emitters and particles is that they’re already setup to be ‘oneoffs’ and they clean themselves up so neatly with the Particles.CleanUp() command.
[import]uid: 11636 topic_id: 11570 reply_id: 42491[/import]
Ah, you mean particle trails. No, this wasn’t implemented yet due to performance reasons (even if you try to keep the particle count as low as possible, this feature would need quite a lot of CPU cycles because it exponentiates the processing time needed with every single particle on screen).
Some kind of workaround would be to take an emitter, loop through your missile particles and position the emitter at the first particle’s position. On the next frame (or after, say, 10 millisecs), proceed to the next missile and place the emitter on this particle’s position and so on. The drawback is that this method requires a very high emission rate for the emitter used (as higher as more missiles are on screen).
However, the simplest and most efficent way to solve this (especially in terms of performance) would be to use your own missile movement code (which is very simple to do in most cases) and simply attach an emitter to each of them). [import]uid: 10504 topic_id: 11570 reply_id: 42585[/import]
Nope. No can do. 
The missiles are particles using the FXfields to affect their trajectory and “home in” on the target once they pass into the threshold, along with dying after a certain amount of time set by the particle emitter. Your engine is far too important for me NOT to use!
Oh well, just wanted to make sure there wasn’t an “easy” way to do it before I rolled my own.
I’ll see what I can come up with, but I can live without it if need be. It would be a nice “to have” though down the road.
Appreciate the advice! [import]uid: 11636 topic_id: 11570 reply_id: 42589[/import]
We’d really love to add this, but we must be careful when adding new features. Because each particle has to go through an entire processing chain, the most important thing is to keep performance as good as possible, and particle trails would require another processing chain for every single particle then. But we’ll spend some thoughts if and how we could implement this feature. [import]uid: 10504 topic_id: 11570 reply_id: 42594[/import]
If there was a method similar to GetParticle(index) but that could target only particles of a specific emitter then he could loop through the missile particles of the missile emitter each frame and manually set the position of, say, 4 smoke emitters to the position of the first 4 missile particles.
If as he says there are only a couple missile particles on screen at a time then they would each always be assigned a smoke emitter. If there are ever more than 4 missiles live then the most recently “born” missiles won’t have smoke, but perhaps the screen will be so chaotic anyway the player won’t notice. As long as the emitters get reassigned to the oldest 4 missiles on screen, even if there are dozens of missiles they’ll all eventually get a smoke emitter for the final part of their trajectory before they die.
Knowing in advance that there will only ever be a max of 4 smoke emitters at once he could tune the particles’ parameters to have acceptable performance in that event. [import]uid: 9422 topic_id: 11570 reply_id: 42701[/import]
@Xenon Yeah totally!
I was currently cycling thru every particle in the Particles array, finding the ones that were launched from emitter type “MissileEmitter” and was planning on manually creating and moving a couple of smoke emitters and manually updating their position to matchg the missile particles, but meh, at this point I just might hold off because then I’d have to add checkers to check the “alive or not” state of each missile particle, and if indeed one of the missiles hit their target or timed out and died, then I’d have to manually whack that particular smoke trail, etc.
More trouble than it’s worth at this point, but it DID get me to get down and dirty with ParticleCandy’s source code so it was a win either way.
In my case it woulda been sweet though, because my game is turn based, so fire beam weapons, finish. Fire projectile weapons, finish. There wouldn’t be a ton of missiles flying every which way with trails blowing smoke out their rears, constantly sucking CPU cycles, etc. [import]uid: 11636 topic_id: 11570 reply_id: 42728[/import]
When looping through the particle array you can use each particle’s .emitterName property to find out the type of a certain particle.
We use to code missiles seperately and then simply attach an emitter to it. Since projectile objects are quite numerous in a game, it’s more efficient to do it this way, because most shot / missile movement code can be done in a few lines only and in most games, you have to tailor your shot objects to your specific needs anyway.
Particles usually are not meant to be used as “intelligent” or interactive objects. Generally, they are used as “create and forget” objects to create automated (visual) effects. We added some functions to interact with particles with the later updates, but the particle engine originally wasn’t designed as a “sprite manager”, so there are some limitations if you want to do so.
[import]uid: 10504 topic_id: 11570 reply_id: 42817[/import]