Pete Dowson

If you mean the EFIS control panel with the range and mode knobs etc, the only part of that which is implemented in FS itself (rather than local to gauges) is the BARO setting for the altimeter. You will find that referred to as "Kohlsman" after the German company (actually "Kollsman") which invented the first altimeters with that facility. All the other facilities are related to display modes and settings for the ND and, a little, the PFD. They are specific to the particular gauges and have no offsets nor controls associated with them. Depending on the panel you want to use you may be able to assign keypresses for them, but for FS default panels I think you are stuck with Mouse clicks. For those you'd have to use Luciano Naplitano's "Key2Mouse" program. any help is appreciated Alternative panel programs such as Project Magenta do provide support for their gauges via FSUIPC offsets. Maybe some of the add-on aircraft do too. Regards Pete

"Mixture rich" sets the lever to "Idle", "Mixture lean" sets the lever to "cut off". The mixture has to be set full rich to run (16384). Zero for cut off. Regards Pete

I'm afraid there is no "offset" for a steering axis input, though that's certainly something I will consider adding (but for FSX only). The steering tiller facility in FSUIPC is based on using a joystick axis, and assigning that axis to the tiller control. Can the CPFLIGHT hardware emulate a joystick in that way? You can drive controls through FSUIPC offset 3110. For an axis control you'd provide the axis value as the parameter. However, the FSUIPC steering tiller facility isn't actually an FS control at all, so it is still a problem. For FSX there are two possible solutions: 1. Use the new FSX steering tiller axis control (STEERING_SET, 66818), via FSX -- FSUIPC4 calibration is not involved for this. 2. Use that, or any other otherwise unused axis control, and tell FSUIPC4 by adding this line to its [JoystickCalibration] section (in the INI file): SteeringTillerControl= This was you do get to calibrate the axis in FSUIPC4. I'm afraid there's no real answer for FS9 except to use the rudder control. It operates the rudder in FS after all. Regards Pete

I will try to test 089A here, but I fear it may be too late for the next version, this week, and then I am away till mid-September. Really, when you ask for help, I need more information. I know 088A works fine, 100%, as it is used for many things. 089A is coded but I don't think has been explicitly re-tested in FSX, so i would need to do that. I need information, please. There are plenty of diagnostic tools in FSUIPC4 as it stands -- IPC read and write logging. You can also log Axis data and specific offsets can be Monitored. If you Monitor the offsets and specify "normal log", you will also get the SimConnect reads and writes for those values logged. Please try to assemble some information for me to look at. I cannot operate in a vacuum. And ALWAYS ALWAYS state FSUIPC (4.???) and FSX (SP1?) version numbers! If these problems are with recent versions (4.12 or later) then it may well be due to the way registered versions are only performing axis interception on an as-needed basis. First, the axes are only intercepted when they are assigned via FS or to FS controls (not direct to fSUIPC4 calibration from FSUIPC4 axis assignment), and even then they are only intercepted after their first actual use. This is all designed to remove problems of axis interception when this action is not specifically needed. If your use of 310A occurs before any real axis input has been seen (since the last aircraft load) then there won't be any interception, so the facility won't work. This would not, however, explain why you are finding that writing to 0BB2 etc has no effect. Writes to these are entirely independent of all this axis and control interception. The writes should always result in an onward write to the appropriate SimConnect "simvar". It certainly does here. Possibly you are misinterpreting what is happening, through not having done any separate tests or looked at any logs? Not really. In very earlier versions of FSUIPC4 the joystick axes were ALWAYS intercepted. However, because of SimConnect issues, causing TCP/IP queuing and subsequent extended latency in control surface operation (gradually extending to many seconds over a period), in later versions (still last year) I made FSUIPC4 by default NOT intercept axes on unregistered installs of FSUIPC4 -- this was done on the basis that the interception was only really needed for folks doing calibration or mapping in FSUIPC, and they had to be registered to use these facilities. To be honest, with the desire to avoid so many problems, I clean forgot about the 310A facility and its need for axis interception. This is something I will certainly work on fixing now that it has been brought up -- the intercept needs to be activated when 310A interception is activated, and possibly released again afterwards. FSUIPC4 is almost 100% using SimConnect. The exceptions are minor indeed, and will be eliminated when possible. Please also help me to help you. More information, please! It is a shame you didn't raise this a week or so ago. I have precisely two days before I am away for nearly two weeks. I am due to release version 4.16 tomorrow or Wednesday. I will do my best to fit something in, but it looks likely now that this won't get resolved for a while. Regards Pete

