John Dowson

Which CRJ are you trying to set-up - the 550, 700, 900 or 1000? Or doesn't it matter (i.e. same issue in all)? Got hold of a copy of this aircraft now so I can take a look later and get back to you. John

The 'add-on.xml' is an installation method, where P3D loads FSUIPC due to the presence of an add-on.xml file in a specific location, under your Documents/Prepar3D v5 Add-ons folder (or v5). I recommend not to use this location as the actually FSUIPC installation folder as this can cause issues (especially if using OneDrive). It is far better to choose an installation folder, whether using the xml add-on method or the dll method, outside of a Windows protected folder (such as Documents or Program Files). This sounds that you changed to use the add-on.xml installation method, but you did not necessarily change the installation location, which always defaults to the previous installation location, so would have re-installed into your Modules folder. You MUST have seen this during the installation process and accepted this installation location without changing it. The uninstaller is there as that is where you installed it. If you select to install one copy of FSUIPC for both P3Dv4 and P3Dv5, then only one copy will be installed but an add-on.xml will be created for both v4 and v5. Your install log showsv4 and v5 uninstalled ok, and FSUIPC installed for both v4 and v5 under C:\Users\djzuu\OneDrive\Documents\Prepar3D v5 Add-ons\FSUIPC6 (which is a BAD folder to choose). Note that you CAN get into a bit of a mess if you select to install for both v4 and v5 and then later amend/update just one of the solutions. There will not be anything there - it will be in the location you chose as the installation folder, which is: C:\Users\djzuu\OneDrive\Documents\Prepar3D v5 Add-ons\FSUIPC6 So you really do not have any issues as far as I can see. You should really re-install into a different folder though. Also decide if you want to use one installation folder or two - if the latter, you must manually run the uninstaller before running the installer again (twice, once for v4 and once for v5). If you want to keep just one installation just run the installer again and select a different folder for installation this time. I suggest that you read the provided Installation and Registration guide. John

It is just using the text display features provided by P3D. It is explained in the User manual, with screenshots as examples with the macro names entered for Warning and Caution. Hmm, that is strange. You did press the eESC key to create the first macro before starting the second? You could also have given the same macro filename if you did this a second time, and the 2nd macro would have been appended to the same file. Anyway, glad you got it working. John

Then did you give the macro file a name there? If not, it won't have been created, and the file won't be created as there is no macro defined. Please be aware of the difference between a macro file and a macro. A macro file can contain multiple macros. This should be obvious from the documentation. You enter the name in the same box where it says 'Press TAB to test', which you said you did. Try creating it again and enter the name there, don't press the TAB key. P.S, Finishing now for the day. Please re-read the instructions and try again before posting again...

Ok, but you did say: "I have NOT used the calibration page." !

Please also see this in the documentation, if you are NOT seeing the message window to give your macro (not the macro file) a name:

No, that is the macro file name.... Please re-read the documentation and try again. This facility has been around for many years without any issues. If you are not giving the macro file a name AND each macro that you create in the file, you are doing something wrong.

But you must have given this BEFORE you created the macro...when you clicked the button to start making the macro, you should have seen a pop-up box where you enter the macro name, as described in the User guide. Did you not see this?

When you assign to Send directly to FSUIPC Calibration you MUST calibrate in the FSUIPC calibration page. That doesn't sound right at all - you must assign either in P3D or in FSUIPC, not both. I will see if I can get hold of the CRJ to investigate. John

Is that the macro file name or the macro name? Remember, a macro file can have many macros. You do not need to search your computer, just look in your FSUIPC5 installation folder (i.e. under a folder called Modules, under your P3Dv4 installation folder - here : C:\Lockheed Martin\Prepar3D v4\Modules\). Did you end the macro creation process, by clicking the End Macro Making button? The macro file is created once you do this - as explained in the User Guide: John

FYI, FSUIPC4 v4.977 has now been released.

For the stable A320neo, the MobiFlight hubhop preset list has this calculator code and comment for the A32NX THROTTLE FULL REVERSE BUTTON preset: (A:GENERAL ENG THROTTLE LEVER POSITION:1,percent) -0.1 < if{ -9830 } els{ -16383 } (>K:THROTTLE_SET) Intended for a button press. It will toggle throttle between full reverse and idle. If throttle lever is anywhere idle or above button press will activate full reverse. Pressing again will cancel reverse and go to idle. This doesn't seem to be available in the dev version. If using that, maybe ask about this on the MobiFlight discord channel. John

@light_blue_yonder Are you still having issues setting up your throttle in your add-on aircraft or is this now resolved? Did you check the thrust lever set-up document mentioned by Reingard? John

