[SUGGESTION] Reaction fire automatic weapons behavior

[Yatta]

Maybe automatic weapons could behave differently in reaction fire mode. They are supposed to be the best weapons to shoot at a  moving enemy.

Here's what I was thinking about :
- Soldier is on "reaction fire" with its automatic weapon.
- An enemy is moving in front of him.
- After the enemy spent enough TU moving in front of the soldier, the reaction fire starts.
- The soldier then shoot 1 bullet at the enemy for every x TU (depending on weapon's firing rate) spent by that enemy.
- Once doing reaction fire to that enemy, the soldier should not be able to react to another enemy move in the same round.

It would allow the shooter to 'track' the enemy movement with its automatic gun (quite like cheap TU gun shoot that can happen multiple times on a move), instead of just shooting all the burst at a single point of the enemy course. Would look more realist, and give some 'specialization' to those automatic guns.

I think I might be able to code that if it could be interesting for the official version.

[Hertzila]

I'm not one of the project leaders but you definitely have my support on your idea.

[Duke]

Are you talking about splitting the burst of an automatic weapon or rapid single shots in semi-automatic mode ?
The first wouldn't make sense according to my own calculations, the latter sounds reasonable to me, but would change the balance of the game.

[Yatta]

The first : splitting the burst of an automatic weapon.
Why doesnt it make sense ?

Im currently working on a prototype, but im having difficulties - im not familiar with C and the project, and weapon/fire definitions  gives me a headache.

[Duke]

Why doesnt it make sense ?

1. Select an amount of seconds per TU. I took 0.5, ie. 1 sec to move one square.
2. Select a 'realistic' rate of fire for your auto gun. I know of assault rifle 600 and MG 1200 rounds per minute.
==> I end up with 10-20 shots while the actor moves one square.

At the army we were told to produce tiny bursts of 3-5 shots (it's close to impossible to get less than 3 shots from the MG, not to mention a change of direction during those 3 shots). So I think it's ok if the complete bust is targeted at just one square.

[Yatta]

UFO:AI rpms arent realistic. For instance, during the time it takes for a soldier to run on 20 meters, another soldier can only shoot a 20-rounds burst. One could count to 20 faster than that. So I wont be trying to add realist rpm in the reaction fire if the 'normal' fire isnt realist itself.

Anyways its not possible to consider a TU as an unit of time equivalent to X seconds, since it doesnt work like that : fast soldier doesnt use less TU-time to do an action : they just have more TU units to spend, so you cant base your rpm on the enemy's TU. Well I know you know all this already, its just to make my logic clear.

So what I am doing is searching in the firedefs of a weapon, which firedef shoots the more bullets, and base the 'tu-rpm' of the weapon on that. Then I know the weapon can shoot 1 bullet every x TU spent by then enemy - and use the enemy's speed to influence that 'tu-rpm'.

[Hertzila]

...'tu-rpm'... ... 'tu-rpm'.

Just a small comment, wouldn't that be rptu (rounds per time unit)? Or rpTU?

[Yatta]

Actually yes, I didnt really tought oh it, just kept 'rpm' because it was a known accronym

[Duke]

I'm not preaching realism for a UFO game I was just reacting to:

Would look more realist, ...

And you're right oc, TUs don't have much to do with time. It's a rather abstract unit. Think 'action points'.

Another thing to think about:

- The soldier then shoot 1 bullet at the enemy for every x TU (depending on weapon's firing rate) spent by that enemy.

Have you already looked at that part of the code ? I'm only 98% sure, but I fear you'll only get control when the actor has reached a square, that is after 2,3 or 4 TUs depending on the type of move.

[Yatta]

Yes I did, I also had to modify a little the way an actor spend his point while moving (code wise, it doesnt change a thing ingame).

So the end result is that when an actor moves to the newt tile, it calls the "spending TU" function to spend the 2 TU, and this tells all active reaction shooter tracking this target to check if thats enough time to shoot their next bullet(s).

The whole system works right now, and its quite interesting to see sometimes :
Reaction fire can be triggered by an enemy reaction fire, so during your turn, you can have a soldier with RF enable, and an enemy in view. You tell another soldier to move.
It triggers the enemy RF.
As that enemy spent TU to shoot, it calls for potential RF shooters who might want to shoot at him.
Your RF soldier shoots back to cover your moving soldier.

Im not sure if that has any real strategic application, tough. Its just fun to see the chain  reaction

[Duke]

1. Congrats !   If you managed to implement that, you seem to have a better understanding of the event system than I do. I hope you will also help us with some event-related bugs

2. Guess it's time for you to upload the .diff to our patch tracker at SF. (a line of code can tell more than a 1000 words (TM)).

3. Reaction fire of my own troops during my own turn ?? That *must* be discussed with Winter/BTAxis/Mattn imho. Maybe on IRC ? But I guess you could easily eliminate that just in case.

4. Did you also cover the case when the actor is killed in mid-move ?

5. Do you also have a map where the effects of your patch can easily (and more or less reproducible) be observed ? You may consider to modify the alien spawn points of an existing map.

[Yatta]

The prototype fully work(ed), but I recently began to have to *very* frequent crashes on seemingly unrelated code (netstream things, external dll, TR_TestLine_r() ...).

I dont know that much about coding, but I clearly done something wrong at some point. My current theory is that I gave bad input to a function that directly handles stuff in memory, and this could be causing that random mess. Ill be trying to find what I did wrong, but if you have a clue on what might cause such behavior, ill be glad to hear it.

Other that that, has soon as the crashes are resolved, Ill show you the results, by source or in video - Im not sure my code could be included as it, I really started tweaking the code out of curiosity, and didnt tought I would go that far (the g_reaction.c is almost entirely rewritten) - so its far from clean.

Note im still a novice on C coding, and I dont have a clue on how to generate a .diff or put anything on the vss, which might be a good thing for the moment.

About the actor killed while moving : I had that crash during dev, but could tame it. Not sure I did it in a clean way, tough.

[Duke]

... and I dont have a clue on how to generate a .diff

Rightclick the file->tortoise->Create patch

[Yatta]

thanks, ill give you that when I get to solve the crash thing.

[Mattn]

you should maybe upload it to this forum topic, so others can have a look and maybe help you with the error