Pete Dowson

I amended my previous post. The full UNC parh for the plan is provided in offset 0130 when one is loaded in P3D4. So please check this in your system. Pete

I've split your question into a separate thread as it really needs its own title. I hope you manage to find it. This delay, actuially about 85 seconds here, but in your case this is making it longer: The main delay here occurs on one PC but oddly not on another. I know how to stop it -- remove the facilities for all of the PMDG aircraft offsets -- but of course folks are using these. Up until your report, rather hidden in another thread originally, I thought I was the only one with this problem, so i put it down to something else wrong on my PC 9which is may well be, of course), but didn't spend any time trying to work out what it was. Your report makes it a different matter altogether now. Because whilst in this delay FSUIPC itself gets not calls at all, from any part of Simconnect, and is just stick waiting for one, I'm sure it is some odd problem in P3D4 itself, but as it seemed to only affect me I've not yet reported it to L-M. I shall now have to gather evidence and details to get them to look at it. Meanwhile I will add options into the INI file for disabling each of the three PMDG faciliyties (separately) -- i.e. 737NG, 777 and 747. Then, if you use none of those you can disable them to stop this delay occurring. Maybe only enably one, as needed, will help. I will also try to find a way to specifically identify when the aircraft are loaded, and so enabling them then, but there are such a variety of names (and folds can rename them in any case) that this is not so easy. Look out for an update in the Download Links subforum withing the next day or two, in which i shall do the first option, i.e. make the PMDG stuff optional by user parameters. Pete

The sim is unable to show anything in its Window whilst it is in Dialog Mode, and whilst you are in the FSUIPC Options you are in that mode. That is why there is a "black screen"! To set up Mouse Macros (following the instructions in the user guide) you start Macro creation mode in the Options, and give the name of the macro file you want to create, when you OK out of the options. That will return you to normal flight mode in the Sim, but in Macro Creation mode. When you've done creating all your macros you go back into the options to tun the mode off and finish the macro file. This is all explained in the documentation, with pictures! Pete

FSUIPC does not and never has supplied any such plan data. It only supplies the name of the currently loaded plan, if one is actually loaded in the Sim. I don't know where FlightKeeper gets its plan information from. That's what you need to check. Plans are normally in the appropriate Documents folder. Is that where yours are? Are you loading one into P3D before running FlightKeeper? FlightKeeper may be getting the full pathname to the currently loaded PLN file from the offset in FSUIPC -- offset 0130. Use the Monitor option in the Logging tab in FSUIPC options to log that value as an AsciiZ type, then you can see what FlightKeeper should be loading. [LATER] The Monitor log entry for the offset shows only part of the path actually provided -- just the first 32 characters, but it does show the corrent lenght n [] parentheses. So I think it might just be down to how FlightKeeper gets the Plan. Pete

Why are you deleting your registration each time you update FSUIPC in any case? You shoulvn't delete anything, just run the updated Installer. Pete

