Jump to content
The simFlight Network Forums

FSUIPC 3.12


Recommended Posts

I downloaded and installed the new FSUIPC 3.12 (unregistered).

My PMDG 737 PFD/ND/EICAS screens no longer work and the standby altimeter has a "gyro" flag on it.

My PSS A330 panel now shows 4 engines instead if 2.

This is a joke, right? I hope so. :cry:

PMDG only uses FSUIPC for its TCAS, there's no support in FSUIPC for any of the rest of that stuff. The fact that an FS aircraft loses two engines shouldn't have anything to do with FSUIPC. FS is responsible for providing engines, FSUIPC is only an interface for programs to get information they wouldn't otherwise be able to get.

If this is not a joke, you may have something else going on there. I can take a look if you can supply the FSUIPC.LOG, and also there should be a file called FSUIPC_reg.bin in your C:\ root drive. Can you find that. Zip both up and send them to me at petedowson@btconnect.com.

Regards,

Pete

Link to comment
Share on other sites

Pete,

Just e-mailed you the FSUIPC.LOG file - can't find the other file.

Regarding the A330 - the visual model still has 2 engines - however the panel now shows four engine dials etc - as in the A340. When I go back to FSUIPC 3.11 the panel shows 2 again as it should be.

The PMDG is also ok when 3.11 is reinstalled.

Simon

Link to comment
Share on other sites

I have the same problem with an unregistered FSUIPC 3.12 - the PMDG 737 PFD/ND/EICAS displays are no longer displayed.

Very strange. I can't reproduce it here. I'm really puzzled by this. I am tied up now till probably midnight tonight, then I shall think on it further. Sorry.

Pete

Link to comment
Share on other sites

Pete,

I can confirm this without a doubt - with unregistered 3.12 there's nothing displayed on the NG's LCD's. As soon as I put my registration in, they're there. (I'm a tester for the SU2 patch btw, so it's still happening even with the newest files) Something weird going on...

Ryan

Link to comment
Share on other sites

I can confirm this without a doubt - with unregistered 3.12 there's nothing displayed on the NG's LCD's. As soon as I put my registration in, they're there. (I'm a tester for the SU2 patch btw, so it's still happening even with the newest files) Something weird going on...

There certainly isbut I'm at a loss at present. I simply cannot reproduce this. Can you turn on FSUIPC's read and write IPC logging please, keep the session short, just enough to show the problem, then make sure to close down FS and Zip up the FSUIPC.LOG and send it to petedowson@btconnect.com.

The one log I've seen so far looks fine, but isn't with FS closing at the end, so shows me a little less, and there's no IPC logging.

I have the PMDG 737NG and cannot make it go wrong even with my registration removed. I can only assume that my version of the 737 is different somehow, so perhaps you could include in the Zip the relevant AIRCRAFT.CFG and PANEL.CFG files, please?

If I can think of anything to try to find out more I'll let you know. Maybe I'll try some code changes and send you a version to test. Write to my email first.

Regards,

Pete

Link to comment
Share on other sites

I have a slightly modified version of FSUIPC, version 3.121, which may or may not fix this problem. If the sufferers who've written here already can contact me on petedowson@btconnect.com, I'll send this for testing if that's okay.

In short, I found a possible timing problem, a sort of gap between an aircraft being loaded (i.e. the AIR file then panel) and my detecting this occurring. If any of the new gauges attempt to register during that period, there is a chance that their registration will be accepted then (hence the "ModuleOk" message), but then their access gets denied when FSUIPC actually sees that the aircraft has been changed.

I don't know why this should be different in this version compared to 3.11 -- that part of the code hasn't changed. But in between these releases I have upgraded from MS Visual Studio C++ 6 to Visual Studio .NET 2003 with a new C/C++ compiler (version 7). It produces more efficient code (hence the smaller DLL file size), but evidently the timing changes this introduces are enough to cause this problem on some systems.

Anyway, I've closed that hole, but since I couldn't reproduce it here I need it testing, first, before I release it. Please?

Thanks,

Pete

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.