Pete Dowson

The fuel flow value is the instananeous rate at that time, as displayed in the dials. You are assuming it will remain at that rate for the whole flight. What were you doing at the time you read those values? In any case, the offsets you are reading are in some unknown units designed for compatibility with FS98-FS2000-FS2002 and FS2004 (for programs not specifically designed for FSX/P3D). That's why it says Fuel Flow PPH SSL (pounds per hour, standardised to sea level). Don’t know units, but it seems to match some gauges if divided by 128. Not maintained in all cases Try using the newer easier-to-use ones, such as the 64-bit floating point value for Engine 1 at 0918. Either way, I would have that that computing the range based on the current fuel flow is really unlikely to give you anything useful, unless you wait till you are in a stable cruise and then also assume no winds which can seriously affect range. Pete

Unless you a touch a key which you have programmed in FSUIPC, then really FSUIPC is just not involved. It doesn't care whether you touch the keyboard or not, and most certainly doesn't do anything as a result for a non-programmed keypress. Sorry, but you really must look elsewhere. Folks nearly always pick on FSUIPC first, and it is very rarely involved. I'd start by completely uninstalling the 737NGX and re-installing it from scratch. BTW didn't you look at the Windows error report to see where it crashed -- i.e. in which module? Then at least you have a chance of someone recognising it. You might even find it on one of the Forums already reported and perhaps fixed. You can view previous errors in Windows Event viewer. You didn't review the L-M P3D support site where lots of CTDs are reported? I see you are using Windows 10, and the version and build number of it suggests it is updated. Therefore you must have that update installed. If not, how did you stop it? Pete

Actually, as he is using P3D v3.4, it will be FSUIPC4 and FSUIPC4.LOG. You should refer to the L-M support forum. There are a lot of problems like this resulting from one of the recent Windows 10 updates (KB4038788). Pete

The same as a single assignment, but with a different entry number (the value before the =) and obviously a different keycode or control number, or whatever. They are actioned in ascending order of the entry numbers. There are examples in the Advanced User's guide, as well as a list of keycodes and FSUIPC-added controls. For normal FS controls there's the list in your FSUIPC Documents folder, inside the Modules folder. Oh, and you can have two actions on a keypress - one for the 'press' and one for the 'release', and sometimes that's enough, and appropriate because you know they'll always be executed in that order. Pete

Why are you trying to edit the INI file to do this? You are problably making an error in the encoding. The way to do it is simply assign they keypress in the Key assignments menu! In the INI you can add extra assignments to existing assignments, for multiple actions on the same key, but you muat get the format correct. If you are actually getting them deleted you are probably using the same line/parameter number -- the number before the =. That's the reference used by Windows to retrieve the parameters, and needs to be unique withon each section. Pete

For flight time you'd need to calculate it. note the time of ground flag going off and coming on again, and subtract the two. Read the FS time to avoid pausing, menu access and time acceleration giving false results. I think there's fuel flow. Seach the offset status list documnet in your FSUIPC documents folder. Pete

Further to Thomas's reply, access into FS via FSUIPC is free from shareware and freeware applications, unless they need to run Lua plug-ins. I do not know "MaldAir" but it is likely that it does not need FSUIPC to be registered -- its documentation or author should tell you. As documented, to install without registering you just press the "Not now" button when asked if you want to register. Pete

No. Those errors are only advisory and shouldn't occur. I am n disagreement with L-M about them -- they are when FSUIPC is requesting information about the payloads to be supplied whenever it changes. It does this for all paystations, all engines, all pumps, etc etc, but L- have decided, only in the case of paystations, that requesting payloads for stations which don't exist at present is an error -- NOT one reported back to the program, as it should be, but only logged in that OPTIONAL log. It most certainly is not responsible for any stuttering as it is all over is an instant. Just turn the logging off, as it is by default. (BTW how do you know that your "shaking" (not stuttering? Visible shakes up/down/left/right?) is precisiely for the period of that logging?). Maybe it is bad disk access with retries? Obviously logging will write to disk, though Windows should be caching that. Certainly any view shaking has got to be something else. FSUIPC and WideFS do have a lot of setting up to do before the aircraft is "ready to fly", but after the aircraft is loaded, which is why both of them delay many operations, like connecting to clients, till then. However, there never had been any measurable performance hit, not with any version of FSX or P3D and it really cannot be responsible now. And FSUIPC doesn't touch graphics. Pete

