-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use or invent a standardized method for adding custom commands #13
Comments
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... |
I think this would qualify as an example of the text action: https://springrts.com/phpbb/viewtopic.php?t=30588
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. |
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. |
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. |
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. |
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. |
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). 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) |
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)
The text was updated successfully, but these errors were encountered: