John Dowson

This is not correct - the installer will never replace or remove your ini file - this would cause chaos/sever problems....! As I said, you either installed into a different folder, or you manually deleted your ini or your assignments. If you didn't manually remove or delete the ini, you must have installed in a different folder. Try searching your system (e.g. try with Everything or something similar) for your old/original FSUIPC6.ini file.

As Pete says, you don't have any assignments in FSUIPC apart from those 2 that Pete mentioned. You do have controllers activated in P3D, so are you sure your assignments aren't there (you should de-activate controllers in P3D if assigning in FSUIPC). Could you possibly have installed 6.1.2 in a different location to 6.1.1? Of so, your original 6.1.1 ini should still be in the old folder. Ifthats the case, copy ot toyour new installation folder and try again (and post your new FSUIPC6.ini and updated FSUIPC67.log file if you have any issues). John

Not on our side. Maybe @cellular55could comment if he has heard anything from VRInsight....

Ir looks like your Joy ids have changed. Can you please also attach your FSUIPC6.ini file.

Sounds like some hidden characters have made its way into the script. Try downloading it again. or looking at the file in an editor that can show hidden characters/symbols (e.g. Notepad++) and remove them. 341 does refer to the line number. It is strange that it reports the error for multiple lines - maybe there are multiple hidden characters. Line 341 is also just a comment - you could try just removing that line....

@yvesb It looks like the LvarScanDelay WASM ini parameter had no effect, regardless of what this was set to. I have now corrected this in the attached (beta) release. Could you please try this as I think if this is working then there should be no need to have a regular automatic re-scanning of lvars. The lvarScanDelay parameter is also now in seconds (rather than milliseconds), with a max value of 120. There are also some other corrections for when using lvars, such as not auto-starting luas or macros until the lvars have been loaded. Install_FSUIPC7.2.2c.zip John NB. If you have problems downloading from that link, try right-clicking and selecting 'Save as...'.

It is strange that this issue started after a P3D update, but I really can't see how that can affect something like event.button, which is completely independent of P3D (i.e. P3D is not involved at all). Anyway, try activating the suggested logging, as this may show you something when this happens again - i.e. if the button presses are received, and if anything is picked up by your lua scripts. Cheers, Joihn

It is recognised but did you add it to the [Auto] section of your FSUIPC7.ini file so that it is automatically started? See the Advanced User Guide if you don't know how to do this. I'm also not familiar with FSUIPC3 (and it is no longer supported!). You can add logging, and maybe check the offsets being used are compatible, as @Blake Buhlig suggests,

This information is in the offset status spreadsheet (included in the downloadable zip file for FSUIPC7), which should be used in conhunction with the older FSUIPC Offset status document (which contains the descriptive text). I have heard of some folks using MSFS for the visuals only, but I have no idea how this is done, sorry.

Hi Reinhard. this seems rather strange. I don't understand how a P3D or windows update could affect the lua event handling. There was no change in the FSUIPC6 version you were using, no? Its also strange that is affecting both event.offset and event.button functions. Are you sure that you luas are actually still running when this occurs? Maybe you can activate logging for buttons and keys, as well as lua plugins (but not Lua plugins separately), and show me the log file produced when your issue occurs. John

Sorry, this is not true - I was thinking of FSUIPC7/MSFS - please ignore this! Ok. You can try assigning to the standard P3D controls for this - they may work, but more complex add-ons can implement there own controls, either using custom controls or by repurposing other controls, usually the Rotor Brake control. There are a few things you need to know to do this. The first is how the increment/decrement rotary works on the bravo. It is a one-button rotary type, which means it triggers one button in each direction when you turn this. By default, you can only assign one action to each button in each direction. To get around this, you can use a lua script to convert the physical button presses into virtual ones, to provide a fast and slow virtual button-click in each direction. If you do this, you can then assign large inc/dec controls to the fast virtual button, and as smaller inc/dec control to the slow virtual button press. There is an example lua script provided that you can use (adjust as needed) called Rotaries.lua, and there is also a specific lua script for the Bravo for this in the User Contributions section. To change the heading, you can then assign the rotary buttons (or virtual buttons, if you decide to use that mechanism) to the either: - the heading bug controls, Heading Bug Inc/Dec, and Heading Bug Inc/Dec Fast - to the Offset SWord Increment/Decrement controls, using offset 0x07CC (Autopilot Heading Value), where you can specify the size of the inc/dec for each button or virtual button press Once you have set-up the rotary assignment, you then need to edit the FSUIPC6.ini to add a 'compound button condition'. This is explained in the Advanced User Guide, (P22). You basically add a condition to that assignment which will make it fire/activate only when the function knob is set to the Hdg value, which is when button 18 is set. Once you have the heading function set-up, you then comment out the assignment lines that were added, by placing a semi-colon after the index number of the assignment. This will temporarily remove that assignment to allow you to set-up the next function (e.g. VS), which you do in a similar manner. Once all the functions have been set-up like this, and you have added compound button conditions for all the function button positions, you then remove the semi-colon to re-activate all your assignments. Note also, that you can use the 'Reload all buttons' button in the assignments panel to reload your FSUIPC6.ini once you have manually changes it. John

