Upcoming planned changes
Just an update on what’s currently going on behind the scenes, and plans for the next few months.
As the tool has grown and need for more support, it’s pushed me to rethink how the UI was being approached and consider how the tool can grow without continuous needs to update the UI when new tools become available.
Currently, I’m working on a number of redesigns in and around the UI that’ll fundamentally change the tool
- Automatic connected device detection, and device memory (to prevent need to have devices connected all the time to use the tool) - Binding of windows devices to template files, removing the need to have matching template names - Multithreaded UI to cater for future demands - Saved settings and configs for each tool (remebered paths etc) - Saved configurations of re-named binds from respective tools (DCS World being the key culprit for long strings right now)
Plugins & Post Hooks
I’m currently designing a plugin system which will open up the tool to others, providing 3rd party plugins.
I see this working in the following way
- Some games/tools will be supported out of the box, and shipped with releases (DCS World, Joystick Gremlin, Star Citizen)
- 3rd party developers can choose to make their own plugins which you can download and add to the tool yourself, however these will be supported by the 3rd party developers
This is going to take a lot of work and redesign to make the interfaces easier to use, but ultimately I think it will make shipping new support/updates far easier. Because of this I’m holding off providing new features for the time being, whilst these designs take place and to prevent excessive rework.
Nothing concrete on this yet, but looking to potentially provide a post-hook mechanism to slot in extra scripts/code as part of the export process. The use for this would be where fitting functionality into the main tool might not be in-line with the nature of the tools main objectives.
Once a system is in place for more support of games/tools, I’ll be looking into Modifier support
Supporting Modifiers will be a fundamentally complex change, which is why I’ve put it off. It’ll require a design of the mapping formats for the parsers, extension of all current parsers, full re-write of tests and re-write of templates.
The potential designs of this are ongoing, and it’s really important to me that the templates are “user friendly” and “accessible” to non-developers - Striking that balance is why I want to spend the time thinking about ways this could go.