Smoke code rewrite, please!

[Argh]

Basically, I want the Smoke code to be able to make use of multiple, modder-defined texture sets. Instead of the current code, which always uses the same series of bitmaps, it should make use of whatever bitmaps were assigned to it, just like the custom cursors do.

If it could do that, and use ColorMap, it'd replace a lot of of the more complex FX processing in Spring with smaller numbers of objects that looked complicated due to the bitmap animations. This could greatly aid Spring's performance and make it look more realistic. Moreover, while it would be really nice to have stuff with SimpleParticleSystem complexity around, it's not really necessary.

I will try and pry some time free over the next week or so to look into this. If anybody else is already messing with this, let me know... this should be almost-trivial coding, frankly...

[Neddie]

How did z get the custom smoke in Kernel Panic to work? It may already be possible, Argh.

[zwzsg]

I replaced all the \bitmaps\smoke\smokeXX.tga by my own.

BTW the RESOUCES.TDF resources [resources]{[graphics]{[smoke]{smoke00=.... was ignored at the times.

It works in Kernel Panic because in KP the smoke is only used on geovent, nothing else smoke. However, it's a very crude solution, and doesn't allow multiple kind of smoke.

[Neddie]

By the by, the more I play KP, the more I think your smoke rocks.

[Argh]

Yeah, I've messed with it, too. The trouble being that you just can't do anything to it without ruining it for everything that uses it, because:

A. All of the Smoke FX that are hardcoded expect that one sequence.

B. All of the hardcoded FX may not be changed.

So the big challenge is to figure out a way to cut the hardcoded FX out of Spring. I think that getting Smoke's code to be able to look at different sets of files is the less-messy challenge, and will allow us to sidestep the hardcoded stuff for a second.

[kiki]

Custom smoke is important to me too. Need for mah mahd

+1