Ranma13

Looks like they're also going to sell a limited run of gauges: It's unknown at this time if the HSI will be the only gauge or if there will be others, and it's also unknown how it will interact with the sim, and also which sims it will be compatible with out of the box. The picture shows though that it's a LCD screen rather than physically moving parts, with cutouts for the DME range and course windows. Also, I mis-read the earlier post on their front page regarding the F16 grip. It will have one two-way rotary (the one around the trim hat) rather than two rotaries.

No, it doesn't make sense to do it that way. DCS implements the common standard (DirectInput FFB API), whereas Brunner uses custom software. What you're proposing is like saying that hardware manufacturers should send their devices to Microsoft so that Microsoft can write a custom driver for it. It doesn't work like that. Microsoft creates a common standard (for example the HID interface), and if you have a custom device that doesn't use that standard, it's up to you to write the driver for it.

It's not impossible, but it's difficult. DCS does not export FFB data, so a virtual joystick device has to be created that can receive and process the data. Also, the FFB API uses 'shapes' such as Damper, Friction, Sine, Spring, etc, and the joystick hardware is supposed to handle the implementation of these shapes. This saves the devs the trouble of having to create commands with the correct tweens so that they can say "do a sine movement for 500ms with a force of 2.0" instead of actually having to draw out the sine wave and constantly send it over to the joystick. The CLS-E joystick has an API available to control it via software, but it only seems to support two types of forces: an 'active' force that applies a force in a direction with a certain magnitude, and a 'passive' force that attempts to keep the joystick in a certain position, resisting any movement away from that position with a certain magnitude. In order for it to work with DCS, software needs to be written that will adapt the force feedback API's shapes to the two types of forces that the CLS-E supports. The best party to write that software would be Brunner, but it's a bit of a chicken and egg issue. There's not much point for them to spend the time to write the software for DCS if nobody's going to buy their base, but until they write the software, nobody's going to buy their base. In the past I considered picking up the base and writing the software myself, but given that there's not a single review of it anywhere, I didn't want to be the guinea pig.

Once again, the Brunner CLS-E joystick won't work because it doesn't use the DirectInput force feedback API. Please stop suggesting it, someone's bound to buy it without doing enough research and be sorely disappointed when they find out that it doesn't work with DCS.

The laser painting will run for 6 seconds beyond the estimated impact time. It is highly unlikely that the painting will stop before the missile hits unless the initial range finding is very off (like estimating 1km when the target is 6km away). I use them on manual all the time, you don't need to be at a vastly superior altitude. If you're hovering at 20m and the target is on a flat plane from you, you can get about 6-7km out of the missile. At 300m or higher, this extends out to about 8-9km, maxing out at around 10km if you're very high above the target.

In the settings under Monitors, you have it set to "1 Screen". This needs to be set to "3 Screen". If you want the lower 4th monitor to display the MFDs, you'll need to create a custom monitor lua file in C:\Program Files\Eagle Dynamics\DCS World\Config\MonitorSetup. I won't go into the specifics, but if you take a look at the LMFCD+Camera+RMFCD.lua file, it should show you how to add in the LEFT_MFCD and RIGHT_MFCD objects to set the position of the left and right MFCDs.

As I already mentioned in the Open Source Joystick FFB thread, the Brunner base does not use the DirectInput force feedback API, instead relying on a plugin for Prepar3D/X-Plane/MSFS. This means it's only compatible with those 3 sims, and won't work with DCS unless a plugin is written for it.

I got my CM in recently and wanted to confirm 2 things: 1. Is the brake lever supposed to hit the body of the joystick when fully depressed? 2. Is the flip-up trigger supposed to feel a bit sticky when it's getting flipped up? On the VKB MCG it's a smooth motion (I can just flick it forward and it pops up by itself), but on the CM I have to assist it all the way, otherwise it gets a bit sticky towards the end of the travel.

