Make the exported (pop-out) MFDs clickable

[screamliner]

Hi, it's a pity that while you can export (alt-click or use msfs pop-out manager) the displays, its impossible to click on them on the exported screen (cursor must still hover over them in virtual cockpit). This is especially disappointing when using a touch screen for EFB and the FMS. For example, FlyByWire A380 supports this without any issue. Dear IniBuilds, could you consider fixing this in near time, pretty please? :3

[Eddie]

Hello,

We'll take a look 🙂

Have a lovely weekend! 

[screamliner]

aww thank you ❤️ You too!

[screamliner]

I was hoping this will come in the .13 update, sadly this was not the case 😞 also, the interior LOD is broken with SU3 beta - cabin and interior elements are not showing up in external view

Edited August 13, 2025 by screamliner

[Eddie]

Hi again!

I understand but it's important to not have expectations on when something will make it into the aircraft to avoid disappointment like that 😅
As for the LOD issue, that is a known problem in the SU3 beta -- also affects other aircraft. 🙂

Thank you 

[Jacob Van Wie]

On 7/25/2025 at 5:38 PM, Eddie said:

Hello,

We'll take a look 🙂

Have a lovely weekend! Hello

 

 TLDR: I am proposing that iniBuilds expose new SimConnect variables for MFD/FMC cursor control bypassing the non-interactive limitations when WASM panels are popped put.

Eddie, iniBuilds, and fellow A350 pilots,

I want to start by saying the A350 is an absolutely brilliant aircraft, and the complexity and fidelity are exactly what I’ve been looking for in a long-haul simulation.

I too would love to see an interactive pop out FMS, as I am in the process of designing a A350 home cockpit.

I know the HTML based OIS/EFB pops out and retains full interactivity, which is fantastic. However, for most of your target audience for the A350, the FMCs are the heart of your product, and not being able to control them on their dedicated monitors should be classified as a major issue.

Acknowledging the Technical Challenge

After much research, I understand why this is the case. These high-performance WASM gauges render differently than the HTML-based OIS. I recognize that asking to make these complex WASM-based bitmap displays fully mouse and touch-interactive in a pop-out window (like a Fenix-style web server) is likely a monumental, if not futile, development effort.

So, I’d like to propose a different, and hopefully much simpler, solution that completely bypasses the need for direct mouse interactivity.

The Proposal: Expose SimConnect Variables for MFD Control

Could the team expose a small set of new SimConnect variables or events specifically for controlling the MFD's cursor/pointer? (This would actually be more realistic as the actual plane uses a ball mouse)

If we had access to these, the home cockpit community could build the "bridge" ourselves using external software. We don't necessarily need direct mouse-click injection; we just need a way to remotely tell the MFD what to do.

Here are a few options for how this could be implemented:

Absolute Position Variables (Ideal): Expose two variables that accept a coordinate (e.g., INI_A350_MFD1_CAPT_CURSOR_X and INI_A350_MFD1_CAPT_CURSOR_Y). An external program could then read and update mouse position based on a controller or other HID and feed those coordinates to the sim.

Relative "Nudge" Events (Simpler?): If absolute positioning is too complex, perhaps four simple events could be exposed: INI_A350_MFD1_CAPT_CURSOR_UP, ..._DOWN, ..._LEFT, ..._RIGHT. 

The "Click" Event: A single, crucial event: INI_A350_MFD1_CAPT_CLICK

Why This Is a "Game-Changer" for Everyone

This "SimConnect variable" approach would be a massive win for the entire high-fidelity community:

Home Cockpit Builders: This would be the "holy grail." We could use simple scripts to map a dedicated ball mouse to these variables, creating a 100% functional external display.

Third-Party Hardware: This would open the door for hardware manufacturers to create physical MFD/FMC units that can interface directly with the A350, just by writing to these variables.

