Pete Dowson

Those indicators, where they work at all in default aircraft, are operated by code in the relevant gauges checking the conditions under which they are lit. All such conditions are discernible from examining other values. The same applies to add-on aircraft, only more so -- the very sophisticated add-ons do the whole logic like the real aircraft. This is also done, for instance, in pmSystems logic. I don't know how programmable FSBus is. Maybe you can still do it? Otherwise you'd either have to write your own logic, or use something like pmSystems. Regards Pete

Well, I can change it for FS2004 only and check to see if I can measure any performance impact. Or I can release it as an interim update and if no one complains it must be okay! ;-0 Leave it with me for now. I'm in the middle of a couple of other things. I'll get you an interim update done within the next couple of days or so If it isn't desirable I'll look at alternatives for you. Regards Pete

The only times this sort of thing has happened is when there's some other process going on in Windows which is interfering. We've never really solved it fully, but examples of programs which mess it up are Windows Blinds Kensington Mouse Drivers Faulty Video Drivers. I don't know why they interfere just with this part, which is only a standard Windows dialogue. Try running FS in Windowed mode. Otherwise it is a matter of eliminating other programs / processes / services one by one till the answer is found. Since you already have an FSUIPC registration, then to get round your problem you could open the FSUIPC.KEY file (in the FS Modules folder), and add the line "WideFS=xxxxxxxxxxxx" in the [user] section, where xxx... is your WideFS7 key. Regards Pete

But in those examples the heading changes not reflected in the ADF bearing were only a few thousandths of a degree (9 and 13 thou for the two sequences), surely not enough to register on any normal ADF gauge? Isn't thiss simply the result of an "epsilon" setting deciding whether the change is sufficient? I can delve into the code, but So are you saying that you notice jumps in a fast turn but not a slow one? Also "five times slower" doesn't mean anything useful in itself -- for instance, the heading could be changing several times per visual frame. It is a direct read-out from memory whereas the ADF data has to be read by calling functions in FS internals. I have looked at the code and the ADF data is read at the same frequency as most of the other "fast" variables I have to get procedurally: NAV radials, CDI, GSI, HSI, that's every 4th FS frame. For a good frame rate that should be barely noticeable, unless maybe you have a very much enlargened ADF needle display? I could "promote" these values to once per frame, but I am a little reluctant to do so because of possible performance deterioration. Could you explain more about your unusual needs please? Regards Pete

Are they so different from any ordinary controls? I don't have any of these. If someone who has them wants to provide a guide I will certainly host it. What is wrong with following the steps in the User Guide to do this? They are aimed at ordinary non-computer literate users and have been quite well received now for many years. Have you even tried? what is it you don't understand? I spent a lot of time writing and developing the user documentation. It really does upset me that no one reads it and wants personal tuition instead. There is really no way I want to repeat the same stuff here, but seeing as that is the best achieved in instruction so far, what else could you be expecting? Regards Pete

Where's the full Install log showing it, then? There are three versions of SimConnect -- RTM, SP1 and SP2. You should always have the RTM one istalled, as this is the only one guaranteed to be there (it is installed with FSX from the DVD), and it is needed to run FSUIPC4 -- and many other Add-Ons. The tools are different. The tools for RTM are loaded by RTM's SimConnect, The tools for SP1 by SP1's SimConnect and so on. There are different versions of the tools for each, and you have to have the right ones. I cannot afford such complications for FSUIPC. It would multiply the support load threefold. There is one current version of FSUIPC4 at any time. It is loaded by the RTM SimConnect (the only one that should, in a correct installation ALWAYS be there), and then it changes to the latest version it can find. Please refer to the FSX Help announcement and try to repair the RTM SimConnect as it says. Regards Pete

Only arithmetically from the aircraft heading and the relative bearing. Really? Never noticed that. I need to know which version of FSUIPC and FS you are talking about, and the actual offset you are talking about would help. Tell me more about versions (information always needed!) and I'll check. I did change the priority of a lot of values recently. I don't want to delve into code unnecessarily, nor, indeed, the wrong code! Pete

