John Dowson

No, no chance. There are no facilities provided by Asobo/MSFS to implement this feature, and theere is no planto do so. Things have moved on..... There are several other options available that replace the need for these: hvars, input events, and presets/calculator code. But there are also so many new ways to control/assign. Have you looked at the presets available? See https://hubhop.mobiflight.com/presets/ - these are all available from FSUIPC by selecting assignment to presets. Hvars (html variables0 are also available, but these are difficult to discover and best best used via presets. Input Events are the latest innovation. Currently these are only available in the latest beta release of FSUIPC7, which I will release before the end of the year. You can try these in the latest beta, available from John

All license details for products purchased from SimMarket can be found in your SimMarket account. Look at your Purchase History and click the relevant Order No.

Ok, I will look into this next week. Is that mapping I proposed ok? I will also map the following helicopter throttle controls: AXIS_HELICOPTER_THROTTLE_SET -> Throttle HELICOPTER_THROTTLE_SET -> Throttle AXIS_HELICOPTER_THROTTLE1_SET -> Throttle1 HELICOPTER_THROTTLE1_SET -> Throttle1 AXIS_HELICOPTER_THROTTLE2_SET -> Throttle2 HELICOPTER_THROTTLE2_SET -> Throttle2 There is also AXIS_TAIL_ROTOR_SET, but I am not sure about this one.... If you could update to the latest beta at some point (currently 7.4.0b), I will post an updated beta here for you to try this when done. The latest beta is available from John

License sent. John

I understand your issue, but there is no way I could possibly allow calibration for any axis. Calibration is only useful for the main flight control axis, and I fully understand that this is currently not possible for the new axes for helicopter flight control. The only possibilities at the moment are to use the axis scaling functionality, as you are doing, or to write the axis value to an FSUIPC offset and have a lua script pick-up the value and apply any calibration needed before sending to the FS. I am not prepared to add further calibration pages for helicopter axes at the moment - I just don't have the time for such a large undertaking. What I could do is to map the helicopter-specific axis to the existing calibration sections (i.e. aileron, elevator, rudder, throttle, mixture, prop pitch). As I am not familiar with helicopter flight controls, does this seem reasonable, and if so what would the mapping look like? e.g. AXIS_CYCLIC_LATERAL_S -> calibrate as aileron AXIS_CYCLIC_LONGITUDINAL_SET -> calibrate as elevator AXIS_COLLECTIVE_SET -> calibrate as prop-pitch ?

Are you sure that you are using the latest beta release, 7.4.0b? Please check this as your browser may have cached the download file. If that is not the issue, please show me your .log and .ini files... John

So it was there...why couldn't you find it earlier? That log file ends after less than a second (94 milliseconds) and shows nothing. FSUIPC7 was also still running. Unless something is stopping it. Check your anti-virus. But I don't think it is going to reveal anything anyway. You are using an unregistered version. There is no way your pauses/freezes have anything to do with FSUIPC7. I have now finished for the day. John

I am not interested in seeing images... Run FSUIPC7 and open the logging console (Log->Open Console). Do you see messages logged? Then use File->Open Installation Folder. That will open a windows Explorer window on the folder being used. Is the log file there? If there is no FSUIPC7.log and FSUIPC7.ini files in the folder, then something is wrong. Check any anti-virus software that may be blocking this.

Yes You can do this via lua, but if its on-start, why have a continually running lua? For on-start, you can also use the InitialButton ini parameter (see Advanced User guide), This can trigger one-off actions already assigned to buttons. Alternatively, consider individual lua functions - one to insure the ignition is on, one to open the fuel valve, etc. Or combine as needed, These don't need to be continually running - they can exit once their function is complete. From the lua you attached, you seem to want to handle all your assignments via lua and event.button. You can do this (this is what LINDA does), but it can get really complicated and is not necessary. Assign your buttons/switches as normal, via the button assignments, and just use lua for more complex things.

