Pete Dowson

10 is P3D1-3, 11 was reserved for the 64-bit FSX (which would be FSW, but not (yet?) supported), 12 is P3D4. Oh, and the "U" means unsigned, but in this case it doesn't matter. Pete

"The program" being some FSPS product do some sort of sound? Really? And why is it "losing connection"? Without knowing that, what do you think I can do? The developer needs to tell us why it is losing connection, unlike other FSUIPC applications. Maybe you are using some really heavy add-ons which are occasionally causing pauses in SimConnect and so causing FSUIPC to stop getting any data? hve you tried looking at the FSUIPC lofg file to see if any problems are noted there? There are complete cockpits (like mine) which have many FSUIPC clients needing continuous connection at rates sufficient to keep gauges, dials and displays properly updated (mine is one such), so i know there isn't a problem specifically with "connection". If the program, or your system, has a problem causing loss of client connection, then it won't magically work in a later version without something being done about it. And nothing can be done about something which is not properly explained in the first place. Pete

Okay. Please try FSUIPC 5.103g, now available in the Download Links subforum. Pete

On top of what? If you mean you don't get the translucent window coming up "on top" when you click on a switch or dial it simply means that there is no normal C/C++ type gauge programming support for that action, but most likely just an XML module. Most modern add-on aircraft do not use the gauge tools which are amenable to mouse macros. Even the default aircraft have many gauges which are not built using the standard gauge tools for C/C++ gauges and are therefore not able to support mouse macros. For most XML-based gauges the method is generally to use L:Vars (local panel vairables), but not even those work on all add-ons. it just depends how they are built. Pete

No, neither FSUIPC nor WideFS have no built-in facilities for talking to IOS. You'd probably need to write a Server module to run on the FS PC to connect to your IOS devices. Many folks have done this already for their IOS programs. If you only want GPS data and the program in your IOS device can read standard NMEA sentences on the USB connection (acting now as a standard serial port) then you should be able to configure FSUIPC's GPSout facilities (see User Guide) to provide the correct data for that program from a USB acting as a standard serial device on the FS PC. The GPSout facility also supports AV400 format (and a simple text format, in the case that you are writing your own IOS program). For a WiFi or normal Network connection you'd certainly need a server program, but that could be written as a Lua plug-in rather than a completely separate program. Pete

You have somehow managed to have P3D3 installed into the path which the Registry also says has P3D2. BUT the installer has then assumed it is more likely to be P3D3 than 2 so installs for that. However, the Prepar3D.EXE in that install path is NOT a version 3 Prepar3D! You need to properly uninstall Prepar3D version 2 so that the registry removes that bad entry, and you need to reinstall or repair P3D3, because there's something very wrong with it. Just check the Prpear3d.exe file you are pointing the Installer to so many times. Right click on the EXE and select "Properties", See what version it says. Pete

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