Luke Kolin

There's a reason you haven't found anything - PHP is a language for web servers, not clients. To be honest, if you don't have the client-side development expertise to do it yourself, you're probably best off with some sort of pre-made flight recorder. You can always take a peek at simFDR - it should do what you want, except no P3Dv4 support yet. Development has been on a hiatus but I should probably get it up to speed with modern sims. Cheers! Luke

It looks like a character encoding issue. Cheers! Luke

4.60 is a very old version of FSUIPC. Cheers! Luke

It's not needed, but a 32-bit app will automatically read from the WOW32Node unless you explicitly force it to read from the 64-bit registry. I don't know what will happen if you attempt that call on a 32-bit version of Windows, but that's something the installer can check for and avoid. Cheers! Luke

Looks like windows is doing that behind the scenes.... Cheers! Luke

Sorry, just to show that there wasn't anything untoward going on. I need to step out for a bit; I'll fire up the PMDG777 and set the autosave interval to something short and see what happens when I get back. Cheers!

********* FSUIPC5, Version 5.103e (3rd July 2017) by Pete Dowson ********* Running inside Prepar3D v4 Module base=7FED2D00000 Windows 7 Ultimate 64 Bit with SP 1.0 reported as Build 7601 (OS 6.1) Prepar3D.exe version = 4.0.28.21686 Checking the Registrations now ... User Name="Luke Kolin" User Addr="luke@kolin.org" FSUIPC5 Key is provided WIDEFS7 not user registered, or expired 0 System time = 04/07/2017 15:13:32 0 FLT path = "C:\Users\luke.POLARIS\Documents\Prepar3D v4 Files\" 15 ------ Module Version Check ------ 15 acontain.dll: 4.0.28.21686 15 api.dll: 4.0.28.21686 15 controls.dll: 4.0.28.21686 15 fs-traffic.dll: 4.0.28.21686 15 G3D.dll: 4.0.28.21686 15 language.dll: 4.0.28.21686 15 sim1.dll: 4.0.28.21686 15 visualfx.dll: 4.0.28.21686 15 weather.dll: 4.0.28.21686 15 window.dll: 4.0.28.21686 15 ---------------------------------- 15 FS path = "D:\Program Files\Prepar3D v4\" 140 ---------------------- Joystick Device Scan ----------------------- 140 Product= CH PRO THROTTLE USB 140 Manufacturer= CH PRODUCTS 140 Vendor=068E, Product=00F1 (Version 0.0) 140 GUIDs returned for product: VID_068E&PID_00F1: 140 GUID= {8AC6B6E0-DEC1-11E3-8001-444553540000} 140 Details: Btns=19, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U0,V0,X245,Y242,Z228 140 Product= CH PRO PEDALS USB 140 Manufacturer= CH PRODUCTS 156 Vendor=068E, Product=00F2 (Version 0.0) 156 GUIDs returned for product: VID_068E&PID_00F2: 156 GUID= {8AC6B6E0-DEC1-11E3-8002-444553540000} 156 Details: Btns=0, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U0,V0,X255,Y255,Z254 156 Product= CH FLIGHT SIM YOKE USB 156 Manufacturer= CH PRODUCTS 156 Vendor=068E, Product=00FF (Version 0.0) 156 GUIDs returned for product: VID_068E&PID_00FF: 156 GUID= {907D8530-E044-11E3-8001-444553540000} 156 Details: Btns=12, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U255,V255,X255,Y255,Z255 156 ------------------------------------------------------------------- 156 Device acquired for use: 156 Joystick ID = 2 (Registry okay) 156 2=CH PRO THROTTLE USB 156 2.GUID={8AC6B6E0-DEC1-11E3-8001-444553540000} 156 Device acquired for use: 156 Joystick ID = 1 (Registry okay) 156 1=CH PRO PEDALS USB 156 1.GUID={8AC6B6E0-DEC1-11E3-8002-444553540000} 156 Device acquired for use: 156 Joystick ID = 0 (Registry okay) 156 0=CH FLIGHT SIM YOKE USB 156 0.GUID={907D8530-E044-11E3-8001-444553540000} 156 ------------------------------------------------------------------- 156 LogOptions=00000000 00000001 156 SimConnect_Open succeeded: waiting to check version okay 156 Opened separate AI Traffic client okay 2839 Running in "Lockheed Martin® Prepar3D® v4", Version: 4.0.28.21686 (SimConnect: 4.0.0.0) 2839 Initialising SimConnect data requests now 2839 FSUIPC Menu entry added 2839 ... Using Prepar3D with Academic License 2855 C:\Users\luke.POLARIS\AppData\Local\Lockheed Martin\Prepar3D v4\Prepar3D_Default.fxml 2855 D:\Program Files\Prepar3D v4\SimObjects\Airplanes\IRIS Raptor Driver\Raptor.air 39562 D:\Program Files\Prepar3D v4\SimObjects\Airplanes\PMDG 777-200LR\B777-200LR.air 68515 Aircraft loaded: running normally now ... 68515 User Aircraft ID 1 supplied, now being used 69030 System time = 04/07/2017 15:14:41, Simulator time = 10:12:36 (08:12Z) 69030 Aircraft="PMDG 777-206LR KLM Royal Dutch Airlines (Fictional)" 75972 Starting everything now ... 76066 ASN active function link set 76066 Ready for ASN WX radar 76393 Weather Mode now = Theme 77314 Advanced Weather Interface Enabled 688916 Sim stopped: average frame rate for last 620 secs = 14.5 fps 688916 Max AI traffic was 10 aircraft (Deleted 0) 4662526 **** Restarting traffic scanning due to non-reception **** 31179998 Sim stopped: average frame rate for last 30450 secs = 27.7 fps 31179998 Max AI traffic was 16 aircraft (Deleted 0) 31884405 Sim stopped: average frame rate for last 553 secs = 16.9 fps 31884405 Max AI traffic was 16 aircraft (Deleted 0) 31885653 === Closing session: waiting for DLLStop to be called ... 31901783 === DLLStop called ... 31901783 === Closing external processes we started ... 31902781 === About to kill any Lua plug-ins still running ... 31902922 === Closing global Lua thread 31903936 === About to kill my timers ... 31904139 === Restoring window procs ... 31904139 === Unloading libraries ... 31904139 === stopping other threads ... 31904139 === ... Button scanning ... 31904232 === ... Axis scanning ... 31904326 === Releasing joystick devices ... 31904326 === Freeing macro memory 31904326 === Removing any offset overrides 31904326 === Clearing any displays left 31904326 === Calling SimConnect_Close ... 31905043 === SimConnect_Close done! 31905043 === AI slots deleted! 31905043 === Freeing button memory ... 31905043 === Closing my Windows ... 31905043 === Freeing FS libraries ... 31906073 === Closing devices ... 31906073 === Closing the Log ... Bye Bye! ... 31906073 System time = 05/07/2017 00:05:18, Simulator time = 12:27:01 (16:27Z) 31906073 *** FSUIPC log file being closed Minimum frame rate was 8.8 fps, Maximum was 31.8 fps Average frame rate for running time of 31635 secs = 27.3 fps Maximum AI traffic for session was 16 aircraft Memory managed: 13238 Allocs, 13237 Freed ********* FSUIPC Log file closed ***********

