Pete Dowson

What do you mean by "current" FSUIPC? Where have you ever seen an "Aileron Trim Set" or "Rudder Trim Set"? FS2004 doesn't provide any such controls, only the Left and Right controls. Pete

No, not in any way that any such value won't get immediately overwritten by FS's simulation engine on the next computation frame. It is a result, not an input. No, I don't know that? Where is this published? What is the error? Why not write your own gauge to replace the one in your favourite aircraft, then? If this is a well-known fault in FS, why haven't the competent aircraft makers fixed it in the gauges? The gauge code doesn't have to use the value exactly as provided, it can do as it wants. Regards Pete

Erunfair I think to pick out FSUIPC4 specifically. There are problems with FSX and pretty much any and all add-ons at present. Three things: 1. Is the weather the same without ActiveSky as with? You need to check whether it is simply the numbers of clous levels and extra weather which is hitting the performance. 2. What about FSUIPC4 without ActiveSky? There is currently a known overhead, usually about 10-15%, from just installing FSUIPC4 -- this is part of the current SimConnect performance problem we are hoping MS are working on. Some have reported as much as 40% but I am pretty sure these are down to anti-virus and other programs like that which, although deactivated, still have inefficient hooks embedded in the TCP/IP path. 3. If all these are running on the same PC, are you sure it isn't merely that ActiveSky and FSX represent just too much load on your PC, with the settings you havve in FSX? Sorr,y you mean *without* ActiveSky running? If so, then I can only suggest trying to deinstall both your firewall and anti-virus program, as a test. Just deactivating sometimes doesn't help -- it seems to varyt depending on the program. Also check the firewall hints provided by Microsoft. Regards Pete

Thank you. Happy New Year to you! PMDG aircraft tend to do their own thing as far as their autopilots are concerned. If your assignments work with the default aircraft (try the 737) but not in PMDG it will be because those functions are implemented in PMDG's own code, separately and differently to the similarly named facilities built into FS. Check to see if PMDG have already provided keystrokes for those functions. Otherwise, if they've made them a mouse-only operation, to use the keyboard you would need to use something like Luciano Napolitano's "Key2Mouse" program. Regards Pete

Thank you, and a Happy Christmas to you and yours too! The option does not exist in FSUIPC4. There is no need to "uncheck" it as the action you are stopping isn't implemented. It was a fix for bad behaviour in some default and add-on aircraft in FS2002 and FS2004 using the default AutoPilot, I'd hope it was not needed in FSX. I don't carry over fixes for old versions of FS unless and until it is determined that the bugs they fix still exist. Do you know that FSX's default autopilot still exhibits the bug? If all you wan't to do is disable the 'fix', there's no need as the fix isn't implemented and won't be unless the bug is proven. Regards Pete

Something is blocking messages. Check your firewall settings both ends. Regards Pete

Thanks! You too! Pete

Thank you Frank. Of those three nice wishes, the first has zero chance -- but stem cell and other generic research may eventually help my grandchildren, if not my children (for the condition is heridary), the second is, well, okay at present though I think a lot will now depend on what Microsoft does to deal with FSX problems and performance, and, as for the third, well, that is most certainly an ambition and I will be making a Resolution to have at least one fun flight a week, if not one per day! ;-) All the best to you, Pete

You mean AutoBrake? Use the Buttons option page. Foolow documentation (User Guide, supplied with FSUIPC). The drop-down list of controls includes Decrease autobrake control and Increase autobrake control Regards Pete

