[http://sourceforge.net/p/ufoai/bugs/304 Item 304] imported from sourceforge.net tracker on 2013-01-28 18:18:28

If reaction fire is activated and was used by a
soldier, the necessary TUs are taken from the next round.
So when the next round starts it may be impossible to
move this soldier.
Since enabeling reaction fire (or not disabeling it) is
an action which takes place in the actual round
(logical, isn't it? :-) I would expect the TUs beeing
taken also from the actual round.
This way players also gain more control over the
soldiers, because it's up to you to decide how many TUs
are reserved for reaction fire an how many are used for
other actions. (for Example: Am i going all the way to
the corner ending with just one shot for reaction fire
or am I stoping after half the way to be able to shot a
second time?)

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

====== bandobraz (2006-09-07 15:58:54) ======

Logged In: YES
user_id=1557623

This is intentional. However, perhaps we should add a limit
to reaction fire, e.g. 7 TU should always be left for the
soldier, or 14 TU, or half of his TU. Or perhaps the
reaction button should be tri-state (hoerer already
implemented that, but we have no button pictures): no
reaction, 1 shot, many shots. What od you think?
====== hoehrer (2006-09-08 06:42:23) ======

Logged In: YES
user_id=1434318

Bandobras is right, thsi behaviour is intended.

Currently the TUs you use up by clicking the RF button are
only for _RF-activation_, not for the actual shots, which
occur in the next round.


e.g.:
1.turn: TUs for activation
2.turn: TUs from shots + TUs for activation (auto)

The "TUs for activation" can be given back to the soldier by
clicking on the button again.

=================

IMHO the current bad behaviour is
1. that the soldiers can shot as often as he likes ... as
long as he has TUs left in the next turn.
2. That the TU-reservation is made _after_ the actual
attacks are executed

My proposal to fix the first problem is to only let the
soldier shot 1 time. No matter how few TUs the shot may
take. Haven't looked into the second one yet.

=================

If we would reserve the TU amount for a shot in the _same_
turn as the button is pressed we would eed to either make
the TU-cost _fixed_ or used the exact value that is used by
the current weapon (which one on two-handed?)

=================

Concerning bandobras comment on the tri-state code: Only
part of it is in the code yet, so the pictures are not the
problem ... there need to be intensive checks (saved TU
amounts of different states) in the code so it can work
correctly. It's therefore still a TODO. It can be used to
detect how many shots are allowed with only two states (on /
off) though.

=================

If anybody comes up with a better implemention than the one
abothe (with potentional fixes), please submit a patch so it
can be tested.
_I_ am not going to touch the code until the players focus
on _one_ behaviour. And I beg the other developers to do the
same.
Use the forums to discuss that or this bug-tracker (but NOT
IRC, except you put the log into one of these two)

Werner
====== hoehrer (2006-09-08 06:45:46) ======

Logged In: YES
user_id=1434318

See also the following feature requests (especially the 1. one):

FR 1543830 Raction fire: Remember setting after turn
http://sourceforge.net/tracker/index.php?func=detail&aid=1543830&group_id=157793&atid=805245

FR 1530240 Camping, a third "reaction-fire"-mode
http://sourceforge.net/tracker/index.php?func=detail&aid=1530240&group_id=157793&atid=805245

Werner
====== rechner-tester (2006-09-08 11:37:16) ======

Logged In: YES
user_id=1363849

Damm no function to quote! So i go by hand :-(

bandobraz wrote:
> However, perhaps we should add a limit
> to reaction fire, e.g. 7 TU should always be left for the
> soldier, or 14 TU, or half of his TU. Or perhaps the
> reaction button should be tri-state [...] no
> reaction, 1 shot, many shots. What od you think?
What about "multistat"? Pressing one time enabels 1 shot, 2
times 2 shot and so on as maximum.
If calculating the remaining TUs reachs 0 (or exactly: TUs
mod (shotcount * TUpershot) < TUpershot) the next klick
disables RF. So the player can start again.
Obviously this behaviour isn&#039;t compatible with selecting RF
for one round/multirounds, and wouldn&#039;t be necessary at all
if we would use TUs from the actual round. (see below)


hoehrer wrote:
[...]

> IMHO the current bad behaviour is
> 1. that the soldiers can shot as often as he likes ... as
> long as he has TUs left in the next turn.
see my suggestion above :-)

> 2. That the TU-reservation is made _after_ the actual
> attacks are executed
Sorry no idea :-(


> =================

>If we would reserve the TU amount for a shot in the _same_
>turn as the button is pressed we would eed to either make
>the TU-cost _fixed_ or used the exact value that is used by
>the current weapon (which one on two-handed?)
Ähm sorry I&#039;m not sure I get you&#039;re point (maybe my english
isn&#039;t good enough)
What do you meen with TU cost&#039;s aren&#039;t fixed? And what about
using "the exact value that is used by the current weapon"?
Isn&#039;t that the same? TU&#039;s depend one the weapon i use and
this amount is a fixed one?

As far as I can see there is no problem reserving TUs in the
actuall round at all. We simply use all TUs we have for RF,
because next round we get new TUs. So it&#039;s up to the player
to reserve TUs. :-)


The two handed problem maybe solved by prefering the right
hand (all the soldiers are right handed, aren&#039;t they? ;-)
If we run out of ammo on the right we switch to the left hand.
One question btw: Is there a difference shoting with right
or with the left hand?

[...]
>_I_ am not going to touch the code until the players focus
>on _one_ behaviour. And I beg the other developers to do
>the same.
Okay, I can completly understand your point. Hope we can
reach an consensus
[...]


Rechner-Tester

====== bandobraz (2006-09-08 18:01:11) ======

Logged In: YES
user_id=1557623

I&#039;d like to freeze RC5 code this Sunday, so I&#039;d like to do
something with the reaction fire before the freeze. Even
just for now, to enable better testing. What about a
restriction that reaction shot can be performed only if it
leaves 13 TUs for the actor?

This is 7TUs for enabling reaction shot next turn plus 4 TUs
to flee into hiding. Or the whold 13 TUs can be used for
fleeing or for a quick shot. This makes reaction fire not so
deadly both for the attacker and the defender. It&#039;s then
less of a frantic fire exchange between 2 actors and more a
tactical team-based fight. Another advantage is that newbies
will no longer be puzzled by the fact they only get several
TUs by disabling reaciton fire (after reacting this round).

I say again: this is only a temporal fix for RC5. Is it
acceptable? After some testning with this setting we may go
ahead pondering about the only true way of doing this...
====== rechner-tester (2006-09-09 09:38:20) ======

Logged In: YES
user_id=1363849

Sound&#039;s okay for me. But I&#039;m still sure of taking the TUs
from the actual round would be the better solution. Let&#039;s
give a few arguments:

1) No problem with "missing" TUs in the next round.

2) No problem with one/multi RF or mutil use of RF-Button
since...

3) ...It&#039;s up to the player how many TU&#039;s he wanna leave for RF

