John Dowson

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

What values - in or out? That is a very small range, and also doesn't match the values shown in your previous log. But if those are the values FSUIPC is showing, tttthose are the values that FSUIPC is receiving from windows. Did you try calibrating your pot in windows game controllers, as advised? FSUIPC logs all events seen, not just those sent from FSUIPC. In fact, controls sent are never logged, only those that are applied. It is possible to send an event that isn't appplied/used in the loaded aircraft, and this will not be logged. And many aircraft in MSFS contiually emit certain events, and these events vary from aircraft to aircraft. You can ignore such events using the DontLogThese ini parameter. Not sure what this means... It does work together with the sim, and it only changes it if you instruct it to do so. No it doesn't. As I said, that is just an event that is occurring and that FSUIPC is logging. It does not originate in FSUIPC. FSUIPC will log every event it sees, not just those that are sent. No idea what this means... Of course it is helpful to log all events, this is thee whole point of event logging. The log you attached shows the LIGHT_POTENTIOMETER_15_SET event/control with values going from 16119 to -16184 and back again: So that shows your pot axis is working as expected....so I am confused about your issue. I will take a look at that control in the Asobo A320 here, when time permits, to see what effect it has. John

What error? I see no error in the log you attached. Note that the comment characters are '--' and not '-'. i.e. a double-dash. Is that your issue? The error message should indicate what the issue is.... Your lua script is auto-started, However, it looks like yo have also assigned EVERY button yo start the lua script: As the lua script is running, when you press a button that is assigned to start the lua script, the currently running script is killed and then restarted, hence the error messages. As your lua script is auto-started and waiting for your alpha button events, you don't need any assignments in FSUIPC7. just remove all of those. As it says in the lua plugins document: John

You should not delete FSUIPC7. If you want to remove it, run the uninstaller or uninstall via the windows app management panel. And if you are updating FSUIPC, just download and run the installer, no need to uninstall. If two copies of FSYUPC7 are running, check your EXE.xml file - you can get the location from your InstallFSYUPC7.log file. If there are two entries for FSUIPC7, remove one, However, this shouldn't be possible as the installer for FSUIPC7 should only add an entry if non exists, so if there are two then something has gone wrong. Please show me/attach your EXE.xml before you edit it. As for your pauses, I doubt very much that these have anything to do with FSUIPC7. If you are using auto-save with a complex add-on (e.g. PMDG 737) then this can cause substantial pauses, but there are also remedies for this (see the FAQ entry Problems with Autosave on Windows 10/11 : The Answers!). You can also attach your FSUIPC7.log file and I can see if there are any issues reported there. John

There are also the following presets available: They use the custom controls via the ROTOR_BRAKE method - see

Not easy to read your comment...please don't use a black background. If you are pasting, paste as plain text... For the horn cut-out, use the following custom control: and for the speed intervention, maybe this one: To use custom controls, please see the following FAQ entry: John

You cannot calibrate a LIGHT_POTENTIOMETER_* axis, and this shouldn't be necessary. You only need to calibrate the main flight control axis. Have you calibrated this axis in windows game controllers? That is where it may need to be calibrated. Probably. But you can check via logging - keep the logging console open (Log->Open Console) and you can see the values sent in real time. What In/Out values do you see in FSUIPC's axis assignment panel when you move the axis? What do you see as the minimum and maximum values for both in/out? You can do. Your limit is low as you are a new user - it will increase as you post more. What program? Do you mean FSUIPC? The log you attached shows very erratic values...

Not in the log file you attached, which also ended after 97 seconds and was attached while FSUIPC was still running. I cannot tell anything from that! Anyway, glad its now sorted.

Please do not use the New Log function when sending logs to support - i need to see the full log file. If its too large, it can be zipped/compressed. This menu item will be disabled (by default) in the next release for this reason... If you look at the log file you attached, you can see that the parameters to the LIGHT_POTENTIOMETER_15_SET control, which will be the values your pot is sending, after calibration, jump all over the place: Not sure why this is, but it certainly doesn't look correct... what values do you see when you move the pot slowly through its full range and back again? You should see the values increase and then decrease (or vica versa). If its not sending such values, there is an issue somewhere. What are you trying to control with this?

