Pete Dowson

Okay. I managed to do something about it which should work quite well, and before Christmas too! Try FSUIPC 3.855 or 4.409, from the Announcements above. Full details are provided in the Announcements. Regards Pete

Are you kidding? Search for "reverse" in the user guide, you'll find plenty of help. It's always been one of the main reasons folks buy FSUIPC and it gets plenty of attention! You can do it in two different ways depending how you want it. If you want a reverse zone on the throttle levers, then the instructions in the user guide are specific on how to do that by calibrating them with a centre idel zone -- and in fact the "reverse" is even labelled on the calibration screen for the 4 throttles. Or you can use separate axes altogether and have either one common reverser lever for all engines, or up to 4 reverser levers, one for each. These are on other pages in the calibration tab! If you are assigning through FSUIPC there are the 5 reverser axes there to be assigned to -- one common or 4 separate. I cannot understand how you can have missed all this. Can you explain how, please? Two questions: first, what are FSUIPC offsets to do with what you are doing? Are you writingh a program? Second: what makes you think there are separate Caption and First Officer pedals or brakes? There's no such thing as "first officer pedals" and most certainly nothing documented as such. Where are you reading this stuff? I've no idea what you are talking about. FSInterrogate doesn't receive any signals from any pedals. It is a way of reading and writing FSUIPC offsets. It is for programmers, investigating how to interface to FSUIPC from a program. If your program isn't writing to the correct FSUIPC offsets then FSInterrogate will not see them change. How can it? You need to work out what your program isn't working and fix it. Regards Pete

So you had them working well with FS assignments, but you decided to use FSUIPC anyway? Why are you assigning axes in FSUIPC when the assignments in FS work okay? You can still use FSUIPC to calibrate controls assigned in FS. You are running before you can even walk, perhaps? The assignment of axes in FSUIPC is another step. Are you trying to do too much too quickly, and not understanding what you are doing? When you assign in FSUIPC you have to disable things in FS, otherwise they will interfere severely. Sorry, but you really need to be clearer in your descriptions if you want me to understand. I don't know what that means. Are you saying that you disabled the joystick in FS and assigned them in FSUIPC only? Did you assign them to FS controls, or direct to FSUIPC calibration? It makes a lot of difference. When you say "all the setting for the go to the same number", can you explain more, please? What numbers are where for which? I cannot visualise anything from your description. The "software" cannot possibly "messed thing right up". I think you are being rather irrational and abusing the software because you don't know what you have done and, to be honest, don't appear to know why you are doing it. I can help if you explain what you want to do and what you are trying to do to achieve it -- step by step, number by number. Or please just delete the FSUIPC INI file (the configuration settings), then FSUIPC will do simply nothing again. Everything you ever do with FSUIPC is just listed and stored in that file. It is quite innocent. You seem to be rather prone to gross exaggeration I think? Why uninstall the "game" when you can simply delete your settings? You are a bit extreme in your assessments. Please calm down and think things through. Perhaps read a little more before messing about? I'm sorry it is in English. There are some translations around, but i don't know if there are any in your language. Regards Pete

Sounds like they are broken then. Try using them in FS normally first. FSUIPC should never be your first resort in any case -- what is wrong with CH that they cannot make controls which work with FS in the first place? Pete

I think you could probably implement such a scheme using a Lua plug-in for FSUIPC to process the axes and simply discard those currently switched off, but ... Exactly. I think you could have a button which doesn't really do anything. Or if you were really keen you could do it in hardware, of course, routing whichever wire it is providing the main signal, or power, or more likely the common return connection, through a push-button toggle switch. If you want any help with Lua after reading the manuals and my supplementary documentation, let me know! ;-) Regards Pete

But surely the "stick with priority" is the one which is actually in use? What is the other one used for when the "priority" one is being used? With FSUIPC's arbitration (or even without if there's no jitter), the stick in use will be the stick in use and therefore the one "with priority", assuming the other is not in use for other things. Otherwise i am sadly completely misunderstanding you still! Regards Pete

