Allow Unit AI on Force Fire with Hold Position

[CrazyEddieTK]

Currently, units on Hold Position will not use Unit AI when given a Force Fire order. They will move directly to firing range and will neither jink on approach nor kite at skirmish range.

I propose that since Force Fire includes an implicit "move into firing range" order, Hold Position is not meaningful, and accordingly a unit with Unit AI enabled should use Unit AI while executing its movement while engaging an enemy it has been explicitly ordered to engage. I suggest that this should be the standard behavior; but if for some reason that's not desired, I'm requesting an option to enable it (perhaps under Settings/Unit Behavior, along with things like "Stop clears target).

This would not change the unit's idle behavior; a unit on Hold Position would continue to not skirm, jink, chase, or move in any way at all if approached by an enemy when idle.

While it's true that Attack Move does already engage Unit AI, I think that this same behavior needs to exist for Force Fire. Force Fire lets you specify the unit to be attacked; Attack Move only lets you specify a location and leaves target selection up to the engine and/or gadgets.

[sprunk]

Force Fire lets you specify the unit to be attacked

As a temporary measure use the set target command. IMO the better solution here would be to make Attack-Move able to target units in addition to locations.

[CrazyEddieTK]

IMO the better solution here would be to make Attack-Move able to target units in addition to locations.

Attack-Move has movement semantics, including things like line-move and formation-move. Force Fire has target semantics, such as area-attack and target-splitting. I'm not sure giving target-like semantics to Attack-Move is a good thing.

[sprunk]

Just single target, no area version.

A precedent for mixing semantics already exists (Force Fire also has movement semantics if you hold Alt).

[CrazyEddieTK]

I wouldn't consider Alt+Fire (draw a line of targets) a movement-like order, any moreso than the normal Fire (which carries an implicit "move into range" order).

Still, you're right; giving Attack-Move a unit-targeted version might be a good idea, because people probably expect a command named "attack" to, well, attack. It should probably be identical to Force Fire on a unit.

In effect we'd be making a compromise from the old argument over renaming Attack/Fight to Force-Fire/Attack-Move.

• Old Zero-K: (A)ttack targets units and ground, (F)ight attacks while moving
• Expectations from Starcraft: (A)ttack/Attack-Move targets units and attacks while moving
• Current Zero-K: (A)ttack-Move attacks while moving, (F)orce-Fire targets units and ground
• New Zero-K: (A)ttack-Move targets units and attacks while moving, (F)orce-Fire targets units and ground

If so, then Attack-Move and Force-Fire, when issued on a unit, should be identical, and in both cases should engage Unit AI even with Hold Position. In both cases you are implicitly telling the unit to move and attack, so Hold Position is irrelevant, and if Unit AI is enabled then it should be engaged when a unit is moving and attacking. Someone who wants to override Unit AI can issue explicit Move orders after issuing a unit-targeted Attack-Move or Force-Fire order, or use Set Target with or without Move orders.

[sprunk]

I wouldn't consider Alt+Fire (draw a line of targets) a movement-like order, any moreso than the normal Fire (which carries an implicit "move into range" order).

I assumed your "order X has Y semantics" was about what was able to be targeted (which then affects the UI) since every order with target semantics already carries an implicit "move into range" order anyway (Set Target is the only exception I can think of off the top of my head, but then it is more of a targeted unit state than an order because it doesn't go in the order queue).

Attack-Move and Force-Fire, when issued on a unit, should be identical (...) Someone who wants to override Unit AI can issue explicit Move orders after issuing a unit-targeted Attack-Move or Force-Fire order, or use Set Target with or without Move orders.

I disagree, it would change existing behaviour even though that's what the new behaviour is for. You'd reintroduce the same problem you're trying to fight (pun intended): you can already keep issuing explicit Attack-Move orders but that requires you to keep doing that because the orders don't stick to the unit, which would also be the case with regular Move (and I don't think Move should get a sticky version because that's what Force Fire is already for (and Guard for the allied version)).

[CrazyEddieTK]

I assumed your "order X has Y semantics" was about what was able to be targeted

Partially, but it also involves the modifier keys. Move, Attack-Move, and Patrol have the same behaviors when dragging, ctrl-dragging, and alt-dragging. Likewise, Force-Fire and Set Target have the same behaviors as each other, but different from Move/A-Move/Patrol. Repair, Reclaim, and Resurrect - being target-like orders - are nearly the same as Force-Fire/Set Target and different from Move/A-Move/Patrol.

I disagree, it would change existing behaviour even though that's what the new behaviour is for.

If by this you mean that Force-Fire on a unit would engage Unit AI even with Hold Fire, and that that would be a change to the existing behavior, then I agree with you, it would be a change. But this behavior should be changed, even if there is also another command that also has the new behavior.

Also, Drag-F (area attack) and Ctrl-Drag-F (split attack) should also engage Unit AI even with Hold Fire. Your proposal of having Unit AI only on Attack-Move and not Force-Fire, while also keeping unit-targeted Force-Fire single-target only without an area version, would not accomplish this.

You'd reintroduce the same problem you're trying to fight (pun intended): [etc]

I didn't understand what you're saying here.

[sprunk]

But this behavior should be changed, even if there is also another command that also has the new behavior.

I don't think you gave a good enough reason. Containing an implicit move order is a bad reason because units with Move orders don't engage in unit AI on hold position. The major practical reason to use Force Fire on a unit that can engage AI is the "chase and kill this without unit AI" behaviour which is a useful way to temporarily disable unit AI without having to touch the unit state (we believe that orders are generally better UI than unit states), to which there is no other order alternative (move doesn't stick to the target so it can run away; set target does not make the unit go into range). This is especially important because Force Fire (like Move) is given through rightclicks - as long as you're directly microing the units are doing exactly what you tell them to, without unit AI interfering. I don't think the benefits to making Forcefire engage unit AI on Holdposition would outweight the costs - even now, when unit targeted Attack Move doesn't yet exist.

---

I didn't understand what you're saying here.

You said:

Someone who wants to override Unit AI can issue explicit Move orders after issuing a unit-targeted Attack-Move or Force-Fire order

This is just as bad as the current situation:

Someone who wants to override the lack of Unit AI can issue explicit Attack-Move orders after issuing a unit-targeted Attack-Move or Force-Fire Set Target order

[CrazyEddieTK]

Containing an implicit move order is a bad reason because units with Move orders don't engage in unit AI on hold position.

Units with Move orders don't engage Unit AI when on maneuver or roam, either. They only do so when the move is complete and they become idle.

The major practical reason to use Force Fire on a unit that can engage AI is the "chase and kill this without unit AI" behaviour which is a useful way to temporarily disable unit AI without having to touch the unit state

This only works (currently) if the unit is on hold position. If it's on maneuver or roam, then Unit AI is engaged even with Force Fire.

This points out that the real issue is the semantic overloading of "Hold Position" as a means to control Unit AI. I think this is a mistake. HP should only control whether the unit moves to engage enemies when idle.

If you want to have one right-click command that uses Unit AI and another one which disables it, then Attack-Move vs. Force-Fire does make sense. However, for consistency it should apply across all three movement unit states. AND it should be a behavioral switch controlled by a UI option setting (similar to "Stop clears target").

Someone who wants to override the lack of Unit AI can issue explicit Attack-Move orders after issuing a unit-targeted Attack-Move or Force-Fire Set Target order

Ah, I understand, thanks. You make a good point. I would prefer the first arrangement over the second; I can see why others might prefer the second over the first. So perhaps this is a further argument for making this an option setting.

[sprunk]

I don't know much about the design behind maneuver/roam, but the engine hardcodes some behaviours there so the design might've been constrained some some extents. GoogleFrog should know more.

[GoogleFrog]

I think not using tactical AI with Force Fire hold position is the better behaviour. If the unit is in range then it essentially holds position. If units did tactical AI then they would skirm away or jink forwards, which seems like a non-hold position behaviour.