Pete Dowson

FS has never provided a direct IAS/Mach c/o facility, except in gauges using mouse clicks. Internally it only switches when you select the relevant hold mode -- IAS hold or Mach hold. In previous coockpit implementations I've had to save the A/T Arm enabled/disabled state first, then make the change, then restore the disabled state of the A/T if necessary. Very annoying. Regards PEte

Well, that's the IN values, and they look okay -- surely nothing wrong with your joystcik -- but where's the OUT values corresponding to those (the ones you can read off the Calibration screen)? Did you check it all with the default King Air as I suggested? These things always need checking with default aircraft, as it could easily be a function of the add-on aircraft to modify the default behaviour. Regards Pete

Please show me the values. With the default aircraft I can even test the same values here. Pete

Ah. I clean forgot you were talking about an add-on aircraft. Apologies. Can you test it on the default King Air and let me know? If it is still not right, then something strange is going on for sure. If the 4 values are all different then they must correspond (be calibrated to) the correct values for the aircraft's prop pitch lever movement. Maybe you can show me the FSUIPC INI file line for the appropriate Axis calibration, or read the values from the calibrate screen, and also tell be the OUT values shown there for each of those axis postions? However, if it is specific to the Aeroworx add-on, maybe you should fire them a question about how it should be operated? Regards Pete

Right. Thanks for confirming. I know that on any one joystick I cannot read some axes in RAW mode and others not -- they must all be one or the other. I have to impose that in the FSUIPC options (I suppose you would have noticed). When I tried to mix them I was getting really weird incorrect values for one mode or the other (whether it was RAW or calibrated I don't remember). I didn't actually think that the reading of the buttons only (which is not done in the same call and for which there's really no "RAW" mode as such) would matter whether the RAW flag was set or not, but evidently it does. One solution in my code might therefore be to read the buttons in "RAW mode" (i.e. set the flag) if the corresponding axes (i.e. the axes on the same joystick) were being read in RAW mode. Really, unless it becomes necessary, I'm not inclined to do that at this stage. It is no where near as complex as changing over to DirectInput, but it is still non-trivial, and therefore risky. FSUIPC3 is so modified by now, over its seven plus years, that each small change risks introducing bugs in other parts. Thanks for letting me know in any case. I think I'll note down the possibility of a fix as I described, just in case it arises again. Regards Pete

Please do, and let me know. Of course you'll need to re-calibrate them. RAW mode is really only intended for axes which are meant to set values DIRECTLY. For instance, an axis deliberately designed to feed specific values for Flap detentes actually providing the exact value, without calibration, for the correct flap positions. Or one designed to provide values 0-359 to set a heading. Such axes can be built with multiway switches and a set of resistors (trimpots), each preset for the correct reading, or also of course by other electrical means. EPIC cards can be programmed explicitly to send any exact values on any of its possible 16 axes. This is why I support RAW mode, but it really does not have any other applications that I can think of. Sounds like it is using a better driver? Regards Pete

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