It is just confusing for me when you keep talking about offsets as opposed to events. Offsets are FSUIPC-specific and are just memory addresses that you can read and write to. Controls/events are the commands that you send to the FS, which are defined either by the FS (standard controls), the aircraft (custom controls) or FSUIPC (FSSUIPC added controls). Yes, logging events can show many events that you are not interested in, and many add-on aircraft can continually emit some events which are just noise. You can ignore these by using the DontLogThese ini parameter. Yes, that is what I thought. Please update this thread if/when you get a response or understand why the controls are not having the desired effect. Cheers, John

Try logging offset 0x66C0 - this is an offset designated as 'free for general use', so you must have something else writing to that offset. Also activate logging for buttons & keys, and this will show you what is happening when you trigger those key assignments. Also the limits set in those assignments don't look correct. What values is that offset holding? A lower limit of 1 when decrementing looks ok, but not when incrementing you need to set the upper limit. And you are incrementing and decrementing by 9, which also seems strange... John

If you want me to check that you have assigned correctly, please show me your FSUIPC7.ini and FSUIPC7.log files, the latter with appropriate logging activated. This can either be due to an incorrect assignment, or the axis could have been flagged as a digital on/off axis in the windows registry, but I need to see your assignments and log to determine what the issue is. If the axis is flagged as a digital on/off axis, there is a post in the FAQ section on how to remedy this. John

All PMDG-specific offsets are read-only. I know how offset 0x3110 works - it is a facility for sending any control/event to the FS. You do NOT specify the offset, you specify the custom control number together with the parameter to the control/event. You are NOT writing an offset address, you are writing a custom control number. I don't understand why you keep trying to explain this - I understand what you are trying to do, it is just that your terminology is misleading. Do not confuse offsets with controls/events. Offsets are only logged when the value is changed, Writing the same value that the offset already holds will trigger the event, but it will not be logged as an offset value change as the value has not changed. This is why I also advised activating logging for Events, as you would then also see the event/control being sent together with the parameter. If FSUIPC is sending the correct control/event with the correct parameter, and this is not working in the aircraft, then this is a question for PMDG. I am not familiar with this aircraft (and I do not have this aircraft) and therefore cannot advise. The PMDG header file does say 'Sets MCP MACH (if active) to parameter*0.01' - so is MCP mach active? have you tried using control/event EVT_MCP_IAS_SET (84134) instead? As I said, I am not familiar with this aircraft and do not know how these MCP control work, but if FSUIPC is behaving as expected, you need to ask about this on the PMDG support forums. John

License sent.

I know that and think you are misunderstanding me. I meant that it seems that the parameters to whatever controls you are sending are offset addresses ('base + OFFSET_MACH'?), which doesn't make sense, but I need to see the logging to know what controls/parameters you are writing/sending. As I said, it is difficult to know what values you are sending with code extracts. Please show me a log (or log extract) with those offsets monitored (0x3110 and 0x3114) as well as offset 0x6540 (as FLT32). Then those should set the MACH value to 0.600 and 0.800 respectively. If the correct control/value is being sent and the value in offset 0x6540 doesn't match this, then that would be a question for PMDG. Well, .780 is .78.... but if you need to specify to 3 d.p. then this doesn't seem possible (as the parameter to the control is an integer and is the mach value * 100), so yes you would need to ask PMDG about this. John

License sent. Not sure what device you are using, but if its the streamdeck, maybe try this user contribution.: John

Compress/zip them if too large. When you attach them, can you please explain what the issue is, and also remember to check any/all assignments in P3D (or disable controllers). If an axis goes from 0 to full, then this is usually because it has been registered as a digital on/off axis. See the following FAQ entry on how to resolve this (written for saitek devices but applies generally - just use the correct VID/PID numbers for your device):

This will be the cause. Only luas that are auto-started are stopped/killed when you go back to the main menu. You are responsible for stopping/killing any lua scripts that you manually started. As the auto started script was killed and manually re-started, it will not be automatically killed. John

Usually anti-virus software can prevent the installer running, or FSUIPC7 running correctly, but I did not know that it could prevent license validation. Not sure how/why it does this, but I will add a not to the registration guide about this. John