Pete Dowson

One thing that occurs to me which makes it more important to try 4.156 before "retreating" to FS9, and that is that the problem could, just possibly, be related to the business of axis interception, and loops which Simconnect could be made to perform depending on how you use FSUIPC's joystick calibration and axis assignment facilities. This area has been specifically improved in 4.156. If you don't use either of these then I don't think it will make much difference, but it is still worth trying. Please let me know. Regards Pete

No, sorry, I saw that, and ignored it, because Emile did NOT actually say that. Please go back and re-read. He had a crash then went and looked. He never said "only". You can go look at the event log and find every single time you loaded FSX, with FSUIPC -- 4.152 or later -- installed, you will get those errors. It is actually impossible not to unless you have the appropriate SimConnect Betas installed. Please do read my explanations of why this is so. Regards Pete

Well, the log certainly shows that something you are running is clogging up SimConnect, well and good: There's really nothing I can do with that -- either your aircraft add-on isn't working very well, or there's a problem in SimConnect, or it is just that your PC cannot cope with what you are asking it to do. To check on the first two I'd need to see a SimConnect log. For this please see the "FSX Help" Announcement above -- when you have a log, ZIP it up (it will be very large) and send it to me at petedowson@btconnect.com. I should be able to tell if it is a SimConnect or add-on problem. Not that would be any different with this, no. Actually there's a later version -- 4.156 -- from the FSX downloads above. Try that, by all means. If it helps at all it will be because of something the add-on aircraft is doing. I'd like to understand thatr, so a Simcopnnect log would still be useful, please. Why? Is it so essential you use this add-on aircraft, if it is only that causing the problem? Is it one designed to work in FSX by the way? If not it might be an incompatibility problem in the first place. Regards Pete

Okay, please let me know how you get on. Really, it is a bad sign if the time-out is occurring, and extending it as a work-around, whilst getting you past the problem, is not an ideal long-term solution. Hopefully updates to FSX will alleviate this sort of thing, but in the end it is a processor limitation. Regards Pete

Unfortunately there appears to be no provision for preventing these log entries, nor is there a facility I can use in Windows XP or Vista which allows me to check for a valid SimConnect version without actually "trying" its context, which produces three Error entries each time. Basically, therefore, there will always be a multiple of three "Error" entries whenever FSX is loaded with FSUIPC4 present and the latest version of SimConnect which that FSUIPC4 version supports is not installed. To understand this, look at the current set of SimConnect releases understood by FSUIPC 4.156 (this will vary depending on FSUIPC4 version): 1: Acceleration update (add-on), Beta1 2. Acceleration update (add-on) Alpha 3. FSX update SP1 4. Original release It tests for these in that order. Since only Beta testers will have the first one or two, currently there will be 6 "Error" entries, 3 for each of those two. If the user has not installed SP1 there will be 9. When the Beta period is finished and Acceleration is released, a new version of FSUIPC4 will be provided which will have only these listed: 1. Acceleration update (add-on) 2. FSX update SP1 3. Original release Then those who purchase and install Acceleration will get no error entries, those with SP1 as the latest will get 3 entries, and those with only the original installation will get 6. When the next update for FSX (SP2 or DX10?) is available the list for the matching FSUIPC4 will have that as number 1. I'll leave the Error counting to youyou can see how it goes by now. And so it goes onthe big advantage is that FSUIPC4 will continue always to work with older versions of FSX whilst still being able to take advantage wherever possible of the latest changes. This is the purpose of the SidebySide installation system. The only disadvantage, it appears, is the appearance of these Error log entries and the annoying confusion it creates for those users like you who look for them. Maybe I need to document this someplace, though getting folks to read documentation is difficult anyway! ;-) Regards Pete

Both 05EB and 05ED are documented as 1 byte offsets, yet you are writing 2 bytes for 05ED. The second byte will cause something to happen at offset 05EE, which controls the pitch. You said that the roll and yaw were affected, which seems odd. Are you sure it isn't a high speed pitch change? Try using 1 byte writes of 05EB and 05ED then get back to me. Regards Pete

