| 1 |
[quote]shouldnt this be a developer thing?[/quote]
|
1 |
[quote]shouldnt this be a developer thing?[/quote]
|
| 2 |
If you really want something and no-one wants to do it, you can dev it yourself. This is one of the benefits of open source.
|
2 |
If you really want something and no-one wants to do it, you can dev it yourself. This is one of the benefits of open source.
|
| 3 |
\n
|
3 |
\n
|
| 4 |
\n
|
4 |
\n
|
| 5 |
Staring at the screenshot and thinking it over suggests to me that the current behavior is indeed the lesser of two evils.
|
5 |
Staring at the screenshot and thinking it over suggests to me that the current behavior is indeed the lesser of two evils.
|
| 6 |
[spoiler]
|
6 |
[spoiler]
|
| 7 |
* The behavior requested in this thread is in a way directly opposed to the fix requested in the Slasher thread.
|
7 |
* The behavior requested in this thread is in a way directly opposed to the fix requested in the Slasher thread.
|
| 8 |
* This thread: Units on attack move should chase an enemy out of their current effective range, in order to bring it into effective range, regardless of potential hazards in the target's area.
|
8 |
* This thread: Units on attack move should chase an enemy out of their current effective range, in order to bring it into effective range, regardless of potential hazards in the target's area.
|
| 9 |
* Other thread: Units on attack move should [i]not[/i] chase an enemy out of their current effective range, in order to bring it into effective range, regardless of potential hazards in the target's area.
|
9 |
* Other thread: Units on attack move should [i]not[/i] chase an enemy out of their current effective range, in order to bring it into effective range, regardless of potential hazards in the target's area.
|
| 10 |
*
I'd
say
the
current
Fencer
misbehavior
and
the
proposed
change
to
radar
dot
targeting
stem
from
the
same
defect:
breaking
the
fundamental
assumption
that
a
unit
on
Attack
Move
will
kill
all
enemies
presently
in
range
before
attempting
to
chase
one
not
in
range.
|
10 |
*
I'd
say
the
current
Fencer
misbehavior
and
the
proposed
change
to
radar
dot
targeting
stem
from
the
same
defect:
breaking
the
fundamental
assumption
that
a
unit
on
Attack
Move
will
kill
all
enemies
presently
in
range
before
attempting
to
advance.
|
| 11 |
* Arguably it's worse for snipers, since they'll get afflicted even if the selected target has not yet left their range.
|
11 |
* Arguably it's worse for snipers, since they'll get afflicted even if the selected target has not yet left their range.
|
| 12 |
* "You can get the other behavior with move" applies to [i]both[/i] the current and proposed behaviors, within the pictured case: manually move so that the sniper can see its target, manually move (stop, rather) so the sniper doesn't go chasing its target.
|
12 |
* "You can get the other behavior with move" applies to [i]both[/i] the current and proposed behaviors, within the pictured case: manually move so that the sniper can see its target, manually move (stop, rather) so the sniper doesn't go chasing its target.
|
| 13 |
* In principle, the latter is preferable, since the former requires active micromanagement to keep the sniper from going not far enough / too far, and to react to new threats. However, I submit that letting a 750 metal, 560 health unit get within 400 elmos of the enemy without user attention is a contraindicated action, and thus the attack-move-chase sniper would require most of that micro anyway.
|
13 |
* In principle, the latter is preferable, since the former requires active micromanagement to keep the sniper from going not far enough / too far, and to react to new threats. However, I submit that letting a 750 metal, 560 health unit get within 400 elmos of the enemy without user attention is a contraindicated action, and thus the attack-move-chase sniper would require most of that micro anyway.
|
| 14 |
[/spoiler]
|
14 |
[/spoiler]
|
| 15 |
\n
|
15 |
\n
|
| 16 |
Is there a compromise?
|
16 |
Is there a compromise?
|
| 17 |
[spoiler]
|
17 |
[spoiler]
|
| 18 |
* GoogleFrog's idea is the obvious one: tie it to movestate.
|
18 |
* GoogleFrog's idea is the obvious one: tie it to movestate.
|
| 19 |
* Hold pos: don't close
|
19 |
* Hold pos: don't close
|
| 20 |
* Maneuver: close if already within <500 range or such (we're already near, might as well inch forward a bit)
|
20 |
* Maneuver: close if already within <500 range or such (we're already near, might as well inch forward a bit)
|
| 21 |
* Roam: always close (assume this is the "I go wherever I want" state)
|
21 |
* Roam: always close (assume this is the "I go wherever I want" state)
|
| 22 |
* Tactical AI logic: If don't fire at radar gadget tells us we can't shoot yet, and movestate permits, move slightly towards target repeatedly, until we can shoot.
|
22 |
* Tactical AI logic: If don't fire at radar gadget tells us we can't shoot yet, and movestate permits, move slightly towards target repeatedly, until we can shoot.
|
| 23 |
[/spoiler]
|
23 |
[/spoiler]
|
| 24 |
\n
|
24 |
\n
|
| 25 |
This is not, on the face of it, exceptionally complicated to implement – but it is still nontrivial. Given that the current behavior is considered entirely adequate by all but one of the people who have bothered to comment, it's going to be low priority to say the least (@Sprung might be interested, you can try asking him).
|
25 |
This is not, on the face of it, exceptionally complicated to implement – but it is still nontrivial. Given that the current behavior is considered entirely adequate by all but one of the people who have bothered to comment, it's going to be low priority to say the least (@Sprung might be interested, you can try asking him).
|
ignore radar dots bugged does not ignore radar dots