I'm guessing you've changed something since the last release. I've just done a fresh reinstall of W10 and P3D V5. No issues there. Just installed 1.8.2 however and am constantly running into issues getting FSC to work over the network.
Running the FCDU on the client computer will result in "SELF-TEST FAIL" unless I change the location of P3D in the P3DInfo folder from "D:\P3D" to "\\P3DDESKTOP\P3D\" to utilise the network path name. I never had to do this in previous setups so presume this is something new. I'm sure in the past I just had to change the shortcut for the FCDU on my client computer to "START IN" D:\P3D\FSCAPTAIN\BIN.
The problem with changing the path in P3DInfo to a network one is that sometimes, Windows being Windows, even on the P3D computer itself the P3DDESKTOP computer isn't show or identified. God alone knows why - Windows networking is a pain in the arse. In these cases however, when I run administrator I get a message saying "DID NOT FIND CONFIGERATION FILES. HAVE YOU INSTALLED FSCAPTAIN". Clearly because the program can't find the root folder.
Is there a way around this? It seems the process has become unnecessarily complicated and finicky.
Ah, you are using P3D 5.0. Ignore my question in the other thread There have been some changes in the SDK between 4.5 and 5.0. Dutch is the only one of us who has the new sim already installed, I will ask him to have a look at your problem.
Just saw this reply after the other one. Yes, V5. Even when I do jump through the hoops of selecting which simulator version and manually entering the P3D.EXE location each time I start the FDCU the FDCU is VERY slow to respond. I understand the network setup may slow things down a little but never had this much lag in V4.
Today for some reason it was asking me to enter P3D's location regardless of if I had \\P3DDESKTOP\P3D or D:\P3D set.
In any event, the below LOG files represent the dispatch of a flight and then the opening of the FDCU from the remote computer to the point of LOGIN. The FDCU does work and function correctly, its just asking me to enter the P3D location on each start.
I've tried setting the shortcut on the remote computer to "START IN" both \\P3DDESKTOP\P3D as well as \\P3DDESKTOP\P3D\FSCAPTAIN as well as \P3DDESKTOP\P3D\FSCAPTAIN\BIN to no avail.
With the P3DInfo file set to \P3DDESKTOP\P3D (i.e. using the network path) if I change the short cuts starting location to \\P3DDESKTOP\P3D\FSCAPTAIN\BIN then it loads up ok.
The problem with this is that is, as I mentioned above, sometimes Windows networking is a PITA and doesn't if for some weird reason W10 can't "see" itself (or the P3DDESKTOP entry) on the network then the Administrator won't be able to load.
Sorry to be confusing. There are ways of working around these issues but it would be great to have a fix. I never had to (nor did I even know about) the P3DInfo file prior to this problem arrising so I'm sure in previous setups I would never have changed it from the local location (D:\P3D).
I don't have an "all still good" flight unfortunately - I removed P3D V4.5 some time ago and that was the last time I it working as it should.
Today I got a "write fail 8/1" message on the FDCU during boarding (and FSCaptain identify GSX loading pax).
I'll send you the log files from today in the hope you can figure out whats going on. Its becoming frustrating to the point that its not actually worth trying to work with anymore. The juice just isn't worth the squeeze as they say.
That WRITE FAIL 8/1 message is troubling - that means that the company log file was not written (if it was at the start of the flight, it would have been to update the flight data to show you've started the flight).
That's a serious error and I can only imagine a network or permissions glitch at that very moment. When I get your log files, I'll look to see what error code we may have noted.
I'll assume that you're running P3D5 and the FCDU "as Administrator", etc....
Going back to your earlier logs - your FCDU logs are 99+% identical, and both "Direct" and "Network Path" logs show the same ("Network") path. That makes me want to think that it's not the path that's the root cause.
We're going through another heat wave, so my time & focus is limited. I'm currently working on some legacy bugs and I will focus on the SELF-TEST FAIL conditions this week. I'm hopeful that if a workaround can be found, that should make the path type issue null and void.