Pete Dowson

That message is documented in the FSUIPC4 user guide and explained. It is an inevitable result of FSUIPC4's "manifest probe", which is the way it finds which is the best version of SimConnect it can use on your system. it looks like you haven't got FSX SP2 or Acceleration installed, so the first probe gets a failure. It then goes on to find the SP1 SimConnect. If that wasn't there you'd get another entry. All that happens at the loading of FSX, and it is perfectly harmless, as clearly documented. Sorry, I'm afraid you must look elsewhere for your problem solution. Pete

Okay, I see what is going on: The variable "longitude" is defined as an Int64. Dividing an Int64 by 65536.0 4 times diminishes it to zero. I think it is a result of how your Delphi compiler deals with the code. Even your solution probably only gives an accuracy of 1 in 65536, not 1 in 2^63 as it should. In C and C++, once you use a floating point value, like 65536.0, in a computation, the whole computation is performed in floating point. Maybe Delphi is not so clever. Your code longitude * 360 / (65536.0 *65536.0 * 65536.0 * 65536.0); is possibly getting converted into something which is supposed to work on a fixed point 64 bit value. You could try: longitude * 360.0 / (65536.0 *65536.0 * 65536.0 * 65536.0); or possibly even safer: (longitude * 360.0) / (65536.0 *65536.0 * 65536.0 * 65536.0); but the general solution, which should work in all languages, is to first copy the int64 value you read into a double floating point value, and THEN do the computation. You should do that for the latitude too, and any other value you need to convert. Regards Pete

Can you show me the raw value before you try to compute the longitude? You can use FSInterrogate2 to monitor these things also. It would be helpful to you when debugging your software. You'll find FSInterrogate in thee FSUIPC SDK. (It was written in Delphi also!). For instance, I just went to EDDF (active runway selection, whichever that was) and FSInterrogate shows this for those offsets: Viewing the longitude computation which FSInterrogate2 performs, you'd see this: which appears to suggest a discrepancy between what you are reporting and what is actually happening, since the computation looks to be the same, doesn't it? Regards Pete

Well, you can either use the same keyboard combination -- Shift+Z (cycles through info bar 1, then 2 then 1+2 then both off), or the FS control which that keystroke invokes. I think in Flight mode the control is "READOUTS FLIGHT" and in Slew mode it's "READOUTS SLEW". Try those anyway. For any FS control you know how to invoke you can work out what the FS control name for it is by using FSUIPC's logging. Just enable "Event" logging on the logging tab, operate the control, and look at the FSUIPC4.LOG file (from the FSX Modules folder). If you switch FSX to windowed mode, you can have the FSUIPC4 log displayed on screen in real time, just choose the Console option also on the Logging tab. Regards Pete

Okay. That's good. Strange puzzle nevertheless. Regards Pete

Not without getting a new registration. And there's really no point. The name and address you gave when purchasing are only used to uniquely identify you, and that is all. The name alone is not enough. The address could be a street address or an email, depending how you ordered. It doesn't matter as it is never used as such, it is only used as part of the unique identification. The thing to do now is to save all the details. For example, make a copy of the FSUIPC.KEY file from the Modules folder. That is merely a text file containing the correct name, email/address and registration key. It does advise you to do this in the documentation. Regards Pete

FSUIPC4 won't have anything whatsoever to do with it unless you have made settings to do such things. If you don't know what you've done just delete the FSUIPC4.INI file from the FSX modules folder, so that everything reverts to default -- i.e. no actions by FSUIPC at all. Pete

That is, or maybe was, its entire purpose. I think it was invented to work with an earlier version of SquawkBox, so I don't know if it'll work with anything else. Squawkbox 3 was enhanced to do the job itself, so AIbridge fell into disuse I think. Regards Pete

Make sure that every part of what you are entering is exactly correct -- your name, the one you used when buying it, the email or address used when buying it, as well as the key remembering to carefully distinguish between 0's and O's, 1's and l's, 2's and Z's. All parts must be correct. Then it will work. If not it won't. It is that simple. Pete

Why be so cryptic? Why don't you just say there are values for the inboard flaps but no values for the outboard flaps? FSUIPC is merely relaying internal FS values, and all those offsets most certainly do work when they need to. What aircraft is this with? Maybe it has no outboard flaps? Did you bother to check? Please do so before making strange unexplained postings -- look in the assorted [flaps...] sections in the Aircraft.CFG file. That'll tell you what parts to expect populated. Sorry, but I have enough to do without wasting my time trying to interpret strange postings. :roll: :roll: :roll: Regards Pete

Your latest message crossed with mine, just above. Sorry for the bad news. Pete

