John Dowson

There are a couple of things you can try: 1. Switch to using the control Set Fuel Valve Eng1 with a parameter of 1 for on or 0 for off 2. If there is an offset that holds the current state of the fuel valve, you can add an offset condition to the assignments based upon that offset (see the Advanced User guide on offset conditions). You can try with offset 0x3590 (GENERAL ENG FUEL VALVE:1) - this seems to work for some aircraft but not all. Alternatively, if there is an lvar that holds the current state of the fuel valve, you can add that lvar to an offset and then add an offset condition to that lvar offset. John

The SimConnect_Text function is broken in MSFS and has been since release. This is documented in the README.txt under Missing Functionality: The only alternative at the moment is to use the lua Wnd library. I will update the offset status document to make it clear that these offsets no longer function correctly in MSFS.

Sure. I will look into adding these on Monday, so if you know of any others that may be useful (e.g. anything similar for airspeed/vertical/rpm/etc) then let me know and I will add them all at the same time. Note I will be unavailable (on holiday) from 12th-17th (inclusive). I am also going to see if I can add a lua functions to return the value of any simvar (i.e. provide access to the get_named_variable_value gauge function via the WASM/WAPI). As mentioned, it is already possible to set any (settable) simvar via calculator code, but I may also add a helper/wrapper function to make this easier.

hvar names don't appear in the assignments drop-down, or do you mean when in a macro file? The same issue should also apply to lvars, no? I understand the issue, but if they are in a macro then they should be ordered by index number (or alphabetical, not sure which without checking) so should be relatively easy to determine which is the correct entry. I can look into allowing more characters/space in the drop-downs and panels, but this will be low priority - I'll do this when I have some other updates to these panels which are in the pipeline. John

The FSUIPC_WAPID.dll is the (dynamic library) interface to the FSUIPC_WASM module - your link software must be using the FSUIPC WASM module via this interface. The version needs to be the same version as compiled in the software and be compatible with the WASM version installed into your Community folder. There should also be a log file in the same folder, maybe called FSUIPC_WAPI.log but could be different (your link software can set this name). If you look in that file it should log the versions and should also log an error if incompatible with the WASM. This is an example of the first few lines: The version compatible with your FSUIPC WASM installation can also be found under the SDK folder of your FSUIPC7 installation folder, in a file called FSUIPC-WASM.zip, or can be downloaded from www.fsuipc.com. John

Hi Andrew, Sure, I can add them. They are only available for aircraft that use the new electrical system - I will also add the simvar NEW ELECTRICAL SYSTEM which will flag when these offsets are/should be available. I will add them as read-only offsets. There are quite a few new simvars for the various new systems (electrical system, fuel system, etc). I still need to go through the MSFS documentation to compile a list of new simvars which I will add to the offset documentation (as available upon request). No, not that I could think of. You can update unknown simvars (those that are settable) using the lua ipc.execCalcCode() function, but there is no way to return the result when executing calculator code to read the current values. I will post a version here for you to test when ready.

Hi Klaus, Its Dowson, not Dawson. John preferred. I so not know why the CDU is not working any more, but for the changes between versions please see either the changes.txt file included in the downloadable zip, or the FSUIPC7 History.pdf, located in your GSIOPC7 Documents folder. Try activating logging for Buttons and Keypresses as well as events, and generate an FSUPC7.log file for the version where it is working and also in the latest version. This should show any differences. You can attach the files here and I can take a look. John

The internal controls do sometimes work differently from those provided by SimConnect. I am not sure what is happening in this instance - I will take a look when I get time, maybe next week... John

Why are you not doing as I asked? What have you actually done? Can you please tell me exactly what you have done, as you don't seem to be following my advice - and why are you running MSFS - I only asked you to run FSUIPC7.... I cannot really help you if you are not willing to follow my advice.... I hope that you at least took a back-up of your registry...

From that page: There are Pause offsets - see 0x0262 and 0x0264. For the Fuel Transfer Pump, there is an indexed variable FUEL TRANSFER PUMP ON:index Returns 1 (TRUE) if the indexed pump is active. Bool Which could be added, if needed/useful, but this is only available in aircraft that use the new MSFS FuelSystem. Note I recently added a similar indexed variable FUELSYSTEM PUMP ACTIVE for up to 16 pumps. There are also several zoom offsets, but I am not sure of their status in MSFS - these have not been checked, but I suspect they are no longer available in MSFS as the view/camera system is very different. Thank you for your contribution. John