It should certainly all work well in FS9. I have an Aerosoft GA28R cockpit with a driver which uses those offsets to provide slewing facilities using the yoke, and that works fine. Do you perhaps have any axes assigned to slewing which may be off-centre when slew mode is engaged? Just check that setting slew mode from the keyboard ("Y") doesn't do the same. Else, I await the Log to see what is happening. Regards Pete

Is this with FSX or FS9? If it is in FSX it may well be my error, as these have not been fully tested yet, I'm afraid (there's been so much to test/develop still!) Could you please enable IPC write logging, and also set the FSUIPC monitor to monitor 05E4 (type S16), 05E6 (S16), 05EB (S8) and 05ED (S8) to the normal log, then reproduce the problem and show me the LOG file? Also, as soon as you confirm FSX (or not) I will try to check it here. Regards Pete

Amazing! Well done! :-) Pete

This sounds like the data being sent to FSUIPC4 from SimConnect is being prevented from arriving in the time allowed. By default, if FSUIPC doesn't receive data about the user aircraft at least once per second (except when in Menus and the like), it assumes Simconnect has disconnected, and so reconnects. It does delete its menu entry and re-set it, but if the earlier connection is broken obviously the deletion of the original entry won't work. Please check the FSUIPC4.LOG file, which you will find in the FSX Modules folder. It will show exactly what is going on. It may be that the aircraft you are loading is putting a really heavy load in FSX, possibly also Simconnect, and generating periods exceeding a second where nothing much else gets done. Does this seem feasible from what you see? Are you getting good frame rates with this add-on aircraft, or does it vary a lot? It may simply be overwhelming your processor. Are you using FSX + SP1? If you haven't yet applied the SP1 update for FSX, you should do so. It is rather more efficient. The next update for FSX should be even better still, especially for Simconnect clients such as FSUIPC4 (when I can get a matching update out to take advantage of it). Meanwhile, you could try making FSUIPC4 more tolerant of bad performance by changing this parameter in the FSUIPC4.INI file: SimConnectStallTime=1 This sets the 1 second time out. Try 5, say. If that fixes it, try 3, then 2. You want it as small as possible really. Regards Pete

Of course. The side-by-side "assembly not available" errors will occur every time you load FSX with FSUIPC4 installed. They merely refer to the versions of SimConnect which FSUIPC can handle but which you don't have installed. Please check the times of those entries. Please yourself, but I think you'll find that it is completely and utterly irrelevant to your problem. As I already explained, if you'd care to refer back, FSUIPC looks for a number of different releases of SimConnect, and uses the one it prefers from those it knows. In the course of checking their presense, Windows in its wisdom, logs these errors. They mean exactly what they say, that FSUIPC has tried to connect to a specific version of the DLL and failed (because it isn't present) -- that error is actually returned as a result of the calls FSUIPC makes and this tells it that that version isn't present, so it proceeds to the next one. It is absolutely nothing to do with any SDK -- the SDK isn't even provided to FSX users of the non-Deluxe version. FSUIPC 4.156 supports 4 different versions of the SimConnect.DLL. This will vary from release to release as Beta versions are superseded, but on the whole it will simply grow. The "Acceleration" expansion pack option will add another, as will the DX10/SP2 update later. Since it worries you so much I will have a further look to see if the error can be prevented from going into the Log, but even if there is a way of doing it, it won't change anything else about what FSUIPC4 has to do in this area. You please yourself what to believe. You are misinterpreting what you are reading, or simply not reading what I am writing, so there's no point in me trying to say much else really, is there? Pete

Sorry, I've no idea. Does BlueTooth look like a normal serial port to applications? If so GPSout may be able to send to it if you have the port name (COMx perhaps?). What might be more difficult is telling the other end how to receive it! Regards Pete

Your yoke must be on the PC running FSX. There is no advantage to having it on a Networked PC -- in fact there is a disadvantage in that the latency (delay) in the action in the aircraft of manipulating the main flight controls will not be acceptable, except possibly in the more normally sluggishly-responding aircraft. Buttons, switches and so on are supported via a network through WideFS, but I don't support analogue axes that way for the above reasons. Regards Pete

