Ranma13

Yes, all the modifier keys on the right side of the keyboard will be distinct from the modifier keys on the left.

If you run into something that DCS BIOS doesn't seem to support based on its documentation, have a look at the source code first: https://github.com/dcs-bios/dcs-bios-arduino-library There's a bunch of stuff that it supports, but is undocumented. In addition to the reverse flag for ON-OFF switches, there's also things like setting how many steps equals a detent for rotary encoders so that you can speed them up or slow them down.

Thanks for the offer, but I'm not quite at the point where anyone can really help, since I'm still working out the feature set and architecture of the app. With the official app, no. My app will be able to differentiate between the two (the Ka-50 library already does, it uses a fork of RobotJS that adds in the right-side modifier keys).

You need to right click on the file and select "Get shareable link": Otherwise nobody can view the file unless they request permission to do so. You can use Incognito Mode to check to see if it's publicly accessible.

It's just the base. It uses a force sensor, which is why it's so costly.

Nope, that would likely get me a cease and desist from Elgato.

You can extend it out past 2.5 sorties if you do some laser micro-management. When lasing for range, turn it on, lase to get the range, then turn it off immediately after you get the range info. When guiding a Vikhr, it will stay on for 6 seconds past the expected time to impact, so turn it off immediately after the Vikhr hits. That's a lot of micro-management though, so I wouldn't bother and just do a full repair after every 2 sorties or so.

Virpil has not committed to making an analog version of the throttle, they've only stated that they'd like to get the current version up and going before looking into other variants. Whether a thumbstick is important is something that you should decide based the aircraft you fly and your preferences. I would urge you to avoid falling into the trap of using realism as a criteria. Many people on this forum place heavy emphasis on what's realistic, to the point where it almost becomes the sole criteria. However, we do not sit in real cockpits, we do not experience G forces, we don't have control loading forces, we fly multiple types of aircraft, and we need to use a mouse and keyboard. For that matter, real slew controls are usually force sensors, and analog sticks are only a crude approximation. In aircraft such as the Su-27, the slew cursor will stay in whatever position you move it to rather than return to center. The Virpil throttle and stick are based on the PAK-FA controls, but modified for home sim use and are not strictly realistic. As much as we'd all love to get as close to realistic as possible, there are limits to what consumer-level hardware can provide. A much better criteria is to evaluate something based on how effective it makes you. If a side-mounted stick makes you more effective than a center-mounted one, then that's where it should go, regardless of its position in the real aircraft. If you feel more comfortable using slew controls on the joystick (Russian style) than on the throttle (US style), then that's where you should bind your slew controls, regardless of what's used in the real aircraft. If you feel that you need an analog stick and that it's useful to you, then you should get a throttle with one. But if you feel like it's not all that important, then don't bother.

I feel that you're approaching the project from the wrong standpoint. Based on what you've said, it sounds like you have limited experience with Arduino, and you're trying to build a cockpit. This is like planning a road trip from California to New York when you've just started learning how to drive. Building a cockpit is not a simple affair; it requires knowledge in programming, CAD design, electronics, part selection and sourcing, and woodworking/metalworking. You need to get the basics down first before you can move on to the more complicated stuff, which is why I recommend that you start with a single Arduino and a handful of switches and get that working with the sim first. An Arduino Uno has 20 pins that you can use as digital inputs, which is enough to implement about 2 switch panels before you need to start looking into how to expand that out. You should get that working first before moving onto the more complicated stuff. With that said, to more directly answer your questions, the DCS BIOS library does not 'natively' support shift registers or I2C. MMJoy2 supports shift registers 'natively', but ultimately you still need to understand what the Arduino is doing code-wise. It sounds like you want an out-of-the-box solution that you can load onto the Arduino and have it work 100%, which is kind of what MMJoy2 gives you. However, it's almost guaranteed that you'll run into issues where, if you don't understand what's happening behind the scenes, you're not going to be able to troubleshoot. For example, shift registers can't be chained indefinitely; at some point you're going to run into issues with noise, issues with the latching signal not syncing up, putting too much load on the micro-controller, or even running out of RAM on the Arduino. Other inter-device communication protocols such as I2C and SPI require that you know how those protocols work, how to wire them up, and how to write code to send and receive message properly. There's no guide that shows which controls DCS BIOS supports that the control settings doesn't. The easiest way to check is to find a control you're interested in and see what bindings are available for it in the control settings. The A-10C has the most complete set of bindings out of all the aircraft so it'll likely exist, but one thing to check is if the switch has a binding per switch position. For example, the master arm switch has 3 positions, ARM, SAFE, and TRAIN. You'll want to check that a binding exists for all 3 positions (it does for this example). This is important because if you use a 3-way latching ON-OFF-ON switch, you'll want to bind each position on the switch directly so that switch down will always set master arm TRAIN, switch middle will always set master arm SAFE, and switch up will always set master arm ARM. Other switches may only have a switch move up/down binding, which is not going to work great for latching switches because it'll likely be out of sync with the sim. I wrote a DCS BIOS control browser here: https://danieltian.github.io/dcs-bios-api/ which will show you every control that DCS BIOS supports and the types of values that you can set. You can use it to compare with the control settings within the sim.