Thomas/Pete - I think the situation is more complicated than that. I built an autosave feature into Delta/Air France Virtual's ACARS software because I believe strongly in the feature and it's tied into the actual flight recording - I won't persist the data on my end until the flight has been saved on the client. One thing that I do a little differently is that I apply a different ratio to the autosave interval depending on the payware aircraft in use. As an example, I save flights on the PMDG777 every 9 minutes and don't do so when within 30-40 miles of either airport. I can regularly do 8+ hour flights without running into issues with SimConnect disconnecting. I wonder whether there isn't something in the PMDG flight saving code that leaks memory or does something that makes each save incrementally longer? My guess is that the problem is exacerbated by the number of saves, and each save is getting slower and slower. I expect someone with a PMDG777X could test this by turning on autosave and setting the interval to something low like 5 seconds and see when things kicked in. And Randy, FWIW I have seen numerous reports of this problem in P3Dv3 and FSX. It's not new to P3Dv4. Cheers! Luke

I'm not sure if this is helpful or matches well with the code of FSUIPC5, but I think it's acceptable for you to only make the SimConnect requests for the PMDG aircraft if requested by the user. I'm thinking along the lines of an internal 1 or 2-byte read/write offset that we could set to trigger reading of the particular offsets we are interested in, with a zero for disabled. Each specific aircraft would have a different value, so we could check what was being read. When the AIR file changes, you could disable the polling and set the offset back to zero. I think this would work as well for home cockpit builders; they could have an aircraft-specific LUA script that would write to the necessary offset on startup/shutdown. I really appreciate the work you do here abstracting away these aircraft; I know I could do my own SimConnect requests but SimConnect in a C# world is not a breach I am anxious to charge into if I do not have to. Cheers! Luke

