Pete Dowson

There are no problems shown in either log. But the filemon log also only shows a period of just under 4 seconds altogether, so it really shows nothing significant. If you enably filemon logging for all of the FSX activity you'll find lots of non-FSUIPC4.INI access too. Each of the sequences of "IRP MJ CREATE" to "IRP MJ CLOSE" are, I believe, cause by a single "GetPrivateProfileString", one of the standard Windows API's to read parameters from CFG and INI files. FSUIPC4 does no file I/O on the INI file directly. The entire 6399 lines in the log you provided therefore contains just 914 such reads, which are probably scans for any assignment parameters in the many possible sections in the INI. I'm not sure what it is that is worrying you. Your INI file is remarkably short, of course, because you are not user-registered. Possibly I should remove some of the INI file interrogation for non-registered users. I will certainly consider that, but it hasn't been a problem in any version of FSUIPC over the last 7 years or so, and I'm not sure what you think the problem is right now. Incidentally, version 4.072 is no longer supported. Version 4.08 was released last week and there's already an update to 4.081 available above. If you have any more comments or logs to offer, please do so with 4.08 or later installed. Regards Pete

If you have problems with SimConnect causing a reconnection every few seconds then this will cause FSUIPC to also see an aircraft reload every few seconds, and each time that happens the INI file will be scanned for aircraft-specific settings. That is the only way I know of which could cause what you are suggesting. And if this was happening the clearest indication would not be in Filemon logs but in the FSUIPC4 log itself. There is absolutely no access to the INI file by FSUIPC4 excepting in the circumstances I already expounded. If you have more information and evidence please provide it, but I think you are looking in the wrong place. Try the FSUIPC4 Log and do a Simconnect log. Regards Pete

It's an elapsed time, but I am not sure when it starts. I've never bothered to calculate such a thing. Certainly it isn't when FSUIPC is started specifically -- FSUIPC simply maps the offset into a variable being set by FS. As such I don't think writing to it can do anything. Regards Pete

In FS2004 there are no "missions", and flights only really "end" when you start another -- there are facilities in FSUIPC for seeing when flights and aircraft are loaded. Regards Pete

Sorry, I cannot answer unless some other kind visitor can translate for me. Regards Pete

Well, not all of it. The code of FSUIPC4.DLL includes the WideServer module for WideFS7, which used to be a separate DLL. All this does is save you placing another DLL into the FSX modules folder. It makes things a little more efficient and saves some space. As far a product identity is concerned, FSUIPC4 and WideFS7 are distinct, just as FSUIPC3 and WideFS6 are. No, you buy WideFS7. The purchase gives you an access key to unlock WideFS in FSUIPC4. Only the Client (WideClient) is the same for all versions of FS, and that needs no key or unlocking. Ah. You cannot use the WideFS6 key for FSX. I'm not sure. Forget to read the instructions, perhaps? You can buy FSUIPC4 and WideFS7 together for a much lower price than the two together. Did you not see all this on SimMarket? It is always best to download the programs and read the user instructions first. It also helps to decide whether you actually need them. Folks have purchased WideFS before, actually thinking it was something different -- for example WidevieW. Even if you didn't read the instructions on SimMarket, where you buy these things, or use the short-cut buttons from the download site to get to the correct purchase place, I find it hard to imagine how you made this mistake. Perhaps you can appeal to SimMarket to replace it. It is all handled by them. You would have to raise a problem ticket I think. Regards Pete

Check 3364 and 3365 (read both together as one 16-bit value). Pete

Show me the Log file from that attempt please. It sounds like the Signature isn't verifying correctly. Didn't you check, as advised? And which 'older version' were you trying? Pete

It tells you that your read is working and that 8320 does indeed provide zero. So evidently what I said previously doen't apply to your version of VB. So the next questions are: 1. What are you expecting to read in this Logged case, if not 00? 2. Which version of FSUIPC are you using? (Those offsets were not always supported!) 3. If you are using a version before 3.71 (and from that one Log line it looks like you are), have you purchased it and registered it as a user? Perhaps you should try the currently supported version of FSUIPC (3.73, or 3.731 from the Announcements above) before testing again, then check the Log again please. Regards Pete

FS only supports landing lights on or off. There's no separate switching for left, right (or, for airliners, retractable left and right). I expect it would be possible for a panel/model builder to add such things, but the extra lights would have to be controlled by invented controls, keystrokes, mouse clicks, or possibly private mapping into FSUIPC offsets. Regards Pete

Have you tried using FSUIPC's Logging to see what is going on? On the Logging tab in the Options set "IPC Read" logging and it will show what is happening. This is why Logging is provided, to help you solve such problems! In all likelihood, from my little knowledge of VB, your "&H8320" is being compiled as hex FFFF8320, which is an invalid offset in FSUIPC. It will probably convert that to 1F8320 or similar, which is still wrong. Why Microsoft, in their infinite wisdom, decided to sign-extend 16-bit hex values is beyond me. Folks say that even if you specify &H00008320 it is still changed by the compiler to &HFFFF8320. Utterly awful in my opinion. I don't have any VB references here to look up, but check how to stop the sign extension. I think it is done by postpending another & character (&H8320&) but I am not sure. It's been quite a while since this silly problem last came up. Regards Pete

I couldn't even guess what that is. Doesn't the program's documentation or Help explain it? Regards Pete

I don't know if the FeelThere Airbus uses standard FS controls or not. Is there no documentation or help files with it to tell you? Try using one of the default aircraft first. The default autopilot does have FS controls for incrementing and decrementing the target altitude, which you can assign in FS or in FSUIPC. Whether they work with other add-on panels depends entirely upon the implementation of those panels. It is perfectly possible (and not uncommon, unfortunately) for panel designers to support mouse operations on switches without providing any assignable control or keyboard short-cut. If this turns out to be the case with your FeelThere panel I can only suggest using something like Luciano Napolitano's "Key2Mouse" which converts key presses to mouse clicks. Then at least you can program the keypress to your button. Well, yes, for FS controls. But add-on panels don't have to use those. Check by enabling the Event logging in FSUIPC (one of the check boxes on the left-hand part of the Logging options tab). Regards Pete

Yes, and select the NMEA sentences to suit the map program. Yes, exactly. This is the relevant section in the current WideFS user documentation: Regards Pete

Strange. I thought FS only did that for NEW controls, ones which appear as freshly connected via Windows. As long as you leave them plugged in and connected I thought they should remain with the settings, or lack of them, you have made. Is this with WinXP? And if so is it up to date (SP2)? I know Win98 and WinMe had some problems with USB devices being reassigned on each re-boot of the PC. Regards Pete

I don't think that is possible -- it is built into Windows XP and cannot be 'removed'. All you can do is disable it, via the Security Centre. Before the SP2 update it was defaulted "off" and ad to be enabled to be used, but SP2 changed that and defaulted it on. Regards Pete

Yes, it is okay. Microsoft try ty make it "easier" for you by calling CFG and INI files by fuller names. "config settings" means "configuration settings" which is another way of saying "option settings" or "initialisation settings". Hence .CFG and .INI. If you want to see the real filenames use the Folder Options to tell Explorer to show you them. Regards Pete

You'll need to reprogram everything I suspect, as PSS, like PMDG, program their own systems. FSUIPC can only provide settings for FS itself, not specific ones for aircraft which do their own thing. I'm sure there must be a PSS forum where you can get more information and advice. I'm afraid I don't use any PSS aircraft myself. Regards Pete

Yes, exactly as clearly documented -- also the KEY and LOG files, also as documented! Viz: If FS is installed in its default place in Program Files, Vista prevents FSUIPC from altering files even though it created them in the first place! So, if they are left there you get no settings saved, ever! Pete

Yes, if you've not yet run FS with FSUIPC installed. The INI file is only generated when you have used the program at least once. Ah, you are running windows in its default "confuse the user" mode. What you see as "config settings" are represented by files with filetypes ".INI" or "CFG". That's what ".INI" means as a filetype! Regards Pete

FSUIPC supports all of the FS built-in controls. PMDG do their own thing though, especially with the AutoPilot, which I think bears little relationship to the built in one. See if there's a keystroke assigned to the function. I'm pretty sure PMDG provided keyboard shortcuts for most things. If so you can program FSUIPC to send that keystroke when you press your button. Regards Pete

Okay, that's good. I'll do the same for FSUIPC4 and put both updates in the Download announcements at the top of the Forum. Thanks, Pete

Did you check the FSUIPC4.LOG (in the Modules folder)? Whether the Add-Ons menu appears or not is a function of SimConnect, not of the Install nor of Vista vs. XP. There have been many problems reported with bad SimConnect installs, and also with SimConnect reacting badly to assorted Security settings, Firewalls and the like. Please do refer to my Support forum, and check the assorted announcements and help there. The axis assignment problem in Vista was fixed in version 4.08, released last week. Please see the Support forum (as linked to by all my odcumentation, etc) and download updates when they are provided. If you visit the Support forum occasionally you will see these things. The Vista update was released last week. Regards Pete

In your first eport you said: but in fact in the INI file you had this: This was the same result I managed to obtain -- "Keys." being aircraft-specific but with an empty name. Anyway, I have found and fixed (I hope -- still testing) the problem with the Keys section, but I cannot make the Buttons, Axes or Calibrations sections fail. Can you please confirm that you really do have a problem with Buttons? If so I think I need even more information to work out why, as it seems pretty solid here. Meanwhile I will send you 3.731 to test the fix to the Keys section on your system, just to be sure. I think this affects the FSX version (FSUIPC4) as well, so I'd be grateful if you could let me know quite quickly, if possible, please. It is a great pity these things always seem to come to light just after a major new release, not just before when they could have been included so much more tidily. :-( Regards Pete

Oh dear. And you never thought to report it so it could be fixed in 3.72 (released in January), let alone before yet another major release? Please, things don't get fixed unless they are known about. Don't keep them to yourself! :-( I can reproduce a problem where the aircraft-specific Key presses seem to be saved in a section [Keys.] -- i.e. as if it is aircraft-specific but with the actual name missing. Weird. I can't make the same thing happen with Buttons, though. I'll investigate this more thoroughly over the next few days. It seems odd that an error like this could have occurred in, presumably three major releases (3.71 dating from way back in November) with only one report, so late. Seems the facility is hardly used at all. Please keep an eye on the Updates Announcements above. I'll make an interim release when I have it sorted out. Thanks, Pete