You appear to have lost SimConnect, which is needed to load and run FSUIPC and most other add-ons for FSX. Please see the FSX Help announcement above. You need to reinstall/repair SimConnect. Regards Pete

Not quite right there. The 0BDC offset is the standard flaps control value. 0BFC is the flaps INDEX number. 0BDC dates back as far as FS98 and Adam Szofran's FS6IPC. It is one of the originals, reflecting values which were actually at these offset in the FS98 GLOBALS.DLL. As is made perfectly clear in the FSX Offsets documentation, the 0BFC value is new to FSX -- that's why it's listed in Blue. Please do refer to the documentation supplied for all these things. Well, for 0BDC it sounds like he's doing something wrong. How's he checking? Easiest way is to use FSUIPC's monitor -- right-hand side of the Logging options, enter offset 0BDC and type U16. Check the "Advdisplay" option, and it will be shown in real time on screen. The offsets list shows it as 4 bytes, but in fact only the loer two bytes, i.e. 16 bits, are used. Regards Pete

Well, the memory certainly shouldn't be the problem (unless some of it is playing up). but Vista SP1 is something I don't know about. There have been a few folks mentioning problems with SP1, though they might have been using a Beta. Are you? I don't have SP1 here yet -- when I look for it I'm told it isn't available till mid-April, and the my automatic update setting will take care of it in any case. All add-ons, or only some? Re-introduce them one at a time. Regards Pete

But are you sure those were not running anyway? As I said, cleaning the Registry won't stop them. You'd have to explicitly delete the EXE.XML and DLL.XML files, or remove the modules they were loading. Ah, yes, so it is! Sorry. How much memory do you have? Which version of Windows are you using? Regards Pete

Okay, I received the logs. The one from FSUIPC doesn't really show anything wrong, other than the premature termination of course. If does, however, show that you FSX is first loading a default flight with a non-default aircraft: 3666 C:\Program Files\Microsoft Games\Microsoft Flight Simulator X\FLIGHTS\OTHER\FLTSIM.FLT 3666 C:\Program Files\Microsoft Games\Microsoft Flight Simulator X\SimObjects\Airplanes\Aircreation_582SL\Aircreation_582SL.AIR It would be sensible, for elimination purposes, to start FSX up with default data, in case any of the add-on parts are corrupt. Is that add-on FSX-specific, or transferred/converted from FS2004? I know you changed then to a different aircraft: 24180 C:\Program Files\Microsoft Games\Microsoft Flight Simulator X\SimObjects\Airplanes\C208B\Cessna208B.AIR but by then the damage may have been done. The only way to be sure you are not constantly reloading something which is causing corruption is to delete your FSX.CFG file and let FSX make a new one. If you have too much invested in that and don't want to lose settings, then either delete or edit FLIGHTS\OTHER\FLTSIM.FLT so that the third party aircraft is not loaded. Looking at the SimConnect log, I see that there are other SimConnect clients loading: 0.25883 Exe Launched: Path="C:\Program Files\FSForce 2.0\FSForce.exe" CommandLine="/FS" Version="2.0.5.0" and 1.68951 DLL Loaded: Path="C:\Program Files\FSForce 2.0\FSForce.dll" Version="2.0.5.0" These are loading by virtue of entries in your EXE.XML and DLL.XML files, respectively. You didn't mention these in your orginal report. And when you said "Removed FSX, cleaned registry, reinstalled FSX", you should note that "cleaning the registry" doesn't remove much to do with FSX at all -- only its install path really. Most of its data is kept in assorted Application Data folders, in the Documents and Settings areas -- separately for CFG, XML and Scenery configurations. You probably didn't remove all of those before the reinstall. I don't know what FSForce does, but as part of the process of elimination, try without it. There's a freeware program which makes enabling/disabling EXE and DLL modules easy -- download the DBS FS Startup Editor (see http://www.dbsim.com/). I see TrackIR is also running -- looks like a new version, as, like FSUIPC4, it is using SimConnect's "named pipe" interface (added in FSX SP2/Acceleration). The FSForce programs are both using the old less efficient SimConnect interface. I use TrackIR also, so it looks like I should go look for the newer version. The only othe interesting info in the SimConnect log is related to that Exception 2 you referred to earlier. See, here, at 39 seconds into the session: > 39.95232 [ 1, 2383]TransmitClientEvent:ObjectID=0, EventID=66387, dwData=-16383, GroupID=1, Flags=16 < 39.95234 [1] Event: Group=2 EventID=66387 Data=-16383 > 39.95235 [ 1, 2384]TransmitClientEvent:ObjectID=0, EventID=66388, dwData=-16383, GroupID=1, Flags=16 < 39.95237 [1] Event: Group=2 EventID=66388 Data=-16383 These are two events setting Left (66387) and right (66388) brakes, respectively. no error, perfectly good. They re-occur regularly without problem. However, much later (3 mins 42 secs): > 222.61162 [ 1, 11209]TransmitClientEvent:ObjectID=0, EventID=66388, dwData=-16383, GroupID=1, Flags=16 < 222.61164 [1] Event: Group=2 EventID=66388 Data=-16383 > 222.61165 [ 1, 11209] < 222.61166 [1] >>>>> EXCEPTION=2, SendID=11209, Index=0 <<<<< Unrecognized Data Received. [ 1, 11209] SimConnect reports a data error on the same Right Brake setting? I can only think this is an indication on some memory corruption -- named pipes operates through shared memory. This isn't where you get the crashmany more working exchanges with the Right brake occur before then. The log simply peters out at the point of the crash, there's nothing spectacular, nothing indicating anything wrong. Quite honestly, from the varying reports from Windows about where the crash is occurring, plus that very suspicious Error 2 for no reason, I would suspect one of two things: 1. You are running out of real memory during the FSX session. FSX is not very good at dealing with memory shortages and they do often tend to cause crashes in different places, or 2. You have a problem with one or other of your memory chips. Maybe they are not seated correctly, or getting too hot, or have rather precarious timing settings on them. By all means try the process of elimination I mentioned. You already did that with FSUIPC, reducing the memory load, maybe the other add-ons also increase the loading. The other thing is added scenery -- meshes, landclasses, etc etc. They all help to increase FS's demands for memory. Regards Pete