Oh, and here's the log. There's an unclean shutdown because P3D hung (I suspect because the monitor got turned off, but I need to test further). Cheers! FSUIPC5.log

Pete, I'm running P3D 4.0.28.21686 as well as FSUIPC 5.103b. I've noticed that when running the PMDG 777 I'm still not seeing the aircraft-specific offsets getting populated. Apologies in advance for a potentially superfluous question, but am I correct in assuming that this version of FSUIPC is making the necessary calls to SimConnect to populate this data, and the hotfix includes the fix in SimConnect to reliably send it? I vaguely remember that there was a control or offset one could use to trigger FSUIPC to reconnect to SimConnect which may be a potential workaround. If nothing else, if it exists I'd like to try it. Reports from my users suggest that the problem I describe above is intermittent and may be due to a race condition and a reconnect might fix things temporarily. Cheers!

Out of curiosity, does the aircraft.cfg have the payload stations numbered correctly? Is the error valid? Cheers! Luke

Apologies - my spam filter has gotten rather aggressive in the past 4 weeks. I fear it's a little out of my control as it's a Bayesian filter that is trained by the other users of my mail server. I sent it over just in case something was different and it never hurts to have a copy just in case - I have a challenge supporting PMDG aircraft that I don't own (specifically the 744; I can't justify buying it for $100+ when I have the previous version mostly working in P3D. Anyways, thanks again for your great work. SimMarket has a few of my dollars for FSUIPC5. Cheers! Luke

That's fair. If you need someone to give it a quick smoke test I'd be happy to. On a side note, did you get the second copy of the header file I sent? I zipped it up in case there was a picky mail filter. Worst case I can attach it here. Cheers! Luke

You've got mail. The files look identical between P3Dv3 and P3Dv4. let me know if I can help further. Cheers! Luke

Remember that the V in VAS stands for "virtual" - it doesn't monitor how much of your physical RAM is unused. Cheers! Luke

I'd be delighted to. The alloc/free count is what I referred to here: ... but it looks like expected behavior on the FSUIPC side so I'll reach out to PMDG. Thanks! Luke

Second issue report - I'm not seeing a value for a specific PMDG777 offset when using FSUIPC5. I check offset 0x6C1D to get the PMDG equipment type code as a sanity check to ensure that I'm getting proper PMDG data. In P3Dv3 using FSUIPC 4.967, the code is non-zero (4) and it correctly detects the -200LR. When using FSUIPC5 and the same aircraft in P3Dv4, the offset is zero. I've checked my 777X_Options.ini file and the EnableDataBroadcast=1 setting is set under the SDK section, so it should be available to FSUIPC. Is this functionality enabled in P3Dv4, and how can I help determine whether the data is is making it to FSUIPC? (FWIW, it looks like the alloc/free count doesn't match here either, but I'm not getting a P3D crash on shutdown like I do with v3). Cheers! Luke FSUIPC5.log

