Vpilot and COM2 issues on various planes

it seems that Vpilot does no handle correctly COM2 under some conditions. I have tested this on the PMDG 777 and default 748 and the behavior is always the same…

MSFS2020. No Vipilot ie default ATC.

VHF L is set to ATC frequency with ACP set on TX/RX on VHF L.
VHF R is set to ATIS frequency and on captain ACP the RX on VHF R is set with this config the ATIS is heard as expected

MSFS2020 Vpilot and connected on the network

VHF L is set to Tower frequency with ACP set to TX/RX on VHF L working as expected…

VHF R is set to ATIS frequency with ACP VHF R is set to RX. Vipilot does not show the COM2 frequency as active and nothing is heard.

Default 748 → if you set VHF C to the ATIS frequency then Vpilot indicates COM2 Active and ATIS is heard

PMDG 777 → If you set on ACP to RX VHF C then Atis is heard again.

It looks that vpilot for some reason uses VHF C instead on VHF R Anyone has experienced this or is known?
Picture below shows Vpilot not receiving COM2 while it is correctly set

Below how it should be to work.

vPilot reads from the COM1 and COM2 simconnect variables. If the aircraft isn’t setting those variables correctly, then vPilot can’t read them obviously. Sounds like an issue with the aircraft. I say that because if it was a case of vPilot reading the wrong simconnect variables, it would affect everyone in every aircraft across every simconnect simulator. (FSX/P3D/MSFS) I don’t think it’s an issue with MSFS2020 specifically, either, since vPilot has been working fine on both COM radios since MSFS2020 first came out.

Hi Ross, i filed a ticket to JustFlight about the problem with the RJ Professional for MSFS. You need to set RX3 there to receive the “NOT TX channel”. This is the answer I got back from them:

Hi Auke,

Thank you for your reply.

I’ve spoken to the development team again and they have confirmed - as you will see from the attached screenshot - that the variables for COM1 and COM2 are working exactly as per the SDK - these are MSFS core and not local variables.

The Black Square code developer, Nick, has also researched this, offered exactly the same advice to set COM3 to receive and noted the following: “There is a bug with VATSIM clients that are using old variables for COM receiving from the FSX era. They require the “COM RECEIVE ALL” variable to be true to receive COM2 audio, even when the aircraft has more than two radios.” (Underline emphasis mine).

Also, a search for this problem has made it clear that this is not a new problem and that the developers of other networks (specifically, here, PilotEdge) have been asking for the core simulator to be updated to deal with exactly this problem since 2021 - with exactly the same working solution being offered by other users then:

COM1 and COM2 are working exactly as per the platform they operate on (you will note from the screenshot, in both MSFS2020 and MSFS2024). The reason for the issue that you are seeing is that the VATSIM client is looking for all radios to be set to receive, not just COM2, in order to be able to receive COM2’s audio.

Does that make more sense?

Kind regards,

Ian P.

Ahh, yes, this old debate. This is a difference of opinion among developers as to how the COM RECIEVE ALL (sic) variable should work. I’ve given an in-depth explanation of my opinion here before, but I can’t seem to find my previous posts, so I’ll describe it again here.

I’m of the opinion that the COM RECIEVE ALL variable should continue to work the way it always has in the past when simconnect only supported two COM radios. In those sims, if this variable is set to true, it means that both COM1 and COM2 are set to receive. Indeed, this variable is referred to as “COM RECEIVE BOTH” in many contexts, because that is a much more semantically correct name for what this variable actually means, and likely also because the value is set by pressing the “BOTH” button on the radio stack.

It has always worked this way because there were no COM1 RECEIVE or COM2 RECEIVE variables. So the only way to know which radios were set to receive is by looking at which one was set to transmit (only one could be set to transmit at a time, and the one that was set to transmit must also be set to receive) and by looking at whether or not COM RECIEVE ALL was set to true. So the logic has always been like this:

COM1 is set to receive if COM TRANSMIT:1 is true or COM RECIEVE ALL is true.

COM2 is set to receive if COM TRANSMIT:2 is true or COM RECIEVE ALL is true.

When MSFS came along, they added support for more than two radios, and they changed the effective meaning of the COM RECIEVE ALL variable. Now, its meaning actually matches its name. I fully understand this move … the developers are changing the variable’s behavior to match its name. That makes sense, but what they may not realize (or may not care about) is that it is actually a behavior change and breaks compatibility with existing apps. The variable should have been called “COM RECEIVE BOTH” all along, or maybe “COM RECEIVE 1 AND 2” or similar.

Note that MSFS also added individual variables for checking if each COM radio is set to receive, making the COM RECIEVE ALL variable unnecessary. This is why I think they should have kept the original meaning of the variable, and marked it as deprecated, in order to maintain backward compatibility with existing simconnect apps.

This all leaves me in a tricky spot, because vPilot works for all simconnect sims, not just MSFS, so I need to keep using the COM RECIEVE ALL variable. The fact that this variable now has different meaning depending on which sim vPilot is connected to, results in issues like the one being discussed in this thread.

There are a couple ways I could update vPilot to work around this issue and still maintain compatibility with all simconnect sims, but they result in messy, hard-to-maintain code. But I think I’m just going to have to bite the bullet and make the changes since it doesn’t look like the COM RECIEVE ALL variable is ever going to be returned to its original meaning and deprecated as it should be.

I’m extremely busy with real world work currently, so I can’t say when I’ll find time to make the changes. Until then, you have your workaround.

1 Like

@810670 @1535032 I took some time away from work this weekend to add a workaround for this issue. Can you give it a try? I haven’t spent any time testing it in MSFS, so no guarantees it’ll work at all. If you’re willing to be my beta testers, I’d appreciate it. :smiley:

Download the new version here:

https://vpilot.rosscarlson.dev/Assets/Files/Installers/vPilot-Setup-3.11.0.exe

@887155 Dear Ross, thanks for your quick response.
I checked the new 3.11.0 build in MSFS2020. (don’t have 2024 operational yet)
Against all 3 RJ’s and several other (GA) aircraft.
I’m impressed, works fine, no further “complains” :slight_smile:

@ 887155 Works exactly as it supposed to on the 777’s as well. Thank you :slight_smile: