Pete Dowson

Yes, exactly as I understood and explained. Erplease get the terms generalised so we can understand each other. Left to Right on the FSUIPC options you have a minimum then two centres then a maximum value to be set. They might go under different names for different axes, but the INPUT values must always increase from left to right. Then it is not calibrated correctly. Perhaps I need to elaborate on what I thought were sufficient instructions in the documentation: Put the wheel at minimum -- i.e. where you want the fully feathered setting to be. It should show the lowest possible value you can get in the INPUT box. If it shows a large positive value then you need to REVerse the axis. (Make sure you are using the latest version of FSUIPC for this, as axis reversal is a little more precarious in older ones). Okay. Nudge it forward just a little, enough to see the INPUT value change slightly. This is for safety -- in case of slight variations in the input values. Press the SET button above the minum, so that the INPUT value is copied there. Move it to the maximum, nudge it away for a different (slightly lower) INPUT value and click the SET button above the maximum box (on the right). Move the wheel to the detente. The INPUT values should change, right? If not, there's your problm -- the wheel is not sensitive in that lower range. Assuming it is okay, nudge it back towards the minimum just a little, and press the SET above the centre two values. Then nudge it a little past the detente and do it again. That sets the little zone around the detente. And that's it. This is what the documentation says too, all I am doing here is saying it in different words. It does work. You must have different values in each of the 4 boxes, increasing left to right (the middle two don't have an order). It sounds like you have one or both of the centre values the same as the left-hand one. I have done this sort of thing loads of times with different joysticks, wheels, game pads, the lot. Regards Pete

Strange. I've never heard of that before. In FSUIPC3 the same interface is used to scan both axes and buttons, and it is the standard Windows joystick interface. Does the same occur if axes are assigned in FS instead? In FSUIPC, are you reading the Axes in "RAW" mode? If so try reading them in normal (Windows calibrated) mode, as there is a possibility that the joystick driver might not like the modes switching. The only other thing I can think of trying is to reduce the button scan somewhat. Put a "PollInterval" parameter into the main [buttons] section of the INI. The default polling rate is 40 per second, set by 25 here (PollInterval is in milliseconds). Try doubling it (to 50, giving 20 scans per second) -- if it has no effect at all then it isn't the answer. If it does you could try intervening values. Of course if your buttons are only switches to turn things on and off or toggle things, then an even slower scan rate would be worth trying. FS uses DirectInput for both buttons and axes. It's a different thing altogether. It also never uses RAW modes of course. Well the button scanning is identical in FSUIPC4, but the axis scanning is done via DirectInput, just as it is in FS. Evidently there's something about the older mode driver for your devices which isn't very good at reading axis values. I fear most game device developers concentrate on the DirectInput (HID) side of their support to the detriment of the basic Windows facilities. I'm afraid that the work involved in re-doing FSUIPC3 for DirectInput is far too much for me to undertake at this stage. For FSUIPC4 it was relatively easy as it needed to be written almost from scratch in any case, due to the interaction with SimConnect. Regards Pete

AhFSUIPC doesn't stand a chance then. Saitek must have done something a bit strange with their driver. Perhaps they have some manager program in which you can assign them. Did you check? If you can get them to send keystrokes you could assign those instead. Curiouser and curiouser! Seems a call to Saitek Tech Support is in order? Well, no, I don't understand. "AviemoreCltBtn"? Aviemore is in Scotland. Is that where Saitek are based? Strange. Maybe there's another button named after somwhere else in Scotland for the other one, decimal 29 (1d) which you can change to 28 (1c)? If you ever do find the complete answer, please don't forget to post it here. Regards Pete

Well, from here it seems it is you who doesn't understand, but never mind. You want lots of AI but you don't want lots of AI. That sums it up I think, from all you've been saying. Sorry I couln't help and that I certainly couldn't agree with you about a bug in FS. Regards Pete

I don't know how it is routed, but if it comes within a certain range of your positon (I don't know what that range is, but it is at least 80 nm) then it will be generated in flight and maintained. Whilst you were there didn't you bother to check how far away it was? And where were you before, when it was presumably generated? So what do you want? 80 at 100% and 40 at 50%? I don't think the slider ever works linearly unless the AI packages you've added are designed that way. Each flight embedded in the traffic files you add contains a parameter telling it at what percentage value to appear, so different add-ons can skew the effect of the slider in different ways. Maybe you just made a poor choice (for you) of what you added. Anyway, why not just reduce it a bit more to get your 40? Why must there be a bug? It is all behaving as it was designed to do, and did in FS2002 (as well as in FSX for that matter). You get out of it what you put into it. You put the extra traffic in, so that's what you get out. Why did you bother adding traffic if you don't like it? It makes no sense. And calling it a bug when it is only doing what you ask doesn't make any sense at all. Regards Pete

