Yes, I see. I just thought it was easy to add those, if it's not, then it's OK
good, ok then^^
Some new Infos:
Well I often spoke about 4in1 Particle Engine and all that crap, now I want to finally reveal the mysteries about it (I was even asked about that on myspace

). Now first forget about 4in1 another one has made it into my development progress, thus it's 5in1 now xD
The Concept behind it
There're 5 root classes with (sometimes highly) different features, variables, structures and functions compared to the other ones. So instead of having every crap in one class (omg ParticleEmitter.uc of the Demo..

) everything is highly optmized and allocated over the 5 SubEngines.
The 3 major differences
1 - The first group of SubEngines generate particles that become independent from the Emitter and move freely and can be dynamicly changed during gameplay, they use Actors to archive Particles (every UScript Particle System does it that way) - the most common way to generate Particles.
2 - The second group of SubEngines generates particles that always depend on their Source Emitter. They're able to move with the emitter, either while moving for itself AND with the emitter, or in an attached way...
It uses Actors too. It's mostly used for BeamEmitters or Particle Systems whose particles should stay static depending on the Emitter.
3 - The last group is a combination of both, BUT doesn't use any actors or spawns anything. It instead generates pure VISUAL Particles, yes Objects - not Actors, that ONLY have variables and structs relating Particle Stuff, hundreds of variables of Actors aren't worrying anymore... It also gives us the ability to draw procedural/dynamic particles that are fully hardware accelerated and have some of the following features (and of course more..) : Dynamic Color and Color Fading, U/V Size, U/V Tiling, Panning, writeable Particles, stretchable Particles and much more magick..
Concerning the actual draw process it is used for the Lensflares and Dynamic Corona too, but these are actors were the application of actor-driven rendering makes sense - you know you need to add these in the map. Here you just need to add the emitter which controls the particles: you want to control little bastards called particles and not really to spawn actors over and over again..
SubEngines in Detail
1. XSubParticleEngine
Will be the most common type and is focussed on implementation of Standard SpriteEmitters, MeshEmitters, SparkEmitters etc. The "X" is related to it's wide range of usefulness.
2. HermiteSubParticleEngine
Seriously seen Emitters of this root class aren't Emitters because they don't really spawn Particles but Special Actors (Projectiles for example) using already common Emitter Methods. Each Emitter does only what he does, they're far from being flexible but on the other hand they have a reduced data count and complexity.
3. StaticSubParticleEngine
Emitters of this root class are intended to either not move or never really exist during gameplay. Also their particles (here better to call: elements) never become independent from their Emitters. Mostly used for a proper BeamEmitter implementation. However the "static" shouldn't be interpretated too seriously, many SubClasses may move, being attached and so on.
4. VisualSubParticleEngine/EnigmaScreenEngine
One of 2 special SubEngines that don't spawn Actors but pure visual Particles. This root class has a big brother called HydraRootParticleEngine. It also exists in 2 variations: (This) placeable root class that is placed into a map to generate particles and the EnigmaScreenEngine which can be used to render On-Screen-Particles
5. HydraRootParticleEngine
The other ParticleEngine whose Emitters render fully visual Particles. They are based on (many) SubEmitters just like the Emitters (EPIC's Emitters, not xEmitters) of the Unreal Engine 2. This is a major ParticleEngine because it's overall functionality is completely different compared to the other 4 ones. To have the ability of multiple combineable emitters for the other Engines too I also implemented a general Emitter Combiner (it may even combine Emitters of this Engine

).
//Edit:
Here you have a flowchart of all the Emitters and their Root Classes (the structure is far from being final, but yet progressed very well):
"Argh that guy is still just writing f****** boring text.. show ma pix dude!" Some might think.. and yes.. thou shall be rewarded for all my non-pic related posts .. soon xD