A new callback request for SPD BRAKE functionality.
-
For what it matters I have F-16 EX Viper, F-15 EX and Virpil T-50 CM3 throttles. I’ve struggled with them enough to know what I’m asking about lol.
-
@airtex2019 said in A new callback request for SPD BRAKE functionality.:
@Sabre I hear you.
It’s on (my personal) backlog to do
-
It’s not how it works in real F-16. You don’t hold the switch to close SPD Brake completely.
Do you have a source for this?
Common knowledge suggests speedbrake close DOES need to be held but the pilot is assisted in doing by a latched switch on the throttle. Indeed, some RL pilots have stated in the past they leave the switch in the latched close position to ensure they are indeed fully closed.
-
@Malc I agree this sounds like a problem with the different throttle switches on various throttles not being realistic in their functioning, but its not a callback problem. Callbacks work perfectly on Cougar throttle as it does on real throttle. Callbacks are correct. I hope they don’t change them to fake one press callbacks.
-
It’s not how it works in real F-16. You don’t hold the switch to close SPD Brake completely. But SPD Brake Close callback in BMS requires the press and hold logic. I hope this is clear.
So as the person that wrote the code for the discrete callbacks, I’m fairly sure that the existing discrete callbacks do what they are supposed to do for the kind of mechanical control that they are supposed to support. There are any number of places in the cockpit where if you choose to map bindings to callbacks intended for different mechanization then you can get unpredictable results.
That said, I have to confess that I’m not clear what the problem is that you are trying to solve from the descriptions above. The physical speed brake control on the F-16 is momentary on to the inboard (extend the boards) side, off at center and captive on to the outboard side (to close the boards). So it’s an (ON)-OFF-ON type switch and the callbacks are designed to work with that type.
The only thing I can think of is that you might be trying to use a device that has a keyboard emulator that can only pulse the input. Most of these kinds of software can do press-and-hold with some configuration work however. Now, press-and-hold key emulation is generally a Bad Idea unless the key you are talking about is a plain unmodified key – any kind of CTL/SHF/ALT element in a press-and-hold context is asking for other key presses to conflict and generate unexpected results. For this reason the general advice is only to use devices that can support DX button mappings for press and hold controls (such as HOTAS for example where there are several of those requirements in the F-16).
[I did once see a DX controller device that could only generate pulsed button inputs. We’re talking 15+ years ago now though so I’m guessing you don’t have one of those. In that case we contacted the developer and pointed out that the device driver was “broken” compared to DX requirements and they fixed it ;}]
-
@Boxer great explanation. I think what OP is requesting is the “set it and forget” option that the outboard position offers a Viper pilot and at least a TM Cougar/TQS? throttle owner has.
The momentary inboard ON and captive ON have desired effect of making you continue to deploy speedbrakes consciously and then you can just leave switch outboard and know that the switch will eventually get the boards closed.
The current callback toggle option does this but only if you hit it once when open, which sometimes can be iffy when you’re task saturated. So basically a callback that is “fully close speedbrakes” would be a little more practical and still realistic option for those of us that are programing to momentary switches to replicate the outboard captured ON.
-
Yeah, OP is asking for a “close brakes fully regardless of current state” . While such a switch may not exist in the real jet, BMS already has a small number of “convenience” callbacks like prev/next waypoint, turn on Jammer etc. They are in the SHORT category. So this “close brakes” callback could reside among those
-
@Sabre If you are using the keyboard, then use the toggle option. If you are using any sort of switch or HOTAS, then use the callbacks. The switch state callbacks eliminates any confusion. Using a 2-pos switch is not ideal as you only have an “open” and “close” option whereas a 3-pos switch gives you an “open”, “stop”, and “close” option thereby allowing you to partially open/close the speedbrakes.
@Sabre said in A new callback request for SPD BRAKE functionality.:
It’s not how it works in real F-16. You don’t hold the switch to close SPD Brake completely. But SPD Brake Close callback in BMS requires the press and hold logic. I hope this is clear.
The issue here is that in the real F-16, the switch can stay on the “close” position therefore the pilot can put the switch in this position and forget about it as the speedbrake would eventually get fully closed. However, should the pilot want to go from 100% to 50% brakes for example, he can put the switch on the “close” position then move it back to the middle “stop” position when he gets the effect he wants.
I don’t have the HOTAS you’ve stated but the speedbrake switches in the TM WH and TM Cougar work this way to reflect this behaviour.
-
@jayb said in A new callback request for SPD BRAKE functionality.:
Yeah, OP is asking for a “close brakes fully regardless of current state” . While such a switch may not exist in the real jet, BMS already has a small number of “convenience” callbacks like prev/next waypoint, turn on Jammer etc. They are in the SHORT category. So this “close brakes” callback could reside among those
But this is essentially what the present callback for closing the boards does already. Electrically speaking, it’s what the actual switches do as well…it’s only in the case that you can’t get a game controller programmed for press-and-hold that this might even be an issue…a game controller software that can’t do this is…bugged I would argue, ymmv of course
I’m really not excited about creating a precedent that there might be pulse and hold callbacks for the same function…that seems like a recipe for even more confusion. I’d say this is materially different from the jammer example which is creating a one-callback means to do something that normally requires a combination of other actions and context.
-
@Boxer guys you are all seriously over complexifying this
the desire is simple, click an ordinary button or key and have confidence the brakes are closed.
I’ve already said I understand and agree – I’ll code it and send you the PR mark
-
@airtex2019 said in A new callback request for SPD BRAKE functionality.:
@Boxer guys you are all seriously over complexifying this
the desire is simple, click an ordinary button or key and have confidence the brakes are closed.
I’ve already said I understand and agree – I’ll code it and send you the PR mark
Department of Redundancy Department but OK
-
FWIW, you can also get a temporary function by using the existing callbacks.
That’s what I’ve done for many years because I could dedicate only one button to speedbrake callbacks.So I got this in my .key file :
AFBrakesOut 128 -2 -2 0 0x0 0
AFBrakesToggle 128 -2 -2 0x42 0x0 0Which means that when you press the button # 128 the speedbrakes open, whereas they “automatically” close whenever you release the button. That way you can’t get confused in combat : the speedbrakes are open only if the button’s held.
As Airtex suggested, if you have enough buttons left, you can also choose to use that button as an “autoclose” button, and use 2 other buttons to open and close the speedbrakes with the “regular” callbacks.
-
@ewildcat that’s a good method too for instant gratification now. The only thing I’d add for others reading along is to remember that the boards move out fairly slowly but keep moving until they reach the end stops with AFBrakesOut held…this will prevent the jet from attenuating the brakes in landing configuration (because you are holding the override in to ask for max) and will not let you set an interim amount of board extension (for example as a trimming function during AAR which some folks like to do). But other than that, those two lines do add a “close me now” kind of function with a quick press/release that can be mapped to a single switch…I believe that completely addresses the need OP mentioned, if I understood it.
If you combine this with other mappings to get at the usual open/close callbacks as discretes, then you can do more or less everything I can imagine you wanting…with no added callbacks…so it’s all available now.
I grant you, this kind of mapping “trick” is not all that obvious though.
-
@ewildcat that is brilliant actually … thanks
-
@Atlas said in A new callback request for SPD BRAKE functionality.:
@Sabre If you are using the keyboard, then use the toggle option. If you are using any sort of switch or HOTAS, then use the callbacks.
Here is my arsenal - starting from the keyboard and beyond ))
-
@Sabre Dude what sim are you playing? Some sort of space station flying?
You’d need to grow tentacles to operate all your controllers.
-
@Boxer said in A new callback request for SPD BRAKE functionality.:
I believe that completely addresses the need OP mentioned, if I understood it.
@Boxer: Hey, please don’t interfere with airtex2019, he did promise after all! Over 20+ years of diving into Falcon 4, RP, AF, FF, BMS, I’ve never asked for a single special callback. Well, if you don’t want this callback – that’s fine, I can program any switch and button in any way I want on my joysticks. I recall in the 87th Stray Dogs I even once made an AutoHotkey script for a fully automated start-up procedure, where buttons on the ICP and everywhere else in the cockpit were clicking and flipping themselves rapidly and you would, like, just seat and look around amazed lol. (I remember some had a good laugh about it on the forum). It’s just that I don’t like the fact that in the Closed position, unlike the spring-loaded Open position, the switch will continue to send “SPEED BRAKE Switch – Close” DX button the whole time, until/if I remember to flip the switch to the neutral. Yes, I know I can use “SPEED BRAKE Switch – Toggle” instead and it should work right on my Winwing 16EX Throttle, but, for example, the 2-position “T” keys on the VPC MongoosT-50CM3 don’t work well with the “- Toggle” callback, and I don’t like it either. So, I thought it wouldn’t hurt to have it “Retract Full” like in the other sim. airtex2019 said it right earlier - no need to use a cannon (Boxer) to shoot (my) minor sparrows here Anyway, thanks to all involved for your interested attention to the little requests of the users ))
-
@bbostjan said in A new callback request for SPD BRAKE functionality.:
@Sabre Dude what sim are you playing? Some sort of space station flying?
You’d need to grow tentacles to operate all your controllers.
Haha, that’s a good one!
Nah, nothing fancy, just a couple of usual suspects.
-
@Sabre said in A new callback request for SPD BRAKE functionality.:
@Boxer: Hey, please don’t interfere with airtex2019, he did promise after all!
Well all of us working on code pick our own priorities (more or less, it’s a hobby thing after all). Aitex has plenty of things on his plate that are probably more compelling to spend time on than this one though…especially if…
It’s just that I don’t like the fact that in the Closed position, unlike the spring-loaded Open position, the switch will continue to send “SPEED BRAKE Switch – Close” DX button the whole time, until/if I remember to flip the switch to the neutral.
What does that mean, “I don’t like…”?? I’m curious what there is not to like here. These buttons are event based so having the switch captive in the close position (electrically “ON” the whole time) does not consume any meaningful resources in Windows or the game context. Were you thinking that it’s hammering on the game code for attention the whole time?? Not so.
If that is what you were thinking then hopefully the above sheds some light. But would also make me want to actively lobby AGAINST adding a callback…doing something for the wrong reason seems like a bad idea. I do think it’s pointless to add what is essentially a redundant alias for something you can already do. And in fact you are trying to avoid the obvious default way to achieve what you want for a potentially bogus reason.
What’s more, even if you do have a different reason not to use a DX mapping on the captive switch position, your need can be satisfied NOW without waiting for anyone to code up that alias…but if you don’t want that form of help then I’m not sure what to say.
Nice collection of goodies by the way. Love the modular set up on the profile mounted components – that’s a really neat-o idea!
-
@Boxer said in A new callback request for SPD BRAKE functionality.:
What does that mean, “I don’t like…”?? I’m curious what there is not to like here. These buttons are event based so having the switch captive in the close position (electrically “ON” the whole time) does not consume any meaningful resources in Windows or the game context. Were you thinking that it’s hammering on the game code for attention the whole time?? Not so.
That’s exactly what I thought, especially because between Windows and AL + BMS, I also have the Joystick Gremlin Macro, which keeps the DX button (SPEED BRAKE Switch - Close) in a pressed state. If not so, it’s fine, let it be (winking to airtex2019, thumbs up).
As for ‘I don’t like Toggle’, as I already mentioned, T-switches on my VPC MongoosT-50CM3 Throttle don’t always work correctly with this command. Here, I’m more concerned not about myself, but about my son-in-law, who has the same VPC set, but who has very little time to fiddle with such nuances of hardware and software (being LTC in the Rolling Along).
Thanks.