Okay, tried it. And the answer is: no! I'm afraid it isn't possible with the LVars either. You can read the LVars to ascertain the state of the switches (assuming you've not written to the variables), but evidently their code doesn't act upon those values, at least not directly. PMDG aircraft have never been amenable to use with external hardware, and it looks like the 747X is much less so even than their FS9 737NG. Unless you can manage to persuade PMDG to sell you their software development kit (which I think they were originally proposing -- at quite a high price, for hardware developers) I think your only way would be via the Key2Mouse program. Regards Pete

Why are you "back to the option with 3 entries"? Far better to supply the parameter with the assignment. Please read this part of my last message again: Anyway, even if you get it right, it may not work. It really completely depends on how PMDG have coded these functions. If it doesn't work at all this way or the mouse macro way, then it isn't possible with FSUIPC alone. You've need something like Luciano Napolitano's "Key2Mouse" program, to convert keystrokes to mouse actions. Then you use FSUIPC to assign those keystrokes to your buttons or switches. If I get time today I will try to do this myself. I do have the 747X set up one one of my old PCs. Incidentally, you'll be able to read that Lua display on screen if you undock it. Right-clcik and undock, like any other FS window. Regards Pete

Only if the cpflight driver provides access to their states, in FSUIPC offsets, like pmSystems does. How does it operate them? Regards Pete

First this: Module="PMDG_747400_Main.DLL" is only relevant to Mouse macros. You don't need it or want it in an ordinary macro file. Why is it there? Second: 1=L:EFIS_L_NAVR_Switch_var=10=toggle 2=L:EFIS_L_NAVR_Switch_var=0=toggle 3=L:EFIS_L_NAVR_Switch_var=20=toggle Where did you get the format "Name=value=action" like this from? Please please please READ what is written! There's nothing listed like that at all, with the value of the variable stuck in the middle like that! And "toggle" is obviously NOT the action you want. Look what it says: "changes the value to zero if it is non-zero, or 1 if it is zero." You want values 10, 0 or 20 set, respectively. This is what the listing showing what happens to those variables is telling you! 10 for VOR, 0 for Off, 20 for ADF. I already told you this!! So, theoretically you'd need something more like: 1=L:EFIS_L_NAVR_Switch_var=set,10 2=L:EFIS_L_NAVR_Switch_var=set,0 3=L:EFIS_L_NAVR_Switch_var=set,20 See? Unfortunately, all three of those would have the same name so you wouldn't be able to assign to them very easily. So the thing to do is delete two lines and just have one: 1=L:EFIS_L_NAVR_Switch_var=set Then you assign your switch to that control in the drop-down, and use the parameter field to set 10, 0 or 20. This takes advantage of the main feature of the "set" action, i.e. "copies the parameter in the Macro invocation to the identified Lvar. ". If you'd actually run that Lua Lvar logging program as i suggested, and operated the switches and seen the values change, perhaps you would have understood all this a lot better. You are going to have to do this for the other switches you want in any case. Please do try it. Regards Pete

I don't really know, but i don't think so. Why not assign the hat to the PAN VIEW control via the axis assignments tab instead? That's continuous I think. Are these undocked views? I think you should be able to configure those more permanently by editing view windows in the PANEL.CFG. Regards Pete

Why do you want to write a Lua plug in? Are you misreading what I suggested? There's certainly no need at all for you to learn Lua at all! I have already written the Lua plug in which monitors Lvars. I gave you its name! I simply suggested you run it (i.e. assign it to a keypress so you can start it). This is only so you can ascertain the names and values of the Lvars you need to address. Then instead of Mouse Macros you construct Lvar macros, editing them in a Macro file of your own making. For information on all this, please refer to the Advanced User's document. It has a complete chapter on "Macros", and within that a section entitled: Gauge local variable access (L:vars), by macro Regards Pete

FSUIPC4 and FSX are both 32-bit programs. There's absolutely no difference is what they do between the 32-bit and 64-bit platforms. There can't be. Does the mixture control operate correctly using standard FSX controls? Obviously you must have installed FSX on the 64-bit system as you cannot simply use a 32-bit installation on a different operating system without installing. Therefore the main difference is not going to be your code or my code or FSX code, but surely something not right in the installation. Incidentally, I find it a little odd that you'd choose those FLOAT64 offsets rather than the more traditional simple 16-bit integers at 0890 and 0928. Perhaps your program is completely floating point oriented? Anyway, try this: monitor offsets 3AF0 and 3A30 on FSUIPC's Logging page, right-hand side, as FLT64. Select normal log. The FSUIPC log will show the SimConnect actions as well as the offset changes. In FSX windowed mode you could show the log in real time in its own window (select the console on the left hand side). Operate the mixture via a variety of methods, keyboard, normal joystick assignment, even a Lua plug-in, and compare them to what you are doing. You should be able to work out what is going on. I know everything is okay in this area on 64-bit platforms. I am running a Piper Arrow cockpit on Win7 64-bit (previously Vista 64) with no problems at all, though I must admit my little driver for that uses the 0890 offset. Checking my code, however, shows that both 0890 and 3AF0 operate the same SimConnect variable. Oh, also please change to version 4.525 (see Updates announcement). When investigating things it is always best to use the latest version - and you'll be using the same as me, then. Regards Pete

Evidently you have Windows hiding "known filetypes" from you. One of the first things you should do if you ever want to identify files correctly is turn that off in Windows Explorer options. The first file you pasted was the INI file, probably "known" to windows as "configuration settings" or similar. The second is the Log file, maybe denoted simply as a "text" file by Windows. Anyway the reason you have problems is because of this: and the Message you get clearly states this and the solution: The fix is also documented in the FSUIPC user guide, and the ZIP contains the file referred to! Didn't you even look? If that doesn't work the most likely problem is that you have either deliberately or accidentally stopped Windows cryptographic services. Either that or windows is broken and needs repairing. Note that this still wouldn't affect FS's response to your controls, as FSUIPC is not handling them and has nothing to do with them. But it will prevent any program using FSUIPC from operating correctly. Regards Pete

Good. No, sorry. Never had the time (nor really the inclination) for any of the missions. I fly in a 737 hardware cockpit and prefer therefore to fly 737s in any case. I do have a smaller Piper Arrow cockpit too, for VFR low level fun flying. I'm going to try FSFlyingSchool on that one. Sorry, not used either. Apart from my Piper Arrow cockpit, which is by Aerosoft Australia, all my gear is by PFC ( http://www.flypfc.com ). I did have a CH yoke about 10-15 years ago. It got very stiff and I had to get it serviced at CH's local agents in Shrewsbury. That yoke was scrapped years ago. Before that I had one of their FlightSticks, but that went to charity. I've no experience of their recent gear, nor Saitek's. Regards Pete

Hmm. I use Radar Contact -- have done for many years -- and I don't get audio messages displayed. I listen to them on my headset or overhead speakers. I assume this is an option you've enabled in Radar Contact -- one i've never used by the sound of it. Don't. I think you need Radar Contact support, not mine. FSUIPC only displays what it gets. Try the RC forum: http://forums1.avsim.net/index.php?showforum=135 Regards Pete

No idea, sorry. Does everything work okay in Windows generally (I mean outside FS)? If so then I'd advise you ask around in the FSX forum. If not i'd suspect a Windows registry or driver problem -- you might need to repair windows or go back to a restore point. Regards Pete

What "green line"? Aren't you seeing a proper Radar Contact window, with a title and room for several lines? The FS ATC menu should be more lines than that! You do realise that the FS windows can be sized and saved with your flights? You can even undock them if you prefer a solid colour background, or want to move them off to another screen. Regards Pete

FSUIPC touches nothing programmed through FS. There's something else interfering with it, maybe through FSUIPC's facilities. If you aren't going to bother even showing me the Log as I asked, I cannot really help any further. Just blaming FSUIPC does not help. If installing 3.90 broke joystick inputs there'd be hell up from thousands of users. No, it's something on your system, and you aren't helping I'm afraid. I see that "client" you mentioned uses FSUIPC. If you remove that does it solve the problem? Do you have any other programs, aircraft or modules using FSUIPC? Don't forget, without registration, all FSUIPC becomes is an interface for other programs to do as they wish with FS. FSUIPC, unregistered, is completely dormant, just an interface. nothing more. Regards Pete

Okay. Two points: 1. For those functions, ADF/VOR switches, the TAB test doesn't work. I suspect the whole EFIS unit, maybe the whole main panel, is programmed differently. FSUIPC mouse macros can only work when the gauge is written using the standard FS gauge toolkit methods. This doesn't apply to more and more gauges now, especially those written in XML. This is why you always need to test first. 2. Not that it is relevant now, but i notice that there are NOT separate mouse operations for ADF ON/OFf, VOR ON/OFF. It is one three position switch, with the left mouse button pressing it up and the right pressing it down, so even if it had worked, the best you could achieve would be "VOR/ADF1 DN" and "VOR/ADF1 UP". Ie. two button assignments, not 4. Anyway, there might be an answer. It looks like the EFIS uses "Lvars" for its settings, so you might be able to implement everything using Lvar macros instead. If you have the Lua examples installed, try assigning a keypress to "Lua Log Lvrs". It will initially log and display ALL of the Lvars currently known. Then operate the EFIS switches and you'll see the relevant Lvars change. I just did that for the Left and Right VOR/ADF switches and got this: 1635532 LUA: L:EFIS_L_NAVL_Switch_var=20 1639625 LUA: L:EFIS_L_NAVL_Switch_var=0 1641641 LUA: L:EFIS_L_NAVL_Switch_var=10 1645750 LUA: L:EFIS_L_NAVR_Switch_var=20 1648094 LUA: L:EFIS_L_NAVR_Switch_var=0 1650172 LUA: L:EFIS_L_NAVR_Switch_var=10 The switch values 20, 0 and 10 appear to relate to ADF, OFF and VOR, respectively. Regards Pete