I'm a little confused by your question. Why would an A320 be more or less difficult for attaching 2 joysticks to FS? And what is the problem with having two joysticks connected? Providing neither of them suffer from "jitter" (that is, changing values when not being touched), you should be able to simply have them both plugged in and assigned at the same time. If they do jitter and so interfere with each other, you can get around this with a registered install of current versions of FSUIPC. Assign the axes in FSUIPC instead of FS, with the "direct to FSUIPC calibration" method selected, and FSUIPC will arbitrate between the two inputs for the same FS control, taking the one with the highest deflection. Regards Pete

Sounds like you are making an error entering the other parts then. Did you also cut and paste your name and address/email address? All three parts must be correct. Computers cannot guess and are very fussy. The complete set of three entries is used to identify you and your registration and these three are inextricably linked. (It never ceases to amaze me how many ways folks find to spell their own name differently! ;-) ) Pete

Just the same digits, without the leading 1, which is assumed. I thought you'd have noticed that. So: 115.65 --> 0x1565 and the previous examples: 113.45 --> 0x1345 (the one in the documentation) and your erroneous attempts: 132.31 --> 0x3231 (bad), or 112.34 --> 0x1234 (also bad) These last two are "bad" because of their invalid last digits, as I explained (and the first is out of range for NAV, of course). This form of representation has been used in Fs since at least FS4. probably before. it is called "Binary-Coded Decimal" (BCD), because each decimal digit is represented separately in binary -- using 4 bits each (hence 16 bits for 4 digits). The binary values are represented more conveniently in hexadecimal, which is simply a way of grouping binary into 4 bits lumps. Thus 0x1345 = 0001 0011 0100 0101 in binary. Each group of 4 bits is, in BCD, interpreted in decimal, thus 1345. Pete

You have something wrong with your program, then, as that offset is used a lot for writing from drivers for hardware like the PFC Avionics Stacks (I should know, I use them). Have you checked using FSInterrogate? That's why it is provided, so you can do checks outside your own code. Well, I can see why now. You have two errors there. 1. The value to be written is a 16-bit number, encoding the frequency, minus the leading '1', in BCD (binary coded decimal). A clear example is shown in the documentation. It says "a frequency of 113.45 is represented by 0x1345". You are trying to write 0x3231 (the hex value of the 1st 16 bits (i.e 2 bytes) of your inapplicable 4-byte character string). That represents the illegal frequency 132.31. It would produce an erroneous display altogether in older versions of FS, and would be rejected altogether in FSX 2. It appears that you may have been trying to write a frequency of 112.34, which is also not a valid frequency for FS. The last digit must be 0, 2, 5, or 7 (representing 00, 25, 50 and 75 respectively). Regards Pete

No, sorry. I know nothing about either. Regards Pete

Odd, as there's no such message in any of my programs! In fact I would never put out such a meaningless error! It must surely be another add-on you are using? Maybe you should post a picture of this "pop-up", as your description isn't really helping. Does the FSUIPC Log file show any errors? If FSUIPC or WideFs do have any errors to report, it is certainly there, in their log files, where they do so. In my programming I never make a pop-up window report unless there's something really serious occurring which is unrecoverable and so you need to know there and then. Pete

Since the signature does not check in Windows it it most likely #1 in the list I gave in the preceding message. Did you read the Installation instructions and try installing the GlobalSign root as suggested there? I repeat the list from the earlier message here, as you seem to have missed it? 1. Missing GlobalSign root. Usually happens on Windows 98, Windows 2000, Windows XP before SP2, and some non-English installations of Windows XP or Vista later than those. 2. Corrupted registry in the areas discussed earlier. Not sure what causes that -- and there may well be other types of corruption too. 3. Cryptographic services not running or faulty, somehow. A lot of folks stop some services running to try to eek out better FS performance. 4. FS itself installed in a folder which has non-ASCII characters (eg accented or other non-Latin alphabet characters) in its path somewhere. There appears to be an error in the Cryptographic code in Windows which makes it fail to convert these correctly between wide character ans Unicode format. i suspect it is all related to code pages. Note that with the latest versions of FSUIPC I have taken steps to avoid #4, so that shouldn't be the reason. However, it has not been tested as I have no access to non-English versions of Windows. Pete

