Pete Dowson

Sorry, I don't know why that is so, and I'm afraid I no longer have FSX to check. Are you sure it happens with all aircraft? Are you using a default one, or an add-on? Maybe some add-on aircraft aren't written to handle that. Always check things with defaults. It cannot be related to anything like FSUIPC. Pete

Actually, there isn't (yet). The other user, 737-SimGuy, said he was going to, but apparently hasn't yet. I have now verified that P3Dv5 currently does not invoke the events it should be doing for SimConnect Texts and Menus and have posted a suitable bug report in the developers forum. Pete

FSUIPC does not support X-Plane. I don't think ProSim does either. So, I'm sorry but we cannot help X-Plane users further here. If you have understood that ProSim works with X-Plane you need to talk to them about that. Pete

We have already received reports that the SimConnect Text facilities used to obtain the texts for SimConnect windows and menus are broken. I will be testing this today and reporting the details to L-M in their developers forum. It would be a good idea if you could add your complaint to L-M as well. I think you'll find a thread there for this already. Pete

I assume you mean you assign the THREE axes -- rudder, left toe brake and right toe brake? That sounds like you've not properly calibrated the toe brakes. Please refer to the calibration chapter in the FSUIPC User Guide. There are numbered steps to good calibration. Oh, and if you are assigning in FSUIPC, make sure you disable controllers in P3D. Pete

Ah, you mean the text intervention, so that displays can be diverted to another PC via WideClient. I've not got to testing that yet -- I've only just received the DX12 update for TruView (equivalent of your Immersive Pro) and was planning a test flight this afternoon. Note: I was confused by your post because the thread was about the Events (Controls) to select an item in a displayed menu aren't working. It wasn't related to text interventin and diversion. Anyway, if it isn't working in P3D5 that's serious enough for me to stay with P3d4 until that's fixed -- i thought I was only waiting for ActiveSky! 😞 Thanks for reporting it. I will also do so, after I've verified it myself later today, and will post in the developer's section. Thanks, Pete

Hi Andrew I've been looking at this in more detail this morning, and I remain a little concerned about what is actually going on. Are these shutdown times in line with what you'd expect? 30 + 60 seconds seem mightily excessive. John's amendments have only added a few seconds. What is LINDA doing which takes 30 seconds to close? And what is this "background task stub"? The logs show around 23 seconds in total from when SimConnect tells FSUIPC to close and when it actually does close (final log line). Are the additional 67 seconds you are telling us then after that? What can be responsible? I think it is important for us to understand, especially with you advising John to add a note about an extra 60 seconds. That will need some sort of explanation, please. Is it related to the 9 COM devices which seem to be added in addition to the two COM ports used for VRI? Are these all devices you have attached which are handled by LINDA? Is this 60 seconds extra perhaps proportional to how many devices LINDA has been asked to handle? Anyway, in the latest version John sent, the one you seem happy with, there are still those TerminateThread functions. I don't like those. I think they were added ages ago because of these sorts of problems which I didn't understand then either. The threads should terminate by themselves. With that in mind I have made some changes in the code to see if we can make that happen. I wonder if you'd be so kind as to run a test or two with yet another revised version which John will provide shortly. The results of this might not be what you want, so please treat this only as an experiment for now. You may want to retain a copy of your current 'good' one and return to it afterwards. Thanks, Pete DLL: FSUIPC6.dll

I've not seen this Window. How are the selections done normally? By keypress or mouse? If it's a menu then most menus have selections chosen by a number (eg ATC or other SimConnect menus). Pete

Hi James, They never worked for me in P3D4 either. I have always had to assign to the normal keypresses, as you would operating on the P3D keyboard directly.. Do they work if you assign in P3d5, or does "not being populated" mean they aren't listed for assignment? (I wasn't sure what tat meant. Sorry). Pete

