Pete Dowson

Actually, since I changed the "Delta" for POV axes in the Axis assignments to 0 (so that it doesn't discard any values even repeats of those before), assigning a POV in FSUIPC4's axis assignments to the PAN VIEW control (the same one that FSX uses) works fine. Some say it is as good as it is in FSX, others say it is a little bit jerkier. I may be able to smooth it further by by-passing SimConnect for it, as I do for normal "axes". I'll re-check. But here it is smooth in any case. This change appeared between versions 4.30 and 4.40, so perhaps you'd not yet noticed? This is the entry from the History document: Regards Pete

Ah. If you purchased your FSUIPC or WideFS keys after that date, then they wouldn't be valid! Regards Pete

something's changed then, obviously. Is your network okay for all other things? As always, the first place to look is in the Logs. most of my programs produce logs of what they are doing, and for good reason. It's so there's some clues when they don't. WideServer.Log in the FS Modules folder, Wideclient.Log in each of the widecient folders. Make sure everything is closed down first as the summary information at the end of the Logs can be informative too. Pete

What does "2068" mean? But after installing it. I started FSX. And i think that i in the first Security Message click RUN. And then FSX was running i couldn't see Add-Ons up in the menu bar. Why on Earth didn't you try installing it BEFORE buying it? Show me the Install Log and, if there is one, the FSUIPC4 log -- both from the FSX Modules folder. Tell me if there is no FSUIPC4.LOG file, as that means FSUIPC4 isn't being run, pointing to a corrupt SimConnect installation of FSX. Really? I think Simconnect problems are the most common for FSX -- you evidently didn't looks too far? I always need to see the Log files in any case. That is what they are for. They contain all the information I need to start with. And please explain what that cryptic number "2068" is supposed to mean. Oh. If you are not installing version 4.40, the current main user release, please try that first. Regards Pete

No, only in the last sentence (all caps == shouting, by convention). And a sentence I don't even understand? As far as FSUIPC is concerned, if you have a good setup in FS9 you can simply copy over the relevant sections from FSUIPC.INI to FSUIPC4.INI -- just the JoystickCalibration section(s) I think, because you say you are not assigning any axes in FSUIPC in any case. (Assignments might be slightly different in terms of Axis names because FSUIPC4 uses DirectInput for axes, whilst FSUIPC3 and before used the old joy interface, as they all do for the buttons). The same numbers for the same joysticks work the same in both FS9 and FSX (and, in fact, also in FS98, FS2000, Fs2002, FS2004, CFS1 and CFS2). There might be differences in the aircraft models, of course, but the way the flight controls and reversers work is the same throughout. As you are assigning in FS, though, you must be sure that the sensitivity sliders are maxed and the null zone sliders are zeroed -- but that applies equally to FSX and FS9 in any case. If you don't you will be wasting some of the axis range and not achieving proper calibration no matter what you do in FSUIPC. (With assignment in FSUIPC, all that is bypassed so it becomes irrelevant). You still haven't said whether you want a reverser zone on the throttle levers, or you want separate reversing levers. There's absolutely nothing taken out of the manual -- unfortunately it just grows and grows -- but I assure you NOTHING is removed! There's no separate section on reversers. Mostly folks use a zone on the throttles, back from idle, and this method is clearly mentioned in several of the steps in the calibration section -- as well as being shown on screen with the actual word "reverse". I don't understand how you could miss it on screen -- it is really relatively intuitive and you shouldn't even need to do more than glance at the User guide in any case. So, I repeat: If you are wanting a reverse zone on separate throttles then you follow the numbered steps in the Calibration section on the Options Tab page with the 4 throttles. They are clearly showing reverse, idel and max thrust. If you want to set up separate axes for reversers, then they are just other axes on separate tabs, as I've already pointed out. There is NOT a separate chapter telling you how to calibrate each type of axis -- elevator, aileron, brakes, etc -- because the method is the same on each. most axes fall into one of two types - ones with simply a minimum and maximum value, and ones with a centre or idle or "normal" value. The main exception is flaps which can have a number of detentes, optionally individually calibrated. That is why there is a section on flaps, but no separate section on reversers which are EITHER part of a throttle axis or a simple min/max axis on their own. I really don't understand how you managed to do anything at all on FS9 -- FSUIPC's User Manual is almost identical between the two. In fact for joystick calibration I think it is! Pete

I'm not sure who "they" are to say such things, but for certain you have to disable the axes in FS is you are ASSIGNING them in FSUIPC. You must not have the same axes assigned in both places. But you are obviously NOT assigning them in FSUIPC, so you must not disable them in FS. This is logical, as you will see if you think about it. You can calibrate in FSUIPC whether or not your axes are assigned in FSUIPC -- they are separate facilities, on separate tabs, and described separately. You seem to have mixed yourself up. Sounds like you've not calibrated them anything like correctly. Try folowing the numbered steps. You need a defined idle zone. In the FSUIPC calibration display there must be 4 different numbers, one under "Reverse", two under "Idle" and one under "Max", increasing left to right. If it happens which CH#s own software too it sounds like they are faulty. you should get in touch with CH support. What is why you sat on what for a year? Sorry, I don't understand (nor do I appreciate shouting)! Regards Pete

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