That's weird. The only thing I can suggest is that you go to http://www.sysinternals.com and get the free diagnostic utility "filemon" (http://technet.microsoft.com/en-gb/sysi96642.aspx). Run that before running FS. It will generate a lot of entries so set the filter to "FS9.EXE" (or whichever FS it is) so that it only shows actions from that program. Erase the list then run FS. If you can't see what is happening, save the results to a file, Zip it up and send it to petedowson@btconnect.com. Hopefully I'll be able to see what is going on. Regards Pete

Okay, but it is getting late here & I'm off to bed, so there may be a few hours delay ... Regards Pete

It means the the code signature placed on FSUIPC for security against corruption does not check out. Either the DLL is corrupted, or virus-ridden, or something is missing in your system needed for the check. The helpful part saying "Try applying the supplied Global SignRoot Fix." is actually normal everyday English, and it means that you should try applying the supplied Globalsign Root fix. "Supplied" here means that it is actually included in the ZIP file you downloaded, the one containing the FSUIPC.DLL. Did you not even bother to look? This is documented in the FSUIPC User Guide, also in English. Please take a moment to look at it. It would save us both time and frustration. The relevant part is in a Box labelled "IMPORTANT" right at the begining of the section on "Installation". I do write this stuff for a reason, you know. :-( Regards Pete

Nevertheless, the parameter files (configs) should still be saved. If FSX really isn't terminating correctly, albeit after many seconds, you need to find out which it stopping it. it will be a Gauge or DLL, not any external EXE. You'll need to go through a process of elimination. First, eliminate the possibility that it is one of the gauges in one of the aircraft you are using. Assuming your default flight loads a default aircraft (if it doesn't you'll need to change that), have a session where you only use default aircraft, no add-on ones. See if your button settings are saved okay. If so, it is one of your asircraft causing the problem. Then, assuming you don't find it that way, list the DLLs which are being loaded -- the DLL.XML file controls those (in the same folder as your FSX.CFG file). Disable one at a time until you find the culprit. If I were you, to make this easier, download the DBS FS Startup Editor (see http://www.dbsim.com/). That makes this part much easier! Regards Pete

What do you mean "enabled all FSUIPC logs"? Please do not! FSUIPC produces a log in any case, and any serious problem will be logged in there without you messing with any of the options. This means nothing in isolation. Please never bother to extract single lines, if you want me to look at a log, show me the log -- the complete log, beginning to end. You have simply enabled an option which confirms that you don't have either the PFC or Epic drivers installed. They are optional logs precisely because they are not relevant to most users, but help identify problems for those who do use such things! I'm not aware of any problems in those, but it is sounding as if you have a corrupt FSX installation. If you want me to check further all I can suggest is: 1) uncheck all those superfluous FSUIPC logging options you have selected. 2) Set up to get a SimConnect log (those size mismatch errors may not be true errors, but the details about them will be in the SimConnect logging). To get a SimConnect log see the FSX help announcement above. 3)Run FSX until the crash. Find the SimConnect log and FSUIPC log and ZIP them both, send to petedowson@btconnect.com with a description of what you were doing. Regards Pete

