John Dowson

Log file looks ok and just shows its working in the DHC2. I thought your issue was with the T-28, but you dom'y seem to be providing any of the requested logs for this, or reporting on the other controls I have asked you to try. Btw. you should consider using aircraft substrings for your profile sections rather than the full aircraft name, with livery. Then you won't have to continually have to add your aircraft to a profile if not previously used. For example, you could change: to You also have "DHC2 Beaver N1117F Straight Floats" in your "Single Engine Amphib" profile (as well as your "MilViz DHC2" profile) which you probably want to remove. However, if you do use different profiles for different variants (which seems strange to me!), then you may need to use the full aircraft name, but using substrings is far easier. See the documentation for details in profile substring matching. John

You can only have one parameter to events with FSUIPC. The events with 2 parameters were recently introduced (in the simconnect SDK) and I have not looked into making these available with FSUIPC yet - and am not sure if I will do this at the moment. This may be possible using calculator code - although I am also not sure on how to set two parameters for an event with calc. code either. However, the MF preset for the pedestal lights in the C172 classic uses the following calculator code: @ 655.35 / 0 max 100 min (>K:LIGHT_POTENTIOMETER_6_SET) So this takes an axis value parameter, converts that to a percentage (between 0 and 100) and then uses the LIGHT_POTENTIOMETER_6_SET event. So you could try just using that control instead, i.e. ipc.control(66910, x) where x is the percentage. The glareshield is similar - that uses LIGHT_POTENTIOMETER_5_SET which is ipc.control(66909, x). John

Of course - that just means that its a 64-bit application, not a 32-bit one (x86). This is not related to the frameworks you are using. The .Net framework is usually used with C# (or maybe VB). I think it can ve used with C++ but I don't know anything about this. You should decide if you want to use .Net or not, and if so which other .Net framework you want to use for the GUI. Otherwise, just start with the Win32 API without ,Net. Yes - the ability to read and write to lvars using simconnect was recently added to the SDK, and works in the same way as you would read and write/update a simvar. But I have not used simconnect for lvars yet, as I implemented the WASM to be able to do this before this was made possible via SimConnect. Sorry, but this is not the place for simconnect programming or support, or basic windows GUI programming. There are many other resources available for this. I only have time to support the products I provide. John

There was a similar request for support for a MIDI output device called Loopedeck: Someone developed an application so that this can be used with FSUIPC. Maybe that can be adapted for the X-Touch mini? I have no plans to add direct support for such devices in FSUIPC. I don't know much about midi-output devices, and how they interact with the low-level windows HID interface, which is what FSUIPC uses for controllers. John

You have to decide which UI framework you want to use. You seem to have chosen WinForms, which is a .Net framework. I have never used .Net or any of its associated frameworks, so cannot really help you. Try google or StackOverflow to get you started on windows GUI programming, and try and get a basic (non-functional) GUI running first. You can then add the WAPI once you have an understanding of the GUI framework you are using, and then a simconnect connection if you also want to use that. The WASMClient just uses the old/original Win32 API with no additional framework layers, as does FSUIPC. John

The UninstallFSUIPC7.log file should tell you which version was uninstalled when you install a later version. Are these lua files running on the clients or server PC? I would like to see the FSUIPC7.log and FSUIPC7.ini files for when this is working and also when not working in the latest version, as well as the lua files. For now, jut set logging for Events and, if the lua plugins are running on the server also logging for Lua Plugins, otherwise set logging for IPC Writes. If the luas are running on the client PC, I will need to see the WideClient.log and WideClient.ini files. I don't think there is any lua plugin logging on WideClient - I may need to add some offset logging to WideClient, but I will need to see the files first to see what, if any, additional logging is required.

MSFS probably crashed before it even started FSUIPC7. That just shows that FSUIPC7 exited as MSFS was no longer available, i.e. had crashed. I can't really help with MSFS CTD issues - try the Asobo forums. You could try removing everything from your Community folder to see if MSFS starts ok then, and then add the Community folders back one-by-one to see if any of them are causing this issue. I have had similar issues with MSFS on several occasions, but each time they seem to resolve themself as I am investigating... Sorry I can't be of more help. John

