John Dowson

? If you have set it as in the picture, what more is there to do? Have you tried it? As I said, your ini showed you assigned to LuaDebug and Lua, not LuaSet and LuaClear, as specified in the instructions. You are obviously not following the instructions assigning to those controls.... I'm sorry, but I cannot help you if you are not following instructions or doing as I advise. It really isn't that complicated. Can you explain what you are having difficulty with, or why you 'really dont know what to do'? I will be finishing for the day/weekend in 10 mins....

What are these: ? Please remove/delete those assignments, and assign to LuaSet and LuaClear, both with parameter 211, as explained in step 8 and also in the attached screenshot. How do you expect this to work if you are not following the instructions? The lua is ran automatically from your [Auto] section . When you press your assigned button, that should call LuaSet to set flag 211, which is the flag the script is waiting on for action. It then does its stuff (i.e. gradually applies the brakes) until you release the button, which should be assigned to LuaClear for flag 211, which will then gradually release the brakes. John

I have just set this up for the stock 152 and it seems to work as advertised. I found it was a bit slow for my liking, and changed the rate_on and rate_off to 500 (from 300). There are a few strange things in your (continuation) log: Why is the lua being killed and restarted? As indicated in the instructions, you should start the lua from the FSUIPC7.ini [Auto] section (or profile [Auto.xxx] section if only using in certain profiles). And are you sure you have assigned your button to set/clear the 211 flag using the LuaSet and LuaClear controls? If you do that, your log should look something like this: I see no evidence of flag 211 being set in your logs, so it looks like the script "stop" function isn't being called. Maybe show me your FSUIPC7.ini file.... John

You have again posted a continuation log. Please do not do this - as I said, I need to see the full log file. John