CH's own software, for their own products, doesn't work? Are you sure it isn't a hardware problem, then? Sounds rather odd. 3 cm? I didn't think CH quadrants had much more movement than that in any case! Isn't that about half way? Do the "IN" numbers in the Calibration (or Assignment) Tabs or FSUIPC change in that first 1-3 cm range? If so you should be able to calibrate them better in FSUIPC. If not then there's nothing FSUIPC can do -- if it sees no changes it cannot act upon them. You'd need to determine if its a hardware problem or just Vista's calibration not good enough. Well 3 cm i a lot of discrepancy, but if you view cockpit videos of real aircraft you will often see that, for the same engine thruast, the levers are seldom exactly in line together. When flying manually (which is of course mostly only during takeoff and landing) the pilot/copilot has to manage to move the throttles in something less than a straight line. Provided you can get them closer than your 1-3cm, if you still find it difficult you could use the throttle sync facility provided via Hot Key in FSUIPC. That copies throttle 1 to all 4 engines and ignores throttle 2-4 inputs, and can be toggled on and off as you desire. But, wait, looking at the calibration you have made in FSUIPC: The numbers there are: max reverse thrust, min idle zone, max idle zone, max forward thrust You are using the throttles with a reverse zone (you intended this I assume? -- if not see below). The reverse zone seems very large on Throttle 1 compared with the others, and Throttles 2-4 have huge Idle zones, compared with the very very small one on Throttle 1. Did you do this deliberately? If your throttle axis inputs were behaving in anything like a similar manner, I would simply advise you to copy the Throttle1 numbers above to the other three, to make them all the same. bit if, as it looks, there's a huge disparity in how #1 behaves compared to the others, you have to resolve that instead. That would be in the Vista calibration or the hardware itself. If you don't want the reverse zone on the throttles you can now easily eliminate that using an option in the current interim update for FSUIPC (see in the FSX Downloads Announcement above). Regards Pete

That's for commercial developers who are using FSUIPC effectively as part of their product in order to save developing their own interfaces. Seems only fair. Yes. And in any case, if you register FSUIPC as a user (i.e. pay for your copy, with all the user facilities that provides, then it has always provided full access to all programs, commercial or otherwise. In PCs running Windows there's no such thing as "fixed addresses" for programs. Each process runs in its own virtual memory with virtual addresses, translated by tables to access real memory. And even the virtual addresses aren't fixed, they vary according to what is loaded / unloaded already for the same process. The sort of environment where you could almost do what you seem to be suggesting was last seen in MSDOS days And FSUIPC does not handle any hardware directly. You have to have a program running which interfaces between your hardware, however it might be connected to the PC, and FSUIPC. Regards Pete

