Pete Dowson

It isn't a control, but a Hot Key, configurable on the FSUIPC Hot Keys tab in its Options. Are you saying that doesn't work in FSUIPC6? Pete

Thanks. I hadn't noticed this. I'll see what I can do. Can this occur in P3D too? All my radios (in both my 737 cockpit and my VFR Piper cockpit) are only capable of nnn.nn. This 8.33 change is rather a worry. I do my own drivers for this software, so I can fiddle it a bit, but there's no way I can represent all the 8.33 spaced frequencies reasonably within an xxx.xx display. I might need to resort to the same mechanism I used for NDB's, i.e. "AutoTuneADF: This controls an option to ‘auto-tune’ the ADF radio. If this is enabled, when FSUIPC detects no NDB signal being received it alternates the fractional part of the ADF frequency between .0 and .5 every seven seconds or so. This allows external cockpits built with only whole-number ADF radio facilities to be used in areas like the U.K. which have many NDB frequencies ending in .5." An equivalent facility for COMs might work. But it's quite a lot of work to sort it out in my drivers as well as in FSUIPC. 😞 Pete

Agreed, but come on, -5 is the same heading as +355. Are you not correcting the TRUE heading to get MAGNETIC? If the heading is +2 and the MagVar is +6 ypu'd end up with -4. All you need to do to achieve a range of 0-359 is add 360 if the end result is negative, subtract 360 if it is greater than 360. That offset has existed with the same description since FS98, 22 years ago. You are the first to say it is confusing. Quite honestly, there's so much else that needs to be sorted out and clarified in relation to MSFS that this is really trivial. The signed / unsigned nature of most entries is obvious because of what it is conveying. It only takes common sense, surely? Pete

The most common reason for this, explaining probably 99.9% of such reports, is non-matching name and/or email entries. Folks have lots of ways of spelling their name, it seems. To be sure, cut and paste all three fields from the registration email: name, email and key. Pete

Ah, yes, I think there might be. It would be to do with the Memory-Mapped file request in the fsuipc_open. I suppose, theoretically, that could be extended. But there probably is no justification for more. It's really only that size to allow accumulations of requests rather than a single huge one. I'll edit my earlier post. Pete

You'd only have FSUIPC in focus if you are making some changes there. Surely MSFS has focus all the time when actually attending to your flight. If FSUIPC7 has the focus and then you click on the MSFS menu or ATC window then the focus automatically changes to MSFS. That's how Windows works. Or am i also misunderstanding? Pete

As Pelle shows, the FSUIPC_Read function doesn't know or care what the data is you are reading, nor does it limit how much you read in one go. So you can just define a structure for all the contiguous variables you want, then issue an FSUIPC_Read for the base offset address with the size of the structure as the number of bytes to be read. You could theoretically read the complete offset list into a 65536 byte structure or array, though I think the LIB code restricts this to 0x7F00 (i.e. a little less than half) -- see subsequent posts. Pete

The TCAS facilities in FSUIPC are related to AI traffic, not multiplayer. There's no facilities for the detection of multiplayer traffic unless the program injecting those into FSX also inject them into FSUIPC. For AI the limit would really be around 80 nm if you set 0, as the "bubble" in which they are spawned in is around that radius. You can try setting 80 instead of 0 but I doubt it'll make any difference -- it sounds like it is more something to do with the multiplayer system you are using. Pete

I'm afraid most of the view controls are not currently exported as SimConnect events. It's the subject of long-standing requests to MS/Asobo. I think currently the only way to control views is to assign to key presses instead. I have the same annoyance with my VFR cockpit hardware which needs proper solving because it isn't recognised by MSFS as a device and so has to be configured in FSUIPC. Pete

The documentation is clear. for 0x2A0 is shows: Magnetic variation (signed, –ve = West). For 0x580 it says Heading, *360/(65536*65536) for degrees TRUE. with no need to say signed or unsigned because if you want 0-359 as normal you KNOW to read it unsigned. However, if you are correcting it for Mag Var using 0x2A0 you have to correct the value so calculated to be in the range 0-360 or else you can end up with a negative number, or one greater than 360. Since I assume you must be doing that in any case, it doesn't matter if you read 0x580 as signed or unsigned. As an example, here's a Lua plug-in to show the value obtained both ways: Uhdg = ipc.readUD(0x580) Shdg = ipc.readSD(0x580) ipc.log("Unsigned heading = " .. (Uhdg * 360 / (65536 * 65536))) ipc.log("Signed heading = " .. (Shdg * 360 / (65536 * 65536))) Here are the log entries i got for a single reading: 1038578 LUA.5: Unsigned heading = 194.55367097631 1038594 LUA.5: Signed heading = -165.44632902369 Now the second one is identical to the first when normalised to a 0-359 range because 194.55367097631 = 360 - 165.44632902369 Pete

So, you are okay?

A new install of FSUIPC? Or are you talking about a new PC or a new install of Windows? FSUIPC makes the [Sounds] list by scanning the Registry for registered sound cards. The INI is set accordingly. If the list it produces does not match what you actually have, then the new card(s) are not installed properly and the registry still shows the old ones. Try looking at the Device manage in Windows Settings and see what it lists. The [Sounds] entries are only used by the facilities included in FSUIPC to play sound wave files. Are you using such an add-on, or perhaps a Lua plug-in? If not then what FSUIPC sees sound-wise doesn't really affect anything -- the entries aren't actually used. Pete

