cannot reproduce Canopy locking

[sepruda]

I've mapped a switch on my Hotas to close the canopy. That works fine, however I can't close the spider switch. I have to open and close the canopy again with my mouse.

[Lord Vader]

Hello @sepruda

I just tested this myself and it works fine binding it to my HOTAS. I can either bind the Canopy Handle - Up and Canopy Handle - Down individually or the Down/Up toggle. 

Please review your assignments as well as your hardware. There could be an issue or conflict.

[sepruda]

Hello! Thanks for testing.

I have it binded to a toggle switch on my Orion base. Toggle up is open toggle down is close. They work fine, but as I stated I am unable to lock the canopy after it's been closed.

[Lord Vader]

Well, I'm sorry, but I am able to close and lock, as well as unlock and open correctly using both the switch and the handle (spider lock) bindings.

Make sure the side locks are in place before engaging the handle.

Also make sure the button/switch you're using on your HOTAS is in working conditions.

[sepruda]

So after some more testing, seems that if you leave the switch in the Close position, you can't lock the spider handle. You have to return it to neutral. So right now it doesn't work with a switch, unless it has three positions or you want to use the down and up mapping instead, which feels wrong.

[Namco51]

The Canopy OPEN/CLOSE command is bugged because it holds canopy switch down and does not release. This prevents use of canopy handle to lock the canopy.

• If you use Canopy OPEN/CLOSE (default is LCtrl+C) to close the canopy from the fully open position, the canopy switch is held in the down position indefinitely by the sim. 
• While the canopy switch is stuck down, the canopy handle (lock/spider) CANNOT be closed (by design due to the position of the canopy switch and shape of the canopy handle)
• To get the canopy switch unstuck, you must left-click the canopy switch to return it to neutral again. Only then can you actually lock the canopy by clicking on the canopy handle.

Because this switch is a momentary switch in the down position, but a toggle in the up position (aka, a (ON)-OFF-ON switch), it should not get stuck in the down position. 

You can also duplicate the behavior of the swtich getting stuck down without using Canopy OPEN/CLOSE.

• If you click and hold the canopy switch, and with it held mouse over to any other switch (such as CAT I/CAT II) and click it with the other mouse button, the canopy switch will also be stuck in that position indefinitely. 
• The same rules then apply. If stuck down, you cannot interact with the canopy lock. If stuck up, you can interact with the canopy lock

The Canopy OPEN/CLOSE command should let go of the switch after the canopy closes because it prevents use of the canopy handle. What good is the command if you have to then go click on the switch anyway? Can the action of clicking the canopy handle also recenter the canopy switch first?

F-16 Canopy OPEN-CLOSE bug.trk

[Namco51]

I'm just learning the F16 after having bought it a while back, and I noticed the same thing as Sepruda and opened a new thread before finding this one.

It has to do with the command called "Canopy - OPEN/CLOSE". If the canopy is fully open, and you use the binding for "Canopy - OPEN/CLOSE" (default is LCTRL+C) and keep an eye on the canopy toggle switch, it stays down. 

If you look at that yellow canopy locking handle, it's designed so that it can't close if the switch is down. That's why there's never an issue if you click and hold it to close the canopy, because when you let go of the mouse button, the canopy switch is released and returns to the center off position. But the "Canopy - OPEN/CLOSE" command, if you hit it when the canopy is fully open and it's closing on its own with no pilot interaction, you will NOT be able to click that yellow canopy handle to lock it, until you click the canopy switch to get it unstuck from the down position.

So all the parts work correctly, it's just that Canopy - OPEN/CLOSE command never lets go of the switch, which blocks the lock. The real switch is (ON)-OFF-ON, which is momentary down, but toggle up, so it should never get stuck in the down position like that.

[Lord Vader]

Hi @Namco51

Once more, I am pressing the LCTRL+C key to close the canopy and it is a momentary switch. The canopy will only close while I'm holding this key combination. The same thing happens when using the mouse to press on the switch down. I also tried to assign a button on a joystick and it works fine. 

Not sure what your keybinds or configurations are, but again, I don't have a situation where the "Canopy- OPEN/CLOSE" switch stays stuck on the down position. So it's got to be something on your side. 

 

[Namco51]

I see the problem. When I press LCTRL+C, I let go of LCTRL immediately after tapping C.

What you are doing is holding LCTRL+C instead of tapping both. If you try pressing LCTRL, tapping C, and letting go of both immediately, you can duplicte the issue. Or, just assign a single key, like L to the command. The issue will occur if you press that key as opposed to holding it down.

If you hold the keys, it acts like a momentary switch, if you tap the key it gets stuck down. This is why it keeps springing back up. Many of us use the command like we're copying something out of MS Word or something, by tapping it, and others hold the button. 

[Namco51]

Edit: I double posted because the thread got merged, sorry!:

Its behavior, I'm tapping LCTRL+C and you're holding it. You're using the switch realistically and I'm using it like I'm copying a file. And it's how I've always done it for the past 12 years too and it's always worked and seemed fine to me. 

I'm wondering if, because I release the key too quickly, I am essentially aborting from it mid-command, like the switch state never gets reset. 

It's interesting because I'm sure many people use joy2key, joystick gremlin, Arduinos, and macros to just quickly hit LCTRL+C and run into that issue, and it explains a lot of odd behavior I've run into where a command doesn't work as a "map to keyboard" in joystick gremlin and I end up having to use a macro instead to force the key to be held down longer. 

Edited May 27, 2024 by Namco51

[Lord Vader]

I see. Well, considering it's a momentary switch, by doing it the way you describe, you're interrupting the command, somehow, and it may as well enter a loop, which seems to correspond to the bug you're describing. I never done it this way.

All I can say is that the command is LCTRL+C as well as the button assignment depends on a momentary press, if you don't do that it will never work correctly.

[Maverick806]

Hi @Lord Vader

I ran into something similar to this the other day and there seems to be some inconsistent behavior depending on which position the canopy switch is in when you press LCTRL+C.

If the canopy switch was in the middle position, I had to hold LCTRL+C to close the canopy. Releasing those keys would stop the canopy from closing.

If the canopy switch was in the up position, I didn't have to hold LCTRL+C to close the canopy. The switch remained held in the close position instead.

In the attached track (Sorry it's in VR), I did the following:

1. Tapped LCTRL+C to verify that it's a momentary action.
2. Right Clicked on the canopy switch to open.
3. Tapped LCTRL+C again. The switch was held down even though I wasn't touching the keyboard anymore.

 

F16_CanopyClose.trk

Edited June 6, 2024 by Maverick806
typo

[Lord Vader]

Hello again @Maverick806

I can see in your track that the switch seems to be pressed all the way down to close the canopy. You say it's involuntary and I believe you but, in the track, all it's saying is that the button is still being pressed.

I took over this track and tried to do exactly like you describe LCTRL+C, then mouse click back, then LCTRL+C again and I could not reproduce. I even tried with a button assigned to my joystick and it worked fine, even interrupting the movement halfway. I am sorry but I think you have some input issue on your side. I'm not sure what could be.