John Dowson

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.

Strange - just took a look (in the C152) and I can read ok but not update, same as for @ark1320. I have corrected the writing to 0x0354 in the attached version (v7.0.7c) if you can both try. FSUIPC7.exe

Here it is: HidTest.lua Run that lua (via [Auto] or in a button/key press), press some of the switches on your Bravo, those with numbers < 32 and then those above, then attach you log. Maybe also try with the attached version of FSUIPC7 (v7.0.7b). In this, I've corrected when [Auto] luas are started (i.e. when a flight is loaded rather than in the main menu). John FSUIPC7.exe

Yes, sorry. I've corrected a few things in the attached version if you could try that. Ok. But could you just try the attached version please to see if your window is now displayed at the correct time. Also, if you could let me know if, once started, it is still affecting VoiceAttack, that would be good. Thanks, John FSUIPC7.exe

No, not at the moment. Did you not read the Announcement?

Yes, but it is not yet integrated into FSUIPC7 (i.e. FSUIPC7 can't use it yet) - this is the next stage. If there are no standard controls/events (did you try logging to see what, if any, events are produced?) then you will have to wait to see if there are any lvars or hvars for this. You can check for these now if you like, but you won't be able to use them until I have updated FSUIPC7 for lvar/hvar access.

Can you try the following version please, v7.0.7a. In this version, luas won't be started until a flight loads, and will be killed when going back to the main menu. There is a slight issue in that luas are initially started, then killed, then restarted. This is due to the events being received from MSFS being a bit of a mess, but I'll take a look in more detail tomorrow to see if I can prevent this. It should be ok to check for you issue though. Thanks. FSUIPC7.exe