I've read up on the CSL-E joystick, but like a bunch of other high-end force feedback devices, it doesn't use the DirectInput force feedback API, instead opting to use a special plugin with Prepar3D/X-Plane/MSFS. Unless a similar plugin is written for DCS, it won't work.

Most likely. Despite the connector being compatible with the Warthog base, the extra buttons mean that it will only be compatible with the FSSB base. There may be a compatibility option where the extra buttons are unused if connected to the Warthog base, but we won't know for sure until more info comes out.

There's been an update. The F-16 grip is now in final preproduction stages. It will have 38 switches and 2 rotaries. Here's a picture of it. The image says 1 rotary, but the description on the main website says 2 rotaries. It seems like every single switch is now a 5-way hat, including the master mode button, pickle button, and pinky switch. I'm interested in seeing how this will feel, as traditionally 5-way hats don't feel all that great when you're pressing them in, and the 4 other directions don't feel as good as a 4-way hat without center press. One of the rotaries is around the outside of the trim hat, and the other one is unknown at this point. The rotary looks like it re-purposes the 'bezel' of the trim hat. It's unknown whether 'rotary' in this case refers to a rotary encoder, or a potentiometer-style range adjuster. It also looks like it will have the 12-degree forward tilt already built in.

This comment on Reddit is a good introduction on how to add custom bindings:

Not everyone is going to be building a cockpit, and there are many more people who have controllers that don't match 1:1 with the cockpit controls. For custom cockpit builders, editing the input lua file is probably the easiest step in building a cockpit, and whether those extra bindings exist or not is not really a big deal, especially for those tricky switches that can't be matched 1:1 (like the navigation lights switch, which is a 4-way switch where the top position is momentary and the other 3 positions are latching). Where the pre-included bindings would matter a lot though are for people who are only using commercial throttles and don't have the skills to add in new bindings. Saying "just add in bindings that match the physical cockpit switches" would be ignoring the fact that only one throttle has latching switches, the TM Warthog. What about those using the Saitek X52, Saitek X56, CH Pro Throttle, and the TM.16000M? Should those users be completely ignored simply because they don't have switches that act like how they do in the real Ka-50? Just as how you feel that only the bindings for latching switches should be added because it corresponds to the actual switch in the cockpit, I can equally make the argument that only the bindings for momentary switches should be added because that's what every other throttle besides the TM Warthog uses. So my point is, this is not a bug, it's a feature request. The bindings should be added eventually, but it's not as simple as "match the bindings with the physical switch", because not everyone is going to use the same hardware. If ED wants to support different devices with different switch types, then they will need to consider all devices and not just a particular one.

This is my experience as well. Most people who are recommending center mounted with extension have never used a force sensing stick before, and don't know how much more accurate it can be.

Not greatly, but as I mentioned, I can feel it slightly off-center when I just rest my feet on the pedals. I've mounted the pedals tilted slightly to the left in order to compensate. Does the F-3 have the same issue?

I'm having an issue with my Baur BRD-F2 pedals where they're physically slightly tilted to the right: It's enough that I can feel it slightly off-center when I'm resting my feet on them. If I press them slightly left, then it centers correctly: Does anyone know if this is normal, and if not, how it can be corrected?

Yes, I got the Lightning version. With S&H it came out to $700 for the R3 base, and $215 for the MongoosT-50. It's really pricey, but the payoff is the better fine control. I got it because I was tired of the center slack in the FFB2, and the small amount of stiction that I was getting with the Gunfighter base.

