OnCourse Software

I cannot get the PF3_Display on a networked client machine to work with MSFS. Running PF3 3.16.10 on a client machine--WideFS connects and PF3 shows a good connection to MSFS via the wingtip nav lights on the main window. The PF_Display program window comes up, but the connection lights both remain red, and the frequencies are wrong (the PF3_Freqs.dat file in the PF_Displayer subfolder dates back to 2020). PF3 Remote Text connects right up and works fine.

In the most recent manual, page 138, it says that there needs to be a folder in the main MSFS folder named PF_DIsplay, where the PF3_Freqs.dat file is written. The path to the main folder in my Steam version of MSFS is different than the one mentioned on that page, and regardless, I'm confused as to how PF3 can find it, given there are no config file options to point PF3 to the main MSFS folder on the server PC. In the FAQs, Q30, it says the folder is supposed to be named PF_Displayer rather than PF_Display.

Where is that folder supposed to be, what is it supposed to be named, and where does PF3 obtain the path that points to the folder on the server machine?

Debug_monitor.log attached. Here's what netstat shows (I have the PF_Display port set to 1055):

C:\Users\Bob>netstat -anop TCP | find /i ":10"
TCP 0.0.0.0:1009 0.0.0.0:0 LISTENING 20592
TCP 0.0.0.0:10801 0.0.0.0:0 LISTENING 4
TCP 127.0.0.1:1008 127.0.0.1:52235 ESTABLISHED 20592
TCP 127.0.0.1:52235 127.0.0.1:1008 ESTABLISHED 10444
TCP 192.168.1.4:1055 192.168.1.4:52214 ESTABLISHED 20592
TCP 192.168.1.4:52214 192.168.1.4:1055 ESTABLISHED 17200

If I try to run the WebDisplay, it connects to PF3, but after that there is no "listening on port 7339" that I expect to see in the text window. MS Edge reports the connection was refused. Both PF3 and PF_Display are explicity allowed through the firewall, and turning the firewall off does not have any beneficial effect, either. I have run the required .Net runtime installer.

Regards

Bob Scott

Hi Bob,

The folder in question should be PF3_Display. The FAQ was incorrect and that has now been updated, so thanks for the heads up. PF3 obtains the path to your FS via FSUIPC

Could you post your PF3_Display INI file please.

I assume you have tried different port numbers? The reason I ask is I had problems with one of the default ports that simply would not work. I tried firewall settings and AV settings to no avail. I knew it was being blocked because switching the port numbers with Remote Text allowed PF3 Display to work and then RT wouldn't. Eventually I had to settle for another port.

Hi Bob,

Your log file shows that PF3 is set to use port 1055 for PF3 Display and the netstat output shows that PF3 has opened ports 1008, 1009 and 1055.
Also, something has established a connection to port 1055 - so far, so good!
Have you configured PF3 Display itself to use port 1055? This will be seen in the PF3_Display INI file that Dave has already asked for.

Re PF3 Web Display: Are you running with the FSUIPC feature? If you are then I probably need to check that WebD works correctly with WideFS.

Cheers,
Martin

OK, I've found the problem. I looked at the FS path in FSUIPC offset 3E00 via WideFS (v7.160) on the client machine, and the path to MSFS is reported as "C:\MSFS\Packages\"

That's the local path on the server--the path reported in that offset on a WideFS client is supposed to have the UNC network path to the MSFS folder on the server, but it does not, so PF3 is looking for a folder that does not exist on the client machine rather than the folder on the server.

I created a dummy folder C:\MSFS\Packages\PF_Display on the client machine and the displayer connected right up. WebDisplay also works now.

There really needs to be some error messaging that notifies the user of a problem with the PF_Display folder, as it's a really frustrating troubleshooting experience with the program just hanging with no indication of where the problem lies.

P.S. I've reported the FSUIPC path issue to John Dowson.

Regards

Bob Scott

Thanks for the info Bob... glad you now have it working

Hi Bob,

Was just giving this some further thought and would like to know what version of PF3 Display you're using please? The latest is 4.1.1 and it doesn't access the PF3_Display folder in the main FS folder. The PF3_Freqs.dat files is passed to it directly from PF3. So the only way your problem could be resolved by creating that folder is if you're using PF3 Display version 3

Dave;

The Displayer is listed as v4.1.0.1 in the executable's properties, and the exe is dated 12/31/2021.

I chatted with John Dowson, and he determined that the reason the path coming from FSUIPC was the server local path rather than the UNC path was due to not having the correct MSFS folder shared--I had shared what appeared to be the main sim folder using the old FSX/P3D convention (location of the sim executable), and hadn't gone back and shared the ...\Packages folder when it became apparent that's what was being reported as the main sim folder in MSFS.

I now have the Packages folder shared on the server and have created a PF3_Display subfolder there, and the displayer works properly.

As a test, I removed the PF3_Display folder from the main sim folder on the server (C:\MSFS\Packages), and when I ran PF3_Display on the client without that folder present on the server, it hung like before--red indicators and no update of the PF3_Freqs.dat file on the client. I shut down the displayer, replaced the PF_Display folder on the server, ran the displayer again, and it connected right up. So it's definitely using that folder--it's creating what appears to be a temp/working copy of PF3_Freqs.dat in the shared folder on the server, and then that file is copied to the local PF3_Displayer folder on the client.

Regards

Bob Scott

Ah, yes indeed.... It's not PF3 Display that uses it, it's PF3 when initially creating the file. I think I kept that in to maintain compatibility with both versions, but it's not needed now so I'll remove it for the next release and just write the frequency file locally. Save anything like this happening again going forward.

Thanks for highlighting the problem