CEGs (er, CustomExplosionGenerators, since everybody else seems to like this acronym) should be switched from the current, frame-based timing model, to the millisecond timing model used in BOS.
To fix this, simply allow us to define a TTL as a float, instead of an integer, so that we can do TTL=0.5, and so forth. I'm pretty sure it has to get converted at some point anyhow, because it's not (supposedly) sync code, but I'm hoping this is a really straightforwards change here.
Why am I bringing this up?
Well, it's currently impossible to do really nice, low-poly and low-particle-count FX stuff that involves the rapid movement of bodies in space without some unprofessional-looking tearing effects. It's almost good enough, but not quite, and I suspect good enough shouldn't be hard to reach, so I thought I'd ask.
I've been working on building stuff with low TTL values and testing it, and while it works better than I hoped, it still doesn't work to what I'd consider a professional standard.
For example, I have some really kewl flames for my jet aircraft in PURE. The effect looks good and solid, and it's cheap because it uses a single particle, but it has two problems:
A. I cannot keep it at 1 frame, because then it obviously blinks. Ok, it's blinking 30 times a second, which is hard to see for some people, but I find it visually very irritating. Ideally, it should be updating at least 60FPS, so that it's solid, but I can't do that.
B. So, I keep it at 2 frames, which is more expensive overall. 2 particles over 2/32th second > 1 particle over 1/60th, for a variety of reasons, starting with the fact that the particle needs to be tracked in space, etc., that much longer, while another one is being created over that timeframe.
This covers the blinks up, but it has the un-wanted side effect of showing the second frame during sharp turns. Because of the way that colormap works, when you fade from alpha 1.0 to alpha 0.01 in a single frame, it's averaged out to 0.5, therefore it's not faded enough to look like a mere motion-blur, and instead looks like it's tearing or mis-rendering, even though everything is working right in theory.
In short, it's almost acceptable, but not really. And, if I wasn't dealing with relatively slow-turning stuff like aircraft, but instead, say, was trying to do an animated glowing sword-blade, masked lights on the sides of a swiftly-bouncing ground vehicle, etc.- places where changes of vector are really fast, per sim frame, but are being interpolated otherwise- it'd look worse. At 1/60th of a second, it looks pro, and I only have to use the one particle, over and over and over again, to achieve a solid effect.
If anybody could look into this, I'd appreciate it. There are a lot of neat things that can be done with CEG that, frankly, most mods aren't using yet, but with PURE, I'm (finally) going to be able to show some of my work off, and this would help make things look even better.
CEGs and a better timing model
Moderator: Moderators
Oh yeah, and while I'm talking about CEGs in general... something is borked with the behavior of BitMapMuzzleFlame and DIR. It works great, for anything that is flat, but if you have a weapon that goes from low-trajectory to high-trajectory... the muzzleflame is obviously not working right. Something very odd is happening there. Lemme screenshot this:
This is low-trajectory:
High-trajectory:
Any questions? It's, er... broken. Something odd is happening to BitmapMuzzleFlames when dir is applied, when the value of x rotation is changing. It's really dramatic here, but is probably happening everywhere. I've been wondering about that, since muzzle-flames on aircraft have always seemed to be screwy and needed special care, but I've finally caught it misbehaving in an obvious fashion, so there ya go. I'll also put this on Mantis, of course.
This is low-trajectory:
High-trajectory:
Any questions? It's, er... broken. Something odd is happening to BitmapMuzzleFlames when dir is applied, when the value of x rotation is changing. It's really dramatic here, but is probably happening everywhere. I've been wondering about that, since muzzle-flames on aircraft have always seemed to be screwy and needed special care, but I've finally caught it misbehaving in an obvious fashion, so there ya go. I'll also put this on Mantis, of course.
Yes, yes, yell at me for spamming my own thread if you wanna, but check this out: I just found another problem. Smoke (the simple, but only-animated-system-in-Spring-for-no-apparent-reason one) shows up far greater than AirLOS distances. I just finished my landing animations for stuff that is being "airdropped" in PURE, and you can literally watch where another player is placing stuff, by following the smoke 