I have no access to that file, but it doesn't matter at the moment... Your ini file shows you have 2 button assignments to the Bravo to the same control: The Bravo ALT button is button 4, so you should remove/delete/cancel that other assignment to button 18 (the one in bold). Please see the Advanced User guide P22 for adding offset conditions. If you want to assign as suggested then your button assignments section should look like this: You can also configure in other ways. For example, you could use Ap Alt Hold On Ap Alt Hold Off i.e. again overloaded (more than one assignment on the button) using the same offset conditions as I mentioned before. This would then switch ALT hold on/off. You can then assign your VS button similarly, overloading the assignments with an offset condition on 0x07EC (Autopilot vertical speed hold). My MSFS system is currently updating so haven't tried this, but I can look into this in more detail once I've updated and have time - probably next week. For configuring the Bravo with FSUIPC7, also take a look at this post (covers all Bravo assignments except the AP functions - to be honest I haven't had time to look at these in detail yet): John

Sorry, I was mistaken: -15 IS the most sensitive curve (around the centre position) and 15 the least. Glad it is now working and calibrated to your needs. John

You could also look into using your arduino device with MobiFlight + FSUIPC - plenty of posts out there on this. Also, maybe take a look at the following: http://thegeekforge.com/2017/11/10/arduino-lua-fsuipc-tutorial-001_a/ and Good luck! John

That will be the microcontroller USB board that the kit is built on. Yes, arduino boards are used a lot for this type of thinks. Unfortunately I have no experience with such controllers. Your best bet is to look at the microcontroller board documentation - see https://docs.arduino.cc/hardware/leonardo. You could also try looking and/or asking about this on https://www.cockpitbuilders.com/. John

👍

If using FSUIPC, you should use FSUIPC's logging facilities, and also attach your FSUIPC7.log file, with appropriate logging enabled (in this case, for Buttons and Key presses + Events) so that I can see what is happening. I also need to see your FSUIPC7.ini file. Why are you double-pressing/clicking rather than just using a single click/button press? I have just taken a look and pressing the ALT button sends the following events (alternating): Ap Alt Hold - switch to Altitude Hold mode Ap Panel Vs On - switch back to VS and goes between ALT and VS (not clear). Sending the same events in a button press via FSUIPC also has the same affect. Therefore, you need to overload the assignments on your button to use both controls, and add an offset condition to send the correct control depending upon the current ALT mode, which is held in offset 0x07D0. John

I am sorry but I cannot support hardware devices that I do not know - you really need support from the manufacturer. You do not even mention the manufacturer, name or model! If it is detected by windows as a keyboard type device, then you should be able to assign the "keys" in the FSUIPC key assignments panel. However, if doing this then it may/probably will only receive the input when FSUIPC7 has the focus, and not when MSFS has the focus. This is because MSFS does not recognise it as a keyboard input device, and so doesn't forward the "key strokes" to FSUIPC7 when it has the focus. Is there some configuration software and/or driver that this device is using to convert the button presses to key strokes? If so, maybe not run or uninstall the drivers, and see if it recognised as a HID joystick type device without this driver or software. If that is the case, then you can assign in the usual way. If it is recognised as a non joystick type device, it may be possible to assign using lua. You could maybe look into using the example HidDemo.lua script provided (in the lua examples zip file in your FSUIPC7 Documents folder), but I would first check with support for that device. John

