Openra: PortableChrono doesn't support the deploy hotkey.

[GraionDilach]

Discovered by @ZxGanon.

[GraionDilach]

At this point it might be better if there would be an interface which translates the deploy hotkey to an OrderString somehow instead of the static list in UnitCommandWidget.

[rob-v]

I can't use 'new Order' here for deploy like e.g. for immediate MCV deploy, because to resolve it I need to create new OrderGenerator (cursor to select target for teleport instead of immediate teleport), what is not possible from Trait ResolveOrder (do you know how to do it else?). It works for e.g. Guard, because this Trait is defined in Common so it can be done directly after key press. To support deploy hotkey for PortableChrono trait, I would need to move PortableChrono from Cnc (TD mod) to Common (which seems to be used only for RA mod anyway).
Is this acceptable or do you have other ideas?

[pchote]

I would need to move PortableChrono from Cnc (TD mod) to Common (which seems to be used only for RA mod anyway).

The common dll is used for generic RTS logic. The Cnc dll is used for C&C (series, not game) specific logic that doesn't make sense from a general RTS standpoint. PortableChrono is in the correct place.

[rob-v]

Ok, I assumed cnc is only TD, makes now better sense. Do you have some idea how to assign new OrderGenerator when it is from another dll/mod? It works for SupportPowers, because they inherit from Common class and override a function to assing new OrderGenerator. Traits don't inherit from a Common Trait so that approach can't be used here.

[rob-v]

side note: Unit Teleport activity is generic RTS logic (e.g. in Dawn of war or Starcraft). This right click on unit to deploy, then to teleport, is how it worked in original? Because it isn't convinient. You can't now teleport 2 units at the same time in RA. To teleport more units one by one is tedious. There could be only hotkey (without that deploy right click needed) and it could teleport more units at the same time.

[abcdefg30]

You can still use "shift" to teleport multiple units.

[rob-v]

@abcdefg30 You're right, thanks. This Shift is the hotkey I wrote about to immediately teleport unit(s).
@ZxGanon Chrono tank doesn't support Deploy(F) hotkey, but you can use Shift - it is even better. You can teleport one or more units at the same with one Shift + RMB click.

[pchote]

PortableChrono switches the order generator from inside IssueOrder, which a pretty nasty hack. All the other deployers are one-off commands, but this switches the order generator like attack move or guard. I don't think we want to put these on the same hotkey.

[pchote]

A second big issue is that chrono tanks will only jump part way to an out-of-range target, and actors that aren't ready to teleport will ignore the order completely.

The best solution I can see for both issues is to reimplement PortableChrono as a subclass of Mobile. It can then fall back to a regular move order to get the rest of the way to the destination, and the deploy key / force move can toggle an internal state (and change the move cursor) without relying on a custom modal order generator.

[ghost]

The current behavior when selecting a single Chronotank is (since #13971):

Deploy order via cursor: switch to chrono cursor, show range radius and chrono within on click
ALT+Click: On holding down ALT show the chrono cursor, chrono on click (this also works for multiple units)

This is a good setup IMO and the deploy hotkey could complete it by just doing what the deploy cursor does (and perhaps be available when multiple units are selected).

[ghost]

I forgot about the multiple descriptions in the command bar when adding a deploy hotkey for chronotanks so have to correct that I think the current setup is fine and does not need to be changed in RA.

[ghost]

From https://github.com/OpenRA/OpenRA/pull/16069#issuecomment-458270471:

The current non-hotkeyable deploy interface seems a bit redundant to me.

I agree with @tovl here. It is inconsistent to have a deploy cursor but then not a deploy hotkey or description for this, so to address this issue here, IMO the fix is to remove the deploy functionality entirely and stick with the ALT modifier.

[pchote]

Some players (e.g. people who use KDE on Linux) aren't able to use the ALT modifier because their window manager blocks it for its own purposes.

[tovl]

I'm using Linux and this used to be a problem. This I why I always had to play on full-screen. However, just now I tried it out on windowed mode and it seems to not be an issue anymore on bleed. OpenRA will pick up the ALT key and the window manager ignores it.

[GraionDilach]

Alt isn't intuitive enough to be noticed by players. I can imagine false reports incoming if the deploy command is removed simply because that lack of knowledge and no UI implicating that option. (What does Alt even mean, anyway?)

[dragunoff]

This and some other issues around special deploy functionality IMO shows the need for a unit abilities palette (like in CNC3 or other games that have units with multiple abilities). This may not be very useful for the core mods (because very few units have abilities) but it could really open up possibilities for mods.

[pchote]

The overall game design for the classic C&Cs goes against having an abilities palette.

I take the view that the modifier keys + deploy worked well enough for the first 4 games + expansions + d2k, so if we have something that needs a palette (any more fiddly than the command bar) to solve then that is a failing on our part for trying to shoehorn an overcomplicated feature where it won't fit.

[tovl]

To follow up on my previous comment regarding the ALT key and Linux:

• It's actually the lock mouse to window setting that fixed it, turning that off returns the problem.
• This is a thing in both KDE and cinnamon (which I use).
• With both window managers it can easily be turned off or switched to a more sensible key (like the Super/Win key). You don't even need to touch the command line.
• Many other applications that are regularly used on Linux catch the ALT key (e.g. Inkscape). They run into the same issue with those window managers. Do a google search on "KDE alt drag window" and all you get are links to people asking how to turn that "feature" off.

In conclusion: This is not an issue with OpenRA; It is an (easily solved) issue with those window managers. This is not something that OpenRA should concern itself with.