Should units remember their attack target after new order?

[YokoZar]

So, you're microing some tanks. You tell them to target a particular enemy unit that you need killed first. But you also need to move them to the flank.

The problem is, as soon as you tell them to move again, they forget their attack order and go back to default targeting. If you're fighting mixed units, they may shoot a different unit entirely.

Should this change? Should units keep a top priority unit as the one they previously received an attack order for, changing only when it goes out of range? Or will this cause confusion with some units, especially very slow to target ones?


Default priority should resume when the target moves out of range, dies, or the unit is given a stop order, of course. Or should the engine store a list of targets, and resume hitting them in order?

[Pxtl]

I'd rather have a "fire-at" order separate from existing "attack" orders, optionally enabled by the mod (the ability to attack a specific target while retreating will have drastic effect on mod balance). Units retaining their "attack" target having been given other orders is non-obvious behavior.

[Tobi]

Units already remember the last unit they attacked to give it "preferential treatment" when they keep being able to fire on it during the next (move?) order.

[Pxtl]

Units already remember the last unit they attacked to give it "preferential treatment" when they keep being able to fire on it during the next (move?) order.

... did anybody know that?

Anyone? Other than Tobi?

When does it get cleared? At the next attack order?

... can this be used to override firestate at all? Because my usual problem is how to get low-ROF units like the Janus to fire at the desired target (instead of wasting their shot on something else) without stopping.

[JohannesH]

Units retaining their "attack" target having been given other orders is non-obvious behavior.

This happens, though, when they have been given an order to attack ground and then move command with shift... Theyll fire that piece of land whenever given a chance until given a stop command or new attack target.

[CarRepairer]

... can this be used to override firestate at all? Because my usual problem is how to get low-ROF units like the Janus to fire at the desired target (instead of wasting their shot on something else) without stopping.

I suppose a simple widget can be made to do this. When issuing direct attack order with certain units such as Janus, set them to holdfire automatically. When target is dead or some other order issued (like move), back to fire-at-will.

[Pxtl]

@Car - that won't solve the problem that the Janus will stop moving when it reaches firing range. This is even more relevant with the Kodachi, which is a sitting duck once it stops moving.

What I was curious about was could I do the following:

1) Tell a unit to hold-fire (or ret-fire).
2) Tell a unit to attack the target.
3) Give the unit a move-order to buzz through firing range of the desired target, and it will open fire on the target (and only the target) despite being in hold-fire mode and no longer having an attack order.

Actually, the widget you suggest would actually break that approach, if it works. Really, I should just try this out myself when I get a minute, and see what happens.

[JohannesH]

or bind hold fire to a key, for greater flexibility (now id just have to figure out a good key for it...)

[CarRepairer]

or bind hold fire to a key, for greater flexibility (now id just have to figure out a good key for it...)

That doesn't solve the problem. But if you're interested I made a widget that binds "holdfire, stop" to a key of your choice (as well as one for "holdposition, stop").

[JohannesH]

why have holdfire&stop at a single key... when you can have them at separate keys and press both when you want to do that. And obviously also hold fire without stopping.

[Pxtl]

Really, my only frustration with fire-states is that there's 3rd-step - I find I always want to toggle straight from hold-fire to open-fire and vice versa, and likewise with default-move-state (don't remember which it is) to hold position. Because the UI doesn't cache the clicks, I have to click-check-click-check.

And I'm too lazy to bind a hotkey.

But either way, this is a bit of a threadjack.

[lurker]

But it doesn't give much bonus to retargetting the same unit, this is still a valid request afaik.

[zwzsg]

I'd rather have a "fire-at" order separate from existing "attack" orders, optionally enabled by the mod.

Yes, back when I played TA I really wished there was a seperate button to select the turret's current target without impeding the tracks or wheels movement toward their goal.

[Pxtl]

I just tested for this behavior with a pile of different CA units and I couldn't produce it. Is there something I'm missing? Does using right-click-context-move clear the attack target?

And Z, there's actually a button for that command in NetPanzer. The problem is that NetPanzer units don't auto-lead their targets (or even fire while moving) unless ordered to do so, so the game is a nightmare of micro-management - even though there is a "fire at this target" command, you have to fire-at-ground all the time to hit moving targets.

[Tribulex]

Should units remember their attack target after new order?

Yes.

[hunterw]

this will change the game considerably, mainly for commander killing, and it errs towards making them easier to kill.

scenario - you are attacking a comm in his base with 5 flash. with these changes you can give attack order to comm, then queue up a circle strafe around and around him, and they will attack only him.

currently you can either attack the commander, where they will sit still and only attack him, or circle strafe, where they will maneuver around but shoot other shit in his base and not just him.

also, units with very slow reload such as janus will be buffed considerably, since they will be able to maneuver and shoot a single target without ever stopping.

not a good or bad change necessarily, gives you more control over your units, but consider it as a modoption before as it may have large gameplay consequences, especially for 1v1s.

[Dragon45]

creeping graphical UI complexity = problem. we've already had random UI element creep.

i kinda liked redalert's method of hidden hotkeys for some things, like 'z' to scatter (or whatever that was). as long as this magic new 'attack but dont override move' option doesnt clutter up the screen anymore, im game.

[JohannesH]

this will change the game considerably

Yes its often really stupid when engine side changes force gameplay changes to games. Even if the game dev was behind the change, those who prefered the old way cannot just play an earlier version of the game.

[lurker]

Is it really worth respecing parts of balance that depend on units being difficult to control?

[Tobi]

TBH the weights assigned to particular types of targets should be made mod configurable.

Then any mod who wants this can just set the weight for the last target epically high (it's now 25x the weight the unit would have otherwise), so the unit will always keep shooting the last user target if it is able to hit it.