The log explains the Button on line 13: 2119891 [buttons] 13=R1,32,C65734,0 2119891 FS Control Sent: Ctrl=65734, Param=0 2119891 *** EVENT: Cntrl= 65734 (0x000100c6), Param= 0 (0x00000000) PAN_UP It was button "32" on joystick #1 (that's the second one down in Joyview). FSUIPC follows FS2000's (and before) convention for numbering Hat positions from 32 (Forward, or North) clockwise through 45 degree steps to 39 for Forward Left, or North West. You had the North/Forward position of the Hat programmed to send C65734 (PAN_UP) and to repeat whilst held. The problem appears to be that this hat position is permanently held. That is wrong. When released a Hat should return a "released" or "null" value (actually 65535, as would be shown in Joyview, for instance). I think this would explain the problem in CH's "mapped" mode too -- I suspect it does the Repetition of the Hat Forward indication itself in that mode, so providing a constant repetitive "button pressed then released" indication, effectively hanging FSUIPC's test loop. Basically, you have a faulty Hat which appears to be stuck in the "pressed forward" state. Maybe there's some gunk in it causing a short, or it's spring or whatever is bent? Worth checking to see if it is easy to repair. Use that "Joyview" program to see what it is doing. Normal values are: Btn Direction Value 32 FWD 0 33 FR 4500 34 R 9000 35 BR 13500 36 BCK 18000 37 BL 22500 38 L 27000 39 FL 31500 OFF 65535 The fact that FWD is a value of 0 does strongly suggest a short circuit, so it may actually be in the wiring someplace rather than the hat itself. Regards Pete

Same here. Nevertheless, when I open them, and check the "joyGetDevCaps()" entry, several of them show values, including a "product name" -- for example "Microsoft PC-joystick driver". Not sure why "None" is shown in the main folder-type section -- probably something different in XP. The program is really a Win95/98 one. Open each in turn, see what you can find. You need to open them and select "joyGetPosEx()" to see values being read, including buttons. If a button or hat (whether real or not) is constantly triggering (i.e. going on and off) it will certainly keep FSUIPC's scanning in a tight loop, as it is designed to react to the last such change -- when there's always another change it will re-display it, even if it is the same as before. See what you can find. I could probably code around a continually repeating button/hat input, to avoid hanging FS, but I can't think how I would be able to get to other buttons for programming then if that keeps taking precedence. It would need some thought -- it certainly should not be happening (and in fact I've not had such a case in the 8 years of FSUIPC's button scanning). It must be a fault someplace, assuming it isn't a rogue driver. Regards Pete

FS only provides a normal analogue throttle, not a fly-by-wire discrete mode selector. Anything simulated like that by the add-on with have controls determined by that add-on -- maybe there are keystrokes, or maybe it determines them by using little ranges of values in the "real" analogue throttle inputs. I don't know. You'll have to check its documentation. Either way you should be able to handle it. Regards Pete

Oh, one thing which may help identify the problem is the attached small program, "Joyview", originally from Thrustmaster I think. This uses the same scanning system as FSUIPC and may give you more information, such as the driver name and so on, if it doesn't cause it to hang too. Regards Pete joyview.zip

This sounds very much as if you have a driver installed for a device which isn't present, and the button scanning is causing that to hang. In FSUIPC4 the buttons tab scans using an older Windows API whilst the axis assignments uses DirectInput. (In FSUIPC3 both use the older API). Check in Windows Game Controllers, see if there's an old unwanted driver still installed. Regards Pete

So you can program a button to use the FSUIPC added control "Offset Byte Togglebits" with Offset x7b91 and parameter 1. Alternatively, if you are programming a switch instead, use "Offset Byte Setbits" to set Stby and "Offset Byte Clrbits" to set Normal, both with offset x7b91 and parameter 1, again. I think this is easy enough without needing a specially named control as well, don't you? Regards Pete

Yes you can and yes it will. You need to register it properly, not simply copy the KEY file over. If it isn't working it is because you are making an error somewhere. Make sure all three parts (name, email, key) are exactly correct -- cut and paste from the original notification is best. Also make sure the system date on that PC is correct, or at least certainly not earlier than your original Registration purchase. Pete