Ah sorrydidn't read it properly. Connected direct to the PC, not via one of the control systems (and thence via my PFC driver)? What do you expect to happen when you press "forward view"? Normally you would use the buttons to select anything but the forward view when pressed, then view reset when released. Can you tell me what you are trying to do, and please show me the INI file, the [buttons] section. Regards Pete

Sorry, I need more information. Did you confirm the assignment (not exit by closing or ESCaping)? I would need to see your FSUIPC.INI file. I also need to know what you actually mean by "forsware view". Do you mean "forward view"? If so, in order for that to change anything you need to have previously selected a different view. Sorry I don't know CH hardware. But the location of buttons is not relevant. If they are seen by FSUIPC and you assigned them, they will be doing what you assigned them to do. Regards Pete

I use Project Magenta, but my motorised trim wheels are made by PFC and I drive them via my own PFC.DLL driver. I suspect you need to check with your hardware manufacturer to see what drivers you need. Regards Pete

You'll need to re-register once for each operating system, as it makes a little note in the Registry. No, there are no differences. The same INI file will suffice. Regards Pete

310A (joystick disconnection) may only operate if the axes are intercepted -- which in recent versions of FSUIPC4 only happens if they are calibrated in FSUIPC4. I will have to work out ways of doing it for unregistered users or those not using FSUIPC4 assignments or calibrations. If I'm not intercepting the axes I cannot disconnect them. The others aren't for writing to -- that doesn't have any effect in either FSUIPC3 or 4. They are for reading the values which would have gone to FS if the settings in 310A had allowed. What did you think writing to them would do? Do you have any answers to my previous questions? Regards Pete

It occurs to me that I've only ever used them for fixed wing aircraft. Maybe the controls in SimConnect for helos are changed in FSX? Can you see if your programming works okay in a fixed wing aircraft? If so, but not in a helo I'll need to dig deeper... Regards Pete

Yes, they are all the same in FSX with FSUIPC4. I have several applications using them all the time (one being the Aerosoft GA28R cockpit driver) -- except for 089A which should be working as it did in FS9, but admittedly has not been tested yet (088C is the direct throttle and this is certainly working as it is used by Project Magenta in my 737 cockpit). Please enable IPC write logging, and also Monitor those offsets as type S16, with "normal log" checked, run your program then show me the resulting FSUIPC4.LOG file, so I can see what is happening. Regards Pete

I don't really understand the question fully, but if you mean can you assign buttons in FSX as well as in FSUIPC, the answer is yes, of course. Just don't assign the same button in both places unless you really do want both actions to occur when you press it. If you are just asking whether you can have non-aircraft specific buttons assigned in FSUIPC as well as aircraft-specific ones, again the answer is, again, yes of course. Simple untick "Aircraft Specific" when assigning global functions to buttons. When the aircraft specific option is checked you are assigning/viewing specific assignments, when it is unticked you are viewing/assigning global assignments. The same applies to Keys, but not to FSUIPC joystick calibrations or axis assignments, which are either specific to the current aircraft or not -- there's no mixing for those two categories. Regards Pete

