John Dowson

The release notes for the latest version inclkude an SDK update Load and Save Flight using the FlowFlightManager.However, the SDK SimConnected documentation for the load/save flight functions still has these documented as 'Partial works' and 'No errors, no response'., so its not clear. Pete reported he has had success loading an auto-save (or previous) flight, so it might be worth trying. I'll also take a look at some point, but I haven't had time up till now, sorry.

Not directly. FSUIPC only recognises and joystick type devices in the assignments panels. You can use lua, to access them, and I believe there are various scripts available that do this, although (some) may also use Linda. Try searching for these. Otherwise Spad or Spad.next are the utilities to use, and can integrate with FSUIPC, i.e. you can assign in spad/spad.next to a virtual button and then assign to the virtual button in fsuipc.

This has been available for a while, using the Com Radio Set Hz (+ equivalent for COM2 and COM3 + standby), and also via offsets 0x05C4, 0x05C8, 0x05CC & 0x05D0. There are also offsets 0x0B47 and 0x0B48 for the com1/2 spacing mode.

This has been reported several times now. It will be due to a corrupt EXE.xml file. this is usually caused by another add-on corrupting the file. You can either run the installer an uncheck the auto-start component, or delete the existing EXE.xml file and then re-run the installer. Further details on this issue can be found here: and also here: John

