John Dowson

That control will only list lvars. There is a better method in FSUIPC7 - just use the Add-ons->WASM->List Lvars and List Hvars menu options. There are also other options to allow you to test your lvars/hvars (i.e set lvars and activate hvars) before using/assigning. Hvars have no state - you can only activate them (using the Set command), not toggle. The usual way of having multiple controls assigned to a button to be used for different states of the a/c is to use offset conditions. Program your button for one of the controls (e.g. Autopilot Off), then comment out that line in your FSUIPC7.ini, and then program for the second control. Then you need to uncomment the first assignment, and add an offset condition check to each of those assignments, using the offset which holds the AP status (maybe 07BC Autopilot Master Switch, if that is what the Autopilot Off/On controls change). Adding Offset Conditions is explained in the Advanced User Guide, P22. Regards, John

I'm not sure I understand...you would read them from your lua script, where else? You seem to have answered your own question, i.e. a/c on ground with 0 speed! You could have a lua script that is auto-started (from [Auto] or [Auto.xxx] ini section). In the script, you can use event.timer to call a polling function (maybe every 500ms or so - doesn't need to run too fast). In your polling function, you can check the sim on ground flag (offset 0x0366) and the a/c ground speed (offset 0x02B4) and then, if on ground and speed is 0, read those offsets, do your calculation, and display the text. The timer can keep running until you decide that you want to remove the display, either when the ground speed increases past a certain point, or when you leave the ground (up to you). You can also kill the timer when you do this, so the lua stops running (as I presume its no longer needed once you take off). Alternatively, you could have the lua run on a button or key press, to display the information on a key or button press, and remove it on the next.

Hi John, its just that the view controls have not been available since the release of MSFS. I actually haven't checked these in a while, but I presume this is still the case. You can find the current known limitations in the provided README.txt: I don't expect you to read each and every forum post, but you should always read a file called README....! Of course, such information is also easily forgotten... And i need to see the full log as this contains information I need that is not available in a continuation log, such as the FSUIPC version being used, the current loaded aircraft, any programs that re running (including lua scripts that are auto-started), etc. Just rememeber in future to always show/attach a full logfile when you have issues or need assistance, not a continuation log. Regards, John

www.fsuipc.com will give an unsafe warning, as its http only and not https. I've not added a certificate up till now, as its not really been needed. It will be updated at some point, when I get around to re-vamping the site. For now, just ignore the warnings. John

First, you posted a continuation log. That is of no use to me - I need to see the full log. In future, please only attach full logs - don't ever start a new log file. I am going to remove this option as it is always over used/abused. How have you assigned the camera controls? It is known, and has been since the release of MSFS, that the provided camera control events do not work in MSFS. This is stated in many places. To control the cameras via FSUIPC, you have to assign to the key presses that control the camera views, that are assigned by default in MSFS. Otherwise, you will have to assign in MSFS directly. Any other issues, please let me know and show me your most recent FSUIPC7.ini and FSUIPC7.log files (not a continuation!).

That depends on what you want to do with them! Just to read/log the values first, to see if they are populated and something that you can use, try logging them first with the FSUIPC offset logging facility. If they contain the values you need, or the values that you can calculate what you need, you can then write a lua script to read the values, adjust as needed, and then display them, either using the ipc.display function or the lua wnd library

To register WideFS7, you need to re-run the FSUIPC7 installer, and enter your WideFS key in the appropriate field (labeled WideFS Key). If you have already registered your FSUIPC7 version, the other fields should be pre-populated from your current FSUIPC7.key file. Clicking the Register button will valid both keys and update your FSUIPC7.key file. Use the check-box if your email or address are different between the FSUIPC7 license and the WideFS license, otherwise ignore.

I think there is a cheaper bundled price, but as WideFS7 is still with Pete, I'm not sure if this applies to FSUIPC7, which is one of my products. I cannot see the discounts available with WideFS7. Maybe @Pete Dowson could check and confirm, and maybe add the same discount on WideFS7 for FSUIPC7 as for other FSUIPC versions, if this is possible (i.e. adding a discount from a purchase from another vendor).

You do not need an FSUIPC7 to run/use WideFS - you need a WideFS7 license, which is a distinct license to FSUIPC. You should not need an FSUIPC7 license to run any 3rd party programs (WideFS is NOT a 3rd party program!) - they generally only use the free/unregistered facilities of FSUIPC, although there may be some that require the registered facilities (e.g. Linda requires Lua which is a registered facility). You do not need an FSUIPC7 license to run WideFS7, but you do need a WideFS7 license.

This is held in offset 0x060C But that would be the total distance, no? Could that be what is in offset 0x61A0 (GPS Route Total Distance)? The current GPS ETA should also be in offset 0x619C, and the ETE in offset 0x6298 - have you tried those?