Whether it "stays" or not is irrelevant. The SimConnect logs shows that FSUIPC is not operational. It cannot do anything, no matter whether the menu gets shown or not. Something is stopping SimConnect sending most messages to FSUIPC. You've either got a messed up installation of SimConnect, or one or other of your other installed programs is interfering -- a firewall or antivirus or other security related program. The logs are very strange -- I've never seen results quite like that. It is usually more obvious when there is a block. But here, the messages from SimConnect to FSUIPC either never arrive, or start but then dry up almost immediately. There are other steps you could take: 1. First of all check any and all security programs you have installed. If possible, just as a test and provided you can re-install them afterwards, try uninstalling them one at a time. 2. In case it is a messed up install of SimConnect, try to re-install that. This is more difficult. In the "FSX Help" announcement it talks about deleting a particular folder then running FSX repair. This is worth a try, but it may not help with your installation because you've installed SP1 and FSUIPC is using the SP1 version of SimConnect. What you would have to do is un-install SP1 (via the Windows Control Panel add-remove programs facility -- you'll need the option to show updates checked). THEN find and delete this folder in Windows: C:\WINDOWS\WinSxS\x86_Microsoft.FlightSimulator.SimConnect_67c7c14424d61b5b_10.0.61242.0_x-ww_35e8ee9a Then re-install SP1. 3. Whether or not these steps help, please gather the information you sent me and whatever comes of these steps, and send with your error reports to tell_fs@microsoft.com . They need to see this stuff so it can be fixed in future updates. That said, I am hoping a lot of these TCP/IP protocol-related problems will disappear once the next update (SP2) is available. The local data exchange mechanism will not be the same. Regards Pete

There should never be any way it would lose focus just because of TCP/IP traffic. I think you are mis-diagnosing it -- and if so, having Simconnect use TCP/IP less won't help. If it is indeed a SimConnect problem then you need to do two things: 1. Get that SimConnect log as I suggested. If you ZIP it up and send it to me at petedowson@btconnect.com I can see what is going on. 2. Report this, with all such evidence, to the FS team via tell_fs@microsoft.com. You might be right about it being related to your firewall or A/V program. What are you using b the way? There were known problems wuth several such programs. I know for instance Kaspersky gave a lot of problems till they brought out an update. Regards Pete

Not all of it. The Joystick Calibrations, Axis Assignments, Buttons and Keys are all re-read when you change aircraft, and most of those also have "Reload ..." buttons in their option screens too. There really should be no need to reload any of the other sections. Oh, in FSUIPC4.INI (the one for FSX), the [WideServer] section is re-read if you disable then re-enable WideFS on the front option screen. Regards Pete

It sounds exactly as if the real version of FSUIPC you have installed is not 3.75, as you put in your title here, but a different one, certainly made before FS9.1 was known. Go to your FS9 Modules folder, right-click on the FSUIPC.DLL file and check the Version number (Properties-Version). Regards Pete

The numbers in which page of the Calibrations don't change? If you have a single throttle lever assigned through FS to the single all-engine throttle, then the place to look is page 1 of the Calibrations, along with ailerons, elevators and rudder. Pete

This window postion and size seem very odd. This implies a screen which is at least 32123 pixels wide by 32034 pixels deep. Since the largest displays tend to be more like 1600 x 1200 I suspect that, even though you have "Visible=Yes" the window is nowhere to be seencorrect? It way off the screen a few yards to the right and downwards! Delete the Window= line so WideClient can default. Then size the window to get a reasonable size for each of the "Button" rectangles you then get. The Button rectangles get drawn immediately WideClient is ready, the labels are filled in when it connects. Regards Pete

If you have a Registered install of FSUIPC, you can do it via the Joystick Calibration tab, in FSUIPC options. Full instructions are provided for this in the FSUIPC User Guide, in the Joystick Calibration section. Regards Pete

Either paste the test from the Log into a message, or, for a larger file, ZIP it up. Always use ZIP in any case when sending files. Including obtaining a SimConnect log file (in the FSX Help Announcement)? Since it sounds like SimConnect is going wrong, that sounds to be the most useful. Also, since you've read all the Announcements, did you not find Version 4.156 of FSUIPC and try that? I've never heard of that before. What is left in the Add-Ons menu after it "disappears"? Sounds like some other add-on is interfering? As well as a log please tell me what else you have installed or running with FSX. Regards Pete

Please show me the WideClient.INI and LOG files, and the WideServer.LOG from the FS Modules folder. Regards Pete

Yes. This is why the official Microsoft website gives instructions to disable local Firewall and Antivirus checking, though I think that is only needed for certain such programs. Even so, the very action of these programs on such traffic does slow things down somewhat. Incidentally, I think this will be a lot better in the SP2 release. Sorry, I don't understand. When you say "returned to the desktop" do you mean FSX is crashing? What is "rejoining the flight via the task bar"? If you are using full screen mode and FS is minimising all on its own -- usually when changing views -- this was an FSX problem before SP1 but I've not heard of it happening since. Have you installed the SP1 update? Does it happen in Windowed mode too? It may well be a function of your video driver -- see if there's a later version. Well this will obviously be placing a little extra loading on the system, more perhaps depending also on your firewall settings. Does the FSUIPC4.LOG file show anything (you'll find that in the FSX Modules folder). Regards Pete

