Request: Change behavior of "Keyboard defaults"

[tijmenvn]

Feature request here:

Could you make the "Keep keyboard defaults" option in such a way that if you've mapped a certain default keyboard bind in your relation. You ommit that default keybind?

I have a few usecases (and so does a friend of mine) where there are 2-3 default keyboard keybinds that I want different, but I want to keep the other default keyboard keybinds.

[Holdi601]

For next version i did, if you have a keybind and have keep defaults on that it only removes the defaults from exporting which would cause a collision

[tijmenvn]

Awesome! Will try it out first thing when you release the next version

[tijmenvn]

I've just downloaded version 87 to test the fix you put through. But on my end I'm seeing the same behavior.

Export settings I'm using: Clean existing binds and Export Keep Keyboard Defaults

Should I use different settings to use your fix?

Just to make sure we're understanding each other from what I proposed, I'll give my personal usecase:

Keyboard default: Communication menu: \ Kneeboard next page: ]

I personally don't want anything on "\" since I use this for a external program. I want:

Communication menu: ] Kneeboard next page: "don't care" / unbound

[Holdi601]

So you have the options

Keep Keyboard Defaults=False => Then it removes all Keyboard Binds that are there by default and you only have those you have set up in Joypro, no other ones.

Keep Keyboard Defaults=Ture => (Old behaviour) it would just add the stuff you have done in Joypro ontop of the Defaults- (New Behaviour) it checks if the keyboard key that it should export have default bindings for a plane and if so just remove these, so there is no collision.

In case you dont want just remove all keybindings and just a selective key from defaults, you just could add a new Manual Entry with a dummy ID and put it into a Relation and bind then the unwanted to key to it. =>

=> the id should start with a lowercase d given all usualy dcs buttons in their hash always start with that as well Press Add => => Close The manual database manager => => Add the new dummy element into a new Relation and then click finish Relation => Bind a key to the new Relation => Make sure Keep Default Keyboard Defaults is checked as with the new behaviour as described above this will remove it. =>

DCS will ignore the Dummy as it won't recognize it as existing as it cant find any logic attached to the ID, whereas JoyPro takes that as a legitimate ID and with the above written logic removes just that key from defaults.

[Holdi601]

Oh and obviously export then.

[tijmenvn]

Thanks for the little guide you posted!

I have it set-up exactly as you described above here. This is my relation now:

Where communication menu is connected to all communication menu options on every plane. And the dummy to the dummy DB entry as you explained above.

Weird thing is, neither the RightBracket or the Backslash default entry gets removed. As if my instance is not running the new behavior at all.

Would it help to share my profile?

[Holdi601]

ah could reproduce myself. I reopen it as i investigate why the logic is not working as it should

[Holdi601]

Okay closing this as i pushed version 88 which has the fix which worked for me as i tried unmapping the key the way i described above.

[tijmenvn]

Fix is working now!

I do think you forgot upping the version to v88 for the application itself. When running v88 it prompts me that a new version is available and the UI still shows v87 in the bottom right

[Holdi601]

oh yeah. godverdomme.

[Holdi601]

okay version thing is also fixed

[tijmenvn]

Happens to the best of us :). Fijne avond!

[tijmenvn]

When checking all my planes I export to, I notice there are a few FC3 planes in DCS that don't respect the exclusivity of the "RightBracket" keybind and the "Kneeboard Next Page" keybind persists, resulting in a keybind that is double assigned.

The Dummy keybind is working for all of my exported planes.

Since I couldn't find a correlation between which work and which don't I'll make a list of all my exported planes and list if kneeboard next page is empty or not

A-10A: Kneeboard Next Page: "Empty" A-10C: Kneeboard Next Page: "Empty" A-10C II: Kneeboard Next Page: "Empty" F-15C: Kneeboard Next Page: ] F-16C: Kneeboard Next Page: "Empty" J-11A: Kneeboard Next Page: "Empty" MiG-29: Kneeboard Next Page: ] MiG-29C: Kneeboard Next Page: ] MiG-29G: Kneeboard Next Page: ] Su-25: Kneeboard Next Page: ] Su-25T: Kneeboard Next Page: ] Su-27: Kneeboard Next Page: ] Su-33: Kneeboard Next Page: ]

So in my case, all FC3 planes excluding A-10A and J-11A don't seem to work with the new exclusive keybind option.

Can you replicate this issue?

[Holdi601]

Maybe its a different input ID for those planes?

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows

