[http://sourceforge.net/p/ufoai/feature-requests/272 Item 272] imported from sourceforge.net tracker on 2013-01-28 20:16:10

The current shot-animations (includes particles & sounds) are not very flexible in their definitions. They work most of the time, but sometimes we need to make some very crude hacks to get something to work.

Winter proposed some changes to the current system some time ago and I just though I'll sum up my thoughts about it here.
@Winter: I'm not sure I remember everything you told us back then, but I think the following should cover most of it.

To sum it up: A fire-sequence should consist of the following ...
* A number of "shots"
* Each "shot" can have several "traces" (actually being shots themself, but I couldn't find a better word right now)
* A "shot" can either have a single projectile&sound or one for each trace in it.

To get this I suggest to change/extend the "firedef" definition as follows:

* "ammo" - Actual AMMO USED (no change of behaviour to current value)
* "delaybetweenshots" - Delay between the SHOTS (was delay between every single trace)
* "speed" of projectiles (same as now - but used by traces, see below - especially "ptlonce")
* "firesnd", "projtl" "impact" (same as now - but used eiher by each trace or by each shot)
* "numshots" - Number of SHOTS
-) "numtraces" - Number of TRACES PER SHOT
-) "delaybetweentraces" - Delay between each trace (see also "delaybetweenshots")
-) "sndonce" [boolean] - If set to true the defined sound will only be played once (for this shot).
-) "ptlonce" [boolean] - If set to true the actually traced shots do not use any particles - i.e. INVISIBLE TRACES. The defined particle will be launched only once (for this shot). Also: "speed" will only be assigned tot he particle. The (now invisible) traces should use speed 0 to speed up calculating.

* Everything else in "firedef" will stay as it is.

Comments, Thoughts, patches? :)

Werner
===== Comments Ported from Sourceforge =====

====== tlh2000 (2007-10-16 12:41:28) ======

Logged In: YES
user_id=116930
Originator: NO

"delaybetweenshots" and "delaybetweenshots" - please explain a bit more - looks redundant
====== hoehrer (2007-10-16 12:52:24) ======


====== hoehrer (2007-10-16 12:52:25) ======

Logged In: YES
user_id=1434318
Originator: YES

Not redundant, but linked together: delaybetweenshots and delaybetweenTRACES

e.g.:
shots = 3
traces = 5
delaybetweenshots = 20
delaybetweenshots = 5

(first shot)
firing
delay 5
firing
delay 5
firing
delay 5
firing
delay 5
firing
delay 20
(second shot)
firing
delay 5
firing
delay 5
firing
delay 5
firing
delay 5
firing
delay 20
(third shot)
firing
delay 5
firing
delay 5
firing
delay 5
firing
delay 5
firing

Mind you - "traces" in my example in the first post are exactly the same as our "shots" right now ...
I think using the terms "burst" instead of "shots" and "shotsPerBurst" instead of "traces" ... this might avoid confusions.

I think the delay is the hardest part to implement, but it's kinda nice to have. For the rest something like in my patch (i did not change the parsing or headers yet) should work.

Werner

File Added: tracesPerShot_mk2.patch
====== hoehrer (2007-10-16 13:24:01) ======

Logged In: YES
user_id=1434318
Originator: YES

Updated the patch with some parsing and header code.
I also renamed the stuff to "bursts" and "shotsPerBursts".
The only thing still missing is the delaybetweenBURSTS fucntionality (and of course some testing - this is all theory-code)
Also the firstShotInBurst stuff might need some checking.

Werner
File Added: shotsPerBurst_mk3.patch