An FSUIPC update will not affect your FSUIPC7.ini file. Maybe you changed your installation location, and you have your old FSUIPC7.ini somewhere still in your old installation location. You could try searching your system to see if you can find any other FSUIPC7.ini files (Everything is a good tool for this, available here if you don't already have/use it). I am sorry but I cannot give you step-by-step instructions on how to do this, especially as I do not own a Thrustmaster Warthog. You really need to try and configure this yourself, and I get help if you have issues. Initially try following "THE EASY STEP-by-STEP WAY TO CALIBRATE YOUR CONTROLS" instructions on page 37 of the user manual initially. Take into account this (from here) - I think this is the most important thing to understand when it comes to controlling reverse thrust: Given that, if you have an axes range below the detent, you could assign to the reduce throttle control when your axis enters the reverse range (below the detent). But it is difficult to give you exact instructions, not having this throttle to see how it actually behaves. Also, before you start to assign your axes in FSUIPC7, you will need to remove the MSFS assignments. If you want to clear all assignments, you can create a new profile for your controllers in MSFS, which will, by default, be empty. Sorry to here about your recent brain issues/operations. I wish you a full and quick recovery. Regards, John P.S. I am thinking of purchasing a TM Warthog to help out with support, as it is one of the more common HOTAS controllers. If/when I do, I will hopefully be able to provide more detailed help. I will let you know if/when I do....

As the crash is when the lua thread is being terminated, and this does not cause FSUIPC to hang, I really don't think its worth investigating this any further. But one thing is slightly strange - you say "at the end when going to main menu: lua crash but NO HANG", but the log file shows: i.e. FSUIPC7 exited about 1.5 seconds after the crash as MSFS was no longer available. Did you exit MSFS once in the main menu? John

Can you attach a compete log please, not a partial log. Maybe, did you add the offset monitoring? I cannot tell from a partial log. It may also depend on the aircraft being used, so I need to see the full log. John

You can use ipc.exit() to terminate the lua thread. John

It will be a false positive. Either temporarily disable your anti-virus or allow it yo be downloaded/unzipped.

Please see the provided README.txt (the clue is in the name!):

That sounds very strange.... Have you extracted the installer from the zip file, and not running it from within the zip file (as can happen sometimes...)? Otherwise try re-installing the VC++ redistributables - instructions in the README.txt. Maybe you previously registered with a different email? Sorry, but I can't really help with this - try the simflight forum support - from the 'Contact Us' link at the bottom of your page. Your FSUIPC license information will be available from your SimMarket account. John

Look ok to me....

Does this mean that when you initially start P3D, its working? Or its not working at all and you need to activate/deactivate to get it to work every time? Could you add the following to the [General] section of your FSUIPC6.ini file: Debug=Please LogExtras=4 This should then log auto-save activity. If you can produce a log file where auto-save isn't working as you expect, show me that file together with your FSUIPC6.ini and I will take a look. I will also test here to see if I can reproduce. John

Hmm, sounds strange...I will take a look. Which version of P3D, and which version of FSUIPC are you using? John

You could run a script on Ctrl+E and then in the script use the event.key function to wait for a keypress (1,2, or 3, so 3 event.key functions) and then, in the keypress function, call the functions to open/close/toggle the appropriate door, based on the key pressed, and then exit. You my also want to add a timer so that if no keypress is received within a certain amount of time, the script also exits. Alternatively, if the time taken to compile and run the lua script on the Ctrl+E keypress takes solong that the 1,2,3 keypress is missed (i.e. pressed before the event.key calls are registered), you could start a script in your DC6 [Auto] section that waits for the CTR+E keypress, and when received add the even.key calls to the 1,2,3 keys, and in the function that handles the 1,2,3 keys you can toggle the appropriate door and then use event.cancel to remove the 1,2,3 key press event. John

Your FSUIPC4 key will still be valid. If you entered your details previously (on your old PC) and they validated there then they will do again on your new PC. Both the name and address/email parts must exactly match those specified in your SimMarket account/purchase email. You can also just transfer the key file (FSUIPC4.key) from your old PC, if available, to your new one. John

Hi Leo, looks like the only issue was the CTD in test 6, but that looks like it was MSFS that crashed, and so FSUIPC exited. Thanks for the update. John

But the ini you posted shows that you have no axes assignments configured at all in FSUIPC7! Have you assigned your axis in MSFS? Have you tried to configure via FSUIPC7? John

In the next FSUIPC7 release, I will add 0x07CE 2bytes - AUTOPILOT HEADING LOCK DIR:3 0x07F8 2bytes - AUTOPILOT VERTICAL HOLD VAR:3 John

Apologies for my previous reply, I wasn't having a very good day... I still don't particularly want to continue this conversation, but I would like to clarify a few points. First, it should be clear the facilities that FSUIPC provides from the documentation. It is also a free-to-use product for many facilities, with additional functionality provided if you purchase a license. I also offer an extended trial license, so all users can try FSUIPC7 before they buy. We recommend that all users actually try FSUIPC before purchasing - it is not a utility that suits all/many users. This implies that you expect me to understand every single aircraft, both stock, add-ons, and all mods, including those aircraft that will be released tomorrow, next week, etc? To look into the code of every single aircraft (no documentation is provided on how an aircraft is implemented or what variables it actually uses) to see what simvars (A, L, H, etc) they use, and then somehow map them to an appropriate offset. This is a completely unreasonable expectation. FSUIPC extracts simvars (or A variables), as well as local variables (lvars) and makes them available for use. It is up to the user to know what variable to use, we only provide the facilities to give access to such variables. There are many resources on how to use such variables, one of the best being the MobiFlight community-driven website https://hubhop.mobiflight.com/#/. You need to use such resources, as well as the Asobo forums and documentation, especially for control of complex aircraft such as the A320. Of those, only AUTOPILOT HEADING LOCK DIR:3 and AUTOPILOT VERTICAL HOLD VAR:3 are currently not held in any offset. They can, of course, be added - I do this on user request. If added, they will be added to specific offsets. As I said, FSUIPC just provides access to such information, it is up to the user to determine how this information is to be used. I know that there is a lot that can be done to improve the usability of FSUIPC, especially FSUIPC7 where there is more of a need to resort to using lvars. hvars and calculator code. I do have various ideas to make this are more user-friendly, but being a one-man team I find very little time for new development these days as so much time is spent on user support....and developing against the MSFS SDK over the past 1.5 years is also very difficult, especially earlier on with the lack of documentation and the constantly changing SDK... I could go on but I don't see much point. Constructive criticism is welcomed, but I think your expectations are way over the top and are missing the point on what FSUIPC is actually intended for. John

@Edoradar Please try the attached version, v6.1.6b. I have added those simvars (read-only) at the following offsets, all 8-byte/64-but floats: 0x7C00 - EMPTY WEIGHT PITCH MOI 0x7C08 - EMPTY WEIGHT ROLL MOI 0x7C10 - EMPTY WEIGHT YAW MOI 0x7C18 - EMPTY WEIGHT CROSS COUPLED MOI 0x7C20 - TOTAL WEIGHT PITCH MOI 0x7C28 - TOTAL WEIGHT ROLL MOI 0x7C30 - TOTAL WEIGHT YAW MOI 0x7C38 - TOTAL WEIGHT CROSS COUPLED MOI I will also add these to FSUIPC7 in the next release. Cheers, John FSUIPC6.dll

I think the issue is that you are using a .lnk, which is a shortcut file. Try creating a proper symbolic link instead, which is handled by the file system. See https://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/ I find the following utility very useful for creating symbolic links and folder junctions (via Windows Explorer): https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html I could look into interpreting shortcut (.lnk) files, but this will be low priority so I am currently not sure when i will have time to look into this (but I will add to my list). But for now, try symbolic links instead. John

Why not just Run xx="a program link" Doesn't that work? I must admit I haven't tried it - the string is just passed to Windows to execute/run in a separate process. I will take a look when I get time (possibly next week) and can maybe convert the link to the destination, if needed. I will report back once I've taken a look. John

Then please do not purchase FSUIPC. I find it quite incredible that you expect that from any software..... I see no point in discussing this further. Topic closed. Regards, John

@Joe67 Please try the attached version, v6.1.6a. The gear type flags have been added to offset 0x05D6, as in FSUIPC7. FSUIPC6.dll John