Yes, it is. Do the calibration properly first, as if the normal 100% range was desired. Then find the settings file (FSUIPC7.INI in your FSUIPC7 installation folder), and edit the calibration values. Find the [JoystickCalibration] section. in there you'll see the calibration values, in this form: <axis name>=-16128,-2304,-256,15615 These values are those which you set in the Axis Calibration facility in the FSUIPC Options. The last value (15615 here) represents what your joystick axis achieves at max. Just increase that to a number which gives you the results you want. You can edit it whilst FSUIPC is still running. Afterwards press the "Reload" option in the calibration screen so that the change is recognised. Then you can check the change immediately. Pete

On my system it is actually here: E:\WpSystem\S-1-5-21-3630179266-323178033-1425774245-1001\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\UserCfg.opt because I chose drive E: for the MSFS install. However there is a link to it in the C drive too, in the place John mentions. I don't think that Everything program finds it either. In fact on my system most of MSFS is on my E driver but there are the same folders on my C drive all with links to the E folders. Oddly the UserCfg.opt file, though sited in E actually points back to the C drive where the links take me back to the E drive. Very convoluted. Something is very weird about MS-Store installs. It looks lke your installation is similar -- you UserCfg.opt actiually points to: C:\Users\David\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages Perhaps you could try my MakeRunways program (MakeRwys.zip), which also uses a search also involving UserCfg.opt. See if that gives proper results please. If so then my way (if different) might help with John's installer. If not, then I'm not sure how we can proceed without manual intervention. We have been nagging MS/Asobo for proper Registry entries identifying important paths, but no joy so far! 😞 Pete

Yes, unlike the way I used to work with FSUIPC1 - FSUIPC4, with everything in one place, John follows the proper Microsoft Windows conventions where different things go in different places. The Documents would have gone into an FSUIPC section in your regular Documents folder, in the same way that FSX and P3D 'documents' (actually flights and plans, mainly) go into appropriately named folders also in the Documents folder. Pete

I'll need to let John investigate why the installer identified your install as a Steam one rather than MS-Store, but meanwhile, with my MS-store version the BAT file it generated contains this: :: MS Store Installation: start MSFS with FastLaunch cmd.exe /C start shell:AppsFolder\Microsoft.FlightSimulator_8wekyb3d8bbwe!App -FastLaunch Maybe something similar will work for you? Pete

You do realize that a BAT file is a simple Text file, don't you? Right click on it and select "Edit". Then you can actually read what it does -- a few simple steps. BAT files may well load programs containing viruses, but they cannot very well have a virus themselves, in text. Have a look through the text. What do YOU think is "suspicious"? Seems you need to do some feedback to Kaspersky. Maybe it suspects MSFS or FSUIPC7.EXE, the two programs being loaded by the BAT file, but surely not the BAT file itself! See if you can run it on MSFS and FSUIPC7.EXE specifically instead. Pete

FSUIPC's interface for applications has always been free for the user. So don't worry: just install and use. You may want to browse through the User Guide though. It may just be worth purchasing. Pete

Thank you very much for your encouraging and complimentary post. John has been working all hours all this year on this, as well as still developing and supporting FSUIPC6, and I'm sure posts like yours will motivate him even more. Pete

Sorry, I don't understand. Can you explain what you mean in more detail please? Pete

This may be so, but FSUIPC4, the version for FSX was produced in 2006 and one payment gave users free updates and support ever since then. It was only frozen to future development last year. FSUIPC7 for MSFS has more in common with FSUIPC5 and FSUIPC6, the 64-bit versions, which themselves were a great deal of work, and the difficulties of the version of SimConnect implemented in MSFS made FSUIPC7 even more. I'm really more surprised that John has offered a discount at all. Not only that but the main price is substantially less than I expected (compare to previous version prices). On top of this, the facilities offered so far by the MSFS version of SimConnect fall well short of what was provided in FSX, let alone P3D, but because MS/Asobo seem to have pledged ongoing development (unlike FSX which died in development terms within 18 months) there will be continuous ongoing development too of FSUIPC7. Would you rather a discount on initial cost but an ongoing payment for updates? It isn't our policy to do such things. For the initial payment you automatically get the ongoing improvements and facilities. If you don't need or want to use the user facilities offered by FSUIPC then there's no need for you to pay for it in any case. Evidently you and the previous poster don't actually want or need to use those facilities, so you wouldn't buy it in any case. There's no need to post complaints. Pete

This sort of action was always local to the gauge in previous sims. After all, none of the actions relate to anything in the system, only what that gauge is showing. I suspect it is no different in MSFS as there's no need for it to be. The only answers for these normally was L:Vars or, more usually, mouse macros -- neither of which are possible at present with MSFS. Pete

Can you explain this please? By email petedowson@btconnect.com. Unless the following explains your problem: The structure is read directly into the FSUIPC offset area. BUT it may be split. There were a number of developments of the PMDG aircraft in which their structure was extended. That would be okay - it would be split into a different offset area. But, worse, it had more data inserted in the middle. That meant some manipulations to retain compatibility -- moving those additions to the end of the extension area. There have been at least three different layouts for the PMDG 737 if you include the NGu and NG3 versions and the updates. A structural approach can still work, but not just in one structure as in the PMDG SDK. It has to be split into the separate ones matching where the data had to be split. FSUIPC is all about compatibility. That's its purpose, its raison d'etre. And it takes a lot of effort! Pete

Hi Pelle, Okay. Decoded runway surfaces now correct in MakeRwys 5.01, now released. Pete

Hi Pelle I found out how to convert the runway surface GUIDs into the normal type names. So i'll make an update to MakeRwys with that included. Pete