If you have ran FSUIPC7 at least one after installation/re-installation, there must be a .log and .ini file there, unless you have very stringent anti-virus protection. Open a command prompt, change to your FSUIPC7 installation folder: cd C:\FSUIPC7 List the files: dir and show me/paste (i.e. cut and copy, not just write whatever you see) the output. This is obviously incorrect, due to typos, if nothing else...

Now released...a bit early....!

Just released...

Impossible - there MUST be an FSUIPC7.log file. If that wasn't created, there is something seriously wrong... Its not hidden. As I said, uncheck 'hide extensions for known file types'. John

As I said, check the available presets for the aircraft you are using: https://hubhop.mobiflight.com/presets/ That should give you an indication of what to use to control things. Also try Input Events, using the latest beta. Also see the following to determine what to use for an assignment: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ And the MobiFlight discord server, MSFS 2020 channel, is the place to discuss and ask questions about how to define a preset for a function/aircraft that is not yet available on the HubHob server, I just provide the mechanism for these to be used. John

Name, e.g. John

And I have showed you this twice now. For the third time, and to be clear - from your FSUIPC7.ini: This will start the lua script when you press button 143 on joystick C, your Alpha yoke. This will start the lua script when pressing button 144. etc etc. You have such assignments for EVERY button. Can you not see this? What do you think those assignments actually do, if not starting the lua script? From the Lua plugins document: So, each of your button assignments is starting the lua script, and as it is already running, it will be killed first. Only if you assign it as such, which you seem to have done for all your alpha buttons (and similarly for your Bravo). You do this if you want the lua ro be auto-started. Many luas run on a button press. It is up to YOU to decide how to start the lua. However, almost all luas that use the event library, and just run waiting for an event to happen, should be started in the [Auto] section. Or, better, in the profile-specific [Auto.xxx] section, if they are specific to certain aircraft only. Yes, if the lua is running. No!. Don't EDIT this section, apart from LuaPath. All numbered entries are managed by FSUIPC7. Do not add or delete from this section. No! If you have an assignment to a button or key press, then it will be added to this section. You just DO NOT need to assign your buttons/keys to start a lua that is already running. Read the user guide on button and key assignments. If you are a beginner, a I do not understand why you are starting with lua, and not just assigning your buttons/keys to the standard controls/events or presets (also Input Events will be available for assignment in the next release, currently available as a beta - see Announcements sub-forum). It is a lot easier then using lua, and you can do most things via the UI. John

The next beta release, 7.4.0b, which will be released tomorrow, will allow for an additional parameter for [Programs] section entries: CONNECTED. This will delay the start of programs until FSUIPC is connected to MSFS (via SimConnect) and has received the initial data to populate the offsets. John

This will be available in the next beta release, 7.4.0b, available tomorrow. The new parameter is DontLogTheseIE. John

It does NOT start by itself. Something must be starting it. I cannot help you with this - it is your PC. There are two other applications started fromyour EXE.xml: C:\Program Files (x86)\Addon Manager\couatl64\couatl64_MSFS.exe C:\Program Files (x86)\FSRealistic\FSRealistic.exe Maybe one of them is starting FSUIPC? Try disabling each in turn to find out - just temporarily rename each exe and see if the 2nd instance is started or not. If not, then you have found the culprit. Not sure why you attached that. I said I could take a look at your FSUIPC7.log file, to see if there was anything in that that related to your pause/freeze issue, but I doubt it. You probably get some data-stalled issues logged, but this is expected if the sim is freezing. John

Well, it does matter - in fact it is vitally important! Different aircraft use different controls. What works in one A320 version will not necessarily work in another. I don't have the Fenix - and you said: So I assumed Asobo. If using the Fenix, it is up to you to determine what works. Strange that I see the same as you using LIGHT_POTENTIOMETER_15_SET but in a different aircraft. You should be able to, but you have to work out what to use. Have you checked the presets available for the Fenix A320 on HubHop? If available, they should give you a clue, or you can use them directly. You should be able to, as I said, But I cannot help you much as I do not have this aircraft. Use the tools available - presets and logging. Also check if any Input Events available. Assignments are only available in the paid version. You can do this in the free/unregistered version, but you would have to write a program and do this via the FSUIPC offsets. The free/unregistered version is mainly used to support FSUIPC third-party apps.