No, as the lua interface is only available in the licensed versions of FSUIPC.

Oh - and you are still using an old beta release - can you please update to the official 7.2.0 release as well please!

Is this for all your devices? You have one missing device: and one 'new' device with no assignments: Do you still have that missing device, and what is the new virtual device? Other than that, your assignments look ok. Can you activate logging for Buttons & Keys as well as Events, load a stock aircraft and try a few of your assigned buttons/switches, then closed own MSFS/FSUIPC7 and show me the FSUIPC7.log file.

I think the MSFS settings also take affect. so you can use those as well. Best to just try it. Some people have also found that extending the axis range (by editing the FSUIPC7.ini,) in combination with slopes, gives them better control. However, doing this will lose the full axis range. So, for example, if this is my elevator calibration line: Elevator=-16384,-903,600,16383 extending the range thus: Elevator=-22384,-903,600,22383 would give me more sensitivity (i.e. less deflection for the same axis movement), but you would lose the ability to deflect fully. Just something else to try....

You can reverse the axis by editing your FSUIPC7.ini file. See the section Additional parameters to scale input axis values in the Advanced User Guide (P38). To reverse the axis, add ',*-1' to the end of the axis assignment line in your FSUIPC7.ini. @Martin99 You could also try scaling your axis using this method (to get 0 at your detent) rather than using lua.

Macros are available in FSUIPC7, it is mouse macros that are not implemented. To activate a hvar, first you need to create a macro file. e.g save the following content as G1000.mcro: You will then be able to assign to those hvars in the assignments drop down menu. It does look like I missed hvars from the macro section in the Advanced User Guide. I will update.

No, not for this specific use case. There is documentation on the functions you need to use... First, assign the axis to an FSUIPC offset - you can use one of the free ones, eg A000. In your lua script (which you would have auto-started from your [Auto.xxx] profile section), use event.offset to monitor the chosen offset. Your receiving function will receive the axis value. You can then adjust this (i.e. apply your manual calibration), then sent to the sim using ipc.control.

Using ipc.control

I think thats the way the _EX1 controls work, as they are used in a/c that have a reverse thrust toggle, so the full axis range is used for forward thrust, and also revers thrust (once toggled). If you want to calibrate using the EX1 controls, you could assign to a lua script, adjust the parameter value accordingly (your calibration), then send the axis control from the lua. Alternatively, I could provide you with an FSUIPC7 version to test that allows the EX1 controls to be calibrated. However, that development branch is quite old now, so I would need to update this first.

When windows flashes a task bar icon, it means that there us something there for your attention. Not sure I understand this. There are two main (i.e. can be minimised to the task bar) windows in FSUIPC7, The FSUIPC7 main window and the log console window. When you click the tray icon you should just see the context menu. Double-clicking will open the FSUIPC main window. You can only open/close the (log) console from the Log menu. I was suggesting that you try with the log console open, and see if any messages are logged when this occurs. Could it be that FSUIPC is requesting focus for some reason? Maybe check if any ini parameters are set to do this (e.g. KeyboardFocus=Yes in [Buttons] section) and maybe try changing that.

Do this as Pete suggested. Then start P3D/FSUIPC, load an aircraft, then exit, and show me your FSUIPC6.ini, FSUIPC6.log and FSUIPC6.Joyscan.csv files.

Ok, thanks for reporting. The *_EX1 controls don't go through to calibration - they are for direct to FS assignments only. I did start looking into allowing the _EX1 controls to go to calibration instead of the standard controls, activated via an ini parameter. I think I have this working in a dev branch of the code, but the problem was that it would apply to all aircraft as it turned out to be more complicated to allow this just for specific profiles. I could take another look at this, but I don't think it would be useful for the PMDG aircraft due to priority issues - it has been known to cause issues with PMDG aircraft, although I don't know much about the DC-6... Thats also useful to know, thanks.

PMDG aircraft don't usually like the throttle axis going through FSUIPC calibration. Try assigning direct to the FS controls instead. Also maybe try the *_EX1 controls. I also noticed this on the Asobo forums, posted yesterday:

Thanks @Blake Buhlig!

What controls are logged when you move the throttle and prop levers in the UI? You could try activating logging for Axes Controls and also Events, move the throttle/prop levers in the UI to see what controls are logged, then try assigning to those. The same logging should also show you what is happening when you do this. You can attach your FSUIPC7.log (with the logging activated, and the throttle/prop moved in the UI and also from your assigned axis) and also your FSUIPC7.ini and I can take a look. However, not having this aircraft it may be better if PMDG could advise on what controls to use.