Pete Dowson

Ah thanks. So, something this "aaX52P14FS9.dll" is doing during initialisation is clobbering things. I haven't reproduced it here so I assume that DLL only does whatever it is if an X52 is actually connected? Or does it only need the X52 drivers to also be installed? Regards Pete

Sorry, I've no time to study this whole old thread so I don't know what the problem is. Additionally I doubt that any of it is applicable to FSX and FSUIPC4 in any case***. Please start a new thread with a more appropriate title than "FSUIPC 3.96" and provide full details including FSUIPC version numbers and logs. The earliest current FSUIPC4 version supported in 4.60 and we are already up to 4.617 in interim updates, so make sure you are up to date first. I am on holiday after tomorrow (Wednesday) until July 5th, so any answers may have to wait. *** [EDIT] I did a quick scan and see the FS9 problem was related to a change in 3.963 which was fixed in 3.965, with no explanation ever found as to how the original change had such an effect and only with PMDG. However, I've checked the equivalent area of FSUIPC4 (4.617 at least -- I don't keep old code) and there was never any similar change or even similar code to change. Therefore this is a brand new problem and needs to be treated as such. Please start a new properly entitled thread, and supply a full account of the problem and any logs too, please -- one with event logging would be useful But, again, make sure you use the current latest version. And apologies for the probably delay till July. Regards Pete

How strange. I know Saitek use FSUIPC for some of their add-ons. FSConnect too? Hmm. Or is it not a Saitek program? [LATER] Ah, I see it is a separate freeware accessory program. What do you use it for? does it provide more features than the Saitek implementation? Okay. I'll try it, though without an X52 to use it with I suspect it won't do anything here. I'll try anyway. [LATER] No. That add-on won't even run unless it can find some software which is installed for the X52 hardware. Do you have to have that X52 add-on software running already in order to have the FSUIPC loading problem? If not, and it isn't being loaded at the same time as FS/FSUIPC, then knowing it's that software doesn't help narrow down the problem at ll. Unless you have something else using FSConnect as well. Regards Pete

Hi Ian, I don't use SquawkBox, but it has been tested with Squawkbox 4 and FSX and reported working fine. I've no idea about any Squawkbox panel -- I didn't know it had one. Even if I used SB I certainly wouldn't want any on-screen panels. In both FSUIPC3 and FSUIPC4 the only thing the new controls do is change the relevant bits in offsets 0x7B91 and 0x7B93, exactly as it says in the Release notes which I repeat here for you: With SB3 folks have always done this before now by assigning buttons to "Offset Byte Set", to change those offsets. The new controls just make it easier. What happens when the offsets are changed is completely down to SB3 which is reading them. The standby and mode c controls set 1 or 0 to 7B91, the Ident sets 7B93 to 1. SB3 is supposed to clear the latter when done. With SB4 not interfacing to FSUIPC at all, I implemented a way found by "bojote" (see main Transponder thread here) to watch those offsets and copy the changes to registered SimConnect client data offsets. SB4 then does whatever it is supposed to do, and FSUIPC4 clears 7B93 down again. Really it is only FSUIPC4 which has been enhanced. The additions to FSUIPC3 were really just an implementation of two "Offset Byte Set" controls. And I'm pretty sure the action of the Indent one is correct. The SB3 manual says: I've no idea what it does to its panel. I've no control over its own graphics at all. Have you tried using Ident via 7B93 or the added control? Doesn't it work? I was thinking of giving it a miss this year and perhaps only going every other year. There wasn't a lot different last time from the time before and I found myself at a loose end for much of the time. In fact I found a comfy chair in a less busy part of the museum and had a good kip for some of the time! If the weather had been better on the Sunday I'd have gone up in one of the school's aircraft for an hour. But 50 metres visibility?:-( Also it is a bit soon after June and I return from a steam trip in Eritrea (though that's yet to be confirmed). Best Regards Pete

What do you mean, it doesn't exist? How did you amend it then? If you aren't using FS for assignments, then the CFG settings and the slider positions are utterly irrelevant. "elevator set"? That's not an axis command. The FS Axis commands all start with "Axis". And why, if you are using FSUIPC exclusively for axes, are you selecting the option to send a normal FS command to FS rather than the direct to FSUIPC option? If you want to calibrate the FS Axis commands in FSUIPC you need to assign to them. Calibration doesn't apply to all of the hundreds of FS commands you can assign to, only axis commands. Those are the same ones which would result if you assigned in FS. Alternatively use the more efficient direct route, the first checkbox labelled "Send direct to FSUIPC calibration". Then there's no choices to confuse you. If they are normal joystick axes, seen by Windows Game controllers, they will be detected in FSUIPC the same as they would be in FS itself. They use the same DirectInput interface. Check the Game Controllers applet in Windows control panel. Regards Pete