It sounds like FSX isn't terminating correctly -- it only saves config changes when it closes, so if it crashes out instead you don't get its CFG files updated. Does this happen with other options in its menus too? If so then that's confirmation -- something you've added is not allowing FSX to terminate correctly. After you close it, look in the Process list in task manager (Ctr_Alt_Del) for FSX.EXE. If it is still there after a number of seconds, it isn't terminating correctly. Regards Pete

It does the same as the AP_PANEL_HEADING_ON/OFF controls, as appropriate. When turning this on it sets the flight director to use the current Panel (bug) setting. No, the FS control for that is AP_HDG_HOLD. This would also change the bug to the current heading. To do this via the 07C8 offset you'd first set the current heading to the AP Heading offset (07CC). Alternatively just send the FS control via offset 3110. Note that you can easily find out what controls do what by using the Event logging in FSUIPC, and checking the Log file. Regards Pete

I don't know. This is a facility I use all of the time, with never a problem. The command line is used exactly as you enter into the line -- the "Error 2" simply means "file not found", and this is what Windows is telling FSUIPC at the time. Could you show me the INI file and the FSUIPC.LOG file from at least one of these, please? Regards Pete

Glad you fixed it. I suppose I've developed a bit of a persecution complex over the years! Regards Pete

Isn't there a message in the title bar telling you why? It sounds like you are not running as an Administrator. Please check the documentation. Regards Pete

You've made some mistakes with assignments, then? Delete the FSUIPC4.INI file and let it generate a default one. The default trim keys are 1 and 7 -- the 2 and 8 normally operate the elevator itself. It sounds like your FSX assignments themselves are in a mess. Have you checked? Anyway, unless you've got those keys assigned for something else in FSUIPC, this really can be nothing to do with it. Maybe it is something to do with those aircraft. Did you check with a default aircraft to see? Well, that must be pure coincidence. Something else has changed, for sure. No. There is no reason to go back. It will make no difference whatsoever. There is an interim update (4.264) in the FSX Downloads announcement which you can try too, but there certainly isn't anything these which would affect this either. Everyone always blames FSUIPC for everything. It is very depressing. :-( Regards Pete

Ah. Glad it wasn't too hard. ;-) Pete

Actually, that isn't the problem. That's only the UDP server failing to start: Since you are probably using TCP that wouldn't stop it working. What does stop it is this: Now I've never seen either of these errors ever before. WideServer is merely relaying the errors it is getting from Windows. It loooks like you have no network working, possibly no active network adapter, etc. Best to try to get your network really working properly then try again. Incidentally, why are you putting these parameters into the Server's INI file? The server supports any of the three protocols, the choice is made by the Client. And why would the Server need to be given its own IP address? Are you reading the documentation and making your own mind up about what to do? If you've been messing with the INI files, best to delete them and let them default again. Regards Pete