Why are you trying to do it by editing the INI file instead of using the documented and easy method of using the Hot Keys tab in the options? So why go there? What is wrong with the User Guide itself, instead of the Advanced User's guide? For all standard options like these, you should not need to try to be "advanced". There's a chapter listed in the Contents page on Hot Keys! Please just run FSX, go to FSUIPC Options (get the normal menu up at the top of the screen by pressing the ALT key. Choose "Add-Ons". Then you'll see "FSUIPC ...". Select it and you will be able to select from a number of tabs, including Hot Keys. The User Guide does explain this, and also lists the Hot Keys. The "AdvDisplay" window is of course now described as the "FS display" (as AdvDisplay is no longer used), but the chapter on the Hot Keys clearly mentions Radar Contact specifically. Incidentally, if you ever want to find out what keys have what codes, the most reliable method, which works for all keyboards, is to enable FSUIPC's Key and Button logging (on the Logging tab), then press the key and view the Log. With FSUIPC4, if you run FSX in Windowed mode, you can even see the result in real time by enabling the Console window log display. Checking that myself I see that, on my newer Logitech keyboard the keycode 222 is actually the #~ key, and the '@ key is 192. Seems they've been transposed at some stage. I'm not sure whether I ought to change the "Advanced Users Guide" or not, as they were certainly correct as listed there on my UK keyboard at the time that list was made. It does say, just below, the these keys tend to vary from keyboard to keyboard. Pete

All my FS programs are compressed & encoded (which will make them contain meaningless non-program bit patterns) and code-signed, to prevent tampering and infiltration. If any security program finds a problem with them it will therefore be a false alarm. You should report it to the suppliers of that program so they can make their code more reliable. Just check the signature -- right-click on the DLL and select Properties-Signature, then select the signature itself, ask for details, and make sure it says it is okay. That is your guarantee that it has not been tampered with and carries no malicious code. As I said, the code is not even visible in the file to any checker as it is compressed and encoded. Regards Pete

If the failures are set in FS, and not just local to PMDG code, then, yes. You could do it with a small Lua plug-in program. You would need the list of FSUIPC offsets (a document in the FSUIPC SDK) to check through the ones which might be affected by failures -- there's a complete set starting at offset 0B64. Then, to see if the failures affect FS itself you could monitor those offsets (FSUIPC Logging tab, right-hand side) to see if they do get set. If the failures are detectable (certainly, for instance, an engine out should be -- at minimum the Combustion flag in the Engine variables would change to 0), then the change can be set to cause an event in a pre-loaded Lua plug-in, which could then simply issue the pause control. Let me know if you need any more help. Regards Pete

No. Not sure what you mean by "the complete version". 4.40 was never issued "incomplete". It is the current User release, available from the normal download site. 4.408 is an update for it, available here. You can install 4.408 over 4.40 if you wish, but 4.40 is the current supported version in any case. Regards Pete

Never ever publish your key openly as you just did! I may have to stop it now and you'd certainly need to re-purchase then! If your key was rejected it is because you made a mistake entering one or other of the three fields (name, email address, key). You MUST get these exact -- computers cannot guess these things! Cut and paste if you cannot be sure to do this correctly! Pete

It tells you it installed correctly, doesn't it? If you look more closely you'll see that it DID find FSX.CFG -- if it hadn't you would get a real failure reported! It found FSX.CFG for user "Krishan" (I think -- your graphic is hard to read. Why not save time and post the Install log file from the FSX Modules folder -- this is merely a screen picture of the log!?). The "failures" you refer to are for users "LocalService" and "NetworkService", which presumably don't use FSX in any case! Pete

Show me the Install log, and the FSUIPC4 log if there is one -- both from the FSX Modules folder. What "fatal error" was it. Did it say no more? Does it do the same if you remove FSUIPC4.DLL from the Modules folder? It may be because you deleted the other two SimConnect folders -- did you reinstall SP1 and SP2? Pete

With the same failure reported afterwards? Strange. It's always worked before -- though by deleting all three editions of SimConnect you will need to reinstall SP1 and SP2 now as well. But if the base edition repaired okay, FSUIPC4 Install would not show that same error. Is the WinSxS folder for version 10.0.60905.0 back after the repair? I'm sorry, but i don't know how FSX got messed up on your system. I can only suggest a complete uninstall and reinstall, from scratch. If that fails you will need to contact Microsoft Tech support I fear. Regards Pete

Your base SimConnect (the one installed by the original FSX DVD) is corrupted. See the FSX Help announcement to find out how to repair it. Pete

You mean the button/keys assignments for FSX? Disabling a joystick controller won't disable the keyboard. You don't need to disable the keyboard. If the buttons still work then you must have more than one controller. You would need to disable them all, separately, if you don't want any possible conflict with assignments in FSUIPC. Keyboard is different. If you assign a key in FSUIPC it takes precedence. FSUIPC cannot stop FS reading the joysticks. Regards Pete