Scott-S6

We don't need them to inform us and we aren't limited to the exports created by default - we can find any instruments that have exports created by default in the files and any exportable instruments which don't have exports by default we can create exports for ourselves. There's nothing difficult about this.

There are no global names but those three are used fairly consistently (I would have names the F16 EHSI export as center but whatever). Some aircraft have other exports pre-mapped but all (except FC3) have other exportable instruments that you can name as you like. For example, I'm definitely going to be exporting the 6 display lines of the F15E UFC to my fourth cockpit display.

You can set up any number of exports, just as long as the structure of the lua files for the aircraft supports it and they can be called anything you want.

Sure, but it's not a situation that's come up so far. If ED want to do the FF C that would be one thing but we don't know how they'd view a 3rd party doing that . The FC3 aircraft are pretty iconic. If ED are cool with it then it's a little strange that there's never even been a hint of anyone wanting to do a FF F15C, SU-27, etc.

Will ED grant a license for a 3rd party to make one of ED's modules obsolete?

This is correct, no radio. I bought it (both the module and an FSB GNS530 unit) for radio functionality (to provide a consistent interface across aircraft) and for the navigate to cursor feature. Neither works in its current implementation. I've removed it from my pit.

"The two Lakenheath squadrons have started flying ‘clean’ — without CFTs — on occasions since the 493rd Fighter Squadron ceased operations with the F-15C Eagle in 2022." "On occasions" is the key phrase there. Still not standard operational practice.

Of course, RB could give the option to remove CFTs but, other than deleting hardpoints, it changes nothing. That would piss off the purists and the performance chasers.

Developing a whole second flight model is a LOT of work just to "have the option".

Never mind NVGs, have they not looked through a pair of binoculars? It doesn't look like this...

BTW, the alpha grips have more forward rake, the mongoose is very straight. If you're using it on a desktop or side stick that forward rake is nice. If you're using it center stick then the more vertical mongoose is good.

Look at how many unfinished modules we have. If we can get some more aircraft out of EA, that would be nice before growing the scope.of them. Also, what you're asking for simply isn't possible in many cases. It's not just that some version can use HARM so just turn it on. If that version has very different systems then how do you reconcile the HARM integration with the systems that our E has? You end up with different countries versions being different modules in many cases. That said, there are some weapons that are just variants and require no special systems modelling but those generally aren't the ones people are asking for.

Neither the base or stick have a twist axis. If you want a twist axis then have a look at the Alpha grips.

If it's not working then we need a screen shot from the windows display settings showing how you have the monitors arranged, the resolution of an the monitors and your monitor config lua file.

I did and you said "not a general version" even in the bit you quoted but the EF we're getting is pretty generic. (It's mostly German but only mostly) My 2c is that the focus needs to be 100% on delivering that point in time snapshot of the aircraft. We have a significant issue with some developers having aircraft with substantial missing or broken functionality years after release and even after leaving early access. Got to get that core functionality right before adding features from other periods, other services or more speculative options. Every option added to an unfinished module increases the testing and troubleshooting load. Because you're having fun the wrong way and this is clearly a bad thing.

ED do that but other developers have done more non-specific versions of the aircraft. The Eurofighter we're getting is a bit of a Frankenstein, for example. Access to good data on both flight characteristics and systems integration really is the limiting factor and focusing on a specific service and point in time makes that easier.

This is correct. RB have already confirmed that there will be pilot seat keybinds for them so we won't need to swap seats when flying solo but IRL you'd need to get ground crew to turn them on or something.

I guess you could jack it up and put it on blocks so that you could get the quad racks attached. And the pilot would have to remember to get rid of the bottom four so that he could land. That's ignoring the weight issues.

All military aircraft have equipment, ordnance and variants that never made it past the prototype stage and a subset of the community asks for them and more (see in this thread where people are asking for things that physically don't fit). I suspect that BS3 is going to make them more vocal but I guess we'll see. Although, if we're doing prototype aircraft then F-16XL please.

While I agree with the sentiment, BS3 has opened that door for better or worse...

Manley Power Best name ever. If you're into your WW2 naval history you'll know the name - captain and later Admiral Sir Manley Power. But, since he's supposed to be an American, Chad Wolf.

It varies. If you watch the animation in the cockpit you can see that some are pulled out before moving. I also had a look for a lever. Most are 3D printed, even some of the quite expensive ones, and I don't feel this is a good material choice. The only ones I found that weren't were commercial style levers which isn't what I wanted. If you don't want to make something then take a look at the panel from virpil which has a sizable landing gear lever. Might be what you're looking for. Winwing also have a panel with a landing gear lever but it's much smaller.

Okay, here's a rough and ready solution for you. If the on/off positions are out of sync you'll need to move the toggle to the menu position to resync them. There is a better solution referencing switch states directly but that'll need a little more digging. For each of the four CMSP switches you need an additional keybind in the input/joystick/default.lua {down = iCommandPlaneCMSP_JMR_MENU,up = iCommandPlaneCMSP_JMR_ON, name = _('CMSP JMR MENU'), category = _('CMSP Panel')}, {down = iCommandPlaneCMSP_JMR_ON, name = _('CMSP JMR ON/OFF'), category = _('CMSP Panel')}, {down = iCommandPlaneCMSP_JMR_ON,up = iCommandPlaneCMSP_JMR_ON, name = _('CMSP JMR switch'), category = _('CMSP Panel')}, That last line needs to be added. That toggles the state of the switch between On/Off when the switch is pressed and when it's released. Bind up position to menu and down position to switch (the new keybind). You now have working toggles. I'll update if I get the better but messier solution which references switch state directly working.

It's nothing to do with your board or switches - behaviour is exactly the same when bound to the keyboard. Menu returns to On when the switch is released. This works just fine with the toggle switch. On/off toggles on repeated presses. This is not what we want for a toggle switch. A new keybind will need to be created. ETA - I think the reason you aren't seeing discussion about this from other pit builders is that they're using DCS-BIOS which makes toggle switch behaviour easy to implement.

Why don't you ask their maintainers who've actually seen the pedal mechanism to comment? When you handle the unit it is obvious how it operates.