Most of the controls for these are using lvars, hvars or calculator code. You can use MobiFlight events with FSUIPC if you like, but you do not need to. If you want to use the MobiFlight WASM module, event files for MobiFlight are provided in the EventFiles sub-folder of your FSUIPC7 installation. To use these, you need to move them to the main FSUIPC7 installation folder (i.e. up one level). There are event files for the G1000, the GNS530 and the KAP140. Alternatively, you can just use the lvars/hvars/calculator code theat the MobiFlight events use directly. There are various methods of doing this, all described in the user manuals and in various posts, but the general technique is the same. Take a look at the MobiFlight hubhop site (https://hubhop.mobiflight.com/) to see what a MobiFlight event uses, and depending on what that is you can either assign to a control, an lvar or hvar (using lvars-to-offsets functionality, macros or lua) or using calculator code (only available via lua at the moment). No, they are distinct. Simconnect events are also known as K events. Simvars are also known as A vars in gauge /calculator code. Usually its one or the other, maybe a combination of both, or possibly using other variable types (hvars, bvars, etc) or complex calculator code. Take a look at the code for the presets in that MobiFlight hubhop site. But really you need to look at the Asobo documentation and web resources for a full understanding if all the variable types and what they are used for. John

Different aircraft can use different controls - you need to see which controls work for each particular aircraft and use that control. To see what an aircraft uses for a particular control/action, activate appropriate logging in FSUIPC, open the logging console and activate the control in the UI. You will then (hopefully) see what control the aircraft is using, and then can assign to that. But your question is too general. If you let me know a specific aircraft and function (axis/button) that you wish to assign, let me know and I can take a look. There is no way I can provide any information on assignments without knowing which aircraft you are using. Also, if assigning in FSUIPC, best to start with an empty profile for your controller/device in MSFS. And your general [Axis] section in your FSUIPC7 has some strange entries: 0=AY,256,F,65694,65695,65696,0 -{ TO SIM: ELEVATOR_SET, AILERON_SET, RUDDER_SET }- Do you really want yout elevator, aileron and rudder all activating on one axis? I would delete this line. 3=AV,256,F,1,0,0,0 -{ TO SIM: Custom control: <1> }- Not sure what this is - I would remove this. Maybe many aircraft don't "work" as you don't have your main axes set-ip in your general [Axis] section, and your profile aircraft names are full names and not substrings, so will not catch all variants. So, i would recommend: - removing those entries mentioned above from your FSUIPC7.ini file - assign all your main axes for the general axis profile (i.e. no profile) - update your profiles to use substrings. To do this, change: to And to It is a good idea to manually adjust the aircraft names used in profiles to use substrings to catch all variants. John

Ok. Note that there is also an FSUIPC Pause Control (1152)which can also be used to achieve this, in overloaded assignments or compound macros, if/when needed. John

The easiest way to do this is to use the Adding Lvars to Offsets functionality, which may be easier to understand. A full example is given on how to do this in the Advanced User guide, P43. Can you please read the whole section on using the FSUIPC WASM module to get a basic understanding on how to use lvars/hvars, then just try it out. There are also many support requests where I have explained things in more detail, so please check previous support cases if you have any issues, e.g. It is the index number for internal reference. If using mactos, then assign to that macro - it will be listed as: YourMacroFilename: L:A32NX_OVHD_APU_MASTER_SW_PB_IS_ON Toggle I just don't have time for this, but there is already an abundance of information on using FSUIPC macros - they have been around for many many years. If you find using macros complicated, just use the lvars-to-offfsets functionality instead. The example given in the Advanced user guide should be easy enough to follow. Just make sure that the offset control used matches the type of the value you are storing, don't overlap offsets, and make sure that they are boundary aligned (all explained in the Advanced User Guide). John

As far as I am aware, hvars have no associated value and are basically JS / HTML events, and should probably be called H:Events (I have seen this term also used). The FSUIPC WASM just uses the H:varName to execute the calculator code: (>H:varName) I have seen examples where an actual value has been set. However, I don't thing this is an associated value to the hvar, but more like a parameter to an event. There is no way that I know of to actually read the value of a hvar. If needed, I could allow a parameter to set on a hvar, but up to now I have not seen a need and no one has requested such a feature. This can currently be achieved by using the ipc.execCalcCode(“code”) function, if needed. Thats strange - I can only assume that you made the call too soon. Hvars won't be available until a number of seconds AFTER the aircraft has loaded, defined by the LvarScanDelay parameter, which has a default value of 5. However, I recommend increasing this to around 45 if using complex aircraft, such as the FBW A320. If you check your FSUIPC7.log, you should see when the lvars/hvars are available and if you made the request too soon. I can think of no other cause of such behaviour. No problem.

Not sure why you are getting that value, but I found an issue which is corrected in the attached version (still not tested though!)FSUIPC7.exe:

Hmm, strange. I presume that hvar exists....I will take a look - tomorrow now.

They are not lvars. You have created macros that send the control '2999'. Did you read the manual? This is the relevant section: Why do you think that would work? PLEASE read the documentation. To toggle (i.e. change from 1->0 or 0->1), ytu: 1=L:A32NX_OVHD_APU_MASTER_SW_PB_IS_ON=Toggle I don't know where you are seeing this. You are confusing offsets with controls. If you want to add the lvar to an offset, then that is a different way to access lvars which is also explained, with an example, in the Advanced User guide. John