The installer can be run from anywhere in the same PC as your P3D installation. It absolutely does not care where it is -- it doesn't refer to its own location at all, except that it does store a copy of its log file there as well as in the target Sim's Modules folder (but it doesn't even need to know where it is to do that). It does need access to the Registry and, of course, to the P3D folders. Running it in Admin mode will ensure that is possible, though normally Windows will automatically run anything with "Setup" or "Install" in the name in that mode -- as it does with ".msi" files. The crash with error code C0000005 is an access violation, and from the address in the crash details it is somewhere in a standard Windows library, one compiled into the Installer and which works for everyone else. To understand where it might be in my own code I'd need to see the Log file it produced so far, so I can see what it was attempting to do at the time. The log file will be in the same place as the Installer program itself. The Installer for FSUIPC5 is a 32-bit program, and in fact is identical in every way to the Installer for FSUIPC4 and its code has not been changed at all except that it looks in a slightly different place in the Registry to get the P3D path, and of course the content of what it installs into the Modules folder is not identical, being the 64-bit versions. There's no difference between the installer for 5.102 and 5.103 except for the FSUIPC5.DLL module. Going back to your original problem, there are two possible reasons there might be two copies of FSUIPC loaded: 1. The previous session of P3D (or FSX or FSX-SE) had not fully terminated. It might not be listed in the applications list in Task Manager, only in the Processes list. This is the most common problem. There are quite a lot of reasons why previous sessions do not always disappear completely. 2. It is being loaded twice by SimConnect. That would need checking in the DLL.XML files. (Note that there are now TWO of those, on in the Users Roaming AppData folder and one in the main ProgramData folder. Having it in both or twice in one would be the "already running" error when the second was loaded). Pete

The same axis cannot be assigned separately to more than one action. You can assign up to 4 different or similar actions to the one axis, but all that it done on the same tab, in the 4 spaces shown for them on the left. I think you must mea that when you move the rudder axis (say), one of the brake axes is showing instead of the rudder, or vice versa. If this is what is happening it is because you are (maybe unintentionally) operating a little brake movement when pressing the rudder. If this is so, you need to put your foot lower on the pedal to avoid the brake altogether, or calibrate the brake axes with a dead zone at the start of movement. If the axes are causing input values to change without you actually touching them, then that jitter shows a dirty pot or maybe a faulty power supply. FSUIPC can be told to simply ignore an axis, temporarily -- that's what the ignore button is for. Possibly, or its programming, but more likely one of the things I state above. I think it much more likely to be down to what you are doing. Please do read the relevant sections of the FSUIPC User Guide very carefully, and expecially the steps to good calibration. Pete

No, WideFS does not natively support axes, only buttons. You could do it by writing a Lua plug-in. But the reason it isn't supported is that trying to control a flight with even the small delay your network might impose is really not good. You should have main control axes on the sim PC Pete

You supplied two copies of the Install LOG which wasn't needed, and an FSUIPC5.LOG which was abruptly terminated before P3D4 had even got to the "ready to fly". stsge. Please, in future, when supplying logs, ket the sim load properly then, as you wish, close down. The full log is only made after you have closed down. But the JoyScan file also confirmes that your PFC pedals aren't seen. It's as if they are not connected. Are you sure they are working? You still haven't explained what you meant by "conflicts" at all. I'm still not understanding what problem you are really reporting. Pete

No idea. I don't even understand what you could possibly mean by a "smoother" save". Is the autosave jerky in somne way? How? How can you tell? It's effectively paused in any case when PMDG take over. The call FSUIPc makes into P3D is identical to that made when you save manually. The only thing that's different is that FSIOPC provides the filename. Pete

Yes, I agree. Easier for maintenance too. Pete

Good. Should I make the same changes to FSUIPC4? Seems strange that this only occurred with FSUIPC5. The code involved for the whole of the Lua facilities is identical. Well, apart from the 64-bit COM handle business, resolved earlier. Pete

One last test. Please try this: FSUIPC5103f_T4.zip I've removed the extra log lines, but inserted small delays which should amount to the equivalent -- but only for those preceding the call tghe the loadfile function which exeutes the fopen. Let me know please. Pete

I don't think it's really a bug, just a misunderstanding of the way it works. The description is not as clear as perhaps it should be. as you can see from the extracts I gave. This works, though: "%05.2f" So, in your original "%02.02f" there are two bugs: The first 02 tells it the total width should be 2, and you need 5, and the second 02 should just be 2 -- the leading zero there seems to make the first field width specifier null and void. I think I've always used it correctly in the past -- perhaps more by luck than applying proper knowledge. Pete

I just looked up the formal definition of the printf, sprintf format string, and there are two relevant parts: for the 'f' specifier: Signed value that has the form [-]dddd.dddd, where dddd is one or more decimal digits. The number of digits before the decimal point depends on the magnitude of the number, and the number of digits after the decimal point depends on the requested precision, or six by default. and later, for the 0n prefix: If width is prefixed by 0, leading zeros are added until the minimum width is reached. If both 0 and - appear, the 0 is ignored. If 0 is specified for an integer format (i, u, x, X, o, d) and a precision specification is also present—for example, %04.d—the 0 is ignored. I checked the source, and the Lua string library does actually use sprintf, the C library function, passing it the complete format string for each component, i.e. %02.02f in the case we are talking about. So it isn't Lua, it is the Microsoft C library. The leading zero business apparently only applies to fixed point formats, like %d. Because of the wording above I would have thought that &05.2f would give 01.23 in order to make the result 5 characters long. But, no, the 05 makes no difference it seems! I've been using this stuff for 25+ years. You'd think I would have discovered stuff like this long ago! :-( Pete

That is rather odd. Here's the description of the string.format function ffrom the Lua websitr: string.format (formatstring, ···) Returns a formatted version of its variable number of arguments following the description given in its first argument (which must be a string). The format string follows the same rules as the ISO C function sprintf. The only differences are that the options/modifiers *, h, L, l, n, and p are not supported and that there is an extra option, q. The q option formats a string between double quotes, using escape sequences when necessary to ensure that it can safely be read back by the Lua interpreter. I wonder if it was buggy in version 5.1, which is the one built into FSUIPC (the current release lua version is 5.3). Pete

That is set by disabling controllers in the Options - Assignments section of the FSX options. So eiither way -- if you are assigning buttons and axes in FSUIPC. Note that you can still Calibrate axes in FSUIPC even if you don't use it for axis and button assignment. Pete

No, there has always been many reports of problems with V3 as well, on all PMDG ircraft. You can try increasing the timeout (SimconnectStallTime) in the [General] section of the FSUIPC5.INI file. Max is 20 (secs) Default is 1 or 2. A longer time would possibly stop FSUIPC re-initialising its connection with SimConnect which would make things worse. There will stil be an effective freeze whilst PMDG's saves do their thing. Whether they are still too long for your applications I wouldn't know, but if so the only solution, apart from not using Autosave, is to make the programs more tolerant. Incidentally, I've already implemented the longer timeout which is automatically applied IF FSUIPC detects a FlightSave occurring. That's in 5.10e already released as an Interim update in the Download Links subforum. The only doubts I've got about that is whether, by the time SimConnect tries to notify FSUIPC the freeze is already underway. Of course if that is the case I could deal with it for FSUIPC's own AutoSave (since it is the instigator) but it wouldn't work for the other autosave facilities which are available. However, I will add it into FSUIPC for the next update. Hi Luke: whatwas the purpose of the Log you sent, separately? Pete

PMDG are aware of this problem with the 747 and are working to fix it. You need to keep an eye on the PMDG forum. It is not an FSUIPC matter, PMDG have assured me of this. Pete

Just ZIP them! They are all simple Text files and ZIP up very small. Pete

Well, the only difference is those extra log lines, which were intended to be temporary. They must affect the timing but it is a very small difference. Thay's a log of extra log lines each time a Lua is loaded: 90578 RunLua just called: Filename "C:\P3Dv4\Modules\linda\system\init.lua" 90578 About to Create the Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda\system\init.lua" 90578 Create Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda\system\init.lua" 90578 Inside the Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda\system\init.lua" ... 90578 Inside the Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda\system\init.lua" I might have to do a process of elimination on those, or just substitute a delay instead of all of them. But first, because it is presumably because of the Kill action overlapping the fresh load (?) I will double check to make sure the LAST thing the Kill sequence does is free the table entry so it isn't used prematirely by the new thread. It's the only thing I can thing might be occurring. All that must be down to assumptions about your / usage made in other Lua program in your portfolio, as I always only ever use \ with never such problems. Never mind anyway. We know it isn't that. It was only a straw to be clutched! ;-) Pete