Sorry, I'm not at all clear on what you mean there. So you are saying that the "IN" values from your joystick are reading the same all the way from the detente down to the bottom (nearest position)? If that is the case then none of that area of the joysticvk is at all usable -- either it is broken or you have some trim system on it set at one extreme. If you don't mean that, but that the "OUT" values are the same all that way, then you need to calibrate properly with a minimum value less than the two centre values. Whether the "centre" is calibrated centrally or right at one end is totally irrelevant. YOU are in control of that. It is YOU who presed the "Set" buttons to set the values at whatever point you need them to be. But there obviously must be a gap in values between your off-centre detente values and the two extremes. Otherwise there is no "zone" to move the output values into, is there? Regards Pete

Ouch. They must only be handled by the DirectInput part of the driver. Sorry. You'll need to assign those in FS's own assignments. Regards Pete

If the first button in Windows is number 1, yes, they should be 29 and 30. And i really have no idea how they could be missed if they are being reported that way (in the 32-bit value returned to represent the button states) they'd be to 2^29 and 2^30 bits, i.e. 0x20000000 and 0x40000000 respectively. The program I attached should show then in decimal or hexademially, I think (optionally). Okay. Let me know. I've got nothing here with as many as 31 buttons but I expect I could rig up a phoney input if necessary for testing. Regards Pete

