Quick comparison with Forged Alliance UI

[Argh]

I find it disappointing that you cannot queue up a factory, and then select the ghost and queue units from that fac

That could be done, via a Widget, I am fairly certain. That is something I might be willing to spend time writing.

[Gabba]

F + click is too hard?

Yeah, not intuitive. Shift, Ctrl and Alt do something in most complex games/rts, so people will try those first. So you have to map the most important commands to those.

Didn't the latest version of BA have lolui as default? It is simple, but very nice.

It's a nice achievement in itself, but awful, if you compare it to the FA UI.
They don't even have icons for the different actions, that's breaking an important UI design principle.

Waypoint dragging is possible. Just download the widget.

It's broken, read the whole thread before posting please.

I don't really care in which language they write it, I just believe it should be a core engine feature written by core developers.[/quote
Why the hell does it matter where it comes from if it already exists and is working perfectly now? Why waste developer time on things that have already been done fine. No use re-inventing the wheel imo.

You didn't read correctly. It has been "more or less" implemented, and definitely not at the FA level.
And by putting important stuff in the engine, you improve performance and tightly integrate it feature with the rest, reducing the likeliness of bugs. Modular design is good, but not when every module is developped in parallel without knowledge of the others, or a coherent integration plan.

I find it disappointing that you cannot queue up a factory, and then select the ghost and queue units from that fac (before it has started building). (it would also be awesome for that same thing to be done with constructor/engineers)

Would be nice, I suggested something to that effect in a distant past.
If we could pre-assign units to different groups even before they're built (i.e. peewees from this factory go to group 1, cons to group 2), now that would be interesting.

[Pxtl]

F then Click is actually more intuitive than Supcom's, because it corresponds to a button on the gui that has a hotkey with its first initial. It's right there - A for Attack, G for Guard, R for Repair, P for Patrol, F for Fight. Really, this is a Starcraft idiom, not a TA one - the F-for-fight command is really stealing StarCraft's A-for-Attack-Move (with a different command name since Spring already uses attack location for bombardment).

However, I agree that cancelling on-map orders is incredibly frustrating, and a better mechanism would be appreciated.

I usually just end up just re-issuing the whole order list.

Any more complex selection logic for ctrl-A would be mod-specific logic. I'd love to see mods do more providing of key commands that are relevant to their game (CA, I'm looking at you).... but the engine should not be doing that ever.

[Gabba]

F then Click is actually more intuitive than Supcom's, because it corresponds to a button on the gui that has a hotkey with its first initial. It's right there - A for Attack, G for Guard, R for Repair, P for Patrol, F for Fight. Really, this is a Starcraft idiom, not a TA one - the F-for-fight command is really stealing StarCraft's A-for-Attack-Move (with a different command name since Spring already uses attack location for bombardment).

You got a point. However it's much easier to press shift-ctrl-alt, to queue (shift) an attack-move order (alt) while moving in formation (ctrl) than pressing shift-ctrl-f.

FA's formation handling is another thing that works so well, it would warrant a rant. Maybe in another thread, this is already eating too much of my time.

[Google_Frog]

You can always remap keys. F for fight works fine as a default spring shortcut as hotkeys will always be down to personal preference.

formation handling

Have you used custom formations?

[maackey]

Last time I checked (earlier today) the move waypoints widget works perfectly. It may not have some dummy-proof icons or whatever telling the user that s/he can move waypoints around by dragging them, but it took me all of 30 seconds to figure it out. (i realize it might take some people longer, i could've gotten lucky, but it really isn't that un-intuitive)

As for the keybinds, those are trivially easy to change and modify by changing the config file. You can even set it up to loop different buildings with multiple presses of the same key combos. I have thought about trying to lay out some intuitive and efficient key-layouts for ca, that would include ca-specific commands (jumping, sprinting, etc...) but everybody has their own little preferences and differences, not to mention different key layouts for different games, and coming up with a *good* default is difficult. I'm sure if you came up with a layout that was far superior to the ones that spring comes with i'm pretty sure someone could package it in.

[yuritch]

...However it's much easier to press shift-ctrl-alt, to queue (shift) an attack-move order (alt) while moving in formation (ctrl) than pressing shift-ctrl-f.

Among other things, Shift+Ctrl+Alt is almost guaranteed to switch Windows keyboard layout (for those who use more than one, non-English speakers for ex.), which is not always obvious in a fullscreen game and may cause hotkeys to suddenly stop working (if the new layout has no Latin keys, like a Cyrillic one). So that's not always the best key combo for all the players.