Seems that something you had set previously was doing it, but the logs you supplied certainly did not show anything which was not provoked by a definite button press. I can only think that you had some initial setup which imitated that button 9eg possibly by a n INI paramer or a Lua plug-in, or even an external app or internal add-on). There wasno "initial" button press parameters in your INI file, so it must have been something else. Msaybe one of the buttons reads as being "pressed" when initialised. Why not compare your new FSUIPC5.INI file with the one yo posted here earlier, see what differences there are? Pete

AS Thomas says. And more and more modern aircraft do not support Mouse Macros in any case -- a lot are built using XML and that mostly uses "L:Vars", whilst the three PMDG Boeings have a complete set of custom controls you can assign to. I have asked L-M for something similar to the mouse macro operation, but I suspect that with its less and less utility this won't happen. Pete

No, that was done by hacking into the code in FSX and P3D1-3. I'm not hacking into 64-bit P3D, sorry. You'll have to resort to normal methods via FSUIPC or SimConnect, which involves atting Global Weather mode and just setting the global wind value. The short term change you are witnessing uses the latter methods, but you'd first need to set global mode and zero change rate. Pete

As Luke says. Just follow the instruction in that error message (and also in the Installation document included in the ZIP. i.e. right-click on the Install EXE (AFTER moving it from the ZIP file to a folder or desktop, as for any ZIPped program), and select "run as administrator". BTW, in future please make your thread title more informative so you get the right attention. Just "Help" is not useful. Most all of the threads are asking for help of one sort or another! Pete

Best to do that then save it like that as your default flight. Then it will be reloaded that way each time. I am using 3 outside view windows to make a 220 degree FOV on a curved screen, and that uses software to straighten the image (projectors are designed to distort the real image to make it work correctly on a flat screen). Each of the three has to have a precisely pre-set ZOOM so that the overlaps can be blended correctly (to make it all seamless), and ensure that looking directly left and right does show the correct parts of the scenery 180 degrees apart. Those settings are always loaded at the start. All other flights are then made from that starting one. Pete

Well, FSUIPC has no built-in Zoom operations, nor does it do any user actions at all if not programmed to. A registered install is the same as an unregistered one as far as external applications are concerned, though. And they can do many things via FSUIPC. Registration also enables the operation of Lua plug-ins, which can be auto-loaded and started, but again, you have to program that. Yes, these things are often an add-on aircraft effect. I see from the INI file that you have checked absolutely all logging options: WideLuaGlobals=Yes DebugLua=Yes LogWeather=Yes LogWrites=Yes LogReads=Yes LogEvents=Yes LogLua=Yes LogAxes=Yes LogButtonsKeys=Yes LogExtras=Yes That really is NOT a good idea, as it will produce an overwhelming log which would be very difficult and time consuming to find out what is going on! So, instead of analysing it fully I just searched on the word ZOOM. The only ZOOM changes were all instigated by button operation, 142437 Button changed: bRef=0, Joy=3 (D), Btn=1, Pressed 142437 [Buttons] 7=PD,1,C65550,0 142437 FS Control Sent: Ctrl=65550, Param=0 ZOOM_1X 142437 *** EVENT: Cntrl= 65550 (0x0001000e), Param= 0 (0x00000000) ZOOM_1X and 207312 Button changed: bRef=0, Joy=3 (D), Btn=5, Pressed 207312 [Buttons] 1=PD,5,C65655,0 207312 FS Control Sent: Ctrl=65655, Param=0 ZOOM_IN 207312 *** EVENT: Cntrl= 65655 (0x00010077), Param= 0 (0x00000000) ZOOM_IN These assignments are to a Joystick "D" (your yoke), buttons 1 and 5 respectively, asassigned here: 6=PD,4,C65656,0 -{ZOOM_OUT}- 7=PD,1,C65550,0 -{ZOOM_1X}- So both ZOOM actions were due to programmed button actions! Pete

Please update to the currently supported version of FSUIPC, 5.121b. The Log AGAIN shows FSUIPC doing exactly what it should be doing! If switches are operating without you doing anything then you have some very bad connections or equipment. FSUIPC is receiving the signals from the USB device! You have already stated that things are okay on your other device, so why is it you still refuse to believe that your hardware connection/ device is bad? Pete

As I asked before: Can you please confirm that you are using the currently supported version, 5.121b? There's no point in proceeding till you do this. Pete

Can you please confirm that you are using the currently supported version, 5.121b? This ACARS program. Is it an FSUIPC Client, or does it use SimConnect? I'm confused by your statement that "ACARS is connecting to the sim" which contradicts the last part somewhat. Pete

Good. Thank you for letting me know! Pete

I'm afraid the RunIf parameters do not support conditional actions. You could do it by having two different FSX.EXE copies, in the same folder, with different names (i.e. make copy and rename one). This would allow you to have alternative FSX.CFG files as well as alternative FSUIPC4.INI (and FSUIPC.KEY) files. A bit of a messy solution though. Described in the FSUIPC documentation somewhere. Alternatively you could have a Lua plug-in program which checked something easy enough to set (say, the starting flight or aircraft name or type when "ready to fly", and ran the appropriate programs then. I think most folks who want different configurations of programs running use one of the several external starters available, like perhaps SimStarter (see Aerosoft website). Pete

You can do that only by have two assignments to the same button, which is accomplished by assigning the first, then editing the INI fie and adding the second. For details you'll need to refer to the Advanced User's guide, but if you have difficulties, do post again. Pete

Ah! Radar Contact Data. I should have remembered (I used to use RC before I moved to ProATC/X). Those files are actually a function of Radar Contact, which sees that a flight has just been saved via appropriate offsets, and then saves its own data. Let me know if it doesn't work with 5.121b before we commence further investigations. Pete

What's an "RCD version"? FSUIPC's AutoSave doesn't create any files itself (except maybe an ipcBin file if you opted to save data too). All the AutoSave does is call the same function as you would by using the Save flight menu in P3D. It just generates the filename for SimConnect. Please check that you are using the current supported version of FSUIPC (version 5.121b). Pete

Yes. I assume this is one of the buttons in question? 823265 Button changed: bRef=0, Joy=0 (A), Btn=0, Pressed 823265 [Buttons] 33=PA,0,C65750,0 and assigned to this control: 823265 FS Control Sent: Ctrl=65750, Param=0 PANEL_LIGHTS_TOGGLE This section: 823265 Button changed: bRef=0, Joy=0 (A), Btn=0, Pressed 823265 [Buttons] 33=PA,0,C65750,0 823265 FS Control Sent: Ctrl=65750, Param=0 PANEL_LIGHTS_TOGGLE 823312 Button changed: bRef=0, Joy=0 (A), Btn=0, Released 824734 Button changed: bRef=0, Joy=0 (A), Btn=0, Pressed 824734 [Buttons] 33=PA,0,C65750,0 824734 FS Control Sent: Ctrl=65750, Param=0 PANEL_LIGHTS_TOGGLE 824765 Button changed: bRef=0, Joy=0 (A), Btn=0, Released 831234 Button changed: bRef=0, Joy=0 (A), Btn=0, Pressed 831234 [Buttons] 33=PA,0,C65750,0 831234 FS Control Sent: Ctrl=65750, Param=0 PANEL_LIGHTS_TOGGLE 831343 Button changed: bRef=0, Joy=0 (A), Btn=0, Released 848828 Sim stopped: average frame rate for last 32 secs = 93.8 fps 848828 Max AI traffic was 0 aircraft 938890 Button changed: bRef=0, Joy=0 (A), Btn=0, Pressed 938890 [Buttons] 33=PA,0,C65750,0 938890 FS Control Sent: Ctrl=65750, Param=0 PANEL_LIGHTS_TOGGLE 938906 Button changed: bRef=0, Joy=0 (A), Btn=0, Released 939234 Button changed: bRef=0, Joy=0 (A), Btn=0, Pressed 939234 [Buttons] 33=PA,0,C65750,0 939234 FS Control Sent: Ctrl=65750, Param=0 PANEL_LIGHTS_TOGGLE 939312 Button changed: bRef=0, Joy=0 (A), Btn=0, Released 941578 Button changed: bRef=0, Joy=1 (B), Btn=9, Pressed shows that button being pressed and released 3 times, each time sending the correct Toggle control, but with more that one second (6 in one case) between each, before it looks like you went into a menu ("Sim stopped"), then pressed it twice more, bith times with the correct result, but with only about 1/3rd second gap. Not sure what you were doing, so only you can decide if that is right. but certainly FSUIPC is doing the right thing. There's a similar sequence later: 969500 Button changed: bRef=0, Joy=0 (A), Btn=0, Pressed 969500 [Buttons] 33=PA,0,C65750,0 969500 FS Control Sent: Ctrl=65750, Param=0 PANEL_LIGHTS_TOGGLE 969515 Button changed: bRef=0, Joy=0 (A), Btn=0, Released 981375 Button changed: bRef=0, Joy=0 (A), Btn=0, Pressed 981375 [Buttons] 33=PA,0,C65750,0 981375 FS Control Sent: Ctrl=65750, Param=0 PANEL_LIGHTS_TOGGLE 981640 Button changed: bRef=0, Joy=0 (A), Btn=0, Released 983906 Button changed: bRef=0, Joy=0 (A), Btn=0, Pressed 983906 [Buttons] 33=PA,0,C65750,0 983906 FS Control Sent: Ctrl=65750, Param=0 PANEL_LIGHTS_TOGGLE 984140 Button changed: bRef=0, Joy=0 (A), Btn=0, Released 984515 Button changed: bRef=0, Joy=0 (A), Btn=0, Pressed 984515 [Buttons] 33=PA,0,C65750,0 984515 FS Control Sent: Ctrl=65750, Param=0 PANEL_LIGHTS_TOGGLE 984578 Button changed: bRef=0, Joy=0 (A), Btn=0, Released 985890 Button changed: bRef=0, Joy=0 (A), Btn=0, Pressed 985890 [Buttons] 33=PA,0,C65750,0 985890 FS Control Sent: Ctrl=65750, Param=0 PANEL_LIGHTS_TOGGLE 985922 Button changed: bRef=0, Joy=0 (A), Btn=0, Released 993453 Button changed: bRef=0, Joy=0 (A), Btn=0, Pressed 993453 [Buttons] 33=PA,0,C65750,0 993453 FS Control Sent: Ctrl=65750, Param=0 PANEL_LIGHTS_TOGGLE 993687 Button changed: bRef=0, Joy=0 (A), Btn=0, Released 996625 Button changed: bRef=0, Joy=0 (A), Btn=0, Pressed 996625 [Buttons] 33=PA,0,C65750,0 996625 FS Control Sent: Ctrl=65750, Param=0 PANEL_LIGHTS_TOGGLE 996687 Button changed: bRef=0, Joy=0 (A), Btn=0, Released 1009156 Sim stopped: average frame rate for last 73 secs = 89.8 fps but again each press/release sequence generates the one Panel_Lights_Toggle control being sent. So FSUIPC is doing exactly what you programmed it to do. There are probably many more examples throught that very long long. I'm not sure what you were trying to show or provide making it so long. A short test pressing and releasing the button once then grabbing the log would have done just as well. Pete

It will stay on provided that it isn't cleared. Clearing it is a function of the add-on, the disaply disappears when clear because that's the mechanism in P3D (as it was in FSX). Is there a facility in PF3 to change its display behaviour? If PF3 is using FSUIPC offsets to make the display, rather than SimConnect directly, then you could capture the display contents in a Lua plug-in, and re-display as a plug-in controlled display, only redisplaying when a change is detected. Pete

Check that you do not have "repeat" selected in the button assignment. It is a pity that you show no log of these things. If you really want to keep it to yourself, then check it properly. Does it show that the button press/release has been detected for each control event sent (for this you need both Button/key and Event logging enabled). If so then it is the device or its connection at fault. FSUIPC cannot "invent" button press/release events. So, that proves it isn't FSUIPC but your device or its connection, assuming your method of assignment (repeat off) is the same. Pete