@Tom87 Done.

If/when MSFS crashes, it usually generates faults like this in FSUIPC7 as the simconnect connection is no longer available. In such cases, FSUIPC7 will also exit, as the option 'Exit with FS' is set (and always set if FSUIPC7 is auto-started by MSFS). Check your FSUIPC7.log file, it should show that FSUIPC7 closed down gracefully as MSFS was no longer detected. If this is the case, then you should report the CTD to Asobo, including the crash event log. If/when FSUIPC7 does actually crash, the FSUIPC7.log will be cut short, i.e. no close-down messages logged. However, if this happens it should not affect MSFS as that is in a separate process.

This is usually due to having the document already open somewhere - the installer can't replace the document as its being used. Make sure that the document is closed, and then re-run the installer. If that is not the issue, then please show me your InstallFSUIPC7.log file, if there is one. John

No, sorry, there is no tutorial. And how you configure can also depend on the aircraft. Most MCP/Autopilot functions can be controlled using lvars or hvars (or MobiFlight events), if the standard controls don't work (or aren't available). You can try listing the available lvars/hvars (using the Add-ons->WASM-< List Lvars/Hvars menu entry), and then setting/changing (lvars) or activating (hvars) them, using the menu options under Add-ons->WASM. Once you have found the ones that work, you can assign them to your buttons using either macros, lua or the lvars-to-offsets functionality. I can't really help with such a general request, but if you let me know what aircraft you are using (and which mod, if applicable), and which button & function you would like to assign, I can maybe help you with that, which would then give you an idea of how to set-up the remaining buttons. John

Hi Mario, could you try the attached version please, v7.2.2b: FSUIPC7.exe Thanks, John

Could you please attach your FSUIPC7.log file created after the CTD. Also check the event log to see if there was an MSFS crash reported before the FSUIPC one. Thanks, John

Hi Mario, I'm not sure I fully understand this. Could you explain an actual use case, i.e. which lvar and which aircraft? This may be due to the way client data areas function - if the data doesn't change (i.e. writing the same data, lvar +value) a second time won't be registered. There was a similar issue recently related to executing calculator code - if you executed the same code twice, the second would be ignored. I got around this by sending a dummy calc code request after each one requested, just to reset the CDA. I probably need to do something similar for the various other CDAs that FSUIPC uses, i.e. to set lvars and activate hvars. I will look into this next week, but a concrete example would help. Thanks, John

Tried what - using DontLogThese? That will work - just add DontLogThese=68068 to your [General] section or [Profile.xxx] section.

See the following:

I don't think so. FSUIPC is just logging the events it receives from MSFS (it is not sending those). You can stopped those messages from being logged by using the DontLogThese ini parameter (which can go in the [General] or your [Profile.xxxx] section) to prevent those messages being logged, but that will prevent all of those messages being logged, even (perhaps) when you are interested in seeing them. You can always turn off Event logging, or close the console window! Sorry I can't be of more help for this. John

If you check the offset status spreadsheet provided with FSUIPC7, you will find that this simvar has been added to offset 0x0C46 (read-only). I am now working on merging the spreadsheet and the offset document to provide a single source of offset information for FSUIPC7, but this will take a while. For now, you should use the spreadsheet I provide, and consult the document for the offset description (where available). Note if using the A320, offset 0x0260 also contains the current autobrake setting (0=Off, 1=Lo, 2=Med, 3=Max) John

The first execution of the script started at timestamp 1872344. The second execution started at 1872469, which 125ms later. As the first execution of the script was still running when you ran it again, the thread with for first execution was terminated. You can only ever have a script running once - if you try to run it again and it is already running, the current running instance will terminated. Also seems a strange script.... You don't need the ipc.exit() as the script will exit anyway, and you don't need the function call (or delays). The following script would do the same: ipc.runlua("DC6_MP_CONTROL")ipc.sleep(50)ipc.runlua("DC6_RPM_CONTROL")

I just took a look at this and I get the full +/- 16k range in the calibration tab, as expected. How have you assigned your ailerons? Using 'Direct to FSUIPC Calibration' assigned to Ailerons? Which aircraft are you using? Do you have any honeycomb software running? If so, please disable and try without. And do you have controllers disabled in FSX?

If you can populate free user offsets with the weather data from your 3rd party source, you can then spoof the reading of the original FSUIPC offsets to the offsets where the data is actually located. You can do this using the offset spoofing utility at offset 0024. You will first need to get the weather data into the FSUIPC (free user) offsets, and see how they map to the existing FSUIPC weather offsets. Once thats done, I can help you set-up the spoofing of the original offsets, i.e. when anything tries to read the original offset, it will read the data from the new offset that you added to hold this data.