John Dowson

@DrDave- I am not sure I understand the point of your post, or why you are attaching a pdf (of a log file I presume). Do you actually have an issue that has not already been clarified in this post? But there is - have you not even read this topic? My first comment on this issue: Is that not clear?

As I said, you don't need to keep the logging window open, just keep the event logging active, and maybe also activate logging for Buttons & Keys. Then when you get your issue, immediately (i.e. before trying to recover from it or doing anything else) go into FSUIPC's logging tab and click the New Log button to start a new log file. Then find your FSUIPC6.1.log file and rename and save that somewhere. Once you have 3 or 4 of these log files, you can examine them to see if you can see any similar events occurring just before you get the issue. You can also post/attach the log files here and I can take a look.

Your ini is pretty empty and doesn't contain much - your settings will be in your Jet.ini file in your Profiles folder. All it tells me is that you are using an old and unsupported version of FSUIPC6 (6.1.9) and should update to the latest and only supported version (6.2.0). You can clean your profile section, to catch more variants, by changing this: to this: You should keep the event logging enabled for the time being (no need to keep the console window open), and when you experience this issue you can start a new log (from FSUIPC's logging tab) and then save the log containing the events that lead up to your issue. Once this has happened 2 or 3 rimes, you can then compare the logs to see if any of the logged events could cause this issue. This may be easier in the QW or Captain Sim, as with the PMDG you would also have to decode any custom and Rotor Brake controls to understand what is happening.

Where are the fire unlock switches located? I can't seem to get handle unlocked with the custom controls. The initial value in offset 0x6C44 is 0. This is In according to the documentation, which seems correct. If I send a custom control of 70329, which is EVT_FIRE_HANDLE_ENGINE_1_TOP, with a parameter of x20000000 (left mouse click), then the handle does move slightly, and the value in offset 0x6C44 goes briefly to 1 (blocked) then back to 0, which seems correct as it is still locked I guess. So try using the mouse parameters to the _top/_bottom controls, not the values. If I can unlock the handle, I can test further. John

Here you go. I have also attached 7.3.21 - rename to remove that from the filename before using. John FSUIPC7.exe FSUIPC7.exe.7.321

First you posted in the FAQ sub-forum, where it explicitly states NOT for support requests. Please take care to post in the correct form if you require help. Not exactly sure what you mean. The axis and button assignments work in slightly different ways. Once you have created a profile for axes, the profile specific checkbox should be checked and disabled. For button (and key) assignments, the profile specific checkbox will only be automatically checked when you press a button and that button is already in a profile. I see you have installed under C : \Program Files (×86)\FSUIPC6\FSUIPC6\FUIPC6.dll. This is a bad location due to windows restrictions on this folder which can prevent the settings being saved. Re-install into a non-windows protected folder, such as c::\FSUIPC6 or C:\P3D Add-ons\FSUIPC6.. That is the add-on.xml file, and is in a folder prescribed by P3D so that it can located FSUIPC6 and start it. Your installation folder is currently 😄 \Program Files (×86)\FSUIPC6\FSUIPC6.

That is the line number of the lua script that prompts the message. To see how the debug output is generated, take a look at the ipcDebug.lua script in the provided examples. There are just the dev tools (available when in devmode) provided by Asobo, which I use but very rarely. I rely in the MSF SDK. The dev tools can be useful to determine the code that a UI element (such as a switch or button) uses so that you can replicate the action via a controller, but this would be the last method to try. I do help out with this sort if thing, but its really out-of-scope of what FSUIPC provides. John

You have to register your WideFS license when installing FSUIPC6. Download the latest version (which is 6.2, so you need to update anyway) and install that, and register your WideFS license at the end of the installation process. You do not, and should not, uninstall first. John P.S. Pete retired several years ago now!

Sent

Ok - thanks for the explanation. The Rotor Brake method is just another way to use custom controls, just more limited - you can only send mouse operations and not actual values. If you take a look un the FAQ section, both methods are described, but the Rotor Brake one is deprecated in favor of the custom control method. With the switch unlocked, have you tried sending a parameter of 3 to using either one, or maybe both, of the EVT_FIRE_HANDLE_ENGINE_1_TOP & EVT_FIRE_HANDLE_ENGINE_1_BOTTOM custom controls? And then once out, you can use the same control and send a parameter of 3 or 4 to turn the handle. You just need to play around to see what works. I can take a further look tomorrow. John

License sent.

Please do not attach images - just attach your FSUIPC7.ini file so that I can see your assignments. However, if calibrating in FSUIPC, it is (usually) better to assign using 'Send direct to FSUIPC calibration' and not 'Send to FS as normal axis'. But this is nothing to do with your issue. If you are flying a prop aircraft, then this is normal behavior due to the propeller torque effect and p-factor - see https://forum.flyawaysimulation.com/forum/topic/25992/how-come-my-plane-turns-to-left/. You would normally adjust the trim to compensate for this. If there is a button that is triggered in this off position (which hopefully is the case - you can check in the FSUIPC button assignments window), then reverse thrust is normally achieved by assigning this button press to Throttle Decr on repeat, and to Throttle Cut on release (to stop reverse thrust). John