Yes, if you "map" the mail Prop Pitch axis (see FSUIPC's Joystick Calibration pages) to 4 separate prop pitch controls (via a check-box in the main prop pitch part), then go to the page with the four prop controls and calibrate the first, you will see you can calibrate a "centre" zone for feathering where you like. Set it to operate just above and just below your detente. Regards Pete

Are you using FSUIPC 4.08 or 4.081? If not, do so. If you read the Installation section of the FSUIPC4 User Guide it does explain that you need elevated privileges to register FSUIPC4 in Vista, and it does mention the "Run As". Everyone else who has done this has been successful. Regards Pete

You are misunderstanding something quite fundamental, I'm afraid. There is no bug! FS will only load 100 AI aircraft if that's how many are scheduled to be flying at that time according to the AI Traffic files you've installed! There is no bug, it is what you are asking FS to do by installing so much AI and not bothering to control the numbers using the slider. If you move the AI slider to the left you will get less AI traffic loaded. That is what it is for! Please do read what I am saying! Regards Pete

First, please ALWAYS say which version of FSUIPC you are using. If it isn't the latest, always try that first. For buttons FSUIPC recognises the 32 possible buttons supported by the standard Windows joystick API. I believe there is an extended mode in DirectX which does support up to 64 buttons -- but unless your device already has 32 I wouldn't think it would be using one of those! Check in Windows Game Controllers -- see what button numbers it gives there. Edited the INI how? If you don't know the joystick number (0-15) and button numbers, you cannot work out what parameters to enter there! What 'control panel' are you talking about in the latter case? Do you mean the Windows Game controller? If so, why has FSX got to be running? And what numbers does it give? Can you assign the buttons in FSX's control assignments? I attach a program called JOYVIEW, which can be used to examine in detail Joystick inputs using the standard joystick interface (not DirectX). Try that, see what you can find out. Regards Pete joyview.zip

Oh, but there IS -- it is the slider in the Options menu, the one which controls how much AI traffic you want FS to load. That is exactly what it is for. The other way to avoid lots of traffic (apart from uninstalling some, which is presumably too obvious?) is to fly in areas where there isn't very much in any case. Regards Pete

No, nothing like that at all. FSUIPC has no effect on traffic whatsoever. "TCAS" is a Traffic Collision Avoidance System, instrumentation which shows where traffic is in relation to your aircraft so that collisions can be avoided. The TCAS range is merely the distance beyond which such traffic won't be picked up. Such instrumentation doesn't destroy traffic. that would be nonsense. If you want less traffic go to FS's Options and move the traffic slider leftwards! Of course, this begs the question as to why on Earth you've added such a lot of traffic if you don't want it. Why not just remove it again? Regards Pete

Aha! In that case it is probably this bug which was responsible, fixed in 4.073: That would have been trying to read 8 parameters from the INI file quite frequently. The bug was the omission of a flag being set for when it had been done once, reported here in the thread Problems with RUNoptions in FSUIPC4.07 at the end of January. http://forums.simflight.com/viewtopic.php?t=59973 I should have stuck to my guns, requesting reports only from currently supported versions, instead of wasting three hours on it last night before going to bed at 03:30 am! It was the peculiarly different Filemon logging which misled me completely! ;-) Regards Pete

Aha! Found the "Advanced" option in FileMon. That makes the logging look a bit more like yours, though it makes it totally confusing to me as I don't know what most of the lines really mean. I assume you do and that's why you use the advanced logging? The filemon Help says "The Options|Advanced menu item will satisfy users, such as file system filter driver developers, that want the "raw" view of file system activity shown by previous Filemon versions." Anyway, enabling this mode has not produced any real differences. The typical sequence now, during FSUIPC4 initialisation only, again, is like this: IRP_MJ_CREATE G:\FSX\Modules\FSUIPC4.ini SUCCESS Options: Open Access: Read IRP_MJ_CREATE G:\FSX\Modules\FSUIPC4.ini SUCCESS Options: Open Access: 00100080 IRP_MJ_QUERY_VOLUME_INFORMATION G:\FSX\Modules\FSUIPC4.ini BUFFER OVERFLOW FileFsVolumeInformation IRP_MJ_QUERY_INFORMATION G:\FSX\Modules\FSUIPC4.ini SUCCESS FileInternalInformation FASTIO_QUERY_STANDARD_INFO G:\FSX\Modules\FSUIPC4.ini SUCCESS Length: 282 IRP_MJ_CLEANUP G:\FSX\Modules\FSUIPC4.ini SUCCESS IRP_MJ_CLOSE G:\FSX\Modules\FSUIPC4.ini SUCCESS FASTIO_LOCK G:\FSX\Modules\FSUIPC4.ini SUCCESS Excl: No Offset: 0 Length: -1 FASTIO_QUERY_STANDARD_INFO G:\FSX\Modules\FSUIPC4.ini SUCCESS Length: 282 IRP_MJ_READ G:\FSX\Modules\FSUIPC4.ini SUCCESS Offset: 0 Length: 282 FASTIO_UNLOCK G:\FSX\Modules\FSUIPC4.ini RANGE NOT LOCKED Offset: 0 Length: -1 IRP_MJ_CLEANUP G:\FSX\Modules\FSUIPC4.ini SUCCESS IRP_MJ_CLOSE G:\FSX\Modules\FSUIPC4.ini SUCCESS For an unregistered install with no prior INI file (so it creates one) I get a grand total of 1515 entries, all during FSX loading, and nothing thereafter, at all. So, the mystery persists. Sorry, I've no idea why your system is so different, nor what is actually accessing FSUIPC4.INI when FSUIPC4 is doing nothing. Maybe I'll need to log each of my accesses to the INI so we can compare FileMon's results to FSUIPC's logs. I'll wait to see what other results you can get first, though. Regards Pete

No, 7.04 shows exactly the same as 7.03. I've tried it also with Wideclient.EXE running from a folder on my Networked backup hard disk, and FileMon's logging for the WideClient.INI (which is accessed via the same API) is also the same. So that strange sequencing your logging shows doesn't apply over networks either. I have one little portable USB hard disk, which I'll plug in now and try WideClient on that ... ... It's the same on that one too. I simply cannot make FileMon show me anything like the types of operations you have in your log. It's a total mystery! :-( Pete

AhI wonder if that makes a crucial difference! Certainly the internal file access routines aren't the same as those, at the level being logged, as external ones. Well, there's no difference between FSUIPC's INI file access methods between FSUIPC3 and FSUIPC4, and, as I say, for an unregistered install like yours the INI file is only accessed (by FSUIPC) on initialisation and when/if you ever change the few options available to you. I don't think that will make any difference. I just checked and a filemon log supplied by another user (registered) had the same type of accesses listed as your log. I am now assuming it must be mostly to do with using an external drive, though why the system should continue to access a file which is completely unused, after initialisation, by FSUIPC is beyond me. If you have an FSX installation you can check on a local hard disk I'd be interested to see the results with that. I'm now suspicious that there are some hideous problems in Windows' own PrivateProfile APIs when on external drives -- maybe most of what you are seeing are automatic retries going on because of those "errors". Meanwhile I'll try upgrading to filemon 7.04 (instead of 7.03) to see if that makes any difference here. Regards Pete

Further to my last reply, there's something I don't understand, that's for sure. First, contrary to what I said before, I've checked and done tests (yes, with Filemon too), and, in fact, if you are not user-registered, there is no access whatsoever made to the INI files on any regular basis, not even when you change aircraft or load flights. In fact only changing the front-tab or logging options would cause an access. Second, my logging (under winXP SP2) shows all the accesses to the FSUIPC4.INI file to be composed of this sequence: OPEN G:\FSX\Modules\FSUIPC4.ini SUCCESS Options: Open Access: Read OPEN G:\FSX\Modules\FSUIPC4.ini SUCCESS Options: Open Access: 00100080 QUERY INFORMATION G:\FSX\Modules\FSUIPC4.ini BUFFER OVERFLOW FileFsVolumeInformation QUERY INFORMATION G:\FSX\Modules\FSUIPC4.ini SUCCESS FileInternalInformation QUERY INFORMATION G:\FSX\Modules\FSUIPC4.ini SUCCESS Length: 3163 CLOSE G:\FSX\Modules\FSUIPC4.ini SUCCESS LOCK G:\FSX\Modules\FSUIPC4.ini SUCCESS Excl: No Offset: 0 Length: -1 QUERY INFORMATION G:\FSX\Modules\FSUIPC4.ini SUCCESS Length: 3163 READ G:\FSX\Modules\FSUIPC4.ini SUCCESS Offset: 0 Length: 3163 READ G:\FSX\Modules\FSUIPC4.ini SUCCESS Offset: 0 Length: 4096 UNLOCK RANGE NOT LOCKED Offset: 0 Length: -1 CLOSE G:\FSX\Modules\FSUIPC4.ini SUCCESS and in the initialisation phase, just the early few seconds, this is repeated about 180 times, producing 2000+ log lines, a long way short of your example which seems to contain the following sequence repeated many more times: IRP_MJ_CREATE X:\Microsoft Flight Simulator X\Modules\FSUIPC4.ini SUCCESS Options: Open Access: Read FASTIO_LOCK X:\Microsoft Flight Simulator X\Modules\FSUIPC4.ini SUCCESS Excl: No Offset: 0 Length: -1 FASTIO_QUERY_STANDARD_INFO X:\Microsoft Flight Simulator X\Modules\FSUIPC4.ini SUCCESS Length: 282 IRP_MJ_READ X:\Microsoft Flight Simulator X\Modules\FSUIPC4.ini SUCCESS Offset: 0 Length: 282 FASTIO_UNLOCK X:\Microsoft Flight Simulator X\Modules\FSUIPC4.ini RANGE NOT LOCKED Offset: 0 Length: -1 IRP_MJ_CLEANUP X:\Microsoft Flight Simulator X\Modules\FSUIPC4.ini SUCCESS IRP_MJ_CLOSE X:\Microsoft Flight Simulator X\Modules\FSUIPC4.ini SUCCESS So, how do these logs manage to look so completely different? The only two Windows commands used to access the INI file are GetPrivateProfileString and, much less often of course, WritePrivateProfileString. Are you setting some special options in FileMon to get a completely different level of logging? My Filemon version is 7.03, what's yours? Are you using Windows XP SP2 or some other operating system? Is your drive X: a "normal" hard disk partition, or is it mapped elsewhere? I have a drive X: but it refers to an external hard disk on my Network, used for back-ups in a distant room. I am rather puzzled as to how you produced that FileMon log. Regards Pete

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