John Dowson

This has been corrected in v0.4. Please download and try again. I have tried various configurations and aircraft, switching aircraft, etc, and can't get it to crash or otherwise mis-behave, so please report any issue and also always attach both the WASM log + the client log (if using). Also, please change the log level (via the ini files) to Debug before generating your log file. Also, if you have modified the StartEventNo then please let me know what you are using, and also if you are controlling lvar updates via rhe client or WASM (i.e. if you have changed the LvarUpdateFrequency in either client or WASM). And let me know what aircraft you are using (including the mod provider + version if applicable). Thanks, John

Ok, but that doesn't help me investigate this issue for you. I have tried here and it is generally ok, although I have noticed a minor issue that needs addressing - you need to issue a reload to get the initial data. I'll look into this. But to look into why this isn't working for you, I need to see you log files (and also each time you report an issue).

I asked about this on VoiceAttack and this is there response: I still don't know if this is a general issue or in VR only. I'll check without VR when I get a chance. John

So its just the loss of the displays? With a default ini, FSUIPC is doing much. However, I think it may still load the PMDG offset area - you could try with a default ini, but then change the PMDG737offsets ini parameter to No to prevent the PMDG offset area being populated. This sounds like a separate issue for which you have provided no details. If this is also a problem, you need to raise a separate support request and explain what the issue is and attach any relevant files (i.e. you ini and a log file produced showing your issue). Have you tried rolling back to the previous PMDG release (if possible) to see if the issue goes away? Or have you tried without the Honeycomb configuration program ? If assigning in FSUIPC we recommend to to use any additional device drivers or custom software as this can cause issues (but usually as jittery axes). When was the latest PMDG release? If the SDK has changed (which it does quite often) then there could possibly be an issue with the PMDG offset area, but the ini parameter change I mentioned earlier will prevent this from being loaded.

Again those files show that it was MSFS that crashed, not FSUIPC7. And extras logging doesn't look like it was enabled - are you sure you did this? To confirm that it is MSFS that is crashing, you could try starting FSUIPC7 before MSFS. This will generate an error from MSFS when it tries to start fsuipc7, but you can safely ignore that. If you do, you will see that its MSFS that is crashing, not FSUIPC7. However, the ini is still not correct - I will look into this. As well as doing the above, please change the following values in your ini: TrafficStallTime=-2 InitialStallTime=150 NormalStallTime=-2 Also, I think you should also try without FSUIPC running (temporarily uninstall) to see if FSUIPC is involved. John

You can assign without MSFS running, although better to have it running (I think a warning is displayed if not running). Its the calibration thats a problem without MSFS running, but this should also be ok if assigned 'Direct to FSUIPC Calibration'. But we always recommend doing this with the FS running. @Stevan Could you unplug your device, reboot your PC, reconnect and try again. If you get the same issue, please attach your JoyScan.csv file, as well as you ini and log files, all located in your FSUIPC installation folder. Thanks, John

Ok, thanks - but please delete your ini first, or at least the [General] section contents....

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