Feature Request - make it easier to move assignments around (remember all programmed commands)

[shadowze]

Hi, First I want to say I really love your software. I wish to make a feature request that I hope you will consider

I want to make it easier to move bindings about, as in , I would like to make it easier to swap to buton configs about in a easier manner. I have used Saitek software a lot over the years before recently moving to Virpil stick and I think there is a feature in the Saitek software that would make thing a lot easier for Joystick Gremlin users. The Saitek software "remembers" all programmed bindings even the ones NOT currently bound to a button, so if I want to bind a "config" I have already created it is easy to do so.

I am not sure Iam being clear enough about this, so I have created a youtube video showing what I am trying to explain here - https://youtu.be/Ilke7X3sVpc

Can you please take a look at this, thanks for reading and keep up the great work

[WhiteMagic]

A feature like this has been asked about in various forms for a while now and I definitely want to add something like a "function library" which you can use to put a profile together. There's a bunch of different issues open that are related to this.

• 172 which will allow enabling / disabling assigned actions without deleting them

• 102 which would allow copy & pasting of existing actions via the UI which would be the code needed to add actions from a library

• 170 which intends to use an existing profile as the "library" to add actions from

Those three items would provide all the behind the scenes code to build a library and add from it. The additional bit that the Saitek software does is to maintain the library as you add and remove bindings I guess. If I had to guess the profile they generate simply states which entries in the library are bound to what inputs. In Gremlin it won't be that easy because some information about actions is dependent on the input the action is assigned to. For example remapping a hat direction to a vjoy button requires the hat direction which makes no sense when that action is assigned to an axis or button.

While things like the above will make it a bit trickier to add a function like that I definitely will add it for all the reasons you mentioned as well as making it hopefully easier for people to share profiles if moving things around doesn't require redoing everything.

[shadowze]

Thanks for replying, the Saitek software from examining a saitek profile file I can see that

At the bottom section of the profile everything is listed (the library of commands inside the profile file) each entry has

1. a unique ID #
2. string name (what the function is eg flaps)
3. the command itself (button press , macro etc)

The main section then lists the joystick buttons and also unique ID for which command is bound to it

Here is one I have uploaded (just incase you wish to examine it) http://www.filedropper.com/f5

many thanks

[WhiteMagic]

Thanks for that example. This is pretty much what I'm likely going to end up as a layout to get this functionality implemented with some additional complications in the device section. Those complications will mainly be adding virtual buttons when needed, i.e. a macro assigned to a button works just fine but when assigned to an axis needs additional information.

[shadowze]

Hi I have created a simple Saitek config file showing a rotary being configured for bands Sample config file attached

Rotary1 = broken into 3 equal bands named of item - assigned action band1 0 to 33 = keypress 1 band2 33 to 66 = keypress 2 band3 66 to 100 = keypress 2

Hope this helps 3_bands_on_axis.zip

[WhiteMagic]

Ok so bands are what Gremlin calls a Virtual Button and actions are simply assigned to the band / virtual button. That's more or less what I'm assuming I'll end up with Gremlin as well for the split between the action and the "trigger" of an assigned action.

[MadogPL]

No update on this one?

[WhiteMagic]

Nothing other than what lives in https://github.com/WhiteMagic/JoystickGremlin/tree/r14, i.e. rewriting 5 years of UI code while redoing 80%+ of the backend code.