John Dowson

There are two other things that you could try: 1. Running your lua script on a key press, no repeats, and killing it on a key release. In the script, you can loop forever, reading the lvar value, adding 100 and writing it. However, as the lvar update is asynchronous and it will take a while (time depending on the lvar update frequency set in the WASM, which I think defaults to 6Hz) you will need another loop inside that to read the lvar value back and sleep for a short period (i.e. 50ms) if the value is the same, exiting once it has updated to continue the main loop. 2. Use an auto-running lua with an event.key function. In the event.key handling function, you would also need to only update if the previous update request has been reflected in the lvar value, and do nothing if the value is the same. You can also change the lvar update frequency in the WASM to Frame or VisualFrame to get faster lvar updates.

You use profiles to have different assignments for different aircraft - see the User manuals. No - you can have completely different assignments for different aircraft if you wish. Please read about FSUIPC profiles. John

Did you try adjusting/increasing the LuaRerunDelay parameter?

I cannot help you with the WebSocket server as I have never used this - @Paul Henty may be able to assist. However, I assume it is just a matter of writing the correct data to an offset with the facilities provided - you just need to write the preset name (preceded by 'P:') to offset 0x7C50. John

Ah, sorry - misread/understood your request. You could look into adjusting/increasing the LuaRerunDelay parameter - see the Advanced User Guide: That last sentence seems to indicate that if the lua is started on button/key presses then the repeat is not effective until the current lua execution finishes, so it may actually do what you want as-is - have you tried it?

Sure...would be goof to know id that works, but there is not much I can do about it if it doesn't...

Yes. No, sorry - I cannot modify this behavior for all users and all lua scripts one specific use case...there will be a lot of set-ups that depend on this behavior. Ignoring a call to start a lua script seems like a very bad thing to do in any case and would cause many issues. But I don't understand why you would want to do this anyway, even for what you are trying to achieve. Why not just use an event.key function? You can also add a event.timer that would terminate the event.key if no keypress seen within a certain amount of time (and also kill the timer and so exit the lua script, if that is what you want to achieve). John

Hi @mtjoeng I have been looking at the key assignments again and they are currently a bit of a mess... I am going to add support for right shift/ctrl/alt keys, and remove support for the windows key (as this cannot be used anyway). I can post you an updated version here for you to test in a day or so, if you would like to try/beta test this for me. Also note that you can also use the tab key as a modifier in FSUIPC, which also extends the number of assignable keys. John

If you want to use reversers on an axis, they are usually assigned on a separate reverser axis. I am not sure if this would work with the PMDG aircraft, but the way to do this (with a separate axis for reversers), would be to try assigning the forward thrust throttle levers to the normal "AXIS THROTTLEn SET" controls, and either don't calibrate (calibration can mess up things with PMDG aircraft), or if you try calibration in FSUIPC set the "No reverse zone" option so the whole axis is for forward thrust. Reversers can then be assigned the FSUIPC-added controls "REVERSERn". You could try using the "AXIS THROTTLEn SET" control and calibrating with a reverse zone, but this has previously always given issues with PMDG aircraft due to priority levels. PMDG aircraft have always had issues with reverse control on an axis - I don't know about the MSFS version but it looks to be the same... John

Thanks @Cuantreau - that looks like a pretty standard throttle config for jets with a button to activate reversers (rather than using an axis), so I am surprised others are having difficulties. The only difference to a standard set-up is in using Throttle Set with a parameter of -1 rather than Throttle Cut, but I guess that does the same thing...

Does the F1 key work for throttle cut? If that works, but not sending the Throttle Cut control via the SDK (FSUIPC), then you could assign to send the F1 keypress instead. Similarly, if Throttle Dec (when idle) doesn't go into reverse, then try the F2 key instead and if that works assign to that.

But many people can't! People used various different methods for the throttle assignments in FSX/P3D. Perhaps you could share what you use as this could possibly help others who are having issues with this in MSFS.

I don't know - if the standard controls don't work, check the PMDG SDK to see if any custom controls are provided. You could also try logging what events are used when you move the fuel levers to idle/cut-off in the UI. According to the following post, Throttle Cut is being used, so have you tried that? Do you have your throttle assigned and working in FSUIPC? It seems that many people are currently having difficulties with this (again, see that post above). Not having this add-on, I cannot really advise on how the throttle should be assigned. You should check the PMDG forums. There may be an update to make the specific PMDG offsets available - if the MSFS version is providing this data (I am awaiting a response from PMDG to see if this is available). But I don't think there will be any update to help with the throttle assignment. This should really be assignable using the currently available controls/events, but I don't really know not having this add-on, sorry. John

The issue with the the ipc.ask() function is its dependence on a simconnect message window using the API SimConnect_Text function, not on getting the input values back - this is handled by FSUIPC. This function is still documented as not currently available for use. So no, there has been no advance with this, and I don't know if this will ever be fixed or replaced by something else. At some point I could look into adding a similar function to get user input via the wnd library (e.g. a wnd.ask() function), but I can't say when I will get the time to look into adding such a function at the moment. John

