Open gajop opened 8 years ago
silentwings
commented
8 years ago I think the actionHandler (\LuaHandler\Utilities\actions.lua in base content) has one - but I haven't ever used it. It has both both text actions and key actions, but I can only find examples of the key actions being used. Naturally there is no documentation that I know of...
gajop
commented
8 years ago I think this would qualify as an example of the text action: https://springrts.com/phpbb/viewtopic.php?t=30588
In any case I will probably need to implement part of this in the engine to satisfy all of my requirements above, namely:
1) Register LuaUI/LuaRules (synced and unsynced) commands, including whether cheat is required
2) Have them appear in the console /
The actionhandler doesn't satisfy 1) (being widget only) and probably also one of 2) and 3) which are the key point for "standardizing it" (so other widgets/gadgets could also use these commands without much care about how&where they're implemented).
In addition, the engine implementation could provide the ability to unregister or override existing engine commands.
silentwings
commented
8 years ago There are chat actions for luarules too e.g. http://imolarpg.dyndns.org/trac/balatest/browser/branches/BAR/luarules/gadgets/cmd_dev_helpers.lua, http://imolarpg.dyndns.org/trac/balatest/browser/branches/BAR/luarules/gadgets/api_custom_unit_shaders.lua#L495 and both the luarules and luaui versions do work with Spring.SendCommands.
As for (2), you'd have to query the actionHandler itself for a list of commands, or maybe add functionality to it for this. I doubt it's complicated.
An engine level implementation would probably be better, but idk how difficult. Another possiblity is to train the action handler to hijack Spring.GetUICommands.
silentwings
commented
8 years ago Fyi, I've converted all of BARs luaui actions to use the action handler (and removed old widget:TextCommand) with intention to (one day) implement this idea.
gajop
commented
8 years ago Sounds good. Just so you know, this is a very low priority for me, as the system I have works and there are no competing (Lua) consoles to consider compatibility for. Chat will need a drastic improvement first.
silentwings
commented
8 years ago Off-topic, but I'm curious to know what "chat will need a drastic improvement first" means.
I'm essentially happy to implement this in BAR and worry about merging back at a later date. I doubt there are any other games that have fully migrated from widget:TextCommand on to using the actionHandlers.
gajop
commented
8 years ago Chat's unrelated to this, yes, but I think it's fairly important (that's the feature most players will be utilizing anyway). At the very least, mentioning people (name auto-complete) needs to be improved: clans should be taken into account and small errors should be ignored. Spring also supports a whisper (private chat) type of communication, which needs to be taken care of (proper replies with /r). Lastly, I need to start using chonsole with some actively played game (ZK?) so I can get some user feedback -> I might be missing something important!
WRT implementing this, I hope you realize that most of this functionality (outside of Spring.SendCommands) is already possible with what's in chonsole (see https://github.com/gajop/chonsole#customization), it just doesn't offer a standardized solution which I think is important for the future of Spring game(content) development. There are a number of custom commands implemented in https://github.com/gajop/chonsole/tree/master/exts (all files besides core.lua feature something new)
silentwings
commented
8 years ago Yep, I understand, I'll write you something clean. It may even be that none of chonsole needs touching. http://imolarpg.dyndns.org/trac/balatest/ticket/1082
It would be greatly beneficial if we could have a standardized way of adding custom commands that would be used by other console implementations as well as the engine one.
It should be possible to register widget, gadget (synced and unsynced) commands by also providing their name, cheat and description fields.
These commands should be appear in the / and support seamless execution by Spring.SendCommands().
The implementation could be an engine one, or relying on a new, third party library (that would at least separate Chonsole from the command execution)