John Dowson

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

You can always zip/compress files that are too large to attach directely. But I don't need to see any files at the moment - you have already attached a log an ini, both of whuch show rhat your controllers are recognised and acquired. But I still am not sure what your issue is... Yes - but if another joystick/axis is recognised, you have to Rescan. If the same joystick/axis is always recognised, you have to Ignore Axis as the axis is "jittering", i.e. continually sending values. Or are you saying that you move an axis and nothing is recognised in the joystick and axis fields, i.e. they remain empty?

License sent.

sent

Great! Thanks for all your help tracking this one down! I will release a new beta tomorrow, as a full installer (including WASM + updated documentation). The additional log messages I added for this will be removed, and input parameter values will be logged correctly. Please update to this version once released. I will probably release this version officially the following week, if no other issues are reported. Cheers, John

Ok - that log shows that there is an issue with the lvar values lock/mutex: That lock us never obtained. This looks to be due to successive config updates being received before the previous one is fully processed. Hopefully this is corrected in the attached version. Any issues, can you attach the log file again - maybe two copies, one the file when you get the hang, and again after you have killed/stopped FSUIPC7. Thanks. John FSUIPC7.exe

Does it not still open? But the image you attached shows that the Y axis on device A (Bravo Throttle Quadrant) was recognised. If you want to assign to a different axis, click Rescan. If the same axis/device keeps showing, click the Ignore Axis button. You can either use the UI - move the assigned axis lever so that the assignment is shown, then click Clear. Otherwise you can just delete the lines in the FSYUPC7.ini file in an editor - make sure that either FSUIPC7 is not running, or if it is then do this with the Axis Assignment panel open and click Reload all assignments when you have saved the file.

ipc.keypressplus( (and ipc.keypress) send keys to the FS, as it says in the documentation. You cannot use those functions to test for a keypress. They also do not return any value. Use event.key - see the Lua Library documentation in how to use this function. John

Can you test with the main window open - I would like to know if the UI responds when you get this hang/freeze. You access the logging console via Log->Open Console. This shows a real-time view of the FSUIPC7.log file. I would like to know if messages are till logged after the freeze, so keep that open. Yes please - I would like to see the state of the logs when you get the freeze. I suspect there may be a lock contention issue, and certain threads (not all!) are paused waiting for a lock that is never released. Could you try with the attached version. Also activate logging for extras (Log->Extras), as this will also log thread information. I have also attached an updated WASM - save the WASM to your Community/fsuipc-lvar-module/modules/ folder, and the layout.json and manifest.json to Community/fsuipc-lvar-module/ FSUIPC7.exe FSUIPC7_WASM.wasm layout.json layout.json manifest.json

The more I look at your log files, the more confused I am... Can you explain exactly what happens please, and what you do.... The WASM log file indicates that you went back to the main menu: But there is no indication of this in your FSUIPC log file, it just loses the WASM config and is waiting for new data: [timestamp 209297 is approx 14:23:35 + 3m29s = 14:27:04, and the 1 hour difference is due to different time zones being used] Did you go back to the main menu, and if so when? Before or after FSUIPC stopped responding or was killed? It looks like it just stays like this until it is killed. Are you sure there is no response from the UI? What is the message in the FSUIPC7 main window when this happens? If you keep the logging console window open, is this still logging messages, and if not what is the last message logged? And the WASM log looks like it has been uploaded AFTER MSFS has exited. When your issue occurs again. can you attach all files before you do anything else, so I can see the contents when the issue occurred. You also have a lot of stuff running using simconnect connections: Not sure why you are running so much Fenix stuff when you are not even using that aircraft - have you considered moving this out of your Community folder if not being used, and not running any additional software for that aircraft if not being used? Easy to do with the MSFS Add-on manager. Note sure why you are using/running the WASMClient either - twice! You really don't need this - everything that does can be done in FSUIPC. And you seem to be running 'Couatl' twice... I have cleaned-up a couple of things, but nothing that could be related to your issue. I will provide you with a new version to try, including WASM, probably tomorrow now. John

I have just re-read this thread and it seems the issue has changed since the initial report. Can you confirm that the issue now is that FSUIPC7 seems to hang, and that there is no response from the UI? If you kill and restart, does it then work? Do you only get this issue when GSX is running? How frequent is this issue, both when GSX running and when not? Do you see any events (warning or error) related to this issue in the windows event viewer? I am going to run some extended tests in the debugger to see if I can catch anything with this... John

Well, that last log has thrown a spanner in the works... What was the issue - did FSUIPC hang? Could you access the UI? In all your previous logs, the last line logged has always been: However, this time this is the last line logged, out of the blue: And I can't see how that can be logged with no other log message indicating why it was closed.... This is all very strange and I am at a loss as to what could cause this.... It would be useful if I could see a SimConnect log file. Could you configure to generate one - see Also please switch back to WAPI Trace level logging, and show me the files again, including the simconnec.log (it will be quite large and will need zipping/compressing, and still may be too large to attach....). I have also noticed an issue in the WASM from your WASM log. However, this does not cause any actual problems, but I will correct this in the next release. John