John Dowson

You can have it but it won't do anything because, as I said, it is the FS axis events that are calibrated, and this can be done before sending to the FS (done when using 'Send direct to FSUIPC calibration') or when the event is received by FSUIPC (and this event can be generated by FSUIPC when assigned with 'Send to FS as normal axis', or can be generated by the FS or other software, depending in the priority level it is sent at). So what does it use below 10kts? If you are using a preset for rudder and have calibration set up on rudder and this is having an effect, then what must be happening is that the preset is being executed and this is generating the FS rudder control/event (in the FS) which is then being received by FSUIPC, is being masked (i.e. blocked), but the value received is calibrated and then resent back to the FS (using the same event). But this surprises me, as I thought that the standard FS rudder controls don't work...if they do, why don't you just assign to those? When the aircraft is static, do you see the rudder move (external view) when you use the preset? If so, the preset must be working at all speeds, no? And if you activate logging for Axes Controls, do you see any rudder events when using the preset, and if so which one? Do you see any movement when assigned to Axis Rudder Set or Rudder Set (under 'Send to FS as normal axis')? And when assigned like this, can you set up monitoring for the lvar L:INPUT_RUDDER (see documentation on how to do this via the ini file) and see how that changes?

The ! symbol is the logical not operator so !TRUE is FALSE, and !FALSE is TRUE (or, in RPN, TRUE! is FALSE, and FALSE! is TRUE. So the expression (L:someLvar, bool) ! (>L:someLvar, bool) flips/toggles the value of the lvar, i.e. changes it from TRUE to FALSE or from FALSE to TRUE. John Also explained here: https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm

👍

There are no changes in the 7.5 release that could cause this, and that was released at the beginning of December now...have you had this issue since then or have you only recently updated? You can try an earlier version to confirm if you like, e,g, https://fsuipc.com/download/Install_FSUIPC7.4.17.zip So your throttles are not assigned in FSUIPC? Can you be more explicit please - what do you mean by 'but will only slide back halfway'? And what do you mean by 'On single engine aircraft, only throttle 2 works'? In a single engine aircraft, there is only one throttle (throttle 1).... That message is informational and just letting you know that that preset isn't available for use as the name has too many characters. It is not being used (it is not even available for use!). Also looks like you manually reloaded the presets as that message is logged twice. Can you please activate logging for Axes Controls and test again, and show me / attach both your FSUIPC7.log and FSUIPC7.ini files. Just load the aircraft, move the throttles through the full range and back again, and then exit before attaching files.

Just from 1 to 0? Not from 0 to 1 to 0, or from 1 to 0 to 1? As it auto-resets, it should change to 1 value then back again (or to 0 then back again)... Maybe try: DU_MasterBright_Bright#(L:INI_CKPT_LT_DU_MASTER_BRT_INC, bool) ! (>L:INI_CKPT_LT_DU_MASTER_BRT_INC, bool)

Can you attach your FSUIPC ini and log files, as well as your WideServer.log, WideClinet.log and WideClinent.ini. That will ar least give me an idea of your set-up. And please let me know how the avionics on the client PC is configured - are you using any other additional software? If you have not assigned/configured in WideClient / FSUIPC (and if ButtonScanInterval is set to 0) then these devices (whatever they are) must be assigned elsewhere, no? i am confused as to why do you think this is related to WideClient / FSUIPC if your client controllers are not assigned in FSUIPC...

Yes, that sounds correct, as that lvar is documented as a BOOL. I have no idea why it isn't controlling the brightness. When you inc/dev the brightness in the VC, do you see the lvar change value (and reset)? As I said earlier, you should ask on the InBuilds support forums as I do not have this a/c.

The only way they can be coming from WideFS is if you have set it up to do this and have assigned in FSUIPC. If that is the case, remove the assignments. Also, if you set ButtonScanInterval=0 in WideClient, it will not forward any button presses to FSUIPC, and so cannot possibly trigger anything there. What hardware to you have attached to your avionics PC, and how/where are they assigned? If you have not assigned in FSUIPC, why do you think it is coming from there? WideClient only talks to FSUIPC, not the FS.

Yes, you will need to give it a value...probably also a good idea to use repeat when assigning to that preset as well.

But why? Why not just do the correction I suggested? It was detected: However, it was not acquired as you now have registry issues: Continually unplugging and changing USB ports can cause registry issues. Please go back to your previous ini, make the changes I suggested and try again. If you still get issues, please attach your log and ini files again please, as well as the JoyScan.csv file. No, it is due to registry issues. If assi9gning in FSUIPC, we recommend that you disable controllers completely in P3D. If you don't do this, please make sure that you don't have dual assignments, i.e. an axis or button/switch assigned in both FSUIPC and P3D. Also, P3D has a tendency to auto-detect your controllers (if not disabled) and then make default assignments, which can cause issues if already assigned in FSUIPC. John

So it looks like those lvars are acting like a control/event - you set it to 1, this triggers the brightness increase or decrease and then the lvar gets reset back to 0. If you want to inc / dec again, you can set it to 1 again. Does it not work like that? If not, ask on the Inbuilds forums on how those lvars are supposed to work. I don't have this aircraft so cannot take a look here, sorry. John

Those are just events that are being logged....FSUIPC logs ALL events applied to the FS. Why do you think that those are coming from FSUIPC or WideClient? If you have no assignments in FSUIPC / WideFS, they won't be coming from there... Try setting logging for Buttons & Switches - that will log any button press that is triggering an assignment. If those events are being sent from your device and you don't want them to be sent, remove whatever you are using that is sending them. Note that many aircraft in MSFS continually emit certain events, and these event are different for each aircraft. These events are just noise really, and you can prevent them being logged using the DontLogThese ini parameter. No, as they are most probably not coming from FSUIPC or WideFS. FSUIPC is just logging them, not sending them.

You can try setting ButtonScanInterval=0 From the WideFS User guide:

All offsets in the documentation start with 0x and not $. But also only the starting offset is documented (together with the size), so rather than searching for a specific offset, just scroll down to you find the entry that documents the range for the offset you are interested in. Yes - almost all the offsets that have been allocated to 3rd party software use was done many years ago, before my time, and I have no idea what these offsets are used for in most cases! Cheers, John

Note that I also need to see the WideServer.log files for issues with WideFS... However, it should be obvious why it didn't connect the first time you ran FSUIPC7 if you look at your log file: FSUIPC7 never connected to MSFS and the WideServer was never started. Note that, by default, WideServer is not started until FSUIPC7 is connected and you have an aircraft loaded and ready-to-fly. The first thing you need to do is to delay the start of SPAD,next and vPilot until at lease FSUIPC is connected top the FS (i.e. add the CONNECTED keyword). vPilot could be started even later, using the READY keyword. Once that is corrected, try again and take a look at your log file. If you see the following message: 48891 **** SimConnect open event not received in required time limit: Re-connecting now... then you should adjust the DetectToConnectDelayAuto ini parameter. Please see the section Auto-tuning of initial start-up ini parameters in the Advanced User guide, or the following FAQ entry: John

Was this ever working then? Keysend works via windows messages. How are you starting the Discord PTT program? Have you tried directing the keypress to the Discord PTT program? If not, see the WideFS Technical guide from section Directing Key Strokes more precisely and onwards, John

Well, it cannot create the ini file if it isn't running. P3D starts FSUIPC from either the DLL.xml file or the Documents\Prepar3d v? Add-ons\FSUIPC6\add-on.xml file (depending on P3D version and maybe the components selected during installation), which are either modified or created when you install and has absolutely nothing at all to do with your ini file. Check you InstallFSUIPC6.log file for details. Changing the ini file can in no way affect the starting of FSUIPC6, so you must have also done something else. You can always try re-installing FSUIPC6 to see if that helps, and if not then show me / attach your InstallFSUIPC6.log file. John

Yes - its 5.1.4.

7.5.2e is a beta version, and you should not have received any notification for this as only official releases will prompt a message to download, When you re-install, it is far easier to just install into the same folder. This will then just replace the installed files and leave all other files (e.g. settings, key, lua sctipts, macros, dlls, etc). 7.5.2 is the latest official release, and it should say that 7.5.2 is available, and not 7.5.2e. If you are using 7.5.2e, then you are using the last beta of 7.5.2. You should ypdate to the latest official release (hence the message), although there will be no actual difference in the versions (7.5.2e was the last beta and was released as 7.5.2). Please also use the FSUIPC7 support sub-forum for all issues/questions with FSUIPC7, and not the main support forum. I have moved your post. John

Again, all information on offsets is in the FSUIPC7 Offset Status document - why don't you look at that? I provide extensive documentation so that I do not have to spen all day responding to such questions. Please ALWAYS consult the documentation (as well as checking these forums) before posting questions.

No hay ningún problema con su licencia: Consulte la documentación - Installation and Regisuration guide. Los problemas de validación siempre se deben a: - introducir los datos incorrectos - no tener instalados los redistribuibles de VC++ correctos - problemas con el antivirus Todo esto se explica en la documentación, aunque solo está disponible en inglés.

Does that even work? Should be: i.e. presets names should be preceded by 'P:'. Macros are ran in the main thread, and will block that thread until it has finished. If a macro is going to take more than a few hundred ms to complete (and you have an 8 second delay there!), you should use a lua script instead. Lua scripts are ram om separate threads. John

👍

Ah - maybe these are 'scoped' local variables? See https://devsupport.flightsimulator.com/t/how-to-access-scoped-lvars-l-with-simconnect/12540/20

This issue is continually getting reported, and my answer is always the same. Please see one of the other many posts on exactly the same issue: ...etc Basically read the documentation and follow the advise there, and also check out the many posts on exactly the same issue.