Not likely because I don't know what they are and don't have much time. Okay. But the main thing is what FSConnect is there for. No. Often when folks solve things they don't report back, unfortunately/ Regards Pete

I've installed FSConnect.dll into my own FS9 installation, and FSUIPC 3.989 still loads fine. So it isn't simply the installation of FSConnect which creates the problem (assuming you are also use version 3.00 for FSConnect.dll?). So it seems I will know what it is being used for, on your system, and work out some way to re-create the same conditions here. Regards Pete

Oh, right. Hi! My memory is failing me these days. I don't remember much from that long ago! Regards Pete

Glad you found it! I've just downloaded FSConnect from AVSIM, Version 3.00 dated 2005. If I get time before I go on holiday I'll see if I can make it cause FSUIPC problems here -- but it may depend upon what FSConnect is called upon to do, so if you do find out why you have it please do let me know. If I can find out how it clobbers FSUIPC so early on I might be able to make a work-around before releasing the next FSUIPC3 update. But in might be in July now. Regards Pete

Good, glad you sorted it out! Regards Pete

I'm not surprised! Can't you see? The second set are identical to the first except for the Control they are sending! So one direction is not represented at all, and the other direction will send both INC and DEC, so cancelling each other out out! Please apply some thought and logic to the problem. It is not hard. There are obvious 8 combinations altogether of Press/Release, Button 1/2, Other button on/off as the condition (= 2 x 2 x 2 = 8 combinations, all possibilities). If you only use 4 combinations you have it wrong! You only had to copy the example in the documentation, replacing the button numbers with your own. I don't know why you are making it so difficult when it is provided "on a plate" like that? Regards Pete

I've no idea what that code is doing. I know offset 0892, but are you writing something to it, and ifso, what? In practice I find FSX works better if you move the starter lever to "idle" before 20% -- try 18%. It should really be 25% but I think their model is incorrect in this regard. What do you mean by an "offset value being fired"? What does the string "Engine1Info" mean (i.e what part does it play), and what are you writing, if you are writing anything? Sorry, I've no idea what that means. Why not test things using FSInterrogate, or even try writing a short Lua script which would be even easier? I'm not really able to help debug C# as I don't know it at all, and in your extracts above I cannot even tell what you are doing. Sorry. Regards Pete

Why are they occasionally freezing? Sounds like a question for GoFlight support? Hmmm. I can't really support GFDisplay a lot these days. It is pretty old now and I've forgotten most of it. Instead I added GoFlight support to the FSUIPC Lua plug-in facility. I don't know about Wilco, there may be an SDK for that one, but for PMDG I don't think you can fully control the aircraft's MCP through anything external -- or at least you can't get hold of the display values. I'm surprised that much works with add-on aircraft. I doubt it. Can you assign keypresses in those aircraft? FSUIPC's interface only covers things which are implemented in FS. Folks who do add-on aircraft make up their own systems. I don't know about Wilco, but PMDG are well known for keeping their internal access secret, and only available via special drivers, such as the one I think GoFlight themselves use. Regards Pete

What about the other direction? Why ask, why not test instead? How can that be right? If both 2 and 3 are pressed, as in the condition, how can the press of 2 or 3 be detected? The program can only detect a change -- a Press is a change from not pressed to pressed, a release is the opposite. You seem to not understand that the "P" in "CP" means "pressed". You also need "U" for released ("Unpressed") -- half your changes are buttons releasing, not pressing. And you can't possibly use both inputs as conditions when you have to detect one of those changing! You need three inputs for that! Why not simply use the example directly out of the documentation, the part I quoted for you? Logically you can surely work it out from your sequence, 1 0 -> 1 1 -> 0 1 -> 0 0 -> 1 0. Obviously the one which doesn't change must be the condition and the one which does change is the Press or release, thus: 1=CP(+1,2)1,3, 1 0 -> 1 1 2=CU(+1,3)1,2, 1 1 -> 0 1 3=CU(-1,2)1,3, 0 1 -> 0 0 4=CP(-1,3)1,2, 0 0 -> 1 0 That's the whole of that one cycle for one direction. Use the same logic for the other way. If you now follow the logic for the other way you'll end up with the same 8 entries as was given in the example in the documentation -- please do read the part I actually extracted for you! It is directly applicable! Pete