I have both a center mount and a side mount stick. The center mount stick is the VKB MCG Pro with extension on the Gunfighter base, and the side stick was previously a FFB2 and now a VPC MongoosT-50 with a FSSB R3 force sensing mount. If you're going to use a displacement stick, it's best to go with a center stick with an extension. The extension really gives you a greater degree of control, particularly around the center. This is really helpful when doing things like A2A refueling or trying to control helicopters. I don't find it particularly difficult to get in and out of the chair with a center stick, although it will block anything you put in front of it, like a second display. I had to push my second monitor (with MFCDs) back a bit so that I can hit the MFD buttons on it when the stick is all the way forwards (something that you need to do if, for example, the hydraulics goes out on the Ka-50). As for the side stick, I would only use one if you can't mount a center stick, or you're using a force sensing base. Once you get used to the force sensing base, you have much better control over the aircraft than you would with a typical displacement-based base. No more yoyo'ing around when doing A2A refueling, and you can repeat maneuvers with better consistency. We are much better at judging the amount of force applied vs. the distance moved, so it's easier to do the same maneuvers when you have the muscle memory based on force. The downside is that it's difficult to constantly apply a force, like how you need to for WWI/WWII aircraft and helicopters.

And my point is that it's not as simple as you put it. A 'physical switch of the same nature' means different things depending on whether you have a latching or a momentary switch. Even a 2-position switch needs 5 different bindings to cover all the use cases. It's easy enough to say 'it should have it' and dismiss me by saying 'we can argue about these complexities forever', but it's exactly those complexities that make it impractical to cover all the use cases through adding more bindings. Regardless, you can add in the necessary bindings by editing the lua file. I still stand by my original point that this doesn't belong in Bugs and Problems, it's just your own personal nitpick.

The issue is that there's a multitude of ways that a control can be bound, and a variety of switch types. Let's take the RALT/BARO switch for example, which has 3 positions: 1. You have a ON-OFF-ON latching switch. You need two bindings for RALT and BARO, where releasing the switch returns it to the center position. 2. You have an ON-ON-ON latching switch. You need three bindings for RALT, BARO, and the center position. It's arguable that you can just use the same bindings as #1, but DCS sometimes has a hard time syncing the position of a switch that's in an OFF position, requiring you to cycle the switch to sync it up. This issue is avoided with an ON-ON-ON switch and 3 separate bindings. 3. You have an (ON)-OFF-(ON) momentary switch and want the switch to be absolute (moving the switch up will select BARO, moving it down will select RALT). You need two bindings for RALT and BARO, where releasing the switch does not return it to the center position. Note that this means that the center position is not selectable. 4. You have an (ON)-OFF-(ON) momentary switch and want the switch to be relative (moving the switch up will move the cockpit switch up one position, moving it down will move the cockpit switch down one position). You need two bindings, one to move the switch up, and one to move it down. 5. Same as #4, but now you want the switch to wrap around so that if you move the switch up when it's already in BARO position (top position), it will jump to RALT (bottom position). 6. You want just a toggle binding where pressing a button or using a momentary switch will always move the switch down one position, with wrap around. This is what's currently already in the bindings. All of these bindings are valid for different controllers. The TM Warthog mostly has latching switches, but the Saitek X56 only has momentary switches. Other controllers only have buttons or 4-way hats. If ED added all of these switch bindings, you're talking about 9 different bindings just for a single 3-position switch. Now multiply that across all of the cockpit controls and you can see how it will blow up the size of the controls list. Don't get me wrong, I feel that the control bindings in pretty much all combat flight sims should be reworked to support multiple input types. However, they can't just add additional inputs to the list and call it a day, because it would make the list too long. Ideally, we'd have some kind of system similar to the axis binding where you select the cockpit control you want to bind, then a separate dialog opens up that asks you what kind of binding you want to set depending on what kind of controller you have.

Is the UTC Mk II Light still for sale?

You need to post your lua file for us to see.

This has always been the case. The Shkval lock range is only dependent on the time of day, not the contrast shown on the Shkval or the brightness/contrast dials.

Except a touch screen is a very different experience than a physical key. Also, Roccat Power grid is a glorified virtual keyboard and has no interactions with DCS BIOS or the sim itself. You can only send key presses to the sim, but not extract out any data.

Yes, it still works in 2.5. As long as DCS BIOS supports the most recent version, it will work. In other news, I've been working on a more generic UI that allows you to configure the Stream Deck, kinda like an advanced version of the official software. However, progress has been slow due to limited free time on my end.