John Dowson

This is due to an array access mismatch. It works if you use: wnd.font(disp_AP, 3, 10) (i.e. 3 instead of WND_COURIER, which is mapped to 2). I have corrected this in the attached version. John FSUIPC7.exe

I have also moved this post to the FSUIPC7 / MSFS sub-forum. Please use this sub-forum for all questions and issues with FSUIPC7 / MSFS2020 / MSFS2024. John

You can try FSUIPC to see if is suitable for your needs. Download and install it from https://fsuipc.com/ and then install the trial license, available from a post at the top of this forum. FSUIPC provides facilities for calibrating flaps with specific detents - see page 44 of the FSUIPC7 User guide (the FSUIPC documentation will be installed in your Documents folder), section CALIBRATING FLAPS WITH SPECIFIC DÉTENTES. i don't have the iFly, but I believe it uses the standard Flaps Set control (K event) so that should work. If not, there are other methods you can try. Also make sure that the flaps lever is not assigned in MSFS. There is a learning curve with FSUIPC, as there is with all such control software. Read the documentation and try and assigning your flaps (to the Flaps control using Send direct to FSUIPC calibration) and then calibrate on page 6 of the calibration panel as indicated in the documentation. If you have any difficulties, post again and I will try to help. John

I will take a look in a few days. I had an eye operation today and need a few days for my vision to recover... John

Yes, you can download from fsuipc.com. A trial license is also available from a post at the top of this sub-forum. John

Yes, this will be included as default in the next release, hopefully mid-October or before. As the code that caused this must be for some reason (but well before my time and difficult to deduce why), I tthink I will also add an ini parameter that, when set, will revert to previous behavior. Please also let me know about your product. I am currently working on a new FSUIPC website and support forums (as these will be closing soon). I would like to add a page, with links, to all software that uses/relies/depends on FSUIPC, but that will come post-launch. Cheers, John

This is an FSUIPC issue. Successive axis control events that are masked (i.e. can be calibrated in FSUIPC) using the same parameter are currently ignored. I am not sure why this is (probably for performance issues with some devices), but I have removed this in the attached version. So please try the attached version, 7.5.5e. John FSUIPC7.exe

I have looked into this and can confirm this issue. It looks to be an issue with MSFS, but I will investigate further and report back, and will also raise an issue with Asobo. However, there is a workaround - you can use presets instead. I have tested this in a few aircraft and it works with presets - I have only tested in MSFS2020 but should also work in MSFS2024. Define two presets in your myevents.txt file (create this file if you do not have one): Then assign to these, giving the required parameter to the Throttle Set preset. Note that I have moved your post to the FSUIPC7 / MSFS subforum. John

Those files make no sense. Both are from MSFS2020, and the FSUIPC7.log was attached when FSUIPC7 was still running. Your ini file shows that you have no assignments at all, just some strange calibration entries: You should delete those and try again. Both log files also show strange device scanning activity. What are you trying to do with FSUIPC? As I asked before, if using both MSFS2020 and MSFS2024, are you using the same FSUIPC7 installation for both, or distinct installations? Why are you calibrating in FSUIPC but not assigning? This can work in many aircraft, but not recommended for any advanced aircraft.

This happens due to a Windows virus definition update causing a false positive, and its continually happening. It happened in an update a few days ago, but another definition update the same day fixed the issue. If they don't update to fix this in a day or two, I report it and it tends to get fixed in a subsequent update a day or 2 later. I have just checked and I also now get that here - and there have been 2 updates today. You can use the attached, which isn't compressed (its the compression of the exe that seems to trigger this): FSUIPC7.exe If this isn't fixed by Microsoft in a day or two I will report (again). John

These crashes were related to the logging of the parameter type for input events. According to the documentation, this can be either Float64 or String, but, as far as I know, only Float64 types have currently been implemented/are available. I request the parameter types for all input events received, but it looks like I am only getting a response for some of these, leaving the other unitialised. It is these uninitialised ones thar are causing a memory error/exception due to a buffer overrun. I have corrected this in the attached (by setting the default parameter type to 'Unknown'). As the parameter type is also not really useful for end users (it is always a number!), I have removed the logging for this, unless you have set logging for Extras or Input Events. Please find the updated version attached. Regards, John FSUIPC7.exe

Could you please post in the FSUIPC7 sub-forum for all issues and questions regarding FSUIPC7 for MSFS2020 and MSFS2024. I have moved your post. Are you using the same FSUIPC7 installation for both MSFS2020 and MSFS2024 or separate installations? If using the same installation, I can't see how the calibration values can be different in the same profile. Your calibrated values are also very strange - why do you have such a low upper value set (3312 / 3931)? The lower value is also quite high in the second screenshot. Can you show me / attach your FSUIPC7.ini file please, and your FSUIPC7.log files from MSFS2024 and MSFS2020 (if you run one then the other, you can then attach the FSUIPC7.log and the FSUIPC7_prev.log).

The FSUIPC WASM crash is a known and ongoing issue and has been reported many times, and also seems to be more common in MSFS2024. This is related to the scanning for the new lvars which must be disabled - see the following FAQ entry: I have previously looked into this in detail and there are no memory issues in the WASM itself and I am at a loss as to what is causing this. I have also reported to Asobo but have received no response. However, I haven't checked this for quite a while now, and will look into it again at some point (when time permits). If the current crash you are reporting is not related to the scanning for lvars, I will need to see your FSUIPC_WASM.log file, with Debug level logging enabled in the WASM. For all WASM crash reports you should attach this file. Note that, as a new forum member, your attachment limit will be very low. You should compress/zip the file, but if it is too large to attach you can deliver it via one of the free file transfer websites (e.g. https://filetransfer.io/) John

I'm not sure why its using 3 hex digits instead of 6, but try this: https://borderleft.com/toolbox/hex/ John

Ah, I see the documentation says 3 hexadecimal digits (not bytes). I will check this...