Yep, that looks perfect. Thanks! This version, or one very like it, will be released as a new User version in the coming week, probably Monday/Tues. It will be 4.16. Please update to that when it's posted. Regards Pete

Yes, the control is in the same sequence. I expect that is because, otherwise, the SELECT_ controls will actually seelct an ATC option from that window. Rightbut on the other hand I do try to maintain compatibility with FSUIPC. That's been part of its main purpose, after all. I've made one of the changes I suggested -- adding the radio select and swap controls to the list of those I intercept, so that at least they should be kept together. The ATC close thing will occur first then, in fact. I'll post it to you by email (after I've checked that I've not broken anything else) for you to test. Even if it works, I'd like to see the same logs please. Regards Pete

From the logs you sent me it looks very much like it is actually an FS2002 model. They may have updated the graphics and animations for FSX, but it seems all the gauges are very old indeed -- at least the radio ones. Received the Logs by email. Thanks. These controls: 452688 *** EVENT: Cntrl= 65585 (0x00010031), Param= 0 (0x00000000) NAV_RADIO 481106 *** EVENT: Cntrl= 65582 (0x0001002e), Param= 0 (0x00000000) COM_RADIO 481107 *** EVENT: Cntrl= 65581 (0x0001002d), Param= 0 (0x00000000) FREQUENCY_SWAP are all non-specific -- they work on the last radio selected, 1 or 2. these controls: 452751 *** EVENT: Cntrl= 65539 (0x00010003), Param= 0 (0x00000000) SELECT_2 and 357234 *** EVENT: Cntrl= 65538 (0x00010002), Param= 0 (0x00000000) SELECT_1 are supposed to select the appropriate radio first. The sorts of things this cockpit is doing here are rather archaic -- there have been proper NAV1/NAV2 and COM1/COM2 controls around since FS2004 was released and there were better ways of doing this even in FS2002. I'm now pretty certain this aircraft's radio stack is a very old design. The "SELECT_n" controls are processed by FSUIPC because these are the 1, 2, 3, 4 keys used for things like selecting engines, and Pushback direction, and FSUIPC tries to ensure they are associated with the last relevant control -- it allows, for instance, a view left or right whilst pushing back, before pressing the 1 or 2 for direction. FSUIPC certainly doesn't stop the SELECT_2 actions going through, but it is likely that, because I am intercepting them, the order of controls being sent by your panel is getting changed. Here's an example: 379478 *** EVENT: Cntrl= 65582 (0x0001002e), Param= 0 (0x00000000) COM_RADIO 379478 *** EVENT: Cntrl= 66514 (0x000103d2), Param= 0 (0x00000000) ATC_MENU_CLOSE 379478 *** EVENT: Cntrl= 65581 (0x0001002d), Param= 0 (0x00000000) FREQUENCY_SWAP 379478 *** EVENT: Cntrl= 66372 (0x00010344), Param= 0 (0x00000000) COM_STBY_RADIO_SWAP 379569 *** EVENT: Cntrl= 65539 (0x00010003), Param= 0 (0x00000000) SELECT_2 That last SELECT_2 was probably issued just after COM_RADIO. I don't understand why it is issuing both a FREQUENCY_SWAP and a COM_STBY_RADIO_SWAP -- probably only one of them actually works. I cannot do the same as I do for Engine, Exit and Pushback -- i.e. keep back the first command for a short time, waiting for the SELECT, as this would then occur AFTER the "SWAP" control, but I will experiment with either allowing the SELECT to go through even though I am saving a copy for later too (I am a bit worried about such double actions), or, more likely probably, intercepting and forwarding the SWAP controls as well. If it is only the SWAP control which is being affected here that should be okay. It is interesting that this hasn't come up before. It would happen on FSUIPC3 too, except that on that ALL controls are intercepted and processed, so the order isn't being changed. Regards Pete