John Dowson

Also you can try switching to assign using 'Send direct to FSUIPC calibration' and calibrate in the calibration tab, making sure 'No reverse zone' is checked'. Please report back and I can look into this further tomorrow - been a while since I looked at the FBWA320 and now my MSFS is behaving strangely after it updated - keeps freezing.... John

First, you are using an old an unsupported version of FSUIPC7, 7.3.7 - please update to the latest version, 7.3.16. Check your throttle calibration in the flypad - make sure 'Reverser on axis' is set to off: see https://docs.flybywiresim.com/fbw-a32nx/feature-guides/flypados3/throttle-calibration/#5-test Remove that... I can take a look further if you still have issues - been having internet issues and have reconfigured my network and need to complete this. Hopefully I will be back to normal tomorrow... John

You need to assign to the THROTTLEn_AXIS_SET_EX1 controls for the JF BAE 146 - see You should create a specific profile for this aircraft, import your current axis assignments and then switch the throttle to assign with 'Send to FS as normal axis' and then select the appropriate throttle _EX1 control. If you also need to reverse, scale by -1 as shown in that post. John

See the section Additional parameters to scale input axis values on page 41 of the Advanced User guide. Basically you need to need to scale the axis by multiplying by -1, so you add ,*-1 to the end of the axis assignment line in your FSUIPC7.ini file. I could maybe also allow Axis Helicopter Throttle Set to be calibrated using FSUIPC's calibration page.

Ok, thanks, Are you running any anti-virus software (including Windows Defender)? If so, can you also try disabling any and all antivirus software while you install to see if that helps... In the mean-time, I will put back the previous installer version that allows the installation to continue even if no P3D version detected. Should be available sometime tomorrow - although I cannot guarantee as I am having internet connectivity issues at the moment - its been down most of the day and has been very flakey the past few days, not sure what's going on.... John

Can you please attach your WideClient.log, WideClient.ini, WideServer.log and FSUIPC log file. Was this previously working for you, and if so what has changed?

Do you mean that no P3D installation is detected? I don't understand what can be causing this...Can you confirm that you ran P3D at least once and have the mention registry entries please. Did you install the latest combined VC++ redistrbutables? if not, please also do that and try again - please also uninstall any of the original or combined VC++ redistribs that you already have installed for 2015, 2017, 2019 and 2022 before installing the latest combined package.. If you still get issues after that, I will look into making the hacked installer available again, but would rather not if possible. John

The SDK doesn't provide any facilities to save flight plans unfortunately, only to load them. It would be up to the aircraft to save this information - I guess that is what PMDG does. You should probably ask FBW about this. Note also that the FlightSave and FlightPlanLoad SDK functions are still documented as noy working (NOTE: The current status of this function is NO ERROR, NO RESPONSE.) so there may still be issues using those, and the only flight function currently documented as working is the FlightPlanLoad one. John

Note that FSUIPC also provides an additional control that allows you to turn auto-save on/off (when auto-save is activated). Some folks use this to turn auto-save off on take-off and/or approach to prevent these pauses during critical periods. John

You only need FSUIPC6 for P3D - version 4 and 5. For MSFS2020, you need FSUIPC7. If using FSX, then you only need FSUIPC4. All the latest FSUIPC versions, and info on the Flight sims they support, are available from either the Download Links -> Updated Modules section of this forum or from fsuipc.com. John

Thanks for the additional info and links. John

This can happen when a flight is being saved, especially if using a complex aircraft. You can check that your flight-save folder isn't being scanned by any anti-virus software, but other than that there is not much that can be done. FSUIPC just uses the SDK provided API, and it is MSFS that actually saves the flight. John

Download the zip file (from either the Download Links -> Updated Modules section of this forum or from fsuipc.com), unzip it and run the provided installer. Please read/check the README.txt and the installation guide, especially if you have any issues. I will delete your other posts...please stop posting messages that mean nothing in other topics. Just saying 'it doesn't work' means nothing and you will get no assistance. Please explain any issues you have clearly, whether that is with installing or running FSUIPC, and also attach any log files that you may have that would be of assistance, e.g. your InstallFSUIPC7.log file if you have problems with installation, and your FSUIPC7.log file if problems running FSUIPC7. Also, please heck the provided documentation before posting again - at least read the README.txt and the Installing and Registering FSUIPC7.pdf.

You have posted on the wrong sub-forum - please use Paul Hent'ys vlient dll for .Net sub-forum for support for this - I will move your post. John

From @Flávio Oliveira: @pilotjohn I would like to thank you for sharing the Streamdeck FSUIPC plugin. I'm very interested in using it, but I don't understand how to add the two parameters requested when creating a new button: Virtual Joystick: Button Number: I would like to assign simple shortcuts like turning the landing lights on and off. Could you give me the documentation path to use it, or better, give me an example of how to fill in these fields? I have access to the B738 PMDG SDK file and I can assign these shortcuts through FSUIPC. Thank you very much. I hope you can help me! Just to let you know I'm inexperienced with programming, but I've studied a lot on the subject. I tried to do it this way and it didn't work: https://prnt.sc/mq2Fkt5QE0KB

Please see the available documentation on registration issues. Or search for relevant issues on this forum.