You have to start the lua. Either add it an [Auto[ section thus: [Auto] 1=Lua AllTExts (or just add a new entry for this script if you already have an [Auto] section) Alternatively, you can run the lua script on a button or key press via assigning in the usual way.

Looks like there is something wring with your install. Should look like the following (see PRESET MANAGER option at the bottom): I can't really support MSFS issues. You can try MSFS/Asobo support, but if I were you I would do a complete uninstall and re-install. John

Yes, possibly... The problem is that the partial path is partial from a folder whose name is not known and, as far as I know, not possible to derive. I did look at trying to convert partial paths to full paths, but gave up in the end as the information needed wasn't available (easily!). But I guess it depends on how or what you are doing with this.... John

Ok, thanks. I'll take a look on Monday. However, it would be a lot easier to interpret if you could tell me what you actually did....! Could you generate the same log again, but write down what buttons you are trying. Try one that works first (i.e. with a button number < 32), then one that doesn't work (>32), followed by another one that does (so, only three button presses on the bravo). Then post the log again with the description (or just add the description to the log already posted). Thanks.

This is a know issue. It was documented in previous versions of the SDK documentation as to when a full path is given and when a partial path is given, but just checked in the latest documentation and couldn't find it (although its obviously the same - may be there somewhere....). I think, if I remember correctly, it depends on if the plane in question is a default (i.e. in all versions) or a protected (in deluxe and other versions, or an add-on), but not sure.... May also depend on when the event is sent... But, FSUIPC is just showing what MSFS is supplying, so there's not much I can do, sorry. John

Sorry, I have no idea. What has this got to do with FSUIPC? Is FliteMap an FSUIPC-related application? If so, it should work (but maybe needs updating for FSUIPC7, I don't know!). Sounds more like a question for FliteMap support. Or, if its an application using the FSUIPC offsets (i.e. doesn't require an FSUIPC license), then just download and try it. If it does need an FSUIPC license, there is a time-limited one available for you to try (on another support topic with a relevant name if you want to try it). John

Yes please - provide me with details and I will check. There are various warnings I need to address, but there should be no compilation errors.... That is strange - I will check that here....next week... Lvars, as far as my understanding goes, are always 8bytes/64bits, even if they are only actually used as booleans or ints. When you get the value, it just returns this as a double, and you can interpret as you like. When setting, I have provided overloaded functions so that its more user-friendly. If you use the function that excepts a string (recommended), then this will interpret the string value and cast to the correct actual type (either short, unsigned short, double or char*). Also, in the current implementation, the setting of lvars goes via different paths - for short values, I encode in an event parameter and use an event, for anything bigger, a CDA (Client Data Area) is used to pass the value (up to 8bytes). I could easily provide more get functions if useful, e.g. getLvarAsInt(_). getLvarAsString(), etc. Of course, they would be distinct functions (rather than being overloaded) as the parameters would be the same, just the return type different. Also, very easy to add yourself if thats what you want to use.... Thanks for the report. Glad to hear someone has actually tried it, an is even implementing there own application with the API. Please let me know of any issues with building and compiling these. I use Visual Studio, so I'm afraid that the repos are tied to the IDE. I am relatively new to VS, and have previously been used to providing IDE-independent repositories (previous to this, I have always been a unix/linix developer using eclipse/netbeans or IntelliJ....). The v0.1 release was also a bit of a mess in this respect, but hopefully a bit clearer in v.0.2. I am open to suggestions to make this more user-friendly, especially in order to use/include the API in your own projects, so any advise on how I can do this is much appreciated. Regards, John

Hi Ramon, the xml created by the latest FSUIPC6 & 7 installers do create the xml without spacing or line breaks. Unfortunately I can't get around this at the moment with the tool I am using (its a NSIS xml plugin). I have been meaning to write my own plugin to get around this, but as its very low priority I haven't had time to look into this, and probably won't for quite a while! I could, however, verify the integrity of any existing EXE.xml file before updating. I'll look into this when I get a chance. But I think for the time being I will create a FAQ entry for EXE.xml problems as its seems to be a relatively common problem. Regards, John

v0.2 has been released. Both the WASM module and API/Client have been updated to use the default local simconnect connection by default (-1, was 0), and allow for a different connection to be used via a new ini parameter UseSimConnection, The WASMClient code has also been re-organised to make it clearer what is the code from the client and what is imported from the WAPI module. Available: FSUIPC-WASMv0.2.zip John

The FSUIPC 7 installer only creates the <SimBase.Document>..</SimBase.Document> element if there is no EXE.xml and it crates a new one. Otherwise it will just add a <Launch.Addon> element. The original EXEold.xml is completely screwed-up - two Simbase.Document elements (for FSUIPC), the logitech launch.addon element outside of a Simbase.Document element, and the extra closing simbase.document element. The newer one you posted is nearly as bad, but with just one Simbase.Document. Ramon's suggested change will work, but I would like to understand how your EXE.xml is getting in such of a mess....check its not being changed again after you update and run MSFS.

Ok, thanks. Thats quite a screwed-up ini! It looks like it was also updated to start a plugin from Logitech (for saitek panels). If you want that to run automatically, you can add back in the <Launch.Addon> section for that. Make sure its within the SimBase.Document element.

Ok, thanks - good to know. (I edited your post to link to the reference)

No problem. As you have a steam install, could you attach your current EXE.xml file please - this will be what is causing the issue, but I don't know why (if still available). If I can duplicate here with you EXE.xml I can update the installer to handle this more gracefully. Thanks.

No worries, happens to us all...! Glad its now working, but I'm a bit mystified why I needed to make this change...the fix was to add some code back that was removed in a previous version. However, if it was previously working, I don't understand how... Probably to do with MSFS updates - and I may have hacked-it to work via other means which no longer apply. I'll check when I get a chance. John

But its a BCD field - i.e. binary encoded. So, to set as, for example, 0100, write as 0x0100. When you write that as 0100, thats 0x256, so will display 256, etc. Sorry, if thats not clear from the documentation, I will update - I'll check tomorrow....late here and time for a beer...!

Ok, thanks for the update. I'll check that here with VoiceAttack when I get a chance, but it will be without VR. However, looks to be more of a problem with VoiceAttack changing the focus, not FSUIPC. FSUIPC will not be doing this (I think, but need to check!). Btw, have you tried VoiceAttack support? I will look into this further. I think the lua wnd windows are created as sub-windows of the FS, but need to check. I could maybe change them to be FSUIPC sub-windows, or make this an option. I'll take a look in more detail now and get back to you - but sometime next week, when i have time. John

I cannot advise on this as I don't have any PMDG aircraft. If those functions aren't supported by standard FS controls, then you will need to look at the PMDG SDK to see if those operations are supported. PMDG provide both custom controls and data supplied to an offset area (read-only). Check the SDK documentation to see if supported, or maybe other PMDG users can help.... John Later: otherwise check available lvars or try mouse macros

After you have installed the official version of FSUIPC6, replace the FSUIPC6.dll with the attach version please. This has some corrections for when TimeToSelect is set to 0.. Thanks. FSUIPC6.dll

Just seen this over on the Asobo forums - someone has this working using AA0 + Spad.Next, so should also be possible via FSUIPC once hvar access is implemented: https://forums.flightsimulator.com/t/working-title-cj4-v0-9-1-released/348072/145?u=impolitegem5317

The script is the HidDemo.lua one. If you want to recognise buttons > 32 for the Honeycomb Alpha or Bravo, there are dedicated scripts for those devices in the FAQ section. If it is for a different device but only to recognise buttons > 32, you can take one of those scripts and adapt it to your device (by changing the Vendor and Product ids, as you also need to if using the HidDemo.lua). John

When vjoy with FSUIPC it will still hit the 32 button limit, but you can use multiple vjoys for more buttons. I did think you could map real buttons to virtual buttons using vjoy, but I may be mistaken (I think I didi this a few years ago but my memory could be mistaken....!). We are working on adding native support for up to 128 buttons for FSUIPC (6 & 7). I will be releasing a beta version of FSUIPC6 with this functionality shortly. I could also build a version if FSUIPC7 with this update for you to try, but that will be sometime next week.