Live Dev Q&A: Guided Question

[CptLucky8]

[X] Avionics
[ ] Flight Planning for Airport Approaches 
[ ] Input/Controls
[ ] Flight Model

Here are links to some Avionics questions:

(main point highlighted - link for context)

@Ramuss

I can’t even use this sim for any decent IFR flight until Reality XP or A2A Sims come, and who knows how long that will be!

@SlushiestMars33

Wouldn’t that be an amazingly huge improvement in the experience if we could use Reality XP’s GTN750 !!! It’s what is holding me back from flying in FS more right now.** Just some bush flying for me, flying in VR and the GTN750 is a match made in heaven, and one that I have enjoyed in Xplane for the last couple years now.

@BostonJeremy77

I was sitting here recently wondering when someone is gonna come and bring GTN into MSFS… What’s stopping you right now? I don’t know technical details of SDK or software development, but it’s not possible for us to get a GTN or GNS product from third parties?

@CptLucky8

TL;DR: we do need a proper ‘override’ system for simvars which is paramount to a whole category of add ons which can’t be offered on MSFS2020 because of the SDK sandbox.

Let me illustrate: from FS9 up to P3D5.x the only way to integrate our GPS products into the simulator autopilot system is to hack the code inside the simulator in order to ‘override’ the stock GPS code which is otherwise hard-coded in the autopilot system (in-process detours like approach). Similarly the only way to override what any 3rd party HSI gauge is displaying is to hack the simulator to add the capability to ‘override’ the XML, and the C SDK variables, which are otherwise read only.

This is just a glimpse of some of the limitation in the FS2020 SDK inherited from the FSX SDK. Please note the X-Plane SDK doesn’t have any such limitation because it is offering what 3rd party vendors are needing from the get go.

@GAParadise

He is Reality XP

@CptLucky8 Jean-Luc I do hope Asobo reaches out to you to establish some sort of cooperation.
You have provided so much excellent feedback in these past few months.

.

[ ] Avionics
[ ] Flight Planning for Airport Approaches 
[X] Input/Controls
[ ] Flight Model

Here are links to some Input/Controls questions:

About Input/Controls acceleration bug (aka 10 deg increment bug):

(main point highlighted - link for context)

@CptLucky8

I believe, like I’ve written before, the main if not the only problem is FS2020 accelerating inputs regardless of the input source, and this is the same bug since FS9 (in 2004). In other words, it goes like this:

@CptLucky8

@Jummivana I’m glad they’ve announced correcting this problem, I just wish they won’t just issue an alternate set of commands and events to map to Honeycomb switches but instead they will re-implement the input event acceleration logic properly, otherwise, it won’t solve the problem at all whenever you use you’re keyboard to continuously repeat a command, like flaps down, and you turn an autopilot knob with the mouse for example.

.

[ ] Avionics
[ ] Flight Planning for Airport Approaches 
[X] Input/Controls
[ ] Flight Model

Here are links to some Input/Controls questions:

About Input/Controls, both from the 3rd party devs side and the end-user UI side:

(main point highlighted - link for context)

@CptLucky8

you might want to take a look at the Alpha manual and see how the entire concept of named events and commands in X-Plane is vastly superior to the antiquated FS5 area enums and ids… It takes no additional driver nor config to setup the Alpha with XP11, it takes a special tool to map the Alpha to events with Prepar3d/FSX only because there is no way for 3rd party developers to intercept and override standard control events unlike X-Plane (standard SDK feature), which makes 3rd parties having to create their own alternate simvars the Alpha must interact with via a special application mapping the controls to these alternate simvars…* There is so much to get inspired of the XP11 SDK which would tremendously benefit 3rd party devs, and this one is a perfect example in my opinion.

.

[ ] Avionics
[ ] Flight Planning for Airport Approaches 
[X] Input/Controls
[ ] Flight Model

Here are links to some Input/Controls questions:

About Input/Controls game design decision (Simmers vs Gamers):

(main point highlighted - link for context)

@CptLucky8

yesterday I decided to try our the 747 which I didn’t flown for a long time. And what strikes me is how “gaming oriented” it is designed in the controller response. Here is:

I have a long time aversion for cockpit animations which most 3rd party developers are coding on a 1sec time span. When I click a switch, I don’t want this switch to animate for a full second from off to on, I expect it to switch position instantly (or nearly instantly for the sake of animation something like 200ms is enough, at 50fps this still gives you 10 frames of animation to see it moving). Most FS2020 aircraft switches and controls animations are coded exactly the same way with unnecessary 1sec long animations.

But the other problem I’ve spotted in the 747 is that the yoke roll angle animates slowly and doesn’t match your hardware control. […] The same control input flaws (to me these are flaws) can be seen with steering tiler, and brakes.

This is wrong to me for a flight simulator for simmers, but I believe it is right for piloting the game with an XBox controller where you have limited input range (you can’t compare a controller 1 inch stick to a Honeycomb yoke roll amplitude for example).

.

[ ] Avionics
[ ] Flight Planning for Airport Approaches 
[X] Input/Controls
[ ] Flight Model

Here are links to some Input/Controls questions:

About Input/Controls game implementation decision (Simmers vs Gamers):

(main point highlighted - link for context)

@CptLucky8

I’d recommend FS2020 Controller Settings be in clear text and accessible outside the game GUI. It is important for backing up copying, sharing and restoring purposes, but also for any other user editing which is not possible with the GUI because of its Xbox oriented design.

An good example of this is how you can never precisely adjust curve sensitivity with the mouse because the slider range in pixels is less than the number of percentage values you can select from.

There is really no useful reason to hide these inside the convoluted file/folder naming convention in my opinion (see details below) and this further reflects the opposite of a simulator for simmers as well. I strongly believe a differentiator between a game and a simulator is the level of low level access to configuring one’s simmer experience and manual access and editing to these files is paramount to the simmer experience. It has been this way for decades with every single other simulator.

Furthermore, in un-hiding the settings system, it would make it easier to solve this topic question (backup/restore) but also other problem reported in this discussion:

Ability to have separate control setups for each plane without having to manually switch between 20+ controller profiles?