Pete Dowson

You have ESP installed? FSUIPC seems to be using the ESP SimConnect in a copy of FSX which hasn't been updated to SP2, probably because the ESP one is more up to date. Whilst I've fixed, here, the problem of FSUIPC4 trying to use an ESP SimConnect on FSX, in the process I also found a new little bug (in the combined FSUIPC4 / ESPIPC which FSUIPC4 has now become) which could mis-identify SP1 as ESP SimConnect, in the absence of SP2. So I won't be surprised to learn that you've never installed ESP! ;-) I will be uploading another increment over the weekend with these things fixed, but as I don't see where to make any changes which affect your throttle problem directly, I would like to see the full logging as requested first. We'll take it from there. Regards Pete

Further to this: One of your earlier logs did indicate that at least SP1 was installed and working If I remove the SP2 SimConnect, I can reproduce the load and failure of the ESP SimConnect here, so I can certainly stop that by some extra programming, but it recovers okay here and uses SP1, not the Base version: Running inside FSX (using SimConnect ESP Orig) Module base=61000000 Wind smoothing fix is fully installed DebugStatus=255 1031 System time = 11:03:12 1047 FLT UNC path = "\\LEFT\FSPLANS\" 1063 FS UNC path = "\\LEFT\G\fsx\" 5000 LogOptions=00000000 00000001 5406 Failed on SimConnect_Open, return = 0x80004005: FSUIPC4 cannot operate! 5406Now trying to connect to another version of SimConnect ... 5563 Now running with SimConnect SP1 May07 5563 SimConnect_Open succeeded: waiting to check version okay 18438 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) So i'm now wondering whether you might have a broken SP1 as well as an uninstalled SP2? Maybe you need to try re-installing SP1 and then adding SP2? Regards Pete

Yes, you can't get at a file's real properties without extracting it. It is indeed most strange. Regards Pete

Well there's no difference in any version of FSUIPC if you assign to FS controls, because it merely sends the AXIS controls to FS as it receives them. The path through FSUIPC is very short. This is completely inexplicable, and there's not really any logging I can add apart from that which I already asked for. Something may be wrong with your INI file editing, then, because the logging you show is just the default + Axis logging you provided before. It certainly is NOT with these lines Debug=Please LogExtras=2056 The lines showing: LogOptions changed, now 10000000 00000001 show that the "2056" value didn't take -- or you cleared it in the Logging options, but why would you do that? ErOuch! Why are you going into the Logging page? I merely asked you to add the above to the INI file before loading FSX, then do the tests. It looks like you pressed some buttons in the Logging page -- at least "New Log". Why? Please, when running tests for me, never push any buttons or change any check marks or numbers unless I ask. There's certainly never a need to Start a New Log as you've done. If you did add those lines before loading FSX, it certainly looks like you then went into the Logging page and turned the Extras logging off that they would have enabled. considering the test you accomplished was identical to previous ones, with the same logging exactly, this is rather odd too. This is interesting (I hadn't read this part before): Have you not installed FSX SP2 yet? It fixes a lot of SimConnect problems, and is 100% more efficient for programs like FSUIPC -- especially with PFCFSX on top. Do you think you could try updating your FSX? Or is it installed but the SimConnect part broken? This is even more interesting: You have ESP installed? FSUIPC seems to be using the ESP SimConnect in a copy of FSX which hasn't been updated to SP2, probably because the ESP one is more up to date. This same log shows some SimConnect initialisation problems as a result: This is a result, I think, of FSUIPC trying to use the ESP SimConnect. Apparently you can use an FSX SimConnect with ESP, but not vice versa. I'll need to look at how to prevent FSUIPC trying, as I didn't realise that. (This wouldn't have noticed before, as this is the first release of FSUIPC4 combining FSX and ESP support). Even stranger, then, but possibly a side effect of the above: One of your earlier logs did indicate that at least SP1 was installed and working: Curiouser and curiouser ... I'll investigate the misuse of the ESP SimConnect. Perhaps you could try tests (a), (b) and © again, separately (so separate logs), with the logging I asked for (and no entry into the Logging page please!), and also perhaps contemplate installing SP2. Oh, please include PFCFSX in all tests, but do try disabling the throttle quadrant in the way I suggested for the aircraft in which you are using the Saitek. Regards Pete

