Spring RTS Engine

Hi,

I probably just missed it, but is there a way to define completely custom keys for the build gesture menu?
I am learning some alternative keyboardlayout (neo2) and the keys for the circle menu are, well, spread over the keyboard, without the logic they have for qwert[zy].

greetings

Send us a link with an image of your keyboard layout, tell us which key you want as the center key and we'll make an option for you. It would only take a moment.

We should probably leave open the possibility for alteration here, any way to stick bindings in an easily editable file?

Saktoth wrote:We should probably leave open the possibility for alteration here, any way to stick bindings in an easily editable file?

It's already possible. The user can copy the marking menu config file from CA to their local LuaUI/Config folder, edit it, then finally set up the local widget config to read their local LuaUI. But that's not suitable for the common player so I figured adding more keyboard layouts built into the mod would be the nice thing to do (much easier for me than for them).

This is why all these commands should be proper spring commands that can be bound to actions in uikeys.txt. This would require an "unsynced UI" command type.

Google_Frog wrote:This would require an "unsynced UI" command type.

What?
Widgets can add commands!
It's just car who is lazzy, I say him so often that he should use commands that it isn't funny anymore.

What?
Widgets can add commands!

facepalm. I forgot they could add commands, it's been so long since I have added commands with a widget.

So now it's time for everyone to yell at car for not implementing it as a command.

uikeys is no better than editable widget config file. Both are completely unaccessible to average nub.

uikeys is centralised. It does not need to be accessible by average 'nub', it is so that when someone asks a question like this we can point them to a file and simple syntax for creating their own key setup.

If someone is competent enough to ask I think they are able to edit a simple config. The vast majority can still use defaults.

Also uikeys is deterministic, while using callins to catch hotkeys is NOT deterministic ,causing a lot conflicts.

Google_Frog wrote:uikeys is centralised. It does not need to be accessible by average 'nub', it is so that when someone asks a question like this we can point them to a file and simple syntax for creating their own key setup.

If someone is competent enough to ask I think they are able to edit a simple config. The vast majority can still use defaults.

Plus, UIKeys means that any editor implemented for UIKeys will also function for this.

Google_Frog wrote:

What?
Widgets can add commands!

facepalm. I forgot they could add commands, it's been so long since I have added commands with a widget.

So now it's time for everyone to yell at car for not implementing it as a command.

I appreciate all the credit but it is actually Licho's widget, not mine.

Licho wrote:uikeys is no better than editable widget config file. Both are completely unaccessible to average nub.

+1

jK wrote:Also uikeys is deterministic, while using callins to catch hotkeys is NOT deterministic ,causing a lot conflicts.

Also true.

Pxtl wrote:

Google_Frog wrote:uikeys is centralised. It does not need to be accessible by average 'nub', it is so that when someone asks a question like this we can point them to a file and simple syntax for creating their own key setup.

If someone is competent enough to ask I think they are able to edit a simple config. The vast majority can still use defaults.

Plus, UIKeys means that any editor implemented for UIKeys will also function for this.

The problem is, while adding actions is a piece of cake in widgets, saving actions is not. There's a command that saves uikeys to some separate filename which I can't remember but it won't save over your uikeys. So the only thing I can do is save the actions in the widget's config or epicmenu's config and reload them each time.

Right now I'm just doing what jK considers a nono and that is catching hotkeys. I can fix it to use actions instead but as I said I'll still have to save these actions in the configuration, can't save them to uikeys which is a drag.

Is there a way to check if a uikey exists for the action and only catch the hotkey as a fallback for the non-existence of the uikey?

CarRepairer wrote:The problem is, while adding actions is a piece of cake in widgets, saving actions is not.

Why?
You could just append the commands to the uikeys.txt
Or you could even generate a custom (CA only) uikeys.txt and load it each start.

Even removing commands is really easy, parsing the uikeys.txt is really not a problem.

There is no easy way to read bindings?
It needs to know what its bound to to display it.

@jK

Lua-coding a UIKeys.Txt parser seems like a very brittle approach to the problem.

For those who don't know I am currently saving hotkeys that the user can set up for menu buttons and checkboxes. I am doing it entirely in widget. I could cut out some of the code and save them as actions (which does some of the work of parsing modifiers - ctrl/alt/shift/meta, and the work of catching the hotkey of course). But I'd still have to save them and reload them, I'd still have to come up with logic if the user entered his own uikeys and decide what overrides what, and I don't see how it's beneficial for a user to type out stuff like

bind ctrl+alt+x somespecialcommand
bind alt+shift+e selectkeywidget_selectallairplanes

in their uikeys. What's the point?

Would be really nice to have keybinds in a widget, then you could have different sets for different games easier.

But probably most sensible to override the users UIkeys.txt, since they could do all they did there in the widget. Or if they want to use their uikeys they just disable the widget.

@Car - I assume the idea is that at a future date a GUI tool could edit the UiKeys.Text file, and somehow check which mods have registered what commands. Then the CA keys would get keybinding for free, and it's better for the user too since the user can see all their keybinds in this hypothetical tool, not just the core Spring ones.

Imho, the UIKeys approach is important to support, but I'd still provide your default keyset as a fallback using the event-driven method... but jK seems to be saying that this is also doable through UIKeys.

Imo its waste of time to focus on such things instead of solving real problems and finishing GUI. There is plenty of room for improvement but there is no point doing stuff for advanced users, if there is already alternate way to achieve same goal.