DeCaf

On a fast SSD it didn't take more than a couple of minutes to allocate a 100GB cache for me. (On a mechanical HDD I can see that being another story though) Though I'm still not really sure what benefits it gives over not creating a manual cache... Some more documentation on this would definitely be nice.

But since we now have at least three other tools with which FS2Crew doesn't work it seems (Linda, GOFlight and Spad.next), wouldn't you consider investigating if there is something you can do in the FS2Crew implementation to remedy this?

So no LINDA, and no Spad.Next. I'm guessing there is some other application controlling the MCPPro then? It seems every other application interferes with the operation of FS2Crew? Could it be that there is something in FS2Crew that is causing these problems that could be looked at?

This problem appears to be really old as well. Found a post in Spad.next forums that seems to mention this from three years ago: https://www.spadnext.com/forum/viewtopic.php?f=20&t=4157&p=43663#p43663 It suggests that perhaps FS2Crew doesn't wait for acknowledgement of commands which might interfere with the Q400 external event interface? Is this something that could be the culprit? The Q400 external XML interface documentation states a procedure of waiting for acknowledgement after writing to/reading from the various XML variables, is this being adhered to by FS2Crew?

Are you using Spad.next?

As I mentioned, I don't use LINDA, and in my case turning off the Q400 module in Spad.next made everything work as it should (almost anyway), so in my case it is that module that interferes with FS2Crew. I'm working on finding a solution in Spad.next that doesn't use the Q400 module (but just uses normal LVAR's, and it's looking like it should be possible to replicate most if not all of the functionality for the Saitek radio panel anyway. (And the LINDA option in FS2Crew didn't really solve anything for me except for silencing some callouts)