4) it&#039;s much more intuitiv. Actions I&#039;ll make will cost TUs
in this round. Not in the next (Anybody who can give an
example for an turnebased computer game which takes TU from
the next round?)

Ah, one more idea: Can any one remember the behaviour of RF
in UFO:Enemey Unknown?
Maybe this will give as some ideas
====== nobody (2006-09-09 10:54:51) ======

Logged In: NO

Code freeze for 2.0 was in RC4 already .. at least
officially. We should have done this before the first RC,
but that&#039;s another matter.

Since the current behaviour _works_ (not to everybodys
satisfaction but still) I want to hear a _very good_ reason
to change it before the 2.0 release.

Werner
====== bandobraz (2006-09-09 16:17:54) ======

Logged In: YES
user_id=1557623

> Code freeze for 2.0 was in RC4 already

I don&#039;t say about code freeze for 2.0 but for RC5. The game
is too unbalance and has to many icomplete features to have
code freeze for 2.0, IMHO. OTOH, semi-code freeze, where
only balances, incomplete features and fixes are accepted
would be fine, but for trunk --- two branches are too much pain.

> Since the current behaviour _works_

The current behaviour does not work --- it causes lack of
balance between player and AI, currently, a discourages good
tactics when AI starts using reaction fire (planned for RC5,
too).
====== sheldonh (2006-09-09 23:56:57) ======

Logged In: YES
user_id=735845

Here&#039;s how I&#039;d like RF handled:

1) An actor can reserve only one attack for RF. Because
it&#039;s a reaction to enemy movement, it cannot be an aimed
shot. To keep it simple, just make it that RF attacks may
only be primary attacks.

2) Reserving an RF attack costs something (7TU) in the
reservation round. The cost cannot be recovered.

3) Whatever the primary attack costs normally, this cost is
deducted in the round the attack occurs. If no RF attack
occurs, no cost is incurred in that round (but the
reservation cost is not recovered).

4) Regardless of whether an RF attack occurs, the actor
starts the next round in RF mode. If the player or AI
cancels RF mode, no reservation cost for the round in which
it is cancelled, is recovered.

As I recall, this is pretty damn close to how X-Com did it,
and I think it produced a very balanced result. It breaks
up the lockstep effect that ruins most turn-based games,
but still recognizes that your turn is where you have most
control.

====== bandobraz (2006-09-11 07:44:22) ======

Logged In: YES
user_id=1557623

In addition to limiting reaction fire, as I proposed below,
I&#039;d also propose (for RC5 or RC6, unfortunately I&#039;ll now be
busy and I cannot code this):

* reaction fire for AI actors
* AI should not move (only shoot) if any visible soldier is
in reaction fire state
* reacting actor always shoots second, or they shoot
simultanously
====== sheldonh (2006-09-11 16:51:55) ======

Logged In: YES
user_id=735845

See patch #1556518, which completes hoehrer&#039;s work on
tri-state reaction fire.

This doesn&#039;t implement any of the cool ideas people have
put forward here, it just finishes off code that was mostly
there already.

====== tlh2000 (2007-04-02 10:08:59) ======

Logged In: YES
user_id=116930
Originator: NO

if this is still in 2.1 - please reopen
====== sf-robot (2007-04-17 02:20:05) ======

Logged In: YES
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).