Well, a lot better than chapGPT's attempt! The mask for bit 0 is 1, for bit 1 2, for bit 2 4, etc (i.e. the value the bit represents). And you sum to get the mask, so for the function to be called when bit 0 or 1 is changed, so you want: event.offsetmask(0x7390, 3, "UB", "autopilot") Your handling function will then be called when either bit 0 or 1 is changed, and pass in the value represented by the 2 bits specified in the mask, so 0 if both bits are set, 1 if bit 0 is set and bit 2 is off, 2 if bit 0 is off and bit 1 is set and 3 if both bits are set. Next, the handling function needs to both set and clear your new flag offset, depending on the state of both APs (represented by the 2 bits). Presumably you want this new offset/flag to be set when either autopilot is on, and cleared only when both are off. So you need to test the value received in the handling function. So, the script should be: -- Log Jeehell FMGS AP1 & AP2 LED outputs to offset 0x5300 function autopilot(offset, value) -- ipc.log("**** autopilot lua: value received = " .. value) if value == 0 then -- both AP's are off ipc.writeUB(0x5300,0) else -- at least one AP is on ipc.writeUB(0x5300,1) end end event.offsetmask(0x7390, 3, "UB", "autopilot") ipc.log("Jeehell FMGS AP1 & AP2 LED outputs lua started") John

I already have.... see Please try searching the forum for similar issues/requests before starting a new topic. John

No problem - but your issue should be resolved. I hope - especially if you have turned off lvar update requests from the client. Cheers, John

Ok, I will add a comment with more info to that....

I gave up registering bug reports...I raised many in the early days and got nowhere with them (no response except something like 'issue closed'), and no way to track or see any progress. Although most (if not all - difficult to track) now seem to be resolved. Things may have improved, but I will ask about this on the developers channel - I seem to get more response from Asobo through that. I will also try with unregister_var_by_name, but the documentation for that one says "...unregisters a named variable from another gauge..." so I don't think that will do the trick anyway. But I will have a play around and raise this issue with Asobo - although I may have already done this but not sure. Seen your PM - will look into this early next week - need to do/check a couple of things first...suggest you start by looking at the WAPI source if interested in updating this as that will give you an idea of what needs updating on the client side. Will PM you on Monday or Tuesday once I have given you access to the WASM. Weekend off for me this weekend! Cheers, John

This would involve a huge amount of work, on FSUIPC, the WASM and the WAPI. And as I don't see any value in this for me (i.e. more sales), it is not going to happen. There are many other more useful things I could be doing that would provide far more value to the vast majority if users. However, the WAPI is open source, and I will also open source the WASM, so you are welcome to implement yourself...if you did this, I would consider using this in FSUIPC. However, I am not sure how I could implement two different lvar access methods in FSUIPC - I would have to think about that.... I will consider making the current method more flexible in the future (no guarantees when), i.e. allow the user to define how many lvars they want to support via WASM (and possibly WAPI) ini parameters. Strange question....me! Well, I disagree here. The Gauges API even provides a function for this - unregister_all_named_vars, although the documentation for that references token variables,, not named variables (i.e. local variables or lvars) - the other 'named variable' functions reference lvars (e.g. get_name_of_named_variable). I have tried using this but to no avail. There is also unregister_var_by_name but I haven't looked into this. I don't see a problem with this, and I think most advanced users, especially those with home cockpits, tend to concentrate on one aircraft, or maybe a small subset, and don't have any issues restarting if/when occasionally changing aircraft. You can do that, or you can update the FSUIPC WASM / WAPI for your needs if you like and use that (I cannot guarantee that I will use such updates in FSUIPC). I have nothing more to say on this and do not want a prolonged debate on the issue - I consider this closed. If you want access to the WASM code before I open source it (make it public), you can PM me your email and I will send you a github invite. John

No, there are no plans to implement another method or to increase the number of lvars available. What you suggest may be ok for you, but not for the vast majority of FSUIPC users. How would you even know what lvars are available if FSUIPC couldn't list them? I would receive a lot of support requests if this was the case... As I keep saying, the problem here lies with Microsoft / Asobo. I suggest you raise a ticket/bug report with them, saying that all lvars from a previous aircraft should be cleared before loading the lvars for a new aircraft, and the ids re-used. This would solve the issue. FSUIPC doesn't get confused, and you don't need to restart FSUIPC. It is the WASM module that asks/scans for lvars by id using the Gauges API, and it is this scan that is returning the lvars from the previous aircraft. Note also that lvars don't have to be known by FSUIPC to use/write to them - you can use calculator code for that. However, they do have to know by FSUIPC if you want to read them (including adding them to offsets), John

This should be WasmPtr->setLvarUpdateFrequency(0); The default WASM update frequency is 6Hz, so you shouldn't need to change anything, but you can check. Of course it is defined - you have to register your own function, and before you start the WAPI, i.e. WasmPtr->registerUpdateCallback(&LvarsChanged); WasmPtr->registerLvarUpdateCallback(lvarsUpdatedById); // if needed WasmPtr->Start(); and then supply two functions: void LvarsChanged(void) // Called when lvar names have been received and are available { ... // use registerLvarsForCallbck here if needed } void lvarsUpdatedById(int id[], double newValue[]) // Called when an lvar value has changed { ... }

Ah yes, sorry - that should be fine. You can treat an offset area as any size that you like, as log as toy understand what the data holdd. John