This is the first of two issue reports - I just upgraded the P3D to the latest P3Dv3/P3Dv4 version, and I'm getting a consistent crash in PMDG_777X_2.dll on shutdown. Ordinarily, I'd report straight to PMDG, but I'm seeing the following issue in the FSUIPC log at the end: 89638 === Closing session: waiting for DLLStop to be called ... 114973 === DLLStop called ... 114973 === Closing external processes we started ... 115971 === About to kill any Lua plug-ins still running ... 116127 === Closing global Lua thread 117125 === About to kill my timers ... 117328 === Restoring window procs ... 117328 === Unloading libraries ... 117328 === stopping other threads ... 117328 === ... Button scanning ... 117422 === ... Axis scanning ... 117531 === Releasing joystick devices ... 117531 === Freeing macro memory 117531 === Removing any offset overrides 117531 === Clearing any displays left 117531 === Calling SimConnect_Close ... 118124 === SimConnect_Close done! 118124 === AI slots deleted! 118124 === Freeing button memory ... 118124 === Closing my Windows ... 118124 === Freeing FS libraries ... 119122 === Closing devices ... 119122 === Closing the Log ... Bye Bye! ... 119122 System time = 10/06/2017 11:12:29, Simulator time = 11:11:21 (16:11Z) 119122 *** FSUIPC log file being closed Minimum frame rate was 24.3 fps, Maximum was 31.4 fps Minimum available memory recorded was 32768Mb Average frame rate for running time of 47 secs = 28.2 fps Average weather filter write interval in that time = 831.2 msecs Maximum AI traffic for session was 9 aircraft Memory managed: 71 Allocs, 70 Freed ********* FSUIPC Log file closed *********** Note right at the end, we're got a mismatch between malloc() and free() counts. Do you think think this may be the cause, or shall I file a ticket with PMDG? This is FSUIPC 4.967, on Windows 7 x64. FWIW, I see the same mismatch in P3Dv4 with FSUIPC5 and the PMDG 777. Cheers! Luke FSUIPC4.log

Pete, scenery order should be orthogonal to using the new add-in configuration model. I had the same worries as you when I converted FreeMeshX to a single XML file; I was concerned because the patches need to be above the other entries in the scenery library - this doesn't change at all. I define all of the directories using an add-on.xml file, then they appear in the scenery library and I can order them just as before. It's really helpful when sceneries have multiple directories to import, the author can specify them all in the add-on.xml. As you mentioned, you like to keep things "simple and self-contained". I would suggest that this model achieves that goal. Rather than modifying common configuration files such scenery.cfg or dll.xml (and running the risk of stomping on others or getting stomped on) you create your own add-on.xml in its own directory and P3D takes care of the rest. I remember in the old FS9/FS8 days we would just put FSUIPC.DLL in the modules folder; to disable or uninstall it. That wasn't possible in the FSX/ESP world, but today you can achieve the same thing via a folder in MyDocuments\Prepar3dv4 Addons\ and put the DLL and add-on.XML there. Just delete the folder to uninstall. I don't want the discussion about XML and Unicode to detract from things, but I will make two observations. First, this (mostly) unilingual American in the Deep South can appreciate the need for characters outside the standard ASCII (or even Roman) alphabet. I cannot speak to how elegant Unicode is to work with only that much of its cruft is abstracted away from me via the languages I use. Much like, I expect, most of the cruft in x86 assembler is hidden away by C. Remember how you could only do pointer references using DS:SI and ES:DI, only CX could be used for SHL/SHR instructions? Yech. But it's hidden away from us, quite thankfully. XML really is the same way - if you're generating it yourself, you're doing it wrong. It seems like There's enough gotchas when dealing with things like encoding, namespaces, escaping special characters, etc. that you really should be using a tested and validated library to generate the XML for you. No matter what environment I'm in, that's what I do and it cuts down on problems. You didn't write your own LUA interpreter, did you? ;) I have a dim view of most programmers in the FS space. You're one of the good guys - you're responsive, open to suggestions and your turnaround times are absolutely amazing. What I love most of all about you is your attitude when one of our older community members comes in convinced that they cannot understand computers based on their age - your optimism and refusal to let age be an excuse is a great inspiration. I've been dealing with computers since I first fell in love with making machines do what I wanted them to in the early 1980s. I'm now been writing and publicly distributing code for almost a third of a century, so while I've not stated in the punch card era I am old enough to see the dramatic changes we have gone through, and getting old enough to be more and more resistant to novelty. I need to catch myself from time to time, and recognize that higher-level constructs allow me to solve higher level problems rather than focusing on the logistics of the mundane. Again, you can do as you see fit but consider this my gentle nudge - the new layout may actually be more compatible with your philosophy than you realize and may make your life simpler, not harder. Thanks again Pete for making our hobby so great! Luke