DCS BIOS has a barebones Arduino library for a good reason: it can't possibly predict all the possible devices that people will use and in what configurations. It doesn't support shift registers, I2C, SPI, parallel pins, or any other cross-device communication methods because there are many ways of doing this and many libraries out there that already handle it (not to mention different libraries for different devices). You can use whatever cross-device communication method you feel is best, not just RS-485. Using a USB hub and treating each device as an individual Arduino is a decidedly bad idea because you will quickly run out of ports and the resources to handle all those devices (despite the theoretical cap of 127 USB devices, the motherboard will long run out of available resources to handle all of them). Rather, a better idea is to use multiple Arduinos that feed into a master one. This gets around two major limitations: the number of available GPIO pins per Arduino, and the length of the wire runs. It's easier to have one Arduino for each panel or each section and have them communicate with a master control board, than it is to route long wires all snaking back to one Arduino. DCS BIOS allows you to bind to nearly every control in the aircraft, even ones that aren't in the controls setting. For example, there's no analog axis binding for the brightness and contrast dials in the Ka-50, but DCS BIOS exposes these controls. In comparison, MMJoy2 emulates a joystick device, which means that you'll be limited to only the controls that are in the controls setting. I recommend that you start by picking up an Arduino and a few switches and playing around with it. Once you have enough switches and run out of pins on the Arduino, you can then start to play around with shift registers or a key matrix. Either way you can use DCS BIOS or MMJoy2, as they're both just software and both are free. There's not a whole lot of value in picking one or the other at this point, as you can easily switch from one to the other as your use case changes.

You will need to mount the FSSB R3 base somehow. Given the forces involved, there is no way to use it as a table-top joystick, and even a table mount is iffy (though possible). It uses the Warthog plate's inner mounting pattern, so you can mount it to whatever supports that pattern. Thrustmaster will sell you just the stick by itself, but you will have to contact them through their customer support to do so (which is how I got mine). I suspect that they're selling refurbished sticks though, as mine came with some minor cosmetic damage. Though you can use the T-50 stick with the R3 base, I would recommend lowering the required force to reach 100%. At the default setting of 8.50 lb for pitch, I can definitely feel the plastic flexing once I'm near the limit.

You can only buy the FSSB R3 Lighting version, the Warthog version is intended for commercial customers. As far as I can tell, there's no difference between the two. As for the sticks you can use with the FSSB R3, you can use either the Warthog stick or the MongoosT-50. Because it's a force sensor, a lot of stress is applied to the stick, and the Warthog stick holds up a bit better. The plastic of the MongoosT-50 will flex on the FSSB R3 base when you really start putting some force on it.

I would recommend that you look into getting a USB 2.0 hub if you're only looking to plug flight controls into it. USB 3.0 is intended for really high data transfer speeds, like a hard drive transferring hundreds of megabytes. For joysticks and flight controls, it's overkill, and the computer needs to allocate more resources than it would need to if they were 2.0 ports. Some motherboards may also not be able support an additional 8 USB 3.0 ports, but can do that many 2.0 ports no problem. Lastly, the USB 2.0 hubs are usually half the price of the USB 3.0 ones for the same number of ports. I would also recommend that you get a 10-port hub or more. You never know when you might get additional controls and need more. With pedals, a throttle, a joystick, and 2 MFDs, that already uses 5 ports.

Not close. I'm making progress, but it's slow because I'm doing it on my free time, which I split between various games, my family, and this project. It will be a ways out. That said, it's good to know that there's interest in the project, which motivates me more to get it done sooner. I just don't want to make any promises or give a timeline, since I have none in mind.

UltraMFCD hasn't been updated in a long while now, so the only way is to edit the monitor lua file.

https://yourlogicalfallacyis.com/ad-hominem