Right. I don't think that's anything to do with FSUIPC. It's one of the many being reported with P3Dv5 No, both logs show FSUIPC never started its close squence. P3D crashed out before SimConnect notified client DLLs by calling the DLLstop function. You also had the extra logging we asked you to only enable just before you closed down operating for the entire session. 500 LogOptions=00000000 00020051 (x2005 = 8197. the last digit contains standard log flags with 01 meaning "yes make a log" and always set). I think this probably happened because it would have been saved like that from an earlier test. If we do any more tests with this logging (which is unlikely) we'd need you to set LogExtras=1 again in FSUIPC6.INI before each session. Anyway, I think we've learned all we are going to from the logging we added. There's no easy answers -- the hang is somewhere in Windows or a driver, out of our reach. It simply isn't returning from a standard function which is documented as non-blocking. We are looking only at experimenting with delays to alter timings a bit, and/or a forced TerminateProcess (which is like doing it with Task Manager) instead of bothering trying ot terminate the threads. Note that all this ONLY applies to the read and write threads for VRI devices. The general serial port COM threads are Terminating properly. So we'd only have to possibly do a forced terminate with VRI in use in FSUIPC. One of us will be back later tomorrow. Pete

There's no difference in what is logged to the previous tests. These last three are identical to the two successful ones previously supplied (previous #1 and #2). If you set "Debug=Please" in the [General] section of the FSUIPC6.INI file, the Logging Extras field turns into a data entry field which accepts a number. It is not a checkbox then! That's where we asked you to enter 8197 before closing the session. I think you must have done that as the logging does contain the extras we wanted. I understand that. But on any Windows detected crash there will be crash information in the Windows Event Viewer! Have you never looked? Please try it! In the left hand explorer-syle folder list select Windows logs then Application. Errors will have a red icon. Look for one mentioning Prepar3D.exe. When selected you can copy and paste the information displayed below. And i also wanted to see the FSUIPC log for that crashed session, just to see how far it got! Honestly, there's no point in reporting crashes without supplying whatever information there is. Pete

I don't fully understand what you are saying compared to what you've posted. There are three logs. #1 and #3 shows a correct shutdown. #2 shows that the shutdown sequence hung on a TerminateThread call (something MS say is impossible!). TerminateThread is not supposed to block -- the thread is told to terminate and if you want to be sure it has you have to check later, which during termination of the sesion we don't. So, at present I don't know where to go with that. It's something in Windows or its drivers and i wouldn't know how to get to the bottom of it even if we could reproduce it in debugging conditions. I suppose we could just simple not bother to tidy up VRI device connections before closing. We might then have to "TerminateProcess" to close P3D after a timeout instead -- as ruthlessly as Task manager does. We will think about it and maybe supply another test when we have something different to try. I agree with John, though, that this is not a change between FSUIPC5 and FSUIPC6. Something else is going on. But can you please explain more about "P3Dv5" crashed on shutdown. I have read quite a lot of reports now about P3Dv5 instability. If you think this case was related to FSUIPC can you provide information of some sort -- the Event Viewer details of the crash, and the FSUIPC log to that point? I'll probably not get back on this till later tomorrow. Pete

I really don't know. Have you asked in the ProSim forum. That is the right place. We cannot really support ProSim here. Pete

I'm afraid neither the FCU not the Overhead are COM devices supported by FSUIPC. They were later developments by VRI which depended on their own new drivers. The VRI support in FSUIPC is only for the older original devices which only had rudimentary supporting software from VRI. Please refer to Appendix 3 of the FSUIPC Advanced User's guide (page 57) where, right at the top, you will see the list of the original VRI devices supported. Pete

Someone else reported this in the Support Forum. I think it is a change (bug or omission) in P3D5 (among many others it seems, reading reports). It would be worth reporting in L-M's website. I've never had consistent results using those controls in any case, and reverted to using plain numeric Key Presses long ago. Pete

I think Programs can only start other Programs at the same privilege level, but i've never tried. You could list try changing the properties of the Program you want to run (i.e. its EXE) to do this -- i.e right-click, select Properties -- Compatibility -- run as administrator. Let me know if that works. Otherwise you'd need to run the Sim "as administrator" in the first place. Let me know. Pete

That's definitely news to me. Sorry. In my opinion that was a strange decision by GoFlight -- maybe one taken after Doyle Nickless relinquished control. Apart from changes like those we've done now, I'm sure there are other programs using the DLL and not necessarily on an install which has or otherwise needs a Modules folder. It was better when it was automatically installed in a standard folder somewhere with an Installed path entry in the Registry so programs could find it automatically. Pete

Yes, offset 5350 is part of a batch of offsets provided to Mark Hastings for use by SimAvionics. Assigning it in ProSim will be the same as assigning any other offset, which apparently you've done already. Yes, of course. Just go ahead. I had to do the same with much of the software I wrote to allow my PFC cockpit to work with Project Magenta assigned offsets when I changed over to ProSim. Pete

