REQ: Multiple Commands for Units

[Jazcash]

Ok so the current system is that the user issues one command to a unit. That unit will follow that command although if it can, the engine will allow it to perform another command whilst obeying the set one. For example, you may set a unit to move to a position, on the way there, it might shoot at or attack an enemy unit within it's AOE. At that time, the unit is attacking and moving at the same time. This is only possible if done automatically by the engine.

What I suggest is that it be possible for the player to set more than one command at once. For example, if you set a move/attack command on a position, it will move towards that position and as soon as it can, it will start shooting at that position at the same time. This would also allow for coms to shoot and reclaim or w/e at the same time. At the moment, this happens every now and then and not all the time as it should.

What I also propose is that the two parts of the unit, (the parts that move it and the parts that move to attack) should be completely separate on certain units. For example, when a unit is attacking another, and you issue a command for it to move away from that unit, it's attacking parts should stay focused on attacking that unit until it's moved too far away to attack.

Currently, if you issue a move command to a unit and it is attacking, its attacking parts will flinch towards the move position for a small time until it realises that it can still attack.
This would also allow for units to move backwards and such whilst still firing forwards. This would be most epic win.

[==Troy==]

I would suggest to treat the moving part and the "add-ons" separately in general. IIRC you can do that in lua at the moment, but IMO, the current spring engine is too TA-tied and is not generic (and hence many other RTS are nearlly impossible, and very complicated to implement)

And by separately in general I imply the ability to basically do LEGO out of the unit from different parts available.

[Pxtl]

Thinking it over, you could do it with a 2-part unit approach.

You have 2 parts - the base and the turret. The base has an invisible, non-functional version of the turret weapon. The turret is not selectable, nor can it receive orders or damage - everything is redirected to the base, or dropped on the floor. Any orders assigned to the base are copied to the turret. This means attack orders will still work - the unit will position itself to attack (it will percieve that it is armed like the turret) and the turret will fire on the target (because it has the attack order).

The turret exists for one reason - to receive "secondary" orders. If you give the base a "secondary" order, then the order is assigned to the turret and the base keeps its original order.

It's a crufty, hackish solution that will create tons of problems (such aggregate objects will always have warts) but it would work.

[zwzsg]

I wanted that already many years before Spring!

Though that sounds like a pretty big change.

[BrainDamage]

you mean like FPS cam where you can move the head/torso independently from the legs for kbots?

[Jazcash]

you mean like FPS cam where you can move the head/torso independently from the legs for kbots?

Yes. But with the Com, you could have one arm reclaiming and the other lasering which is a bit more complex but would be totally awesome. I think the best benefit would be units being able to move backwards whilst still shooting forwards.

[zwzsg]

No, I mean the ability to tell my vast tanks army which target to pick along while plunging deep into the enemy base, without a stop.

[Pxtl]

This is particularly relevant with low-ROF units such as the Janus, where every shot must be carefully picked. Having to order an "attack", which causes them to stop once in firing-range, leaves them very vulnerable.

Supposedly units will maintain priority-targetting for their last "attack" order- so if you order attack-and-move, they'll prefer to target their last ordered target... but I've tried it and never found it worked. Either way, they still respect "hold fire" in that case. A "move to Y and attack X" would allow you to set a unit on "hold fire" and thus they would save their shots for _only_ the desired target.

[Jazcash]

Maybe priority targeting would be cool too? For example, you list units in a widget and the ones towards the top will always be shot at first instead of anything else.

[Gota]

You can do something similar ATM.
You can tell a unit to attack a target and keep moving to a certian direction while still attacking that specific unit if it is within range.
Problem is it doesn't always work.
Sometimes the unit will attack the specified enemy unit but will not continue moving to the queued move position(you tell the unit to attack an specific enemy unit,press shift anf give a move order somewhere).
IMO this should always work and the unit should alway move to the queued position while shooting the unit,and when you first tell a unit to move somewhere you should be able to press shift and tell the unit to attack a specific unit while movign to the more position.(soe this means that this should work both ways,attack command->move command and move command->attack command).

