There's not currently a way to "attach" an animated sprite (from a spritesheet/atlased animation) to the projectile itself, only to the particles it emits, which limits the kinds of effects we can do, as the particles are left behind, while the projectile keeps moving. There's a "model" tag in weapondefs, so we can assign a simple textured quad mesh to it, but then its texture would be static - and it wouldn't always be pointing at the camera, like particles do.
My suggestion to work out this glaring omission (I can't recall a single game engine with a particle system which doesn't have this) is to add a new parameter to weapondef. Since the texture1 weapondef parameter is used as the projectile, beam, flare or shield sprite for practically all weapon types, is to take animation parameters from a string, just like animParams does within a effect 'properties' table.
The name of that new weapondef parameter would be something like "texture1animParams", and take a string value (xcount, ycount, duration). A randomizable startframe in-string parameter would be very advisable, to prevent excessive uniformity when multiple projectiles are shot at once. The default playback mode would be 'loop', but others, like 'pingpong' and 'playonce', could be added as a final string parameter.
Eg:
texture1animparms = "4 1 8 3r1" -- could start from frames 2, 3 or 4
texture1animparms = "4 1 8 3r1 pingpong" -- plays forward then in reverse, alternating
There's not currently a way to "attach" an animated sprite (from a spritesheet/atlased animation) to the projectile itself, only to the particles it emits, which limits the kinds of effects we can do, as the particles are left behind, while the projectile keeps moving. There's a "model" tag in weapondefs, so we can assign a simple textured quad mesh to it, but then its texture would be static - and it wouldn't always be pointing at the camera, like particles do.
My suggestion to work out this glaring omission (I can't recall a single game engine with a particle system which doesn't have this) is to add a new parameter to weapondef. Since the texture1 weapondef parameter is used as the projectile, beam, flare or shield sprite for practically all weapon types, is to take animation parameters from a string, just like animParams does within a effect 'properties' table.
The name of that new weapondef parameter would be something like "texture1animParams", and take a string value (xcount, ycount, duration). A randomizable startframe in-string parameter would be very advisable, to prevent excessive uniformity when multiple projectiles are shot at once. The default playback mode would be 'loop', but others, like 'pingpong' and 'playonce', could be added as a final string parameter.
Eg:
texture1animparms = "4 1 8 3r1" -- could start from frames 2, 3 or 4 texture1animparms = "4 1 8 3r1 pingpong" -- plays forward then in reverse, alternating