There is an explanation: it's been delayed. If you think that's unacceptable, then get a refund and purchase another throttle.

The Warthog throttle was released in 2010. Some of us have been waiting years for a better throttle to come along. If you can't wait another few weeks, either get a refund and pick up another throttle, or e-mail Virpil directly and get a status update from them. Coming on the forums and complaining about it is like complaining to us that your Amazon order didn't arrive on time and expecting us to do something about it. Nobody likes delays, but they're a reality of life. Virpil wants to release the throttle just as much as we want to receive them, but they're unable to meet the release timeline and thus need extra time to resolve the hold-up. Acting like an entitled brat isn't going to speed anything up.

Would it be possible to get a CAD drawing of the UFC and the screw hole locations? I'd like to make a backplate so that I can mount it to a VESA plate, and having accurate dimensions would save me the trouble of measuring everything out.

That depends on what you define as 'real'. You can just as easily find real cockpit pictures where the buttons don't have labels: https://www.jetphotos.com/photo/7379020 And also ones that do: In aircraft that do have the buttons labeled, most likely they work like the F16's ICP to allow the UFC to change common settings, like changing the UHF/VHF frequencies.

Anything you want. They're blank in the sim, so there's no point in binding them to the sim buttons.

I use these monitors from AliExpress: https://www.aliexpress.com/item/8-inch-Open-Frame-Industrial-monitor-metal-monitor-with-VGA-AV-BNC-HDMI/32797736289.html?spm=a2g0s.9042311.0.0.69ce4c4dHPf3bE The mounting flanges on the left and right can be removed. I got them because I wanted something with VESA holes and buttons that aren't on the front. With monitors that have buttons on the front, the MFD can interfere with them. The metal enclosure is nice too because it makes the front bezel very thin, putting the MFD's closer to the actual LCD screen itself. The screens are also IPS and have good viewing angles. There's two downsides though. The two monitors I got use different LCD panels despite being the same model from the same seller, so they're not 100% color matched. The displays only have brightness and contrast adjustment but no fine color tuning, so even with a hardware color calibrator, I can only get them to look close, but not match 100%. The second is that the monitors don't go to sleep when the computer is turned off, and have to be powered off manually. There's a sleep setting, but the minimum time is 15 minutes, and this is reset back to "never" whenever you turn off the monitor. This is not really that big of a deal, as I just turn them on and off whenever I want to use them. Combine the displays with a 90-degree VESA mount like this one: https://www.ricmotech.com/VESA_Fixed_Mounting_Bracket_p/rmt-vesaf.htm And you got a pretty good adjustable desk stand.

I haven't been able to make much progress on it due to other life events, but it's still something I'm interested in and actively working on when I do have some time to spare. I have a repo up for it here and made a commit just a few days ago: https://github.com/danieltian/powerdeck The challenging thing is setting up the architecture and finding the right tools. For example, I know that I will need the ability to dynamically create text on images, but the JS image manipulation libraries out there have varying levels of support for text drawing. Jimp is slow and only supports bitmap text, but also looks the best. gm needs a separate binary for GraphicsMagick or ImageMagick, but it doesn't have all the APIs implemented. Sharp is the fastest, but it also requires that text be a SVG definition, which is problematic when the text needs to line wrap. Then I need to add an UI that allows the user to set the font, font size, font color, background, position, and alignment. It's a lot of work that, as individual pieces are easy enough to do, but I'm still figuring out the best way to combine it all together. Yes, anything that's supported by DCS BIOS can be used by the Stream Deck. Eventually I will have the UI done, which will allow the end user to set it up themselves.

I don't believe Komodo ever said definitively that they were going to make any controls for the Ka-50, just that it was something they were looking into. As for the website, it does say that "due to extremely high demand some items are already out of stock." Komodo, like most low-volume companies, builds on demand. My guess is that they've received enough orders to keep them busy for the next few months, hence why they've marked every item as sold out.

You can set the speed of the rotary encoder. It's not in the documentation, but the rotary encoder allows you to set a stepsPerDetent value, which defaults to 4: https://github.com/dcs-bios/dcs-bios-arduino-library/blob/master/src/internal/Encoders.h#L58 You can decrease this value for a faster change. The steps per detent refers to how many values are in between each detent on the encoder. By default, most off-the-shelf rotary encoders will change by 4 values per detent, and DCS BIOS is configured to only trigger the button press after it detects that the value has increased or decreased by 4. By lowering this, DCS BIOS will respond by triggering it after the value has changed by 2 or 1, making it 2 to 4 times faster.