Ok, I now understand what is happening. It is actually a very old bug where an array is updated out-of-bounds, and the problem with vPilot/Squawkbox has only just showed itself due to the memory re-alignment in the new build. I have corrected this now in the attached build, which i will release officially in the next few days: FSUIPC4.dll Thanks for your assistance in tracking this down. Regards, John

It is fixed, but I won't be releasing yet as I want to understand why it broke, and if this could cause any further issues. I will let you know once I have done this. John

You didn't say you had tried anything, just that you didn't understand anything... Just look at the logging tab in FSUIPC. Check the box next to Events (non-axis controls). That will log your events. If you check Send to console window, that will open the (logging) console window. Please consult the provided FSUIPC User manual, at least initially, not google. Yes of course, what else would I be referring to? This is support for FSUIPC after all.... Skip the lvars if you are not familiar with them (although there is plenty of provided documentation on how to use these). Mouse macros are also explained in the FSUIPC documentation. John

I cannot see any spoiler assignment: ? And what is the Custom control? Did it go directly from the high number to 0? If so, sounds like the axis is registered as a digital / on/off axis. If this is the case, see: Also, try calibrating the axes you are using for flaps/spoilers first in the windows calibration panel. to see what range of values you get there. John

Ok, but this was only suggested as a temporary work-around. I will fix this, but now I know what is causing it I am trying to determine why this changed between the two builds... John

But why are you doing this? If you want to assign a key press to a button, just use the left-hand side of the Buttons + Switches assignment UI panel. Just do that and then take a look at how the assignment line looks in your FSUIPC5.ini file afterwards. You shouldn't do that either - these comments/annotations are automatically generated. No. You need a number - use 0 if assigning to a modifier on its own, and you need to add 8 to the shifts, so should be: 16=P7,13,K0,12 You need to do this one by editing your ini, as you need to give a non-modifier key when assigning in the UI. Maybe the ENTER key is assigned somewhere to the full throttle control? Try activating logging for Buttons and Key operations, as well as Events (non-axis controls) and see what is logged when you press the assigned button. If you require any further assistance, please also attach your FSUIPC5.ini file the next time so I can see your actual assignments. And, if you are manually editing your FSUIPC5.ini file, make sure that you reload the changes in the UI if FSUIPC is running. John

Ok, thanks. But that is the FSUIPC7 installer being quarantined. The OPs issue seems to be with FSUIPC7.exe, not the Install_FSUIPC7.exe. John

It is not difficult - just go to the logging tab and select the appropriate options. I'm sorry, but I cannot help you any further if you are not even willing to try even very simple recommendations.... John

Ok, thanks for the report. Let me know if/when you hear back from them. John

Hmm, even stranger... I had left FSX and vPilot running while I typed that last comment, where the Mode C issue was present, and just tried again and it now seems to be working as expected...! I can even update that offset (or use the Add-ons -> Squawk Mode C option)and can see the Mode C being activated/deactivated in vPilot. It looks like its the 255 value in offset 7B91 is causing the issue. Once that is reset to 1 (or 0), the Mode C button works as expected. I'll see where that value is coming from (and what has changed since the previous build...) and see if I can correct. In the mean-time, if you are using a registered version of FSUIPC4 try setting the value in that offset to 0 (via a key press or button assignment to Offset Byte Set) to see if vPilot can squawk Mode C once it has been reset. John

Just tried to reproduce this issue. While doing this, I am monitoring offset 7B91 (as UB), which is where the squawkbox data at offset 17 is stored in the FSUIPC offsets. In one test, the Mode C was actually working, and I could see this value changing from 1 to 0 and back again when I click the Mode C button in vPilot, so it seemed to be working as expected. However, on subsequent tests, pressing the Mode C button had no affect - no CDA data update received via the CDA and no change in offset 7B91. Writing to this offset manually also produced no change in vPilot, so it seems to me like the data exchange via the Squawbox CDA is not working correctly. You say that you can see this change but changes back again to 255. Is that via the vPilot CDA logging? Can you try logging the value at offset 7B91 in FSUIPC to see if the CDA change is reaching FSUIPC4 - it looks like it isn't reliably getting through, which is the issue, but I'm not sure the cause of this at the moment. Its very strange that this worked for me the first time and has failed subsequently. I will keep investigating. John

Please see this thread: https://forums.flightsimulator.com/t/using-link2fs-with-fs2020-to-connect-arduino-panels/337926/13 From that thread, it looks like Link2FS was updated for MSFS but has issues. Maybe contact the developer to see if these issues are being addressed... Well, if thats what Link2FS does it seems that its that application that you need, or an alternative that works for MSFS. I'm sorry, but nor knowing or using that application I cannot advise. Maybe ask on cockpitbuilders.com to see if there is an alternative, if Link2FS cannot be configured to function correctly with MSFS. John