You assign a button/key to start the lua if that is what you want to do. You would normally do this for a lua script that ran to do something and then exited, or for testing purposes. Lua scripts that wait for events are started and left running. Such scripts are usually automatically started, but you can start such a script on a button press, but every time you press the button the lua will be started, and if already running that will be killed first. Your lua script is used for assignments, so it should be auto-ran. You do not need to start auto-ran scripts on a button. No, but used with care. You can assign to a button if you have a need to re-start a running (auto) lua script. You have the lua script started on (almost) every button press, as I showed you in my last post: See that every button assignment on your Alpha is starting the Alpha_Buttons.lua script. That is just crazy! No! You want the lua auto-started. You should remove/delete all those button assignments that start the lua script, as you dont need these as the lua is already running nd waiting for button press events from your Alpha. Step 3: You do not need this. You only need to do this if you want to start a lua on a button press, as i have said many times now. Your lua is already running, via the [Auto] section. Also, step 5: You should NEVER manually modify the [LuaFiles] section (unless you REALLY understand what you are doing!). This section is maintained by FSUIPC7 by scanning your folders. But why are you doing all this in lua anyway? Why not just assign directly in FSUIPC?

That looks fine, with just the one entry that is starting FSUIPC7. If two copies are being started, then something else is starting it. Are you sure that you hadn't manually started FSUIPC before starting MSFS, or that it wasn't already running for some reason? The FSUIPC7.log file is in your FSUIPC7 installation folder (C:\FSUIPC7\), together with your FSUIPC7.ini file (your settings). If you cannot see it, you have windows Explorer set to hide extensions of known file types. Change this in the Explorer View Options.

I don't know what happened before, but I tried this again and see similar results to you... I get a full white screen using this control. I don't know why you are using this, it just doesn't work! I tried this and this doesn't work either. For some reason, the parameters are not being used correctly. You need to use the provided Input Events to control the lights. I have tested a few of these (pedestal, called LIGHTING_PEDESTRAL_1 for some reason, panel 1-4 and glareshield 1-3) and they seem to work as expected. They all need a parameter between 0 (off) and 100 (full on). John P.S. Why are you using the Asobo A320 and not the FBW version? The FBW version is a lot more complete...I would forget the Asobo one and just use the FBW. There are many presets for lights also available for the FBW version.

Checking further, the panel brightness in the Asobo A320 uses the Lights Potentiometer Set control with 2 parameters, the first being 15 and the second being a value between 0 and 100 for the actual brightness: N,B. Logging of multiple parameters is only available in the latest beta. You can only assign to an event that takes multiple parameters by using a preset. If you want to try this, I can define such a preset for you.

I have just tried the LIGHT_POTENTIOMETER_15_SET control here in the Asobo A320 and it doesn't have any effect whatsoever - it isn't even logged, which means it is not doing anything in the sim. I don't understand why you see what you do... Looking at the lights in the Asobo A320, the following Input Events are available: Input Events are relatively new and are available for assignment in the latest FSUIPC7 beta, available from Maybe try assigning to the input event for the lights you want to control? You need to determine the range the input event expects. You can do this by logging Input Events, and adjust the lighting you want to assign from min to max in the virtual cockpit. This will then log the input event with the parameter, and you can determine the range needed. You cannot assign an axis to an input event directly. You have two choices: 1. Assign to the input event on axis ranges, using the right-hand side of the axis assignment dialog. This can give you up to 10 discrete positions, which you can assign to set discrete values. 2. If you want the full axis range, assign your pot axis to write its value to a (free) FSUIPC offset. You would then need a lua script that monitors for changes to this offset using event.offset. The handling function would calibrate the value received to the Input Event range, then send to the Input Event using ipc.execInputEvent. I can help with such a script, which should be auto-ran, if you want to do this. John