John Dowson

Ok, thanks - but did MSFS also crash? Any events for that? And the FSUIPC7 log file you attached shows that FSUIPC7 didn't crash - it exited normally due to MSFS no longer being available (after around 51minutes). So, I'm still confused as to if its FSUIPC7 that is crashing or MSFS. Maybe because the logs were generated at a different time? You are also using an unregistered version so FSUIPC isn't doing much.... First, please delete the contents of your [General] section and let that get rebuilt. This will change some of your default settings which are out-of-date. Otherwise just delete it completely and a new one will be created. Also, please activate 'Extras' logging, and keep that activated. And next time it crashes, show me your FSUIPC7.log and FSUIPC7.ini files again please, together with the event log information. Thanks, John

FSUIPC7 is a separate application and should not cause MSFS to crash. If MSFS is crashing, then you need to report to Asobo. But, is MSFS also crashing? I don't know AppCrashView, but for crashes you should first check the windows event log and see if there are any errors there, and if so show me them. I also need to see your FSUIPC7.log file as well as your FSUIPC7.ini file. If MSFS IS crashing, as well as FSUIPC7, then this is usually due to a simconnect issue. You can activate simconnect logging (see FAQ section on how to do this). The log file will be very large. You don't need to do anything with it unless you get a crash, but when you do you should check that file for any errors, and also for client open and close connections (as sometimes such issues are caused by simconnect running out of client connections). Thanks, John

I've tried this and its not really a possibility, as FSUIPC is usually in the system tray (no main window displayed), this also hides any sub-windows. There was also an update issue (slow refresh rate) which was strange, but not worth looking into as I can't make this a sub-window of FSUIPC as indicated. It is not FSUIPC that is changing focus to the Wnd display window. I think you should raise an issue with VoiceAttack, letting them know of the problem. They must be setting the focus back to the FS, but are setting it to the Wnd sub-window instead of the main window. See if they can fix this to give focus back to the main FS window instead. Otherwise, I could look into forwarding events from the sub-window to the FS window, but I think the correct solution would be for VoiceAttack to send the commands to the correct FS window in the first place. John

The log isn't showing anything for button 34. It looks like buttons with numbers > 31 are just not being registered. I don't know why this is happening. You could try the FSUIPC version that supports up to 128 buttons (when ready), but I'm not sure this would help. It would be good if you could try another Bravo to see if its an issue with your device (as other Bravo users don't have this issue), but that may be tricky.... Sorry, not sure what to advise next, except to wait and try the 128 button update.

Me neither....but its done now. Do you want me to remove? Ok, no issues changing this so thats also done. Ok, I'll take a look to see whats happening here. Yes - instructions were posted in the Asobo forums on how to find hvars using the dev console, but I can't seem to find that anymore. I think SPAD.next comes with some scripts that you can run to discover hvars. I've been meaning to look at this for a while, but not sure if I have access to it at the moment (I have Spad.next but no current support license). If anyone else has access, it would be good to use that to get some initial hvar scripts for the default aircraft. I've update the github repos with those changes, but I won't be making a new release for the time being. John

But they are not FSUIPC offsets, as FSUIPC offsets are only up to 0xFFFF, as Pete has said. I think you need to go back to Milviz to clarify.

Sorry, that was wrong! The lvar values CDA is sized to hold the maximum number of lvars that the name CDAs can hold (now 876), up to a maximum of 1024 values. It does this (rather than creating sized to the actual number of lvars) so that it can be re-used with different aircraft, rather than have to be re-created each time with a different size.

Yes, that has a lot more lvars than the stable.... I've now corrected the handling of lvars so it should now load the maximum available for the configured space (was 584) and ignore the rest. I have also allowed for two more client data areas to pass across the names, so the current config will support up to 876 lvars). There was also a problem with the buffer used to display lvar values in the client, which has also been corrected. The github repos have been updated, and I have released the WASM + API + Client as v0.3. Please let me know if you have any further issues. John

Not directly, no. They are supported using lua. But you can use FSUIPC with Spad.next, via assigning to FSUIPC virtual buttons in SPAD.next, and then assigning your control to the virtual button in FSUIPC. Linda has been available for quite a while for MSFS/FSUIPC7, as far as I am aware... John

Hi Yves, ok - I haven't tried with the FBW WASM for a while, I'll do that now and report back. However, a quick look at your logs reveals that there are a lot of lvars - 598 in total. Which of the FBW A320 mods are you using? The issue is most probably that the lvar limit (for the values area) is exceeded, as this is currently sized for a maximum of 512 lvars,. Also, only 4 CDAs are currently configured for lvar names, allowing for a maximum of 585 lvars (with a current max lvar/hvar name size of 56 characters). Of course, if more are found then this should be handled gracefully, loading the maximum allowed and ignoring the rest. I thought that is how I implemented, but it looks like there is a problem somewhere (this is untested until now!). So, I'll revise this and get back to you. I'll first make sure that the WASM module handles this correctly, then I'll increase the maximum number of lvars allowed. Thanks for the report, John

In needs yo be built as Multibyte in VS, so use ANSI. Corrected. Strange I don't get any compiler errors (or even warnings) for those... Yes, that should be supported. However, as it works with a long long or an int in VS, I can add a cast there for you. Not sure why thats not working, Thats the code to get the timestamp for the logger messages. You can pass in your own logging function that will ommit this. I\ll take a look at some point to make it more portable (maybe switch to using a tick count instead, its not really that important what timestamp there is, as long as there is one!). No result is returned when executing calculator code. I'm not sure if I'll keep that function. Its in the beta release as it provides an easy way to test for hvars , before you add them to a *.hvar file. So, to activate a hvar, e.g. A320_Neo_CDU_MODE_SELECTED_SPEED in the A320Nei, then enter calculator code: (>H:A320_Neo_CDU_MODE_SELECTED_SPEED) Yes, I just tried a debug build and get the same. Even worse, when running in the debugger it cannot open a simconnect connection. Not sure why this is at the moment, and don't really have time to look into this now, but I've made a note and will take a look when I can. I've pushed the corrections to the FSUIPC_WAPI github project (but haven't made a release for this yet). John

Is there still a p3d process running, or has it crashed? And this happened when using P3D, nit FSUIPC (ie. when flying not in the FSUIPC dialog)? You must at least have am FSUIPC6.log - can you attach that? Also your ini. Ok, so this only occurs when you add a new aircraft to an existing profile (using the UI), and then start a flight? And this same thing happened in previous versions (i.e. not new to 6.0.13)?

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