Pete Dowson

These options are good: but the Radar Contact window position seems to be set to a rather unlikely place: Those numbers are: top left x, y and horizontal and vertical size. The vertical start position at 14417 pixels would place it well off most folks screens. Are you maybe using multiple screens and changed since it last worked okay? Try deleting that line altogether so it comes up in its default size and position to start with. If that works I won't need to see the Log. Pete

Go to the FSUIPC menu, Logging page, and enable both Key/Button and ipc Write logging. Run the test you mention above, but otherwise keep the session short otherwise the log will become too large. Close FS. Then find the log file (in the Modules folder) and if it isn't too large, paste its contents into a message here. If it is large, ZIP it up and send it to petedowson@btconnect.com. Oh, best too to show me your FSUIPC4.INI file please, in case it is related to settings. Also please list all other add-ons you are running with FSX at the time. Pete

There is a keyboard focus issue with running P3D 2.2 in full screen mode. It is not focus on the RC4 window -- that isn't a separate window which can take the focus: the keystrokes are intercepted on their way to P3D itself, so the keyboard focus is with P3D. But initially when switching P3D to full screen mode it appears to lose its focus. Clicking on it with the mouse once will restore focus and should enable you to continue. The focus problem with P3D 2.2 should be reported to Lockheed Martin. It needs fixing for sure. There's another recent thread on just this problem, which is the only reason I know about it. I didn't connect the two issues (RC4 and keypress assignments in general) until now. Best if all users affected report it to L-M so it gets fixed sooner. See the thread entitled FSUIPC Key stroke commands Pete

Nothing in FSUIPC has changed in regard to these facilities, except for the recent addition of assignable controls to toggle them on and off (see FSUIPC4 History document, item 9 in the 'New Facilities' for version 4.93). Unless disabled by an INI file option, the centre button has always been used when kept pressed to operate the mouse look option (panning in the virtual cockpit), but the mouse move option, when enabled, has always used the wheel, in both directions, for moving the eyepoint back/forth and left/right, without the need to press the button. Obviously the wheel cannot simultaneously be used for other things. To use it for other cockpit functions you must disable the 'mouse move' facility, maybe by turning it off by assigning a button or keypress to "Mousemove option toggle". The mouse move forward back and left / right are part of the same facility. You cannot realistically expect those functions be separated. You just need to toggle the option off when not needed and on again when needed. Pete

Please see the download links subforum. Where you download FSUIPC updates I put a link into the P3D thread where the hotfix is buried. I've pleaded with L-M to make it part of the normal user account downloads oage all to no avail. Well, FSUIPC doesn't touch any files at all outside of its own set -- LOG, KEY and INI. And I don't believe that any aircraft does (or even can) modify its own CFG file, so I really don't understand what you have going on there. If the brakes are still working correctly on all other aircraft then I can only assume that either something has somehow got corrupted in the aircraft files (in which case reinstall it), or there is a problem with it that was always there but you've not noticed it before. The indications from P3D don't tell you what is going on with the brakes exactly enough in any case. You could try logging the axis values in FSUIPC. If you run P3D in Windowed mode, temporarily, and enable FSUIPC's console log, you'll be able to see the axis values change in real time. The red brakes messages on screen (assuming you've not suppressed them) show "brakes" when both left and right pressures are the same, and "differential brakes" when they are different. Regards Pete

Sorry, no. It wasn't me that tweaked it. Pete

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