John Dowson

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

Can you please also attach your FSUIPC7.ini file. Also try adding an event.terrminate function where you should close the com ports, and also log a message indicating that the lua is terminating. Please make this change and resend the files once done and if the problem persists. Why was the first lua killed and restarted at timestamp 3507594?

Please read the provided documentation - Invalid Key Problems in the Installation and Registration guide, 99.9% of these problems are due to not having the correct VC__ redistributables installed, and 100% of these reported problems are due to not reading the provided documentation... As for not receiving am email, please see John

It may be better, and easier, to use FSUIPC's offset logging facilities. Log offset 0x3110 as U32, and offset 0x3114 as S32. This should show you the control numbers and parameters that are written to the offsets. If you also activate logging for Events (non-axis controls), you should also see the controls/events that are sent. John

Please update to the latest version, 6.2.0 - only the latest version is supported. Why don't you try logging the value you are sending to offset 0x3110? I am not that familiar with python, but it looks like you are sending the offset address as a parameter, whereas it should be the parameter to the control. But as I cannot tell what is being sent with that code fragment, it is hard to advise. Try logging the value that you are sending - best to to log as two 32-bit integers separately, so that you can see both the control numbers and parameters. i.e. log 'int(value)' and 'base + OFFSET_IAS' for the first statement. and 'sendval' and 'base + OFFSET_MACH' for the second. You can also log the combined value. John

@ZK-1BWhy did you post your key details? Sharing or posting key details in a public forum invalidates your license, as anyone can then copy these and use them. Isn't this obvious? This is why I asked for your ORDER NUMBER. With that, I can look up your key details. You don't seem to have read my previous comment at all...Did you read the documentation as advised? Did you update your VC++ redistributables? That WILL be your issue...

First, for any questions on FSUIPC7 / MSFS, please use the specific sub-forum for FSUIPC7 / MSFS. FSUIPC7 is being continually updated to keep up with the latest developments in MSFS. For example, there is currently a beta version available (see Announcements sub-form) that provides access to Input Events (via SimConnect). FSUIPC is not a replacement for SimConnect, and it does not provide wrapper functionality around all SimConnect functions. FSUIPC never has, and never will, inject AI traffic or provide facilities for this. There are several other freeware utilities that do this, AIG being the main one these days. Previous versions of FSUIPC (for P3D and FSX) did have facilities for limiting AI traffic (the Traffic Limiter), but this is no longer possible with MSFS and has been removed. There are no plans to re-introduce this as it is just not possible to control AI traffic by an application that has not injected that traffic. FSUIPC does provide AI traffic information via its offsets, but that is about it as far as AI traffic is concerned. Weather is another area that is no longer possible to control, and even getting weather information is generally not possible, as the old simconnect interface to weather has been deprecated in MSFS. But again, this is another area best served by other tools, although weather control is still very limited in MSFS. There is nothing currently planned to enhance the FSUIPC SDK, if that is what you mean. I have received a request to see if I can provide access to the facilities API via offsets - see But I have no idea when I will have time to look into this. I am spending most of my time on support issues, and development of new functionality is generally for registered facilities, and to keep up with the latest MSFS SDK updates (as well as P3D beta releases). I really don't have time for much else at the moment - and not sure if I ever will! John