Are these routed through FSUIPC4, or only assigned and set in FSX? That sounds like the response is so slow from SimConnect that FSUIPC4, as part of its work-arounds for SimConnect problems, is assuming the connection lost and re-connecting. If this is something that only occurs after some time, the only thing I can think it can be down to is a memory leak from FSX. I have heard mention that there are some, but I guess I've not been flying for long enough in one session to have them affect my system -- it would depend on memory availability and all sorts of other things in any case. Just to check this, maybe you could do a CTRL_ALT_DEL, Performance tab, and monitor the assorted memory values it shows. Do this near the start of the flight, then half-an-hour into it, then when the problem occurs, and see if any of the values simply keep increasing. Yes, but when are you checking these figures? FSUIPC4 (and most other add-ons other than pure aircraft and scenery) is 100% dependent upon SimConnect and, yes, unfortunately at present it does have more than its fair share of problems. Whereas most of the complex work of gathering, processing and setting FS variables via FSUIPC used to be down to me and code within FSUIPC, in FSX (and for the future), Microsoft have taken that responsibility on, and FSUIPC4 is well-behaved, following MS's rules, and using SimConnect for everything. When it works it will be an excellent solution, but I have already raised many bugs against it and I am pressing for an early fix. The menu entry is added initially, and then it will be after each lost connection. So far, in all the times I've seen a lost connection the menu entry disappears too -- in fact that was the first symptom that alerted folks to this occurrence. Whe FSUIPC4 re-connects it is like starting again, hence the menu addition. What will likely be hapening is that you are sometimes having a real broken connection, but sometimes it simply that the data from Simconnect has 2-5 second gaps in it (there should be something or other arriving from SimConnect at least once per second -- normally once per visual frame!). These gaps will be interpreted by FSUIPC4 as a broken connection, so it will re-initialise. I've not seen such gaps before. I can, of course, change my code slighltly to make sure that before re-connecting I send instructions to remove the menu and close the failed connection, but in all previous cases I've seen such calls wouldn't have worked because the connection was deemed closed by Simconnect in any case. I'll do this, but it is only a "tidy-up" action, not a fix for anything at all. From past experience with WideFS, slow downs in TCP/IP communication after a period seem to usually be associated with memory leaks, and I think that's the first avenue for investigation on your system, as I mentioned earlier. The FSUIPC4 log file merely confirms what you are saying about the time-outs and reconnections, but it doesn't tell me what Simconnect is doing. Could you see if you can get a SimConnect Log made, please. The instructions are in the "FSX Help ..." announcement above. For such a long test the Log will become absolutely massive. ZIP it and send to petedowson@btconnect.com, mentioning how long FSX was running before you noticed the problem -- that will help me get to that part quickly. Perhaps you could also try actually uninstalling ZoneAlarm, and see if that helps, as a test, please? Although you say FSX isn't "blocked", we have had cases where things did not work correctly in SimConnect until the security programs were uninstalled. If it doesn't make any difference you can re-install it. Otherwise you might consider using WinXP's firewall instead. You don't mention your anti-virus program at all. Whilst this shouldn't block things, these programs do tend to place hooks into the paths for TCP/IP messages, and this may well be another contributing facor. Again, as a test, it might be a good idea not to just dsable it but to uninstal it temporarily. Ah, but is that the same problem? In other words, does FSUIPC4 and SimConnect appear to be properly working except for the controls becoming disconnected? I would be most surprised -- the symptom of a blocked access is that FSUIPC4 cannot connerct to SimConnect at all, and logs a failure to Open. In such circumstances you wouldn't normally get a Menu entry at all, although in some cases I've seen the blockage only affect one direction - SimConnect to FSUIPC4, in which case before FSUIPC 4.061 the Menu would appear and then FSUIPC4 would time-out the arrival of data. By all means show me an FSUIPC4 and SimConnect log of what hapens with the firewall block in place if you think it is exactly the same symptom. BTW I notice in this Log that the first problem didn't occur until the 120th minute, almost to the dot! Strange timing coincidence I assume? Also, FSUIPC4 only seems to be allowing 1.3 or so seconds after re-connecting to see the first response. Possibly that's too tight -- I'll make the timing check a little more generous immediately after a retry. The only other thing I could do in the code is to allow the original response-time check to be extended (i.e. not allow Simconnect to have lapses in its response of more than 1 second). I don't think this is a solution for anything, more another way of finding out what is wrong. Since there are manay things needing updating much more often than every few seconds, I don't think such a change will make it flyable, it would just possibly show us how sssslllloooowwww things are getting. To that end i would add log entries noting the out-of-limits response time but only re-connect when another (parameter-set) timer had expired. I'm making a note of all these things, but I won't be able to make any changes to help till after Christmas now --i.e. next week some time. As I say, such changes won't fix anything, they may just help show more what is going on. Then a complete report, including your logs, needs to go to Microsoft. I'd recommend two routes -- I can send direct to the team, you would send via tell_fs@microsoft.com. But there's no rush on either as they won't look at them now till the New Year. Regards Pete