Just the 5 main program files, you mean, as there are 15 files there altogether, plus of course the two PDF's listing the FSUIPC changes. Strange! All of the Zips I upload, both here and in the Schiratti site, are Zipped using standard default options in WinZip version 10.0, which makes them fully WiinXP and Vista compatible. If the DLL will extract, you can certainly verify the extracted copy by right-clicking on it, selecting Properties--Signature, selecting the signature and pressing "Details", making sure it says it is ok. If there's anything wrong at all with any of the uncompressed bits, it will make the signature fail -- that's what it is for, to prevent tampering and to ensure that what you get is what I made. As well as checking the file by downloading (I use FireFox) and unzipping using WinZip, I've also just checked that WinXP can see it all and extract it al properly too. I'm really not sure how it could be different on your system. Do you want me to email you the ZIP to see if it's something going on en route from the SimFlight server? Regards Pete

You can't, now. It's been superseded. The current interim update is 3.869, try that -- and it is, as usual, in the Updates announcement above with all the other goodies and useful information. I did tell you in any case, please reread my message before, it clearly said "from the updates announcement above"!!! Don't you ever scan the Announcements at all? They are there for a reason. That's where I try to keep folks informed! :-( BTW, the only "official site" i maintain is this one. The main releases go to Enrico Schiratti for him to put on his site (http://www.schiratti.com/dowson) because that is historically where all my Fs programs have been collected, and there are lots of links to it. But that only gets the main releases with full documentation. All the updates and fixes have come here first and have done so for nearly 5 years now! Pete

Okay. Then it is either (a) The problem of arbitration, which should be fixed in 4.432. However, if it was then the original test (b) should have worked, because sending the FS control rather than using direct FSUIPC calibration doesn't go through the arbitration code, or (b) You had not disabled the PFC throttle quadrant so its settings were always overriding those of FSUIPC or FSX. However, that doesn't make a lot of sense either, because the log definitely showed that no throttle controls were even being sent by FSUIPC -- this could not have been stopped by PFCFSX even if it could override their effect in FS. So, I'm plumping for (a) and the assumption I have to make then is that your report of the outcome of the original test (b) was mistaken. If you were not, then no explanation appears possible. The proof is in the pudding. Try 4.432 with PFCFSX re-installed. It includes extra logging which will show me what happens in the arbitration code. To enable this, before running FSX, add these lines to the FSUIPC4.INI file (in the [General] section): Debug=Please LogExtras=2056 (If you already have these, just change them to match this. You may already have a LogExtras= line). Also, please make sure Filters are off in your FSUIPC calibrations -- those will confuse the logging too much (they lengthen the input to output chain by several cycles). I only want to see the log if there's still a problem. Try with and without the PFC quadrant disabled (you can only do that by enabling and assigning a completely blank User Config to the aircraft, explicitly). Regards Pete

FSUIPC has no such message as "IPC timed out on all retries" -- FSUIPC does not have to "connect to flightsim" as it runs as PART of flightSim. Maybe you mean that some utility program you are using (for this VAFS (?) presumably) isn't connecting to FSUIPC? That is not the same thing at all. A possible problem is that your PC is slowed down a lot by the add-on of REX and, whatever VAFS does, it has too tight a timeout to cope with the horrible response times. Could that be the case? Is VAFS the program you are trying to run which fails to connect to FSUIPC? Have you asked the author about it? I wouldn't have thought that REX used FSUIPC at all, so I can't see how it could affect things directly, only via impinging on performance. What does the FSUIPC log show? And what version number of FSUIPC are you using? That information is always needed. If not the latest please try it first -- see the Updates Announcement above. Pete

If you enable Button & Key logging in the FSUIPC Logging page, the Log file might say why. I assume all this is with FS9 or before, not FSX? If FSX you could try listing the Lvars, it might be manipulable via one of those. I don't support that facility before FSX though. The only other alternative is to use Luciano Napolitano's "Key2Mouse" program. Regards Pete

It's usually a video driver problem. Something, usually a video driver (but not always) has installed a COMCTL32.DLL which is not compatible with the normal Windows libraries -- the tabbed part of the dialogue is made by COMCTL32.DLL whilst the standard Windows calls does the containing dialogue. At no time and in no place does anything in FSUIPC have any say, any control, over dialogue window sizes. And it cannot make dialogue windows sizeable -- that isn't a facility of Windows. You either need to repair your Windows installation by including the correct version of COMCTL32.DLL from the installation disks, or, possibly, change the Windows fonts size back to normal -- that sometimes does the job. (With the correct libraries the sizing of dialogues should match the sizing of tabs no matter what the font size selected is -- they are both determined in terms of "font units".). Pete

Okay -- that was a long shot in any case. What about the mouse macro option? Pete

Can you tell us when the fix will be available? Will it be an update or interim version or are you looking for a new "full" version? Edit : OK please ignore, i was to quick and not read the pdf providing the changes. Thanks Pete :) Groan! Pete

Oh, just coincidence that they were the same as the labels in the two files I took as samples. how likely is that? ;-) On FS9, offset 0AF0 tells you. Simconnect doesn't supply this data. Regards Pete