Okay, I did some investigation here. It seems that Spad.Next and in particular the Q400 module is the culprit here. I can run Spad.next without the Q400 module and then all issues above except for number 6 in the previous post are resolved. (it is still almost impossible to get the FO to recognize the "Flaps 0, IAS 210, Climb checklist to the line" for some reason. (I have no problems with any other commands). So I guess there is a conflict between the Spad.next Q400 module and FS2Crew somehow, which is a real bummer. Personally I only have the radio panel, so I guess I will have to try and figure out if there is another way to set the frequencies on that except for via the Q400 module. Perhaps you guys who wrote FS2Crew have some insight there since you can ask the FO to set radio frequencies? Are they available via FSUIPC offsets or LVARS or something?

Okay, so I tested with LINDA set to YES in the configuration. This "solved" two problems, namely that "1000 to go, ALT SEL" was no longer called (at all, even when it should be), nor the "Ice detected" callout. It also removed the callout for "Rotate" for some reason, however the V1 call was still there and at about 50 kts. So the problems I'm having so far, with LINDA selected to YES are: I cannot get the FO to start the engines if I use GSX for push-back. (This is documented I guess, but would be desierable) V1 call occurs at the wrong time, seems to be around 50 kts (before the 80 kts call) There is no call for "VR" The call for Acceleration height occurs way too early (before "positive rate" last time if I recall correctly). On one flight I never got the "positive rate" call, and then the FO does not respond to "Gear up". I just cannot get the FO to recognize any call for the after takeoff flow, i.e. the very long sentence "Flaps 0, IAS 210, Climb Checklist To the line". I have even trained speech recognition for this particular phrase for about 45 minutes, so I can dictate it fine, but for some reason FS2Crew interprets this as gibberish. Perhaps it would be nice if I could give each of these commands separately? "Set and Checked" "works" in a sense, but gives me IAS 160, which I guess I can live with. (Saying "Set and checked again" makes the FO perform the same after takeoff flows again by the way). Asking the FO to set IAS, heading, altitude or course results in an infinite loop of increasing (or decreasing) these values until I say "Cancel last command" and set it myself. So in its present state I really can't use this product, considering it actually just increases my workload. Is there any solution to these problems? As a side note I also have FS2Crew for PMDG 737NGX and PMDG 777, and these works flawlessly. Not sure why I'm having such problems with the Dash-8.

I had a similar problem with the "Set course" command, he just kept spinning it around forever, until I told him to "Cancel Last Command". Same issue with altitude. I did not have LINDA set to YES though, will try with that and see if it makes a difference. (I'm not using LINDA, but I am using some custom LUA scripts in FSUIPC and Spad.next). Additional problems I discovered were repeated calls of "1000 to go alt sel", V1 was called out at 50 kts (even though it was set to 117), and acceleration altitude was called almost immediately after takeoff even though correctly set to 1500 ft in my case, and multiple calls of "We're picking up some ice" but no ice warning and it was at low altitude at 30 degrees centigrade. 😕

Ah, opting out of experimental builds fixed the issue for me. Didn't think the non-experimental versions supported P3D v4, but i guess that was a while back. Well, now it seems to work, so I'm happy again! :)

Gah! Same thing here. None of my joystick buttons seems to be detected by ChasePlane anymore since the last update. Neither from my Saitek X-55 nor my Razer Orbweaver Chroma. :( Now what do I do? Any way to rollback to a previous version? Edit: I tried restarting the computer and the application several times, still doesn't work.

But hey, you can get a 5 EUR discount if you're a previous owner, so perhaps PayPal would accept the payment then? ;)

This is a bit embarassing I believe. Before doing anything I thought I should try running the SimConnect installers again, in case that had something to do with it. Once I was presented with the Activation Key dialog. But now that I went to look up the activation key, I noticed that I probably used the wrong key all the previous times. It appears I may have used the key for the 300ER expansion rather than the 200LR base package... Anyway, I entered the 200LR key and everything worked without a hitch. I would of course have expected an invalid key message rather than the crashes, but perhaps there was something wrong with the SimConnect installations as well. Either way, not sure which of these fixed the problem, but the problem is fixed. Apologies for taking up your time with another user-error, and thank you for your assistance nevertheless! :) Best Regards, Peter.

No, I'm not using any migration tool or similar. Only genuine P3D v4 compatible products installed. Everything is run as administrator. I'll try with uninstalling the anti-virus, even though I've never had a problem with it before. However the built in windows defender cannot be uninstalled AFAIK, so that one I can only disable, but I'm suspecting that a lot more users would have problems if that was causing the problem. Anyway, I'll try a re-install without ESET antivirus installed and report back.

I just installed the PMDG 777 into Prepar3D v4 today, using the latest installers as available on my download page (under previous orders). From the Welcome Screen I select the PMDG 777 and click Ok. Initially Prepar3D closed right after asking for the activation code. Then after a few attempts it closed without asking for the activation code, before showing the progress bar though. After a few more attempts, it started asking for the activation code on each launch again, but this time the progress bar showed up and the aircraft loaded. But after loading almost none of the click-spots in the VC works, and it is cold and dark. The application log was ominously empty, i.e. no entries added when P3D closed for some reason. Then I did another attempt, and this time P3D actually crashed, with the following entries in the Event Viewer: Application: Prepar3D.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: exception code c0020001, exception address 00007FF80D519E08 Stack: Faulting application name: Prepar3D.exe, version: 4.0.28.21686, time stamp: 0x594a7255 Faulting module name: KERNELBASE.dll, version: 10.0.15063.447, time stamp: 0x30ec82a7 Exception code: 0xc0020001 Fault offset: 0x0000000000069e08 Faulting process id: 0x3568 Faulting application start time: 0x01d2f329d8f6a936 Faulting application path: F:\P3D\Prepar3D.exe Faulting module path: C:\Windows\System32\KERNELBASE.dll Report Id: 9f684be9-9102-458f-921e-9ce8868c35e4 Faulting package full name: Faulting package-relative application ID: What surprised me a bit is that the P3D DLL.XML file contains no entries for PMDG. I seem to remember that this file used to contain some entires for PMDG dll's. Has this changed, or could this be the cause of the problem? EDIT: Actually I may have been looking at the wrong DLL.XML file. I was looking at the one in User\AppData\Roamaing... However the one under ProgramData\Lockheed Marting... actually contains one entry for PMDG, the "PMDG Interface" one, so I was probably mistaken there. EDIT 2: I have now also tried the entire process (uninstall/reinstall) etc. without anti-virus or firewall enabled (ESET), but no difference. It crashed again. :(