By "current" do you mean 4.06? Can you check please? I would like to see the FSUIPC4.Log, please, because the re-connecting change has worked fine for everyone else -- and it should only be a few seconds, at most, not minutes! You may not even notice it. If it isn't working on your system then something else is going on. Please let me see the Log. Regards Pete

Yes, if you ever need to. On some of my clients the WideClient.EXE is started automatically (from a shortcut in StartUp), and I use the RunReady and CloseReady parameters for the actual client programs. Basically, WideClient is running for the whole time those PCs are on, but the Apps only run when FS is running. Good. Regards Pete

Thank you very much. And a Very Happy Christmas to all my readers and users too! Best Regards Pete

Well, this line: would seem to indicate that it may not be a firewall (though that is still not clear). I think you should try the SimConnect repair suggested in the FSX Help announcement. Be sure to delete that folder. This line is interesting: "FUSIPC"? There's no mis-spelling like that it the program. Did you, by any changce, edit or hand-copy this file? (Not that it matters) ;-) Regards Pete

Ah. That's a good thing, not a bad thing! So the Install reported okay? If so, and you still get no Add-Ons, then please show me the FSUIP4.LOG file -- you'll find it in the FSX Modules folder. You don't need to attach it, cut and paste the whole thing into a message here will be fine. The problem will be one of two things: 1. Either it is a firewall or security program issue. With some products it seems merely switching these things off doesn't help, they sometimes need uninstalling. Or 2. It is a bad install of SimConnect. For this you should try to repair it following the instructions I give in the "FSX Help ..." announcement at the top of this Forum. Regards Pete

SimConnect stops sending data to all of its clients as soon as you start MultiPlayer mode. Microsoft know about this, they have reproduced it, and I confidently expect a fix some time in the new year. Meanwhile, the work-around I implemented some time ago in FSUIPC4 should get you over this, as it detects the lack of information and re-connects after a few seconds. You will just get a bit of a gap initially, after enabling MP mode. Easy -- please just regularly check the Announcements near the top of this Forum, where such things are listed and fixes and work-arounds provided. The FSUIPC4 re-connection work-around was implemented back in Version 4.04 back in November, so it does sound like you have a pretty old version still. It is best in these early days of FSX to try to keep up to date. The current User release is 4.06 (over in the Schiratti website), and there's an interim version 4.065 available in the Announcements above. Regards Pete

Hmmthat's a shame. Thanks, it is useful information. It hasn't cured it so much as avoided it. It isn't a solution at all, and the next add-on you install may make things go wrong again I'm afraid. It isn't just FSUIPC4 + Another Add-On, but almost any pair of Add-Ons if they are real SimConnect clients (some just use DLL.XML or EXE.XML as a way of loading only). The DLL.XML that works, the DLL.XML that doesn't, obviously each with an appropriate new name, and a description of the crash -- if there's any information with it (or does FSX merely disappear without a trace?). Thanks! I have reported this directly and added it to the MS bug list internally, but reports via tell_fs from "real users" help weight this bug compared to all the others they probably have to fix by now! ;-) Oh, please don't expect a reply -- there may be an automated one at best. Happy Christmas, by the way! Best Pete

