Pete Dowson

Yes. The facility is the same for P3D 2. L-M haven't changed those tables (yet). Pete

I think you would get more help with RC on the RC support forum. You say you are one of the pilot voices on RC4. Is this new, or are you in fact an old hand with RC4? If so, what have you changed recently that you are unable to use it? The only part FSUIPC is playing in this is presumably registering your keypress in the registered list of keys assigned by RC. Have you actually done the correct key assignments in RC, or checked that they are as you think they should be? I'm afraid I don't know MCE at all, but I assume you have also checked that you have programmed that to press the RC-assigned keys correctly? As far as I am aware GSX only responds to keys when its menu is displayed. It uses standard SimConnect-driven menus and so is limited to using keypresses 0-9. But, apart from the key assigned in GSX to invoke the menu, those keypresses are not intercepted without the menu. I use both RC and GSX without any interference between them. I've always found it best to avoid using simple 0-9 keys for things like RC. My choices are like the defaults, but all with both Ctrl and Shift also pressed, and the RC menu then shows "CS1 ..." etc. I've programmed these on a touchscreen as buttons (WideFS's buttonscreen option). I've also successfully used It's Your Plane (IYP) which, something like MCE I suppose, can translate spoken words and phrases into actions such as keypresses. As for the RC menu window disappearing, I'm sorry but I don't know anyway that would occur normally, only by RC action. Maybe something you did caused it to terminate its service. Pete

But if you update to Win7 they will be different drivers. Also most hardware is covered by Win7. It is an excellent operating system, definitely the best Microsoft ever produced, in my opinion. Pete

The Modules folder is created by running the FSUIPC installer in admin mode (i.e. "as administrator, as instructed). If the Installer isn't getting even that far then you need to save the Log file, which you can see on the screen behind the failure prompt. Use the file menu entry you can see. SimConnect is the part of FSX which allows applications to interface to it. It is used by FSUIPC for 99% of its activities, and it is essential for most other add-ons for FSX. Although you can actually repair SimConnect in XP by loads of Registry editing, I wouldn't be able to instruct you. It took me a couple of days and that was years ago and there's no way I'm going through that again. I think you will probably need to reinstall XP -- or, better, upgrade to Win7 whilst you still can! (I don't recommend Win8). Pete

Snapshots aren't in any way useful in any case. You need to show me your Install log file -- just paste its content into a message. You'll find it in the Modules folder in your FS installation. BTW, be prepared for the worst. Uninstalling FSX is very precarious, and is very unlikely to fix a broken SimConnect installation. In most cases, especially with Windows Vista, 7 or 8, a complete Windows re-installation has been found to be needed. Or maybe you can roll right back to a restore point before you first installed FSX. Even with Windows XP a lot of careful Registry editing would be needed. Pete

There are two ways. If you are writing an actual driver program, running as a process on the FS or other computer on a Network, then you need to download the FSUIPC SDK, which includes everything you need -- except maybe, for managed .Net languages you might also look at Paul Henty's superb DLL (see the separate SubForum about this). The SDK is available in the Download Links subforum or on the www.schiratti.com/dowson page. Another way is to write it as a plug-in, using Lua and the Lua libraries built into both FSUIPC and, for network use, WideClient. The Lua library set provided actually includes full serial port support (the com library), so the whole thing can be done that way. Lua document and examples are installed in your FSUIPC documents sub-folder, in the FS Modules folder. Your choice. As far as the variables accessible to you in FSUIPC, please refer to the Programmers Guide (for FS9) and/or the Offsets Status documentation, installed for you in your FSUIPC Documents folder. Regards Pete

Please still report it when you can, on the P3D website. I seem to remember that they had a focus problem with an earlier version and fixed it. I think it is a recurrence and should be fixed. Pete

Thanks Ian. Pete

I've just been experimenting. I now assume you mean keypresses assigned to controls. Because, yes, I've just found that FSUIPC doesn't see the keypresses when P3D is first put into Full Screen mode. It is because P3D is losing the keyboard focus. I've no idea why -- but all you need to do after switching to full screen mode is click on the P3D display with the mouse, so giving it the focus. After that your key assignments work. I believe it must be a bug in P3D, so please report it to L-M. It isn't anything I can control in FSUIPC -- I could keep trying to set the focus of course, but then folks would never be able to use anything else! Regards Pete

What do you mean by "programmed key commands"? If you mean key presses assigned to controls, there can't be any difference because FSUIPC merely intercepts the keypress in the Windows message chain. If you mean buttons or switches assigned to send keypresses to P3D, you need to tell me what they are aimed at. Hardly anything built in needs keypresses, so I assume these must be for other add-ons -- so are you sure it isn't the other add-ons not seeing the keypresses? In either case, please enable button/key logging in FSUIPC's logging tab, then test again. Close P3D down and show me the complete log, NOT an extract (so keep it short please). [LATER -- see my next message] Pete

I had to move your FAQ subforum post to the Support Forum so it can get a support answer. Really? Doesn't GoFlight support the EFIS? Do they expect everyone to work things out themselves? Do they actualy simply say you need FSUIPC? You can use assignments in the Buttons & Switches tab of FSUIPC options. Look down the list of FS controls you can assign to until you get to Efis. The ones you can use are Efis 738 ND centre Efis 738 ND arc Efis ND scale set (the parameter 0-7 selects) Efis ND mode set (the parameter 0-2 selects) Efis ND map item set (the parameter 0-3 selects) Efis VORADF1 set (the parameter 0-2 selects) Efis VORADF2 set (the parameter 0-2 selects) Microsoft never actually provided any controls for the EFIS switches. They are all locally handled in the gauge, so MS assumed you'd only ever use the mouse. FSUIPC actually uses L:Var ("local panel variable) access to implement these additional controls. I used to have a GoFlight MCP and EFIS, but I programmed it for Project Magenta, never for any default aircraft. Regards Pete

Sorry, I've no idea what it is. If it is a joystick type device recognised by Windows as such, and assignable in FS, then it is also assignable in FSUIPC. FSUIPC doesn't distinguish between makes or types of joystick, it simple handles up to 8 standard axes, up to 2 POVs and up to 32 buttons. After that you are dependent on drivers or programming Lua plug-ins. Pete

The most likely reason is that FSUIPC 4.931 is not compatible with P3D 2.2.10437.0. Please apply the hotfix from LM to bring it up to 10438 -- there's a link next to the FSUIPC 4.931 download link in the Download Links subforum. If that doesn't fix it, please double check that your correct KEY file is "C:\Program Files (x86)\Lockheed Martin\Prepar3D v2\Modules\FSUIPC4.AFR-FriendlyD3D.exe.key" because FSUIPC isn't even finding your name and email address from such a file. Since you installed in Program Files, which is a protected area, you might need to run Explorer "as administrator" to edit or rename files in that folder. Ah. I see their his files were named differently to yours, without the 2.exe". All the files, INI, LOG and KEY must be nmaed the same way. I really HATE these EXE renaming fiddles. FSUIPC has to rely on the process name to know what it is running inside. It also messes other programs up, like Opus and EZCA. Pete

Didn't you check the FSUIPC log, because I think it will have logged an error on the line if value <> 0 then because there's no <> symbol in Lua. For not equals you use ~=. ALWAYS check the log. That's where errors will be shown. Also do some other checks. For example, do you see 65CD changing? (Use the Monitor option on the FSUIPC logging tab). If not you haven't enabled the 737NGX to populate the data. Also check that you don't have "NoActionOn7B91=Yes" set in the FSUIPC4 INI file. BTW why are you wanting to set 7B91 to zero when the transponder is enabled? Shouldn't it be the other way around? I don't recall anything about SB I'm afraid, but it seems more logical for it to use non-zero for "on". Pete

FSUIPC can only provide details which are known as AI aircraft to FS. Does the FS Traffic Explorer show IVAO aircraft on the ground? If not then FSUIPC will not receive details of them either. Pete

Except I made a mistake in the Signed Word range -- corrected now. ;-) Pete

Yes, but if you are adding the other lights, as I suggested, best not to call it "Taxi2 but just "Lights". No, whoever did the data file for FSInterogate got it wrong. Only values treated as signed numbers have signs. This one is just a collection of bits. But it actually makes no difference in this case, for two reasons: 1. The top bit (sign bit) is not used, always zero 2. You are not treating the value as a number in any case, so whether it is signed or not is irrelevant. The only difference between signed and unsigned numbers is that, when treated as a number, the range of values is different. Signed Word -32768 to +32767 Unsigned word 0 to 65535 Signed Byte -128 to +127 Unsigned Byte 0 to 255 See? It's all in the interpretation, not the way it actually looks. Pete

The event.offset function does not have any "bit testing" capability. It will give you the event whenever ANY of the bits in your UW (Unsigned Word) change. It might be an idea for me to add such a facility -- by a 'mask' value so one or more bits can be tested -- but it doesn't at present. (Maybe I'll add that in future). So what you have to do is test the relevant bit yourself inside the called function. For bit 3 you are right, it has value 8, so you test for bit 3 like this: if logic.And(val,8) ~= 0 then gfd.SetLight(GFT8, 0, 2) else gfd.ClearLight(GFT8, 0, 2) end Now, because your function will be called for ALL changes in offset 0DoC, you really should just call the function "Lights" (say), and test each bit in turn, setting or clearing its light as appropriate. i.e. a sequence of if logic.And(val, <bitvalue>) ~= 0 then gfd.SetLight(GFT8, 0, <LED number>) else gfd.ClearLight(GFT8, 0, <LED number>) end parts, all in the one function. It might look cumbersome. I'm afraid Lua was not provided with any logical functions like AND, OR, and SHIFT, so FSUIPC provides them in the logic library. But whilst it looks cumbersome, it is efficient -- don't forget it is only called when one of the lights changes, so it isn't doing anything most of the time. And its compiled form internally is small. Regards Pete

It isn't the same problem, then! Please show me the actual log file. Is there a Prepar3D.exe as well as this one with the strange name? Pete

For many applications, and for some of its facilities, I'm afraid FSUIPC needs the very latest P3D 2.2. There are serious problems using it for many things with 10437 -- the latest is 10438. I put a link to where to find that L-M Hotfix in the Download Links subforum, next to the details for FSUIPC 4.931. I know the changes guide says it can be used with the standard 10437 release, but this turns out to be not quite the case, depending on your use. That is why I put the warning in the sticky at the top of this Forum and also details of 10438 next to the download link. Pete

The "profile specific" box provides the drop down list when you have loaded an aircraft not already assigned to a profile. You have already assigned the current aircraft, and the profile it is in is shown at the top, as you actually saw! I did explain this in my previous message! What didn't you understand there? Just load the aircraft you want to assign to a profile BEFORE you try to assign it to a profile! FSUIPC cannot tell what aircraft you want to deal with as it can't read your mind. It only deals with the currently loaded aircraft! Pete

So will you be okay now? Pete

Lua won't understand 2EE0. It isn't a decimal number with E's in it! You either need to precede it with 0x (so 0x2EE0) to tell it that it is a hexadecimal number,, or quote it, like "2EE0". your choice. 1 byte = 8 bits = byte 2 bytes = 16 bits = word 4 bytes = 32 bits = double word, or "DWORD" 8 bytes = 64 bits = quad word or "long long" Also there are two floating point formats 4 byte = 32 bit float = "float" 8 byte = 64 bit float = "double" Please see the FAQ subforum. There's a thread there about numbers. Pete

For a Lua "newbie" you seem to be constructing quite a complex bit of code. Without spending ages try to read through it all to see what you are trying to do, which isn't at all obvious without a lot of study, can you explain what your problem is and where in all that code you think you have things wrong? I don't even understand what the logging is supposed to mean, let alone the code. BTW I can show you even more obscure code of my own, if you like. Even I don't understand it, at least without a lot of study, and i wrote it! I actually get on better reading C or ASM, I find Lua much more difficult to read. Regards Pete

Once you have assigned an aircraft to a profile, it is actually assigned to that profile, and the profile name is displayed so you can see it. You only get to choose again when you load a different aircraft. what is your actual problem? As reading1871 says, FSUIPC provides access to all FS controls and in fact many more FS controls than you can find in FS's own dialogues, and many others added by FSUIPC . The only problem you may run into is deciding among them all which ones to use. In FSUIPC all of the FS controls listed are actually directly from FS's own "CONTROLS.DLL" index and it uses the names FS provides there, not the more descriptive names shown in FS's own dialogues. If you wish to know what control is normally used by FS to do something you can use FSUIPC's event logging to see what it shows in the log when you operate a control in FS, e.g. via the keyboard or mouse click. As far as deleting assignments in FS, there is no need. The best way to avoid conflicts is simply to disable the controllers in FS -- that's one mouse click. You don't need to worry about keyboard assignments as FSUIPC sees the keypresses before FS does so will apply its own assignments and stop FS seeing those it it dealing with. Pete