This is very strange, especially as FSUIPC has nothing to do whatsoever with the visuals. Have you tried with various aircraft? Did you get the dialog to activate FSUIPC for P3D after it was installed? What happens if you disable FSUIPC? i.e. when you start P3D, click the Options button, and then disable in the Add-ons section before you continue. Do you get the same issue? I suspect so, as FSUIPC will already have been loaded. So now exit P3D and restart it, and FSUIPC will be disabled. Do you then get the same issue? What ither add-ons do you have installed? Can you show me/attach your add-ons.cfg file, which will be under [USER]: AppData\Roaming\Lockheed Martin\Prepar3D v5\ John

Do you have an actual issue? If things are working as expected, then there is no point in me looking at your file. If you have an issue, then explain what that issue is and then I may take a look at your files, id needed. This support request has already gone on quite a long time already, especially as this script for rotaries has been around a long time, is included with each version of FSUIPC, and there are already numerous support requests on using this script. That depends on which control you are using, as there are several got the heading bug. For example, the heading bug inc/dec controls take no parameter, but the set control does (hopefully that is obvious). John

What do you mean by 'Lua Log Entries'? You can see the lua documentation provided in your documents folder: FSUIPC Lua Plug-Ins FSUIPC Lua Library LuaFileSystem Lua Plugins for VRInsight Devices Lua License Example are also provided in the Example LUA plugins.zip file and are described in the Lua Plug-Ins document. For any other lua documentation you require, see the official lua documentation: https://www.lua.org/docs.html No. For simvars (A-type variables) and controls (actually called events in MSFS and also accessible as k-type variables), see the MSFS SDK Documentation: https://docs.flightsimulator.com/html/Programming_Tools/SimVars/Simulation_Variables.htm For other variable types (l:vars, h:vars, b:vars, etc), you can use the Dev tools provided by MSFS to inspect the code of the current aircraft. For example, see the following article on how to use these dev tools to discover input events: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ John

Ok, thanks for the update. If you deleted the FSUIPC6.ini file, did you redo your settings/profiles/etc? This seems such a drastic action to take, and I would never recommend this to fix in an issue (if this did indeed fix the issue, of which I am doubtful). Temporarily rename or moving it out of the installation folder for a test is ok though.

Ah, ok. That would make a difference (such as de-activating the logging you had set), but I would be very surprised if anything in the ini could cause this issue. And if anything in the file had changed, then you must have done this via changing the settings in the UI (or editing directly). Doing this would also delete all your assignments, if you are using a registered version of FSUIPC6. The Rotor Brake control/event is one way to use the custom controls provided by the PMDG SDK. To understand how these work, see the following page: The parameter 97903 indicates a mouse-move event (03) on the following control: So that event just looks like the mouse moving across the HUD, which is nothing to worry about, and is emitted by the aircraft.

Olvidé decirle que necesitas reiniciar FSUIPC7 después de que se hayas habilitado el WAPI, ya que los presets solo se cargan cuando se inicia FSUIPC7. De todos modos, me alegro de que ya esté funcionando. Un saludo, John

Add-ons -> WASM -> Enable Esto generalmente está habilitado de forma predeterminada... No sé por qué está deshabilitado...

This cannot possibly have any effect whatsoever. It is just a log file, and is cleared/newly generated each time FSUIPC/P3D is ran. That is a huge log file and I am certainly not going to go through that in detail, especially as you are using many Rotor Brake/Custom controls. What issues does it "definitely show"? Looks ok to me, on a quick scan. The difference between the two log files is that in the first one you had logging for Events (non-axes controls) activated, and in the second one not: I don't think this is an issue with FSUIPC, but you could possibly be accidentally triggering an assignment that is doing this. To narrow this down, you can use Event logging, with the logging console window open, and see what events are logged at the time, and just before, your issue occurs. Then track down where that event is originating, John

👍

En su archivo FSUIPC7.log: presets no se cargan porque WAPI está deshabilitado; habilítelo para usar presets.

compress/zip it

Please try the attached version, 7.3.26b, and add ObeyThrottleLowerLimit=Yes to the [General] section of your FSUIPC7.ini file: FSUIPC7.exe

I can confirm this behavior. The max reverse throttle value is defined by the simvar THROTTLE LOWER LIMIT, held in offset 0x0B00. It seems that this value is correctly set - it is -4095 for the 787-9 (and -6092 for the PMDG 737), but it seems that the aircraft is not respecting this limit. This is a problem with the aircraft, not with FSUIPC7. However, I can add a fix for this - I can add a new ini parameter (ObeyThrottleLowerLimit) which, when set, would inhibit the sending of a Throttle Decr controls, as well as the individual Throttlen Decr ones, once the lower limit has been reached. I can take a look at this over the weekend and will post and updated version here for you to test. Regards, John