From: Tijmen van @.> Sent: Friday, 10 March 2023 12:34 To: @.> Cc: @.>; State @.> Subject: Re: [Holdi601/JoystickProfiler] Request: Change behavior of "Keyboard defaults" (Issue #56)

When checking all my planes I export to, I notice there are a few FC3 planes in DCS that don't respect the exclusivity of the "RightBracket" keybind and the "Kneeboard Next Page" keybind persists, resulting in a keybind that is double assigned.

The Dummy keybind is working for all of my exported planes.

Since I couldn't find a correlation between which work and which don't I'll make a list of all my exported planes and list if kneeboard next page is empty or not

A-10A: Kneeboard Next Page: "Empty" A-10C: Kneeboard Next Page: "Empty" A-10C II: Kneeboard Next Page: "Empty" F-15C: Kneeboard Next Page: ] F-16C: Kneeboard Next Page: "Empty" J-11A: Kneeboard Next Page: "Empty" MiG-29: Kneeboard Next Page: ] MiG-29C: Kneeboard Next Page: ] MiG-29G: Kneeboard Next Page: ] Su-25: Kneeboard Next Page: ] Su-25T: Kneeboard Next Page: ] Su-27: Kneeboard Next Page: ] Su-33: Kneeboard Next Page: ]

So in my case, all FC3 planes excluding A-10A and J-11A don't seem to work with the new exclusive keybind option.

Can you replicate this issue?

— Reply to this email directly, view it on GitHubhttps://github.com/Holdi601/JoystickProfiler/issues/56#issuecomment-1463675663, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEKZPQQCOSBGUT6BULRFHLLW3MGUNANCNFSM6AAAAAAUUPVQTM. You are receiving this because you modified the open/close state.Message ID: @.***>

[tijmenvn]

Okay well, I did have a quick look in the KeyboardCleanProfile\DCS folder to look at the .cf files of different planes.

I took two "working" planes and searched their ID: A-10A: ["d3001pnilunilcd100vd1vpnilvunil"] J-11A: ["d3001pnilunilcd100vd1vpnilvunil"]

two not working planes: Su-25: ["d3001pnilunilcd14vd1vpnilvunil"] Su-27: ["d3001pnilunilcd14vd1vpnilvunil"]

So yeah, they seem to have a different ID. However, this ID handling should be invisible to the user no? If I assign "RightBracket" to a user bind, it should search per plane configuration if this bind is set and not check for the first ID hit and check for the same ID on different planes?

[Holdi601]

No. Joypro gives you the freedom to bundle Ids together and map them to keys. My template is just an easy starting point for people that agree with my sort of bundleing. Which template did you use? If you used mine (Holdi) I will fix it in mine. If you used another. Welp im not updating other peoples work.

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows

