Jacob Van Wie

@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)

iniBuilds, and fellow A350 pilots, I want to start by saying the iniBuilds A350 my favorite aircraft to take on long haul flights. And I am in the process of designing a "Airbus" home cockpit, of which, I want all Airbus types (except A300 & 310) to be compatible with. I know in the iniBuilds A320, 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 issue. I do understand why this is the case. 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. Could the team expose a small set of new LVARS 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. (I already know variables not unlike exist in the WASM code: (ND::SetMouseCoords; SD::SetMouseCoords; FMSpage::MouseClicked; FMSpage::MouseScroll; FMSpage::MouseDrag)) 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. (Another variable could be added to where when it's value is true, it takes position only from this LVAR, as building a function call whenever a variable changes externally could be unstable) 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 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: 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.

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.