All that does is re-scan the devies. It's nothing to do with the assignments. The usual reason for this is that the device is "going to sleep", maybe as a result of Windows power management. Check the Windows Device Manager, USB section, and make sure Power Management is turned off for all USB Hubs. (Right click on each for Properties). I'm not sure what you intended to convey with the LOG you supplied, but that appears to show the rudder device responding fully. You operated the Right Brake pedal well enough, then later the rudder itself, and all within the first 7 or 8 seconds of the system being "ready to fly". Then later the Left brake axis, but still within 26 seconds. All without visiting the Options at all! Pete

As does the one I included in the FSUIPC ZIP file. Is the "new" one a later version? The one I supplied was 2.2.8.0, as shown in my Logs along with the devices I could test here: 174269 Using "E:\Prepar3D v4\Modules\GFDEV64.DLL", version 2.2.8.0 174269 GoFlight GFP8 detected: 2 devices 174269 GoFlight GFT8 detected: 2 devices 174269 GoFlight GFRP48 detected: 2 devices Do you have more devices tested? Maybe check the FSUIPC5.LOG for similar lines to the above? Pete

There is absolutely no relation between the two different simulators. Which are you having problems with, P3Dv3 or P3Dv4? And what exactly do you mean by "conflicts"? What is all this switching between P3Dv4 and P3Dv3 got to do with anything? It makes no sense Talk about them separately. They are separate, not related! If you are assigning in FSUIPC you must disable controllers in P3D. It is not enough to "delete axes", they will be picked up again. And if you do things like delete FSUIPC INI files then how are you going to show me what is wrong? You supply a log only for FSUIPC5, not FSUIPC4. Does that mean all is good in P3Dv3? If so you should be able to use the FSUIPC4.INI from P3D3 in P3D4 after renaming it to FSUIPC5.INI. And if you show me the other files for both sims I would be able to spot any responsible differences. The log shows just three devices actually connected: 796 Device acquired for use: 796 Joystick ID = 2 (Registry okay) 796 2=vJoy Device 796 2.GUID={F9721F10-96BD-11E6-8002-444553540000} 796 Device acquired for use: 796 Joystick ID = 1 (Registry okay) 796 1=PFC Cirrus Yoke 796 1.GUID={352AD440-9656-11E3-8001-444553540000} 812 Device acquired for use: 812 Joystick ID = 0 (Registry okay) 812 0=Arduino Leonardo 812 0.GUID={DE67F590-3F2E-11E7-8001-444553540000} I don't know "vJoy". It says it's a "virtual joystick" made by Shaul Eizikovitch. I suppose you know about this? It appears to provide 8 buttons and 6 high resolution axes. You do have a PFC Cirrus Yoke. I assume this is one of the later USB versions which looks like a joystick type device to Windows too? There's no PFC rudder connected. The only other device is an Arduino. I have no idea what you have or have not assigned as you didn't supply the INI file with your settings. And I have no idea what your "conflicts" are because you don't say. Next time, please also supply your settings (the INI file) and also the file called FSUIPC5.JoyScan.csv (or FSUIPC4.JoyScan.csv for P3D3), as well as describing what your problem is, and in which simulator. Pete

Whether buttons are pushed or not is probably irrelevant. Are there hardware-related programs or drivers running when you Kill the thread responsible for them? As this is the only thing I can think of which might be able to cause the crashes. I'm sure there not related to the problem we are investigating. On that, here's my final test module, with logging as close as I can get t where it says there's a "" filename (or did do when I added that log line into the base Lua code, now removed). After this test I give up. FSUIPC5103f_T3.zip I thought you were out all day today? Pete