I have no idea if PMDG provide this data yet, and if they do what the size is and how much space is needed in the offset table (i.e. if it fits in the currently allocated area). I will know more once I have heard from PMDG and can give an estimate once I know the details.

Yes. If you have a WideFS7 license purchased for use with FSUIPC4, FSUIPC5 or FSUIPC6, then that WideFS7 license can also be used with FSUIPC7. A license for FSUIPC5 or FSUIPC6 is not valid for FSUIPC7 - you need an FSUIPC7 license for FSUIPC7. Or are you saying that your WideFS7 license is not valid for FSUIPC7? It will be, but if the name and/or address fields for your WideFS7 license are different from those used for your GSUIPC7 license, then you need to tick the appropriate box and also enter those. FSUIPC and WideFS are distinct products and each requires its own license. John

Well, must have been quite a while ago (and before my time!) - this is one example of many responses by Pete on this subject: A waste of an add-in purchase then... You should try what I advised in my first post. I am sure it will be possible, you just need to work out what controls it is using. I am familiar with the manuals....they provide general instructions applicable to a lot of aircraft, but not all, especially complex add-ons. If the general methods/controls don't work, you have to investigate further.

No, I don't think the offsets will be populated at the moment as I believe I disabled these in FSUIPC7. Now the PMDG 737 has been released for MSFS, I will see if these are still valid. John

That is strange - many people get issues when calibrating the throttle in FSUIPC for PMDG aircraft... It is still not clear to me if you have any issues or not, but if you do, I cannot advise anything further than I did in my original post.

I am slightly confused by your post...are you assigning in MSFS or in FSUIPC? As I don't have the PMDG 737, it is difficult for me to advise on how the reversers work in that aircraft in MSFS. For the P3D PMDG 737, you can assign the throttle in FSUIPC but without calibration. For the reversers, you would normally program a throttle button (or the button detent on the throttle axis, if you have one) to send repeated throttle decrement controls (when throttle is at idle) and then send a throttle cut on button release to bring it back to idle. However, I have no idea how the reversers work in the MSFS - this has additional reverser controls that may be used instead. You could try activating logging (both for Events and Axis Controls) and reversing via the cockpit UI to see what controls/events are logged. Otherwise, check the documentation that came with the aircraft or ask about this on the PMDG forums. John

Yes - see the LuaPath ini parameter, Advanced User guide page 9.

To be honest, I have no idea how your set-up is working. FSUIPC4 (and all versions of FSUIPC prior to FSUIPC7) are dlls and run in the FS they are designed to work with. You cannot even install them if there is no FS for that version, so I have no idea how (or if) your TRC link and RCSLink software are using them. FSUIPC7 will log the events and simvar changes that it sees in the FS, regardless if where the events and simvar updates come from, and will log both when used on the server or on a client PC. The button/key events will only be logged when seen, i.e. for button/key events initiated from the PC on which it is running. Yes. Or you can open the FSUIPC7.key file and replace the trial license details with your own. John

What do you mean by this? What is 'old FSUIPC'? What version of FSUIPC are you using? It shouldn't make a difference where your assignments are - FSUIPC logging logs all sim events, not just those sent via FSUIPC. And the offsets hold the FS' simvar values and will update whatever is changing them. And if you are using TRC LInk and RCSLink software for your assignments, why did you ask me to correct your ADF swap issue in FSUIPC: ?

Please always attach your FSUIPC7.log file if you think FSUIPC7 has crashed - this usually shows that FSUIPC7 exited normally due to an MSFS CTD. If/when MSFS crashes, this can cause an exception (in the event viewer) for FSUIPC7, but this is usually due to the MSFS CTD. Check the event viewer again to see if there is an MSFS crash reported before the FSUIPC7 event, but it is the FSUIPC7.log file that would help in determining what actually happened. In all cases, MSFS CTDs should be reported to Asobo. As FSUIPC7 is an external program that only communicates with MSFS via the MSFS-provided SDK, and crash in FSUIPC7 (if it did actually crash) should not affect MSFS, and if it does, it is an issue with the SDK (which is an Asobo/MSFS issue). John

I have just checked this with a simple lua script: And when I run this and list the lvar values I see: A320_FCU_SHOW_SELECTED_HEADING = 2147483648.000000 A320_NE0_FCU_STATE = 2147483649.000000 So values > 2^31 are being sent and applied correctly. I therefore suspect that it is the aircraft model that is not accepting such values. You can also verify that the value is being sent and applied correctly by setting Debug (or maybe Trace) level logging in the FSUIPC WASM module and check the FSUIPC_WASM.log file to see what values the WASM is applying (see the Advanced User manual for details). John