Yes, but the label and the actual angle aren't always the same. Best in both FS9 and FSX really to get the label data from the CFG file. You only need to do this on a change of aircraft of course -- the AIR file changes are notified by a count in the offsets. The Aircraft.CFG file [flaps.0] section seems to contain what you want. For example, C182: flaps-position.0 = 0 // degrees flaps-position.1 = 10 // degrees flaps-position.2 = 20 // degrees flaps-position.3 = 30 // degrees 737-400: flaps-position.0 = 0 // degrees flaps-position.1 = 1 // degrees flaps-position.2 = 2 // degrees flaps-position.3 = 5 // degrees flaps-position.4 = 10 // degrees flaps-position.5 = 15 // degrees flaps-position.6 = 25 // degrees flaps-position.7 = 30 // degrees flaps-position.8 = 40 // degrees You can use the regular ReadPrivateProfileString() API calls for these, and they share access well so there's no danger of conflict. They should even work using the UNC pathnames from a Networked PC (though I've not tried that). Derive it from the full AIR file pathname offset, just replace the filename part by "aircraft.cfg". Regards Pete

Maybe, maybe not. Each such case is different. Here are some pointers: 1. Maybe it uses a control you can actually assign to. Enable Event logging in FSUIPC (one check mark in left-hand side of FSUIPC's Logging tab), then operate the facility with the mouse and look in the FSUIPC Log file (in the Modules folder) to see what it caught, if anything. 2. Try using the mouse macro facility, described in the FSUIPC User Guide. If that works you are all set. 3. Finally, there's a chance that it may operate using local panel variables ("Lvars"). If it is FSX you are using, then check out the very latest FSX version of FSUIPC in the Updates Announcement above. It contains facilities for listing Lvars so you can work out Macros for assigning them. Sorry, but the last one isn't provided for FS9 or before. Regards Pete

You'd need to compute that from the increment at 3BFA. It does say that. Apart from using FSInterrogate to check things, why not search the document listing all the offsets? I found that one in two minutes just searching for "flap". The full documentation is the document. Don't rely on what is written in FSInterrogate FSI files and they are difficult to maintain and not done very thoroughly. I *think*, but I'm not sure, that the relative handle position is the value actually provided in the 0BE0 and 0BE4, but it might not be. It changed between FS2000 and FS2002 but I never determined the real meaning. That's more difficult. You'd need to know what the maximum is in radians or degrees. Sorry I can't help with that. No one ever asked before anyway, all these many years! Looks like it. Why do you need the true angle? Regards Pete

I found a way for your symptom to happen (though it looks very unlikely), but it can only happen for Direct To FSUIPC assigned controls -- so it doesn't explain why test (b) failed which was sending to FSX. It is related to arbitration between axes. I've fixed what I found in versions 4.432 and 3.869, now available in the Updates announcement above. So please use 4.432 in further tests -- which I think will still be needed as in the previous message. I have added some more logging for the "direct" assignment path -- there's really nothing to the one for FS controls to be tracked so that won't log much. After you let me know about the results with 4.432 and the tests above, I'll tell you how to enable the extra logging. For now I don't want to confuse the issue. Regards Pete

No need now you found and fixed the problem. ;-) Pete

I have my PFC software running too. It does not prevent FSUIPC sending the throttle messages on to FS, but possibly you should please just also test with the PFCFSX module temporarily removed from the FSX Modules folder. Let me know. I would have worried that if there's no throttle on the PFC device, the values being passed to FSUIPC for calibration there might be arbitrated in the non-existent PFC throttle favour, but that doesn't look possible from my code, and furthermore another of your tests (see next) really eliminates that as a possibility. Incidentally, after investigating that area, I have to clarify something I said earlier: I said "The only way to have both FSUIPC and PFC axes working is to disable the axes in the PFC driver and assign those, too, in FSUIPC4. Then for multiple throttles it will arbitrate (using the max setting). In fact the only way to disable the throttle axis in PFC is to assign an empty user configuration explicitly to the aircraft. Now test (b) was the one where you are assigning the axis IN FSUIPC4, but asking it to send the standard Axis control to FSX, not direct to FSUIPC. This isn't subject to arbitration -- in fact it isn't subject to anything. It is simply sent to FSX and it should then behave exactly as if it were assigned in FSX. So, please re-check test (b) to be sure, and then the next test is obvious. Temporarily delete your throttle assignment in FSUIPC4 and assign it in FSX. Try that with FSUIPC calibration and without. That's normal for the "THROTTLE_SET" control because the negative section is used for reverse thrust, and that isn't supported in the single-throttle calibration sections. With the standard control AXIS_THROTTLE_SET the full range -16384 to +16383 is used for forward thrust only. Not a lot. It deepens the puzzle greatly because your result for test (b) is actually of the shortest possible route through FSUIPC4 for the axis -- detection and sending to FSX. Apart from the extra tests mentioned above (for which let me know please), I need to think how to get more information. Regards Pete

Anything more than the maximum set in FS or FSUIPC will be set to that maximum. That's why they are called maxima! ;-) Please read the FSUIPC User Guide, the section on the visibility options. Change them if you don't like them. The user guide provides the description of the user facilities, and especially for the weather filters he can apply. Have you never looked at the documentation, or browsed the user facilities offered by FSUIPC? As explained at length in the User Guide, the "random extend METAR maxima" is a useful facility for generating visibility distances beyond 10sm or 9999 metres when the METAR explicitly specifies those figures -- many METAR reports generate those values to simply mean "at least ...". they do NOT mean "restricted to" or "is". Generally it is the automated stations which provide these fixed maxima. The option is defaulted 'on' because it is so annoying never having visibilities more than 10sm or 10km. Well you can turn off the FSUIPC options, but you cannot exceed FS's own maximum. You can also force FSUIPC to bypass all of the filter mechanisms (and so risk annoying your user! ), by using the clearly documented NW_SETEXACT command -- did you miss this one too? Regards Pete

If it can be calibrated / configured in Windows Game Controllers, and uses one of the standard Joystick Axes XYZRUV supported in the original Windows joy API, then both FSUIPC3 and FSUIPC4 will see it in their axis assignments. If however it uses one of the later DirectInput-only axes, then only FSUIPC4 will see it. Scanning the installation instructions it seems to indicate that is comes across as "Z-rotation", which I think is normally mapped to "R" in the older interface, so it should be seen by FSUIPC3, but there's no way I can possibly guarantee it. It depends on how is defines itself in its USB handshaking I think. Sorry, I'm not about to buy one to try it for you. Perhaps you can ask the suppliers. Regards Pete

Can you explain what you are talking about? Also always state FSUIPC version number. And try the latest updates. Whatever it is you are having problems with might already be resolved and it would save everyone's time. See the Announcements. Pete

Okay. That eliminates most things. What is wrong is that your Registration Key doesn't work. This can only be for one of two reasons: 1. Your PC's date setting precedes the date of your purchase of a registration, so making it look invalid, or 2. Your registration key is an illegal one, possibly made by a pirate key generator. If you believe it is neither of these, please ZIP up the FSUIPC.KEY file and send it as an attachment to me at petedowson@btconnect.com . Meanwhile I suggest you remove it from your FS Modules folder, to make your FSUIPC unregistered. Then your add-on will work. Pete

Sounds like either there's a serious bug in that program, or you have a registration problem. I could tell from the LOG. Yes, just paste it into a message. It will be quite short. You've not enabled any extra logging I hope. Don't go to the Logging TAB in FSUIPC, simply run FS as usual, get the error, close FS, show me the log. Regards Pete

That is too far out of date. I cannot support anything older than 3.85 at present. If you want more help, please update first. Then close FS before getting the Log for me to see. Regards Pete