You have one texture, and the texture contains multiple frames on it. Check the default sins texture directory and look at autocannon.tga.
So, this contains several small sheets in it. Various muzzle flashes to randomize between and some tracers for projectiles.
The sheets I am using in Black Sun look something like this, but their individual frames are much larger. I seem to have run into some kind of limit in that sins can't use a 4kx4k texture properly (I wanted high-definition frames for explosions), so most of my animated sheets average 512x512 to 2kx2k. Yeah, if your project is really straddling the ram limit you want to be super careful with these.
How it works is that in the respective TextureAnimations directory, a text file hands the game information about that sheet. This is what my average entity for that looks like.
TXT
textureFileName "ah_medflame1desaturate.tga"
numFrames 16
numFramesPerRow 4
startTopLeft [0, 0]
frameSize [128, 128]
frameStride [128, 128]
To explain what these lines do,
textureFileName is pretty obvious. Both dds and tga work. I try to stick to tga.
numFrames - this is your total frames for the animation this file accesses. For something like that autocannon.tga the next lines will be a lot less clear than this.
numFramesPerRow - This tells the game to cycle rows after X frames have been played. Again, this helps keep the autocannon.tga from drifting off its current stuff. For my sheets, they are usually 4x4.
startTopLeft - This will almost always be 0,0 except in the circumstances where your frames don't start at the top left (like autocannon.tga, this will determine the starting location of whatever part of that sheet you are using). Since stuff like autocannon.tga involve math and co-ordinates and stuff I avoid using complex sprite sheets like that. I suck at math.
frameSize - Fairly obviously. You can use XNview to build a grid to determine frame sizes in most sheets, because for some reason some companies use non-standard sizes like 99x99. If this is not correct, the frames will "drift" on the particle.
frameStride - This should be the same as frameSize always, I think. I am pretty sure this determines how the game "sees" what the next frame should be located at.
Inside ParticleForge, instead of assigning a texture, you assign that animated texture text file. Here's a gander at my high-performance, streamlined workplace.
So, basically, the life of the particle spawning that animated texture is determined by the frame counts and the FPS. The FPS and frame counts don't seem to translate 1:1; my 16 frame sheets @ 30fps usually last 0.85 or 0.8. Well, I don't pretend to know math. If the life is too long for the sheet, it flips out. If the sheet has too many frames it also will flip out. Not sure why. But, a single particle can cycle the entire animated texture. The goal of particles is usually to simulate animation - I can turn an explosion into 1/8 of its original uptime by using these animated textures, and they will usually look much better than using static textures. It all depends on what kind of texture sheets you have available, though. I had to rip dozens of games to find anything good. I still don't have exactly what I need; I'll need to make some custom ones.
But the end result really can't be competed with in this game, I think. I may not be the best particle editor here, but I think Black Sun will really catch people off guard on how good the particles look. Many of those are probably too large/flashy for something like b5 weapons but the methodology could still be useful. Maybe I could build a video tutorial to explain my designs.