Shared Cockpit (A "Relief Pilot"): This is the most exciting part for me. This exact functionality is the key missing piece for shared cockpit utilities like YourControls. By exposing these variables (absolute positions), it might finally be possible for a co-pilot's inputs to be synchronized. This would unlock the A350 for true, multi crew operations, which is the very essence of long hail flying.

I'm not asking for a total re-architecture of the pop-out system ASAP. But just a few "hooks" can band aid this apparent gap in functionality. Think of how many people already have a second display and second HID they could bind to the FMC. Entire markets of products, communities, and add-ons are built around it.

[Andrew M]

Bring this back into the conversation. It would provide some genuine advantages to users.

[cee_gee]

Reviving this, any news Inibuilds? This is a show stopper at the moment not having this feature. 

[iniSteven]

23 hours ago, cee_gee said:

Reviving this, any news Inibuilds? This is a show stopper at the moment not having this feature. 

It's not possible at this time. Popped out WASM gauges cannot receive mouse click or scroll events, so it is impossible to make them clickable.

[Andrew M]

I think the most significant screen we want to be clickable is the MFD. Why is the OIS clickable but the MFD is not, and/or how is the MFD a WASM gauge? 

[Jacob Van Wie]

18 hours ago, Andrew M said:

I think the most significant screen we want to be clickable is the MFD. Why is the OIS clickable but the MFD is not, and/or how is the MFD a WASM gauge? 

@Andrew M The OIS is Html and the MFD is C++. The OIS functions exactly like an embedded web browser. When you extract it to a 2D pop-out window, Windows just passes standard HID pointer events directly to that browser container, so full interactivity is preserved natively.

WASM is basically a set of code for making instruments that is based on C++ instead of HTML. Since the MFD is C++ (WASM) the modules render to a static framebuffer. In the 3D VC, MSFS uses raycasting against the instrument mesh's UV map to calculate your mouse intercept coordinates, then feeds those discrete X/Y values to the WASM event handler. (TLDR, the code only works in the Virtual Cockpit)

In a WASM 2D pop-out, Asobo's window manager only streams that 2D texture buffer. The sim currently lacks the API bridge to translate native OS pointer events back into the WASM module's localized coordinate space. The gauge is essentially blind to your mouse the second it leaves the 3D environment. (Complain to Asobo about this one)

iniBuilds isn't stupid for doing it that way either. The MFD handles massive computational loads given the complexity of the A350. Executing all of that within a JavaScript engine would cause severe main-thread bottlenecking. (Ask any C++ dev why they like C++ any they will go on a 30 minute speech about performance) 

@iniSteven ↓↓↓

This is exactly why I am proposing the SimConnect variable workaround earlier in the thread. Since we can't click the 2D window natively due to Asobo's engine limitations, we need iniBuilds to give us external hooks so we can feed those X/Y coordinates back to the WASM handler ourselves.

This way people could at least make peripherals and controllers work with the panels (like how the real plane has a trackball)

[iniSteven]

On 3/7/2026 at 7:39 PM, Andrew M said:

I think the most significant screen we want to be clickable is the MFD. Why is the OIS clickable but the MFD is not, and/or how is the MFD a WASM gauge? 

The OIS is a JS gauge - all the rest are core avionics and are part of the WASM package.

[iniSteven]

19 hours ago, Jacob Van Wie said:

This is exactly why I am proposing the SimConnect variable workaround earlier in the thread. Since we can't click the 2D window natively due to Asobo's engine limitations, we need iniBuilds to give us external hooks so we can feed those X/Y coordinates back to the WASM handler ourselves.

This way people could at least make peripherals and controllers work with the panels (like how the real plane has a trackball)

Having this many simconnect events (one for each pixel the mouse moves) is going to be a huge problem. Simconnect has trouble handling even double-click events like the Autopilot Disconnect, so I doubt this would even work. Plus, having this many events would significantly increase the chances of Simconnect crashing/hanging entirely.