From: Tijmen van @.> Sent: Friday, 10 March 2023 12:45 To: @.> Cc: @.>; State @.> Subject: Re: [Holdi601/JoystickProfiler] Request: Change behavior of "Keyboard defaults" (Issue #56)

Okay well, I did have a quick look in the KeyboardCleanProfile\DCS folder to look at the .cf files of different planes.

I took two "working" planes and searched their ID: A-10A: ["d3001pnilunilcd100vd1vpnilvunil"] J-11A: ["d3001pnilunilcd100vd1vpnilvunil"]

two not working planes: Su-25: ["d3001pnilunilcd14vd1vpnilvunil"] Su-27: ["d3001pnilunilcd14vd1vpnilvunil"]

So yeah, they seem to have a different ID. However, this ID handling should be invisible to the user no? If I assign "RightBracket" to a user bind, it should search per plane configuration if this bind is set and not check for the first ID hit and check for the same ID on different planes?

— Reply to this email directly, view it on GitHubhttps://github.com/Holdi601/JoystickProfiler/issues/56#issuecomment-1463686992, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEKZPQRZ6WBLRQTA6KFKWQDW3MH5ZANCNFSM6AAAAAAUUPVQTM. You are receiving this because you modified the open/close state.Message ID: @.***>

[tijmenvn]

Okay, got it.

I didn't start from any template. But if you mean did I alter any of the files in "CleanProfile" / "KeyboardCleanProfile" / "DB" the answer is no. Just unpacked new v88 version and loaded my profile (made with version v86)

[Holdi601]

Ah okay. No I assumed you used a template, as its easier if you want to get quickly going. And also the most popular video from the reapers suggest going with one though the one mentioned in the video has not been updated by johnny ever since the video and is likely to have tons of faulty relations.

But more power to you if you create the relations yourself.

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows

From: Tijmen van @.> Sent: Friday, 10 March 2023 12:51 To: @.> Cc: @.>; State @.> Subject: Re: [Holdi601/JoystickProfiler] Request: Change behavior of "Keyboard defaults" (Issue #56)

Okay, got it.

I didn't start from any template. But if you mean did I alter any of the files in "CleanProfile" / "KeyboardCleanProfile" / "DB" the answer is no. Just unpacked new v88 version and loaded my profile (made with version v86)

— Reply to this email directly, view it on GitHubhttps://github.com/Holdi601/JoystickProfiler/issues/56#issuecomment-1463693539, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEKZPQSUFQQQ2MNYOPOXYA3W3MIVPANCNFSM6AAAAAAUUPVQTM. You are receiving this because you modified the open/close state.Message ID: @.***>

[tijmenvn]

I've gone through the JoyPro interface, and indeed. To get all "Kneeboard Next Page" ID's in 1 relation I need to bundle about 10 ID's to cover all planes.

Still, coming back to the expected behavior.

When assigning a keyboard binding to an in-game function. The function should check the default profile of that particular plane if a default binding exists with the set keyboard binding. If it does find something, it will remove the binding to the default ID of that plane.

I understand that JoyPro works by combining ID's into a single relation. But from my understanding, this function should work the other way around, where it searches per exported plane for ID's that match set keyboard bindings.

I don't know how else I can prevent the "Kneeboard next page" to get binded every time I export

[Holdi601]

That would make it unpredictable. As you expect if a key is being used on multiple airplanes that it all does the same thing, but realistically I can only then check if the title matches. Which necessarily not being the case. Also there is possible collisions, so if a user has set for whatever reason on some aircraft on right bracket and on others somewhere else but a different function on right bracket, it would cause now to things being bound to right bracket, when the user in his profile has just ve mapped one.

Also my personal expectation is, everything I see and bound in joypro as a user is exactly what ends up being in DCS and not on the last step the user does not see, make anything funky which the user didn’t set.

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows

From: Tijmen van @.> Sent: Friday, 10 March 2023 13:08 To: @.> Cc: @.>; State @.> Subject: Re: [Holdi601/JoystickProfiler] Request: Change behavior of "Keyboard defaults" (Issue #56)

I've gone through the JoyPro interface, and indeed. To get all "Kneeboard Next Page" ID's in 1 relation I need to bundle about 10 ID's to cover all planes.

Still, coming back to the expected behavior.

When assigning a keyboard binding to an in-game function. The function should check the default profile of that particular plane if a default binding exists with the set keyboard binding. If it does find something, it will remove the binding to the default ID of that plane.

I understand that JoyPro works by combining ID's into a single relation. But from my understanding, this function should work the other way around, where it searches per exported plane for ID's that match set keyboard bindings.

I don't know how else I can prevent the "Kneeboard next page" to get binded every time I export

— Reply to this email directly, view it on GitHubhttps://github.com/Holdi601/JoystickProfiler/issues/56#issuecomment-1463713986, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEKZPQVGDMYYSGKHL45FJQDW3MKTNANCNFSM6AAAAAAUUPVQTM. You are receiving this because you modified the open/close state.Message ID: @.***>

[tijmenvn]

I understand your point, however. Current implementation will create illegal keybinds in DCS. DCS UI won't let you bind a duplicate keybind and will remove the old one if you try to do so. So my suggestion is to copy this behavior from DCS.

You intentionally bind a keybind to a key that already has a keybind? Sure, but I'll remove the old keybind the key was previously on. This is exactly what the DCS UI does.

So if people choose to use this more advanced way of managing keybinds. I do think this is predictable and expected behavior.

[tijmenvn]

For the off chance that we might not agree on this matter ;). I'm trying to find a workable workaround for my usecase.

Creating duplicate Relations (whilst cross referencing which planes use the same ID for Kneeboard Next Page) with assigned key "RightBracket" will not do the trick.

Is there a way to give all planes the same ID for Kneeboard Next Page? Or would this break the link to DCS?

[Holdi601]

There should not be any collissions. If you export without “Keep existing keyboard” it nukes everything that was bound to keyboard by default. And if you keep it checked since v88 it checks if a button is bound to an aircraft by default on keyboard and if you have it in use on any aircraft it unbinds it.

Also if you have any other problem regarding collisions, joypro has a button validate profile and if you see something in the bind section, that is critical and needs fixing.

And no, the Ids are set by dcs. Thats the link how DCS knows what input function is when you mention in their config file. If you change the ID dcs would not correspond with not doing anything.

I can kinda see a point of adding things that have the exact same name, but I would rather do it within a relation and have an extra button instead of just Add Item , but Add All Items with same Title. That would be something I would be willing to spend time on.

Otherwise if your works better or is better. Be my guest and add the feature yourself. After all this is open source. Feel free to do anything with my code as you please.

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows

From: Tijmen van @.> Sent: Friday, 10 March 2023 15:21 To: @.> Cc: @.>; State @.> Subject: Re: [Holdi601/JoystickProfiler] Request: Change behavior of "Keyboard defaults" (Issue #56)

For the off chance that we might not agree on this matter ;). I'm trying to find a workable workaround for my usecase.

Creating duplicate Relations (whilst cross referencing which planes use the same ID for Kneeboard Next Page) with assigned key "RightBracket" will not do the trick.

Is there a way to give all planes the same ID for Kneeboard Next Page? Or would this break the link to DCS?

— Reply to this email directly, view it on GitHubhttps://github.com/Holdi601/JoystickProfiler/issues/56#issuecomment-1463873824, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEKZPQXI6QSAXNH7MSPRO33W3M2IJANCNFSM6AAAAAAUUPVQTM. You are receiving this because you modified the open/close state.Message ID: @.***>

[tijmenvn]

There should not be any collissions. If you export without “Keep existing keyboard” it nukes everything that was bound to keyboard by default. And if you keep it checked since v88 it checks if a button is bound to an aircraft by default on keyboard and if you have it in use on any aircraft it unbinds it.

If we understand each other correctly then, there is still a bug in this implementation. Since it does not unbind it in all usecases / planes. If you see my implementation on https://github.com/Holdi601/JoystickProfiler/issues/56#issuecomment-1437208628

I use the validate button extensively. As it is indeed easy to miss such a conflict. That is not what's happening in this case.

I would gladly help to contribute. I unfortunately don't have experience in C#, FPGA developer here with embedded C experience only. I've tried going through some code but I don't think I can offer you assistance in the short term

[Holdi601]

So 2 things

1. Can you give from your bug exact repro steps from a clean state, that are reproduceable for the collission?
2. Is the Add Item with same title a solution for your other suggestion?

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows

From: Tijmen van @.> Sent: Friday, 10 March 2023 16:11 To: @.> Cc: @.>; State @.> Subject: Re: [Holdi601/JoystickProfiler] Request: Change behavior of "Keyboard defaults" (Issue #56)

There should not be any collissions. If you export without “Keep existing keyboard” it nukes everything that was bound to keyboard by default. And if you keep it checked since v88 it checks if a button is bound to an aircraft by default on keyboard and if you have it in use on any aircraft it unbinds it.

If we understand each other correctly then, there is still a bug in this implementation. Since it does not unbind it in all usecases / planes. If you see my implementation on #56 (comment)https://github.com/Holdi601/JoystickProfiler/issues/56#issuecomment-1437208628

I use the validate button extensively. As it is indeed easy to miss such a conflict. That is not what's happening in this case.

I would gladly help to contribute. I unfortunately don't have experience in C#, FPGA developer here with embedded C experience only. I've tried going through some code but I don't think I can offer you assistance in the short term

— Reply to this email directly, view it on GitHubhttps://github.com/Holdi601/JoystickProfiler/issues/56#issuecomment-1463943789, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEKZPQWGIB5OOFO7OLSVP2LW3NAAPANCNFSM6AAAAAAUUPVQTM. You are receiving this because you modified the open/close state.Message ID: @.***>

[tijmenvn]

I've tried to keep it as simple as possible:

1. Select Clear to clear out current profile
2. Create dummy entry as you've described here: https://github.com/Holdi601/JoystickProfiler/issues/56#issuecomment-1437148764
3. Create DummyBind relation with dummy entry for all planes
4. Bind key "Backslash" to this DummyBind relation
5. Create CommMenu relation and find Communication menu for A-10A, pretty much all communication menu's have this same ID. Keep them all checked.
6. Bind key "RightBracket" to CommMenu relation
7. Export using: "Clean Existing Binds and Export" with only "Keep Keyboard Defaults" checked
8. Select plane: A-10A + Su-27
9. Export

At this point, you should be able to go into DCS and check both planes. A-10A will correctly have Kneeboard Next Page unbound, whilst on Su-27 this keybind is now used twice. By both Communication menu and Kneeboard Next Page.

I've attached my profile with these exact steps where I was able to reproduce it with: test_profile_issue_56.zip

About 2: I don't understand to which suggestion you are referring?

[tijmenvn]

Any luck reproducing this behavior?