Well, I'm probably not the best person to ask because Ive never had a gray-code type encoder to play with. All those I've ever seen have been the easy types, pulsing a connect on one button number one way and another the other way. Well I don't understand your examples, and expressed like that they are most certainly not valid (there's no such thing as "PC..."), so perhaps the "many times" you've read the relevant section aren't yet enough? The following parts of the Advanced User's guide section you refer to should surely help? Maybe you are continually mis-reading them? You need to follow the format of the parameters rather more carefully than you appear to be doing -- they aren't flexible enough to recognise parameters in any arbitrary format! Regards Pete

Yes, you need to purchase the bundle if you want both. The integration is only that when I had to re-write both FSUIPC and WideServer for FSX I took the opportunity to make it all more efficient. Installing FSUIPC4 effectively also installs WideServer because what used to be a separate DLL is bundled into the one DLL. But, just as with WideFS6, placing WideServer into FS doesn't enable it, only a purchased key does. Incidentally, there's a much later version of WideClient available in the Updates announcement at the top of this Forum. It works well with all versions of FS. Regards Pete

Not extant? No, it is "extant" in the sense it exists. It is just that there's insufficient information in your submission for me to advise further, which is why I prompted for more. Pete

But the signature check must have failed, nevertheless. Maybe you've disabled some of the Windows services needed? In particular trust verification needs the cryptographic service. Seems you have installed it before? What happened last time? Unfortunately you've cut off the last lines of the Installer log file which would have included the error number. The DLL would still be installed in the FSX Modules folder, along with the complete Install log. If you right-click on the DLL and check Properties-Digital Signatures you should find more information. It may simply be that you have a corrupted download. Check the signature on the Installer EXE file. Regards Pete

I don't understand. Are you deleting the FS9.CFG before starting FS9? The tools I use come from http://www.sysinternals.com. Yes, I did it on a new partition with a complete new FS9 installation, and it WORKED ! No, I said did you try it on your original configuration. However, it seems that is now answered by the foregoing, confirming therefore that is wasn't some shared file outside the FS folders. As I've said several time, there is really nothing much done before the Log file is opened. But 3.93 is now nearly a year old, and there have been about 30 updates since then. And any changes in the early part, before the Log is opened, will have been trivial. I can send you some older interim updates if you really think it would help, but the previous main release, 3.96 is no longer available. Unfortunately the main releases all have the name "FSUIPC.ZIP" so archives overwrite each other. Interim versions posted in this Forum have unique names and I have some in my archives. Send me an email -- petedowson@btconnect.com if you want to try any, but I'm still not sure that it will tell us anything. [EDIT] There is one thing you can check, please. Delete or rename the FSUIPC.INI file before starting FS9, with 3.989 installed. After it is rejected by FS, see if there is an INI file produced. If so, show it to me please. It might tell me how far it got. [LATER EDIT] Another thing that occurs to me is that, if it is getting clobbered so early it is unlikely to be the fault of any add-on which isn't part of what gets loaded very early on, like FSUIPC. For that to happen it must either be whatever aircraft you have loading initially (and I think that was a default FS aircraft, wasn't it, so would be okay), or, much more likely, another DLL installed in your FS Modules folder. So, could you compare the DLL's listed in your new "virgin" FS installation with those in your original installation, and tell me what ones are extra, apart from FSUIPC.DLL. Thanks. BTW I am away on holiday from Thursday this week until July 5th. Regards Pete

As I said, it couldn't be a function of FSUIPC except by making special assignments to do so. There is the possibility that the aircraft you are using is sending many controls to FS all the time. If one of these controls occurs between you pressing the E and the 1, 2, 3 and/or 4, then those subsequent presses will be missed -- or worse, apply to some other function. To see if this is what is occurring, reinstall FSUIPC then go to the Logging tab in its options and select "event" logging. When you get the problem, look at the FSUIPC.LOG file. You will see the controls sent, by name and parameter, for example: 238656 *** EVENT: Cntrl= 65554 (0x00010012), Param= 0 (0x00000000) ENGINE 239250 *** EVENT: Cntrl= 65538 (0x00010002), Param= 0 (0x00000000) SELECT_1 239484 *** EVENT: Cntrl= 65539 (0x00010003), Param= 0 (0x00000000) SELECT_2 239734 *** EVENT: Cntrl= 65540 (0x00010004), Param= 0 (0x00000000) SELECT_3 240000 *** EVENT: Cntrl= 65541 (0x00010005), Param= 0 (0x00000000) SELECT_4 If another control gets between the ENGINE control (from pressing E) and any of the SELECT controls (1,2,3 or 4), then the latter's effect can be nullified -- depending on what sort of control it is. Using FSUIPC you can monitor the state of the internal FS variable which selects the engines to be affected by the generic throttle, prop and mixture controls. This is as follows: 0888 (1byte): Active engine (select) flags. Bit 0 = Engine 1 selected … Bit 3 = Engine 4 selected. In the FSUIPC Logging tab, enter 0888 as an Offset in the table on the right-hand side, select U8 as the Type, then check the option for "advdisplay" below. OK out. Now FSUIPC will display the value in 0888 in real time on screen. 15 = all engines 1 = engine 1 only 2 = engine 2 only 4 = engine 3 only 8 = engine 4 only (add values for other combinations). One possible solution: There is an option in FSUIPC, in the Miscellaneous tab, entitled "Fix control acceleration" (please look it up, page 21 in the current User Guide). To quote part of the description: Regards Pete

