Pete Dowson

Good, thanks. Found it. And in fact the crash actually helped, because following the logging which SHOULD have happened I found the one which crashed FSX was in an exception routine which sets out deliberately to suppress other throttles when PFCFSX has detected a throttle quadrant! It's actually not a bug but a facility i incorporated years ago and evidently clean forgot about. It was added into FSUIPC2 many years ago, and was originally optional, but became "compulsory" shortly afterwards after too many folks were getting into trouble. Humble apologies. I shall add a new parameter to the Joystick calibration section(s) of the FSUIPC4.INI file to allow folks to disable this suppression. Provided they then take care to assign a blank quadrant to the relevant aircraft, things should remain perfectly flexible. I shall have to document it in both the PFC and FSUIPC packages. I don't remember which PFC unit you have. Is it the cirrus? If so, it is the mags and fuel selector on that. The PFC controller sends the state of some of those switches even when you don't operate them. It helps keep them in sync, though oddly they don't do that for all latching switches. No need now ... ... I'll add the parameter facility you need and give you further details when the revised FSUIPC4 is ready. Meanwhile, remove those logging lines. You shouldn't need them now. Watch this space! Regards Pete

Ouch! Were there no details of the crash reported by Windows -- module name, address? Yes, that's okay. hex 808 is the same as decimal 2056. It concerns me greatly, that trying to get details of the route followed by your throttle changes actually crashes FSX. That is unexpected, and may be related to the problem you have. Okay. I'll look at that to see what it might show me ... That's the only good way to do it. In other words: 1. Run FSX. 2. Change the axis assignments to suit the test needs. 3. Test. 4. Close FSX (if it doesn't crash!). 5. ZIP up the FSUIPC4.LOG file (also, please, the FSUIPC4.INI file with it -- then I can be sure it is set okay), with an appropriate name for the ZIP. Yes. In actual fact, if the quadrant was interfering I wouldn't expect it to be only the throttle that's affected. After all, there are 6 axes there. Yet you did prove that everything was fine when the PFCFSX module was removed, did you not? On to the log, which I'm afraid never gets as far as showing much of any operation of any axis, be it Mixture, Prop or Throttle. You seem to start the test by using a control to "PAN_DOWN", then operate the Magneto/Starter switch "MAGNETO1_SET" and the fuel selectors "FUEL_SELECTOR_SET", etc. and then again some more "PAN_DOWN"s and a "PAN_LEFT". Are all these operations needed before you try moving the throttle lever? It would simplify things just to move the throttle, nothing else if possible. Anyway, there is one sequence which helps me: 118547 Axis 0Z=-16123: Action=4 (direct to calib) 118547 Direct Axis 4, Ctrl 65765=-16123 : in calibration ... 118547 ###JOY### Event seen, ID=65765 (0x000100E5), Joy=3, value=-16123 (Direct) This is AXIS_THROTTLE_SET. Then it crashed. Which test was this from, do you recall? All the hard work seems to have been done -- it has seen your axis "0Z" change, sent the raw value, -16123 to the calibration routine, and should then calibrate is and send it on...the arbitration with any other axis is long past, so that explains that my correctioon to the code there didn't help/ Best not to do the tests again, yet, till I work out how to stop or detect the cause of the crash. It isn't just the logging selection, as that doesn't cause a crash here ... Later. Pete

I assume you mean an FS plug-in DLL? Can you make a .NET managed DLL which runs inside FS? It would need some sort of wrapper I suspect -- nothing in FS is "managed", it is all native code. The interface to FSUIPC from inside FS, whether from a DLL or Gauge, is different to the external one. Remember to use the correct library, or the code therefrom. It's the one using FSUIPC_Open2. In this version of the interface, you supply the memory space for the data exchanges instead of creating a memory mapped file, which is only needed to share memory between different processes. FSUIPC doesn't need to be user-registered, but if your application is going to be payware you should write to me privately, petedowson@btconnect.com, to agree a commercial license. Regards Pete

Ah, you are well set, then. For those 'bit' operations there must be another parameter, to provide either the bit number (eg 0-7) or the equivalent value (1-128). Right? And also you presumably have to tell it the size/length of the offset (1, 2 or 4, or Byte, Word or Dword?). To press a button or switch on use "set bit", to release it or switch off use "clear bit". That'll provide you with an exact button or switch operation. Start at 3340, with bit 0 (value 1) up to bit 7 (value 128), that's your first 8 switches/buttons, then 3341 -- another 8, and so on. Carry on until you run out of buttons/switches or switch positions (for multiposition ones). No need to "setup" any virtual buttons. Those 288 are always available. Do the above first. When you've done that, go to FSUIPC's Buttons and Switches tab. When you operate your buttons/switches you will see them identified just like any joystick or GoFlight buttons. Go ahead and assign them to do whatever you like - the OHD macro options or anything else. It's all "normal" FSUIPC button assignment from then on. You don't need to edit the INI file unless you are thinking of doing some clever button programming. Just use the option screen provided for the purpose, it is much easier. Regards Pete

Okay. All that happens in the 288 bits starting at offset 3340 is that each bit (binary digit) represents one button or switch. When the bit is 1 that particular button or switch is pressed or on. When it is 0 it is released or off. Because of how PC processors are designed, the 288 bits are, for access, divided into 8-bit bytes. So that is 36 bytes (36 x 8 = 288, right?). Each byte can be addressed by its offset -- 3340 for the first, 3341 for the second, and so on, up to 3363 for the 36th (36 is "24" in hexadecimal, and offset addresses are in hexadecimal: 3340 + 24 = 3364, all in hex). A byte is the smallest unit you can read or write, so to operate a single button/switch, you actually have to READ the byte, change the one bit out of the 8 which you wish to affect, and WRITE the byte back. If the software you are using can do this (they might refer to it a "toggling" or "exclusive or'ing") then you are all set. It may require you to provide a mask -- 1 for the first bit in a byte, 2 for the next, 4 for the next and so on, up to 128 (decimal) for the 8th. Does the utility provide any facility to change an offset other than simply write to it? For instance, doesn't it provide for incrementing a value? Changing bits in a value? A lot of the FSUIPC offsets are bit-oriented, so it should be something the utility's author made allowances for? Regards Pete

and I don't have this chance. you are getting all this support and haven't even paid for your copy of FSUIPC? :-( Everything can be "changed" according to the filters provided. Please read the User Guide sections on clouds, winds, visibility. Also the smoothing for pressure and temperature in the miscellaneous section. I cannot reproduce it all here. You are free to read it even if you have not paid to use it! Regards Pete

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