[CarRepairer]

You can do something similar ATM.
You can tell a unit to attack a target and keep moving to a certian direction while still attacking that specific unit if it is within range.
Problem is it doesn't always work.
Sometimes the unit will attack the specified enemy unit but will not continue moving to the queued move position(you tell the unit to attack an specific enemy unit,press shift anf give a move order somewhere).
IMO this should always work and the unit should alway move to the queued position while shooting the unit,and when you first tell a unit to move somewhere you should be able to press shift and tell the unit to attack a specific unit while movign to the more position.(soe this means that this should work both ways,attack command->move command and move command->attack command).

I think I can make a gadget that would let you do this. In order to let the user purposely choose when to use this behavior, it could require a combination of modifiers (ctrl, alt, shift).

[Gota]

When would u not want this to work in the described manner?
IMO all it needs is the minimal shift button.
your selected unit moving->enemy unit comes into your unit's weapon range->you press shift and give an attack command->your unit keeps moving while shooting at the enemy unit->enemy unit is out of range of your unit's weapon->your unit keeps moving to the move target->unit arrives to move target and goes to attack the enemy unit.
So attack after move+shift works on 2 levels,telling the unit to attack the specified unit while moving and to tell your unit to attack the enemy unit after it finishes moving to the move target.

The only reason I'm against adding tons of keyboard buttons is cause spring is already so complicated in the kind of orders u can give and the keybinds...
Anything added must be thought of 10 times before making it have yet another keybind IMO and whenever possible making commands require special keys should be avoided.

[CarRepairer]

When would u not want this to work in the described manner?

1) I select unit A, want it to attack enemy B then move to some point.
2) I select unit A, want it to attack enemy B while moving to some point.

Both are viable scenarios.

[Pxtl]

Attack after move-shift or move after shift-attack doesn't make sense. Attack means "shoot this unit until dead". Move means "go here". shift means "after done X, do Y". So semantically, either one of those commands has a different meaning - either "destroy X and then move to Y" or "move to X and then destroy Y". Neither of them have the semantics you describe.

Either way, my understanding of the engine-support was that it was "give attack order to target X, then give an order to move to Y - no shift command involved" The unit will retain X as a high-priority target, but will otherwise follow normal moving/shooting behavior. Either way, that approach never seems to actually work for me.

[CarRepairer]

Either way, my understanding of the engine-support was that it was "give attack order to target X, then give an order to move to Y - no shift command involved" The unit will retain X as a high-priority target, but will otherwise follow normal moving/shooting behavior.

Okay, this can be done gadget-side. But as far as move-then-attack that would need a modifier to specify that this attack includes "don't stop moving."

[JohannesH]

Theres already the possibility to give move&fire command when attacking ground btw.

[Argh]

I think the best benefit would be units being able to move backwards whilst still shooting forwards.

Already working in Spring 0.81, games just need to use the feature.

[SpliFF]

Some of this behaviour is possible using "fireplatform" transport code. The way it works is you make a transport unit that has no turret and you tag it 'fireplatform' in FBI. Then you create a turret unit and 'load' it onto the fireplatform using Lua.

The result is the turret rides around on the chassis doing whatever it wants independent of the orders given to the chassis. You can disable selection of the turret as well so clicks fall through to the chassis.

I'll be using this system almost exclusively in my mod. Basic testing indicates it works and turrets still track correctly regardless of wether the chassis is moving or turning.

There will probably be some issues to iron out though. One that comes to mind is that this method provides no means to tell turrets where to fire or to set them on hold fire (if you set them noselect). Cloaking the chassis won't cloak the turret. I've seen a case where the turret was hitting its own transport. I'm sure there are others.

You probably won't really want to do things this way but I'm putting it out there as an option in case you or anyone else wants to play with the concept.

[FLOZi]

Easy to pass fire and move settings and cloaking from the 'master' unit to its turrets