Good. You should know, however, that a corrupted FSUIPC will always be detected as it is code-signed and the signature is checked on every load, so it could not actually be a corruption of the DLL itself. The updated graphics driver may well have had something to do with it, though the fact that your crash was in WEATHER.DLL also suggests the possibility of a faulty weather download or weather (WX) file on disk. The only reasons the presence of FSUIPC may have exacerbated such a problem are (a) that it reads the weather via SimConnect regularly, possibly unlike the other things you had loaded, and (b) that its mere presence would change timings and memory arrangements slightly, possibly revealing a bug elsewhere. Additionally, the weather characteristics would of course affect graphics (in the cloud renditions) and this in turn relates to the graphics drivers. Incidentally there is a later version of FSUIPC (4.156) available in the FSX downloads, above. This is a Release Candidate for 4.16, which I will be releasing properly before the end of the month. Regards Pete

Yes, ignore the "Side by Side" errors. These are all a result of FSUIPC4's flexibility in selecting the best of any number of SimConnect side-by-side DLLs you may or may not have installed. In your FSUIPC Install log you will see a list of SimConnect versions you have installed. Each time the Install runs, it tests for the presence of each version it knows about and lists them. That process in itself unfortunately creates these error entries, which are irrelevant -- it merely means that the installer issued a Manifest Probe for those versions which failed because they are not installed. Similarly, when FSUIPC4 runs (it is manifested to the original SimConnect DLL so that it can get itself loaded), it checks for the latest versions it knows about, and works backwards until it finds one it likes, then links to that. The same Manifest Probe produces the same errors. The alternative for FSUIPC4 would be to have a different version for each supported version of SimConnect, which would be intolerable. I think this marks a deficiency in the way the SidebySide system works, as it does not differentiate between an error caused by "trying" from an error caused by "doing". Maybe it should have a separate API for "trying". But that won't occur now in Windows XP. We'll see what Vista SP1 brings -- but then, more incompatibility. :-( Meanwhile, don't worry about it. It does no harm other than helping to fill your disk with a little more unnecessary logging -- and it has actually been occurring since version 4.10 of FSUIPC, which was the first version with the flexibility to cope with multiple SimConnect installs (because of the release of FSX SP1). Regards Pete

But not FS controls, which would be an easier choice. Of course any of the FS controls can be sent by writing its number to offset 3110, so all is still possible. Well, deleting the keystroke assignment in FS will free that keystroke but won't help if your driver is trying to use that very one to invoke the function! Really, for a much more efficient and reliable system I would advise programming all of your functions as FSUIPC offset writes. There's a list of FS controls available for every FS version since FS98, so you can re-program any keypress as an FS control write to 3110. An alternative way, which might be more attractive as it is more versatile (more easily re-programmable, including use of FSUIPC's aircraft-specific and button programming facilities) -- is to program each of your switches/buttons as a "virtual button" (a bit on any of the offsets from 3340 to 3363). This is how I provide programming facilities in FSUIPC for any button/switch on PFC equipment -- the PFC driver simply toggles bits in a similar (but different and reserved) area. These then show up as regular buttons in the FSUIPC buttons tab. Sounds like buggy software. Sorry, but if you want to go that way I think you need to deal with their support, and get their driver fixed. Regards Pete

I don't really understand all of that, I'm afraid. Are you saying that the driver software ("InterfaceIT"?) drive functions in FS either by keystroke or button pressing, if so where does FSUIPC come in? Or is this all about FSUIPC? I assume that "switch" is actually a button? If you are using what I call a switch (something with more than one position, on and off), it would make more sense to use the Autopilot On and Off controls instead. Where are you assigning these keystrokes? You know that you can assign keystrokes in FS as well as FSUIPC, and presumably now in your "InterfaceIT" program? There's a lot of places for keys to be re-interpreted! Really, for all FS functions, I'd recommend using FS controls all the time -- more efficient and not liable to interception/change by assorted facilities and other programs. The main use of keystrokes is for third party add-ons which don't, of course, provide the equivalent of FS controls. If you aren't assigning keystrokes in FSUIPC then it isn't doing anything to conflict. But by all means use the Logging facilities provided in FSUIPC to not only log keys but also resulting controls -- see the options on the left-hand side of the Logging options tab. Regards Pete

What action is needed, exactly? Sorry, I don't recall and don't have the reference to hand. Isn't it a simple matter of toggling a bit in an offset, something that can already be done with one of the Offset Byte controls? Regards Pete