I did not know about the added data in a later release. PMDG don't tell me these things. So yours in the first mention. You didn't make a request for more data to be added, just a problem report that you were getting zero. Surely you should have referred to the punlished list of offsets before trying to use them, and make your request for extension then in a proper manner. Thank you. We will see about adding the extra data in a future release, but you should understand that at present there is a more immediate need to resolve any outstanding problems which may be discovered with P3Dv5, it being a rather premature release (in our opinion). When we have a version of FSUIPC with the additional data we shall supply you with a test version and ask you to check that all the fields are correct. To this end could you please send me an Email (it is easier then for me to mark it for attention): petedowson@btconnect.com. Note that you'll need to be using a registered install of FSUIPC6. Pete

The sudden decision to release V5 came as a surprise (and an annoyance!) to all Beta testers. Most of us didn't think it was suitable yet for release -- it seems to have been more of a bean counter decision than a technical one. You can tell there are lots of problems with it, just look at the complaints and problem reports. FSUIPC6 would not have been ready for release & sale before the P3D5 release. Worse, the long Easter holiday weekend was in the way of SimMarket being able to set it up. So it would have been wrong to withdraw FSUIPC5 from sale beforehand. John offered to supply free Registration keys to those who purchased FSUIPC since February 1st. That covers you easily, so why the whining? Pete

Really? Are you sure? No GoFlight installer I've seen has ever installed the driver in the Modules folder. The 32-bit version was included in the SDK which was in a folder linked via the Registry, and that was how FSUIPC used to find it. Maybe more recent versions of the GoFlight package included the 64-bit one too, but I really can't imagine it installing into Modules. After all it is a general use driver -- other programs use it too -- it isn't specifically for FSUIPC. And wouldn't the GoFlight installer fail if a Modules folder didn't exist because the User didn't have FSUIPC? For 64-bit I just remember it always being up to the user to get it, and place it next to FSUIPC. That's why we provide a copy in the Download Links subforum (see below). On page 24 the FSUIPC User Guide says: For GoFlight buttons to be recognised you must have the GoFlight module (GFDev64.dll) installed. If you install thel atest version of the GoFlight software the correct DLL may be installed automatically for you, but otherwise download it from the Download Links subforum on the FSUIPC Support Forum. Just place a copy into the FSUIPC installation folder, alongside FSUIPC6.DLL. Pete

What are you talking about? Are you in the right place? What does the subject heading "MPR" mean? That's not particularly helpful, is it? You also posted the twice at the same time. Please don't. I've deleted the duplicate. Pete

What's wrong with sending the "Situation reset" control (65591) via offset 3110? Well, some minor comments first: 1. You don't need to "get the current flight" into 3F04 first. The pathname will already be there, as documented. 2.& 3. You don't need to process it to remove the path. It's better if you leave the path as is. 4. So all you need to do is write the 0 to 3F00. I know loading a flight, ANY flight from anywhere works fine, in both P3D4 and P3D5, because I use it regularly. There's a facility built into WideFS to do just that (also to Save flights and to load Flight Plans). As to why you are ending up with a black screen, i've no idea. Try some logging. Did you at least look at the FSUIPC log to see if it logged the flight loading attempt? After all, all FSUIPC does is pass the request on to the Sim. it's the same as using FSUIPC's optional flght loading menu. BTW it's a bit pointless poating a picture of a black rectangle. Just the words describing the problem would beenough. The black rectangle doesn't help. Pete

You have local pwr = ipc.readUB(0x6C9F) -- bool MCP_panelPowered but 6C9F is not part of the Offsets provided. Where are you getting that information from. Please use the 747QOTSII offsets list provided! As it shows, the last byte provided is at offset 6C9C. Pete

That's most odd. I'm sure there's been no change in the area of COMs support. I can only think it's a matter of a small timing change ... or, just possibly, a change in the Microsoft Libraries we are using. (We updated to a later version of Visual Studio for the new version, matching the change in P3D). We might look to see if it is confined to a COM thread which can be ruthlessly terminated after a tineout of some description. But it might be better to first see if there's some logging we can turn on or add to narrow it down to the particular system call which is not returning. It's late here now, and Sunday isn't a good day for me work-wise, so I'll discuss it with John on Monday and see what we can do. Meanwhile please remain with the use of Task Manager. Pete