Just for information: 2 standard Windows keyboard layout switching key combos are Alt+Shift and Ctrl+Shift (you can only have 1 of those selected, or none at all, which few people who use multiple layouts do as it's inconvenient). Ctrl+Alt+Shift triggers both.

[CarRepairer]

You got a point. However it's much easier to press shift-ctrl-alt, to queue (shift) an attack-move order (alt) while moving in formation (ctrl) than pressing shift-ctrl-f.

FA's formation handling is another thing that works so well, it would warrant a rant. Maybe in another thread, this is already eating too much of my time.

No, you have it wrong. You don't press ctrl+shift+F. You press the F key which sets your next order to be Fight, then you shift-click to queue the fight on the map, or ctrl+shift+click to do queue a formation-fight.

And like googlefrog said, try the custom formations widget.

[Gabba]

@carrepairer

Well I kind of got mixed up there. What I said describes well the FA UI, not the Spring one.

Edit: I have already tried the customs formations widget v2 (either it's included in BA 7.04, or I downloaded it some time ago, but I have it) and it's nice to position a small number of units; but otherwise compared to FA's formation handling it sucks.
In FA if you hold when giving an attack or move order, it will display a formation your units will arrive in. It mixes your units in sensible ways so that tanks are mostly at the front, shields are mixed throughout for better coverage, artillery is mostly in the back. You can switch between deeper and wider formations by right-clicking while you're still holding the left button. You can also orient the formation in any direction by dragging the mouse cursor.
Also units get in place without making a big mess. I'll have to check, but I think they get in formation as they start to move, instead of trying to do it at the very end.

@yuritch

I have several keyboard layouts (not cyrillic ones though), and never had this problem in FA. This is starting to be a narrow use case, windows users with cyrillic keyboards... plus if they are gamers, they probably already faced the issue and know how to disable the shortcut, isn't it. Or they can use Linux

@maackey

Sorry, but this widget conflicts with the use of the ctrl key to place a ring of buildings around another [built-in Spring function], and sometimes trying to place two blueprints next to each other (i.e. a solar next to a mex) moves the first one instead of placing the second.

[manolo_]

that formation widget sounds really good

[CarRepairer]

@carrepairer

Well I kind of got mixed up there. What I said describes well the FA UI, not the Spring one.

Edit: I have already tried the customs formations widget v2 (either it's included in BA 7.04, or I downloaded it some time ago, but I have it) and it's nice to position a small number of units; but otherwise compared to FA's formation handling it sucks.
In FA if you hold when giving an attack or move order, it will display a formation your units will arrive in. It mixes your units in sensible ways so that tanks are mostly at the front, shields are mixed throughout for better coverage, artillery is mostly in the back. You can switch between deeper and wider formations by right-clicking while you're still holding the left button. You can also orient the formation in any direction by dragging the mouse cursor.
Also units get in place without making a big mess. I'll have to check, but I think they get in formation as they start to move, instead of trying to do it at the very end.

The premise of your thread is a default Spring UI. Not all games for spring have tanks, artillery and shields in the sense that TA/FA do.

Spring's move-in-formation (move and ctrl-click or fight and ctrl-click) keeps the units in formation as they move. So whatever widget is included in the game to set up the game's ideal formation would work with this.

[Gabba]

Edit: I've edited the original post to separate engine-specific and *A-specific suggestions.

The premise of your thread is a default Spring UI. Not all games for spring have tanks, artillery and shields in the sense that TA/FA do.

Spring does have a default UI (I'm not talking about just the Graphical User Interface here). And it's already geared to a TA-style game.
If it's not supposed to, and if any feature that won't be used by every game out there should be done in lua, then default keybindings, the default menu, the console, the minimap, cameras, hell anything else than displaying the map and units should be removed from the engine, and be done lua-side.

And this thread has two purposes:

- I'm proposing to improve the default UI so it works better with games that have TA-style gameplay. Thus benefitting most of the players, and improving Spring's image. Other games can do whatever changes they want, it won't affect them.

- I'm also proposing some generic engine improvements that will benefit all games that want to use these new or improved functionalities. Such as: better zoom, displaying and dragging waypoints, and so on.

Spring's move-in-formation (move and ctrl-click or fight and ctrl-click) keeps the units in formation as they move. So whatever widget is included in the game to set up the game's ideal formation would work with this.

True. But since moving units in formation implies some pathfinding and placing algorithms --> which can be slow --> which needs to be optimized, providing a C++ framework for that task would be better, even if at the end it's used from lua to achieve the same result.

[CarRepairer]

- I'm proposing to improve the default UI so it works better with games that have TA-style gameplay.

This is a controversial topic. Spring itself is purposefully distanced from TA based mods (even if that was its original purpose, I don't know the actual history on that and I see contradicting stories everywhere). TA based mods are illegal to distribute and the Spring engine is a legit open source RTS engine with no direct ties to TA that does not promote downloading of any OTA content. The part that I don't like is that engine devs have so much to do that would benefit all modders and users, and working on a default niche GUI is a huge distraction. That is the reason it's an unpopular topic and you're not the first to bring it up.

[smoth]

- I'm proposing to improve the default UI so it works better with games that have TA-style gameplay. Thus benefitting most of the players, and improving Spring's image. Other games can do whatever changes they want, it won't affect them.

I am sorry, the devs are not responsible for anyone's project. you need to go talk to the guys developing the *a projects. Feature request is not for mod requests.

[Gabba]

- I'm proposing to improve the default UI so it works better with games that have TA-style gameplay.

This is a controversial topic. Spring itself is purposefully distanced from TA based mods (even if that was its original purpose, I don't know the actual history on that and I see contradicting stories everywhere). TA based mods are illegal to distribute and the Spring engine is a legit open source RTS engine with no direct ties to TA that does not promote downloading of any OTA content. The part that I don't like is that engine devs have so much to do that would benefit all modders and users, and working on a default niche GUI is a huge distraction. That is the reason it's an unpopular topic and you're not the first to bring it up.

Yeah, I know about the controversy, and that I'm late to an already old debate. I've been following Spring's evolution for a while... However banning OTA content and banning anything remotely ressembling TA gameplay is not the same thing.

As I see it now the effort is dispersed in every friggin' direction. If the engine and lua devs and some content makers consciously planned together and collaborated to make a flagship TA-style game (that's what the engine does best, and what most people like best) with 100% original IP, they'd be able to iron out the engine's rough edges much faster, and sort out better what goes in the engine and what should be done in lua. (You know, instead of throwing the blame back and forth when something doesn't work.) The benefits for the community would be major, and then as a second flagship project they could work on something totally TA-unrelated.
The Blender people did something similar with two flagship projects, and I hear it worked rather well.

In my opinion, it's better to do one thing well, and then branch out from there, than to try to do everything at the same time, and fail at it.

Okay, rant over. Hopefully, even if my opinion is heretical, this thread can serve a repository of ideas for eventual engine improvements.

[Gedanken]

You're wrong about the cancelling of orders, sorry. The SupCom way is heinous for anything more than a couple of orders. It isn't true that in Spring you need to shift and reissue the order in exactly the right spot - it just needs to be in the ball park. Also it is hard to live without the command insert widget (where you can insert an order in between any two orders by holding meta)

[luckywaldo7]

I don't understand your fixation on doing stuff in the engine as opposed to widgets.

I don't understand your fixation on TA-based mods.

[Gabba]

You're wrong about the cancelling of orders, sorry. The SupCom way is heinous for anything more than a couple of orders. It isn't true that in Spring you need to shift and reissue the order in exactly the right spot - it just needs to be in the ball park. Also it is hard to live without the command insert widget (where you can insert an order in between any two orders by holding meta)

That widget is nice.
About the canceling of orders, you seem to be the only one that likes Spring's current system.

I don't understand your fixation on doing stuff in the engine as opposed to widgets.

Meditate deeply on it, and maybe you'll understand. Or better, do some programming.

[Neddie]

It does make sense to implement much of this engine side in the basic selection of options we should have pre-lua.

[Saktoth]

All this debate and argument is pretty useless, if you sit down yourself and make clear improvements to the UI, it will get implemented, either engine or lua side depending. Talk to TheFatcontroller about BA, he is the only person who matters ATM (but dont expect him to spend any dev time on your ideas).

If you want a testbed for your ideas, CA is designed to be a hotbed of innovation, with an open development model: just dive in. We dont have much dev time at the moment though, but we are looking at UI design ATM, go write some comprehensive proposals and we might work them into our longterm goals. Fresh, outside perspectives like these are always helpful. BA will take any widgets that are clear improvements, like they always have, if we make them.

Try a request on the lua forum or a proposal for edits to the current order management widget to make it usable.

Camera Controls
These commands are essential. I dont know how often people use the alt-zoom or control for slow down, but control for rotation and shift for speed are important (though the default could just be faster, since it scales by zoom level anyway). Still, manipulating the camera while you give orders is no great inconvenience. But you really have to offer a new proposal.

Cancelling orders
You can use any building to cancel another building, it need not be the same one. Showing all commands will lead to a very messy map, and make it harder to give orders to the currently selected unit. However on the whole probably an improvement, and order moving/cancelling is really important (perhaps you can just improve the current widget).

Selection screening
You mean bandbox selection? Very annoying. Imperial Winter locks out selecting units and buildings at the same time and its infuriating for keeping rally points up to date. Its important to be able to bandbox constructors, as you are often managing a large amount of them, and mobiles are often mixed inbetween. Turrets dont move, who cares if you select them. Double click and control z help a lot with selecting a unit type. The only problem i have is control-z all cons, but i found myself missing the functionality when i screened them. Thats a keybind anyway.