The files just arrived. Only one of them was needed of course. The failing SimConnect log shows this (which you could have mentioned directly in answer to my first question -- i.e. FSCopilot.DLL loading as well): This is just about the most connon clash causing SimConnect to crash that has been reported. It first happened with FSUIPC4 version 4.01 or so I think, which was, of course, when FSUIPC4 was being loaded last instead of first. I changed FSUIPC4 to delay its Simconnect initialisation, and this work-around worked, then. However, having FSUIPC4 last in the DLL.XML file can give other problems, as I found later, which is why I changed the installer to put it first, in 4.061. The problem *probably* is that, loading first but with a delayed initialisation probably puts its initialisation on at the same time as FSCoPilot's. The StartImmediately=Yes parameter should be tried first, as I suggested. If that doesn't help, remove it and edit the DLL.XML file to put the complete FSUIPC4 entry at the end. i.e. move this part: FSUIPC 4 False Modules\FSUIPC4.dll to the end, just before the final line which reads Alternatively, disable FSCoPilot (rename the DLL or change its False line to read 'True' instead of 'False'. Until Microsoft manages to fix these problems with SimConnect crashing easily with multiple clients there are going to be these sorts of problems, and since they are all very timing-dependent there is no universal work-around. Regards Pete

Erit most certainly is a problem! Who told you that a missing SimConnect.dll was not a problem? FSUIPC4 cannot install if there's no Simconnect.dll, it is one of the essential checks the Installer makes. If FSUIPC4 won't install and says this is because of SimConnect.dll, then you will probably need to try to repair your FSX installation -- see the FSX Help announcement at the top of the Forum. When the FSUIPC4 installer fails, you have the opportunity to save the detailed install Log is displays on screen. Can you do that, then show vthe actual log in a message here so I can see exactly where the Install is failing? Regards Pete

The only change which can induce the Simconnect bug to change behaviour is the one which puts FSUIPC4 at the head of the list of DLLs to install. That was done in 4.061. That's what I understood you to say in the first place. The question I asked seem to be unanswered, i.e, you seem to have not read this part of my message: The error you are reporting has been reported before and it is all to do with the way multiple clients cause Simconnect to crash depending on timings during initialisation. I also said: Did you not see that part either? Sorry to have to repeat myself. I also said this: Did you try that at all? All this information is important to decide the correct work-around to use for these SimConnect bugs until we manage to elicit a fix from Microsoft. Why would I need information from three installs? The only reason for the SimConnect LOG is just in case there's extra information there, not already sent to Microsoft.I'll will look at it and advise you, but you need to report all this stuff to Microsoft via tell_fs@microsoft.com. It's the only way to apply enough pressure to get this all fixed! Perhaps you could please look again at my message and see if you can answer the questions, pretty please? It is very difficult trying to help else. Regards Pete

Sorry if the short-hand in the documentation is a bit obscure, but I expected folks to be using FSInterrogate, which does those calculations for you and shows original value and derived proper values so you can see exactly what happens, in real time. Have you tried that program at all? The documented formula "% * 128 * 65536" just means that 100% is represented by the value 128 * 65536 (which looks strange but is simply hex 800000). So 4230/19458 would be represented by (4230/19458) * 128 * 65536. The other way of doing it, of course, is to put that amount of fuel in the tank and seeing what the offset reads (either in FSInterrogate, or via the FSUIPC Monitor facilities). All the tools are provided for you to reasearch this sort of thing for yourself, and it isn't really so difficult. Regards Pete

Sounds like that installed a very old version of FSUIPC.DLL, losing the later one you had before. I really hate installers that do that -- you should write to them and complain! Simply install the current (and only supported) version. If you browse the Announcements above now and then you will see that it is updated regularly. You can always get the latest official release from http://www.schiratti.com/dowson . That is three years old and only ever worked with the original FS2004 release. You are evidently running the FS9.1 upgraded version of FS2004 which was not released until nearly a year after FSUIPC 3.040! Regards Pete

What other SimConnect clients are being loaded automatically? The FSUIPC installer now places FSUIPC as the first DLL to be launched instead of the last, which probably changes the timing of some of the loads and the well-known SimConnect bug of multiple launches comes into play. Check the DLL.XML and EXE.XML files and let me know. Also please see the FSX Help announcement, and get a SimConnect Log. We need evidence for Microsoft so they can fix this thing! Mind you, that change was made in version 4.061. When you say "all the previous FSUIPC version updates", did you possibly skip 4.061-3? There's a parameter you can add to the [General] section of FSUIPC4.INI which may also help may things work better, but it remains precarious. This is StartImmediately=Yes It make FSUIPC4 initialise the SimConnect interface immediately it is loaded, instead of waiting till FSX is ready. That used to work fine, until additional Clients were added. Regards Pete

Which "INI" file? All the files related to FSUIPC are in the FS Modules folder, next to FSUIPC. Regards Pete

Oh dear, it is a bit embarrassing to be right so often! ;-) Pleasing though of course, when it helps. Good. Happy flying! Regards Pete