Pete Dowson

You would need to set "Log=Debug" in the FStarRC.INI file [settings] section, then run a session. The FStarRC.Log file it produces will be quite big, but it should help me work out what to change -- you'd then have to test any changes for me. but not now, when I come back! ;-) No, that must be something else entirely. Are you using MixW to create two virtual serial ports? Flitemap should not be able to tell any difference between a real COM port and a virtual one -- that's the point. Can you not select the port? Maybe they've restricted it now to COM1 and COM2, though that would make no sense. I did read something someone reported that Jeppesen were dropping the moving map feature from FliteStar/Map in some version. Regards Pete

Yes. Jeppesen, in their wisdom, keep messing about with the print formatting. FStarRC relies on recognising bits of the print output stream so it can extract the data it needs. It cannot do this directly as it is encrypted. I have a world-wide corporate FliteMap, currently at version 9.0. To update to that from the last cost me hundreds of Euros, and the price gets steeper, so I am not willing to update it continuously I'm afraid. Maybe the changes needed to FStarRC are minor, but it is hard to tell and harder to test without the software. There are some detailed logs I could probably use to decide, and I can try to work out how to get them so you can help -- but unfortunately I am on holiday after tomorrow for nearly two weeks. Please write again after September 12th and I'll see what can be done. Regards Pete

I don't have any web pages. If you mean the Schiratti one, that's a page where Enrico Schiratti, of Project Magenta fame, assembles my various FS efforts. I actually distribute the programs to many website managers but they don't all post them. Version 4.156 has been available above (i.e. in the FSX downloads announcement) for over two weeks-- I've just replaced it by 4.16. Haven't you ever noticed the Announcements? They should always be your first port of call, especially if you are a developer. There's more up-to-date developer SDK bits for FSX there too. How do you gert to posting these thread messages without ever seeing the Announcements which occur right at the top? Regards Pete

4.151? That's pretty old. the current formal release is 4.152, since a month ago, and there's a much-improved 4.156 available above which was available since two weeks ago. Actually I've just finished testing this (in 4.156) and I cannot find any problem with it at all. Of the problems I mentioned in my previous message, the true status, having gone into them in some detail, is as follows: This was a result of a bug in the "ApplyHeloTrim" facility, which I've fixed now. If you haven't enabled this then the elevator control via 0BB2 works fine. This turned out to be a bug only in the automatic clearing of the 310A inhibits after 10 seconds or so, unless replenished. Writing 0 to 310A did restore the throttle link from 089A to 088C. There is and was no other problem with 089A -- it basically simply operates 088C unless inhibited. I've fixed the 10 second (approx) clearing of the inhibits now. This wasn't quite correct the way I stated it. In fact, if the axes are assigned directly in FSUIPC to FSUIPC calibration, the inhibits worked fine. The only problem was for unregistered users or those who were neither assigning axes direct in FSUIPC or calibrating axes in FSUIPC. I've dealt with this by automatically intercepting the relevant axes once the inhibits are set in 310A. These three fixes are tested and working here in version 4.16 which will be released before the end of the day. Please keep an eye on the FSX downloads announcements above. I'm afraid I won't be able to do much more, if anything is needed, till I return in mid-September. I am here tomorrow and will answer questions, but there will be no more changes till then. Always ZIP attachments. In any case, judging by the fragment you included with your message you are not logging IPC writes, so I cannot tell what you are trying to do. You have evidently only set the IPC read logging option. Please refer back to the details of the logging I suggested, which also included Monitoring so that the SimConnect exchanges would be seen. Finally, please do not report problems without first using the very latest version of FSUIPC available. I have no idea why you are still using 4.151 which was an interim Beta replaced very quickly by the formal release of 4.152 over a month ago. Version 4.156 has been available in the Downloads above for two weeks. Now you may as well wait for 4.16. Regards Pete

Okay, I've been doing some testing and this is what I've found: WORKING: 1. Writing to offsets 088C (Throttle1), 0BB6 (Aileron control) and 0BBA (rudder control) works fine. I can't make that go wrong at all. 2. Offsets 3328 - 3330, which are read-only (something you appear to have misunderstood?) correctly give the input values for the relevant control axes. 3. The inhibition of axis inputs via 310A works correctly ONLY IF the axes are calibrated in FSUIPC4, and assigned to FS controls (not the "direct to FSUIPC" method in FSUIPC's axis assignment option). NOT WORKING: 4. For some reason, writing to 0BB2 (elevator control) isn't working 100%. I am looking at this now. It may be my joystick control jittering and overriding my inputs, as there really is no internal differences in the treatment of the three main surface controls. 5. Writing to 089A to control the throttle works just like writing to 088C -- until you have inhibited it via 310A. After that, even if it is allowed again via 310A, it doesn't do anything. I'm checking this too. 6. The 310A inhibits don't work when the axes are not being intercepted. To be sure they are intercepted, the axes have to be assigned to FS controls, either normally via FSX, or specifically in FSUIPC4, then calibrated in FSUIPC4. This is an oversight on my part, a result of recent changes in this area. Hopefully all three of these problems should be easy enough to fix, and I am working on that today. If I succeed these fixes will be in FSUIPC 4.16 today or tomorrow, but otherwise they won't be fixed till mid-September (i.e. in about two weeks or so). Please confirm that the problems you are observing coincide with the ones I have identified. I am still starved of any useful information from you, so if I as missing the point I'm afraid your problems will not be fixed for some time. Regards Pete

No, because FSUIPC doesn't use any redistributables, at least nothing not already used by FS itself. Ahnothing to do with any redistributables. Please see viewtopic.php?f=54&t=64092 I cannot solve it unless someone can find facilities in Windows to do sidebyside probing without generating errors (which are no such thing). I will continue to press for such things from my side, but you do your bit too if you don't like it -- complain to Microsoft's Windows developers. Pete

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