No, only the latest version is ever provided and supported. What about the versions between 7.3.11 and 7.3.19? e.g. was it working in 7.3.12? Knowing the first version in which this stopped working would help narrow down the problem. Can you please provided more details on the actual issue - how are the external lights controlled? And please also attach a FSUIPC7.ini file and a FSUIPC7.log file generated with appropriate logging enabled (i.e. Buttons & Keys and Events). Please also review either the changes.txt file or the History document, which detail the changes between each version, to see if you can identify any possible changes that could cause this issue. If this proves difficult to track down, I may provide some early versions for you to test to try and track down the issue, but I don't like providing an earlier version because something has broken - it must be fixed in the latest version and the patch/update released in the next version. John

The 737 panel brightness presets use the PMDG SDK custom controls via the Rotor Brake control - and there are several of these. Can you let me know the exact names of the presets you are using please? You can use the right hand side in the axis assignment panel to send the inc/dec presets when you enter axis ranges, with up to 10 ranges, so you could set 5 ranges for inc, and 5 for dec, with the control/preset being sent on repeat in the outer ranges. That may work ok - so please try that first. It may also be possible to set this up as a proper axis by assigning the dial to an FSUIPC offset, and then having a lua script monitor that offset and send a custom control (instead of a Rotor Brake mouse control), but I am not 100% sure on this. If you let me know what presets you are currently using for the panel brightness inc/dec, I will see what offsets this changes, get the max/min values and see if I can create a lua script that then calibrates the axis offset value to this range and sends the custom control to change it. I won't have time to look into this for at least a couple of days though... John

Ok, thanks for the update. Please also note that you should consult the documentation for such issues before posting, if you didn't already, as 99.9% of registration issues are covered in the installation and registration guide. John

That does sound strange! Do you know what offsets the ATC map is using - possibly 0x0560 (Plane Latitude) and 0x0568 (Plane Longitude) or 0x6010 (GPS Position Lat) and 0x6018 (GPS Position Lon)? Whichever offsets it is using, try logging those offset using FSUIPC7's offset logging feature, and see how they change both with and without Spad.Next runnning. If Spad.Next is changing those for some reason, you will have to ask Spad.Next support about this - I don't think there is anything i can do if something else is changing the sim variables used... John

No - that section is automatically generated by FSUIPC, and should not be touched unless assigning your own "joyletters" What type of device is this X-Touch Mini controller? FSUIPC should recognise all HID joystick type devices. If its a HID / USB device but no a joystick type device. you will have to use lua. There is a demo script provided called HidDemo.lua which you can adapt and try. If its an XINPUT type device (as opposed to DirectInput) then you need to download and install a conversion utility called XInput Plus, available from https://www.play-old-pc-games.com/compatibility-tools/xinput-plus-tutorial/. With XINPUT devices, FSUIPC will only detect button presses when it has the focus.

You seem to be using the .Net framework. I have no experience with this and cannot help you with .Net. Also, if using .Net, you should use the dll instead of the lib. or Paul Henty;s client dll for .Net which includes a wrapper for the WAPI - see