Maybe the offset after 0330 now comes into play? Either way it is irrelevant. If you are getting a value greater than 65535 from a 16-bit quantity the error is in your program in how you are reading or interpreting the results. I suggest you use a debugger appropriate to the compiler and language you are using. Regards Pete

You can't? What on Earth is stopping you. Don't you read my messages? I said: What is the problem? You can't look in the Announcements in the Forum, the main place I provide everything? Or your system refuses to download it? Or what? I don't understand! :-( Incidentally, it's up to version 3.989 now! I'm preparing the next (and hopefully last?) major update, 3.99, which won't be much different from 3.989. The other way it do adopt a process of elimination, to see what is going on. If you stick to an old version of FSUIPC please never ask for any further support. Did you retry 3.98 on your original configuration after installing the fresh copy of FS elsewhere? If the problem was due to some file missing or incorrect which is installed in a common area then just installing another FS might have fixed it in any case. Otherwise, you can use your fresh installed copy as a source of replacement files for your old installation -- i.e. perform a sort of merge. There are many ways to isolate and correct the problem, but it might take patience and time. This is the way with any sort of corruption in a large installation I'm afraid. No, that is not true I'm afraid, because FSUIPC is not actually running, and there would be a slight difference in memory arrangements in every single increment -- obviously, as if everything were identical it wouldn't be a different version. I know what I've changed in each version, and none of it applies to anything in FSUIPC before it starts the Log file. Pete

Was there mention of it? FSUIPC doesn't really use the Registry except to check the path to FS and to make a small record of user Registration on this machine. Depends on what the VATSIM connector program uses. And there are three simultaneously in-use versions of SimConnect. A problem in one might not affect another. How do you work that out. It actually explicitly says it found it: Are you reading some different file to the one you posted? Where's the FSUIPC4.LOG? Doesn't one get generated? Anyway, the main problem is this: so there's either something wrong with the downloaded ZIP you have, giving a corrupted FSUIPC4.DLL file, or there's something set wrong or missing in your system. I've not seen error 800B0111 before so I Googled it and found it means just "Trust verification failed", which isn't too helpful. I don't know how this has happened on your system, but one possibility is that you've told Windows at one time or another to not trust products with the signature authority I use (GlobalSign), or the signatory (simFlight). Load up Internet Explorer (no matter what browser you use), go it Internet Options - Content - Publishers - Untrusted Publishers and make sure my publisher is not listed. If it is select it and remove it. GlobalSign Root CA should be listed in the Trusted Root Certificate Authorities. You also need to make sure you've not disabled the essential Windows services used for trust checking -- cryptographic services is one of those. Regards Pete

1062485632? Obviously you are missing something pretty fundamental. Offset 0330 is only a 16-bit value (occupying 2 bytes), with a maximum possible unsigned value of 65535, so you are making some serious error in reading it, and therefore probably in writing it too. Use the tools available. FSUIPC provides IPC read and write logging and FSInterrogate allows you to play to your heart's content with any offsets. Pete

What does Error #14 mean? It isn't any message of mine. If it doesn't appear in the AddOns menu then either your FSX installation is corrupted -- SimConnect is not correct -- or, more likely, something you've installed has messed up the DLL.XML which tells SimConnect what to load. When you say " I've tried a couple of different versions", what exactly do you mean? Have you run several different Installers, or merely copied the DLL's? If the latter, try using the Installer. You might not remember but evidently you have. Tell me more about what you've tried. Show me the latest Install and FSUIPC Log files form the FSX Modules folder. Pete