Thanks again Pete for your great work with FSUIPC5. Looking forward to the purchase. One interesting aspect of P3D for me has been the way that it handles add-ons; Umberto from FSDT was talking about it on AVSIM earlier this week and his scenery utilities when migrating content to P3Dv4 use it. Essentially, each add-on defines its contents in a separate XML file allowing it to be easily enabled/disabled, etc. After installing FSUIPC5 into my P3Dv4 setup, I took the liberty of disabling FSUIPC5 in the global DLL.XML file and instead did the following: Created an FSUIPC directory in the $MyDocuments\Prepar3D v4 Addons directory. Created an add-on.xml file with the following content: <SimBase.Document Type="AddOnXml" version="4,0" id="add-on"> <AddOn.Name>FSUIPC5</AddOn.Name> <AddOn.Description>FSUIPC v5</AddOn.Description> <AddOn.Component> <Category>DLL</Category> <Path>D:\Program Files\Prepar3D v4\Modules\FSUIPC5.dll</Path> <DLLType>PDK</DLLType> </AddOn.Component> </SimBase.Document> Loads just fine; the directory of course will differ based on the install. I like the new install mechanism for modules and scenery; it allows better control over what to enable/disable. Something to consider for the installers going forward? It might make your life simpler as there's no risk of stepping on the toes of another add-on. Cheers! Luke

You cannot load a 32-bit DLL into a 64-bit process. This is a Windows (probably x64 in general) limitation. Cheers! Luke

False alarm (as you probably suspected). I think I had the axes double defined as both profile-specific and general. Hope you had a good holiday! Cheers! Luke

Another data point - it definitely looks P3D-specific. I am unable to duplicate in FSX, but there are a few differences between the configs. Cheers! Luke

Noticed something with the recent versions of FSUIPC - it looks like my axes are getting "crossed" between the yoke and the spoilers. I was using FSUIPC to control the spoiler axis (on my CH yoke), using regular P3D axis mapping for the elevator and throttles. I noticed that when I move the yoke side to side and engage the ailerons (in the air or on the ground) the spoiler lever will move. I see this whether or not the spoiler axis is mapped using FSUIPC, P3D or even not at all. If I disable FSUIPC in the DLL.XML, this does not happen. Pete, have any of the joystick changes potentially caused spurious inputs on the spoiler axis, or some other axis? This seems a little odd and I doubt there's enough information for you to debug, so I'm interested in any further details you would need form me. I've noticed this in both the QW757 and the LDS767 in P3D; I can check FSX and other aircraft for you if you'd like. Cheers!