You just add the header files to your project, and include the WASMIF.h file in the source files where you want to use the WAPI, and specify the WAPI include folder (as well as maybe the SimConnect one, if you are planning to use that) under the C/C++ Additional Incude Directories. Also add the FSUIPC_WAPI.lib to your project. Then you need to set the VC++ Directories -> Library Directories to add locations for both the WAPI and SimConnect libraries, and then add the following libraries to the Linker -> Input -> Additional Dependencies: FSUIPC_WAPI.lib;SimConnect.lib;Ws2_32.lib;Shlwapi.lib (and debug versions for the debug configuration. Take a look how the build for the WASMClient is set-up and try and follow that. I haven't got time to clone/download and look at your project, or to help with building standard apps, but if you can explain what your problem actually is maybe I can point you in the right direction:

As I said, the next available id is just allocated on lvar creation. so an lvar could have a different id in a subsequent run of MSFS, but it will not change in the same session, even if you switch aircraft and back again. This is actually a bit of a pain as it means that lvars are never cleared and so the number of available lvars is always increasing, even though many are of no use as they are for previous aircraft loaded. John

Ok, so the rocker is an actual axis - interesting. Ok, good. For the T-28? Did you try with the Rudder Trim Left and Rudder Trim Right controls? Ok - will take a look at them tomorrow - finishing now...cheers, John

Yes. You can use either, but using the id is better/faster. The methods that accept an lvar name are provided for convenience - they will just get the id for that name and then call the method that uses the id. It is permanent for the duration of the MSFS session, i.e. until it exits. Lvars are never dropped, so every aircraft loaded will create more lvars. Due to this, not all lvars that are available are actually in-use, and there is no way to determine which are in-use. The id is assigned to an lvar when created, so the id order is the creation order of the lvars. The ids should be hidden from users as they are not really relevant. However, I include them in the WASMClient (and in the FSUIPC log) as they were/are useful to me when tracking down issues. Really they should be hidden from end-users. The id is assigned when the lvar is created, so it is a sequence in lvar creation order. If you are interested in specific lvars, you should get the id of those lvars from the names and then use the id. You can also flag those lvars for callback in your registerUpdateCallback using flagLvarForUpdateCallback. Cheers, John

Probably better to ask here... The WAPI should be relatively straightforward to use: 1. First get an instance: WASMIF* WasmPtr = WASMIF::getInstance(); (you can also pass in a pointer to a logging function if you like, otherwise the WAPI will create and use its own log file). 2. Set any config options required, using, for example, to set the log level to DEBUG, use: WasmPtr->setLogLevel(LOG_LEVEL_DEBUG); Other config functions: WasmPtr->setSimConfigConnection(connectionNo); // to set the SimConnect connection number - only needed in certain circumstances, e.g. running on a client PC WasmPtr->setLvarUpdateFrequency(freq); // sets the frequency for the WAPI to request lcar updates/values. Recommended NOT to use this, and configure frequency in the WASM WasmPtr->registerUpdateCallback(availableCallbackFunction); // register a function to be called when lvars are loaded/reloaded and available for use. Recommended to USE this function WasmPtr->registerLvarUpdateCallback(lvarCallbackFunction); // register a function to be called when lvar values change. You also ned to flag lvars for this callback 3. Start the WAPI: WasmPtr->start(); Once started, you can use the other functions to get/set/list lvars and hvars once they are available, which is indicated by the ca;;back to the function registered with the registerUpdateCallback method. If you have registered an lvarUpdateCallback, you should also flag the lvars for callback with the registerLvarUpdateCallback method in the registerUpdateCallback method. 4. Close/terminate the session: WasmPtr->end(); // Terminate the WASM connection Thats it really... Note that you shouldn't need to use the reload method any more as this is now done automatically (by the WASM), but can still be used.

It isn't a valid Win32 application. Its an API, and builds the FSUIPC_WAPI.lib. You cannot run it - has no main. If you want an application that uses it, that is what the WASMClient is, also available on github. Btw, I will move your post to the FSUIPC7 support forum, as the FSUIPC WAPI is only valid for MSFS / FSUIPC7. x86 is 32-bit, x64 64-bit. You should build it as x64. You should be able to just built it (not run it!) with the VS solution file provided. John

You currently have to re-run the installer to register. It will uninstall first but you won't lose any settings - just click through to the registration page and enter your details there. You should check for updates and should be re-installing every 4-6 weeks or so, if you want to keep up-to-date. You can just edit the FSUIPC7.key file with the new details, but the registration won't be validated, so if you make a mistake then FSUIPC7 will run as an unregistered version, and you will have to try again. Note also that re-installing will install the current released version again (7.3.19), and you will have to replace the FSUIPC7.exe with the 7.3.20a (or 7.3.20b) version. John

Note you can also use FSUIPC7 on a client PC instead of WideClient, with no need for an additional license. This does not duplicate WideFS/WideClient functionality, but provides most functionality available in FSUIPC7. See the appendix in the Advanced User guide on how to set this up. John

You can, or you can use your own FSUIPC7 key with the details of the trial WideFS key (name, address, WideFS key) - just check the box for different WideFS registration details and copy the trial license details into the relevant fields. Cheers, John

👍Thanks for the update. Cheers, John

First check you are using the latest beta of FSUIPC7, 7.3.20a, posted above - this won't work in the current released version (7.3.19). You need to register the hot-keys being used - I'm not sure how this is done with PF3 - whether this is done automatically by PF3 or via a lua script or something else. Check the PF3 documentation or maybe @bobsk8could advise. John

I can see the rudder trim working in the Trojan T28D: But when the offset is changed with the MilViz DHC2 Beaver loaded there was no monitoring of the offset, and only the offset control is logged: It would be useful to see the offset monitoring with the MilViz DHC2 loaded, but I suspect that the simvar RUDDER TRIM PCT is not being used by that aircraft. You could try the axis control Rudder Trim Set, or the standard controls (i,.e, not axis controls) Rudder Trim Left and Rudder Trim Right in a specific profile for that aircraft. Still not sure how the rocker is controlling an axis, but you could just change the offset control you are sending in the ranges to use those left/right trim controls instead. Otherwise, remove the axis range controls completely and try assigning the rocker directly to the Rudder Trim Set axis control. John