John Dowson

I have released a beta version of FSUIPC6 with native support for HID joystick type devices with up to 128 buttons. Please see Please use this topic to report any issues. John

You can do that using regedit. However, if they are not causing issues, you can leave them. As you are using JoyLetters, the correct entries should be used. If you still want to remove them, then make sure you back up the registry first (you can do this from regedit). Then, disconnect the two devices that have duplicate entries, then delete all registry entries with matching product and vendor ids for thos devices, reboot and then re-connect you devices. If you still want to do this, if you show me your latest JoyScan.csv file I can provide you with a regedit file that you can use to remove the entries.

No, sorry. I'm not that familiar with c#. To use the API in c#, you would need to rebuild the API as a dll project (rather than a static library), and the public functions would need to be exported. You could then call them using P/Invoke, or write a managed wrapper facade. I could re-build as a dynamic library project at some stage if someone wants to look into this.

Ok, yes that is an issue. I will correct this - I will use new though, rather than a global buffer. It doesn't matter if the allocated memory for this isn't released. No problem leaving it as it is for me, although I'll add a comment as to why I did that change, for future reference - otherwise I may reverse it! Yes, although I don't get that warning on my compiler. I'm a but lazy and tend to ignore those type of warnings anyway when I know the implicit cast won't be an issue...the number of lvars certainly will never exceed the max value held by an int! Probably a better fix is to change the printf code from '%03d' to '%03llu', I can do that... Thanks, John Later: I have made those changes and pushed to github if you would like to try.

In your original ini (i.e. not the default generated one)? If so, how strange....

Where are you looking? Its usual to assign to the Pan View control in the axis assignments tab as 'Send to FS as normal axis'. Did you try that? Its certainly there... Its also in the button assignment drop-down: That should be the first entry in the menu (unless using custom event files): John

First, you posted in the FAQ section, where it explicitly states NOT for support requests. I have moved your post, but please try to post in the correct forum for support. I see you have also posted in the User Contributions section for the Stream-Deck plugin, so I'll let your question be answered there. John

Yes. They reveal a few things. First, you have some registry issues with you X-56 Rhino Stick: This may nor be an issue, but if you are having issues best to resolve that to take it out of the equation....more on that later. You scanner and joyscan logs show that the stick has no axis: you scanner log shows: which is strange - one axis with a hex value - not sure why this is, but should show the axis letters if found, e.g. for your rudder: Are you running additional software for the X56? If so, please remove that and try again. Also, if you have installed any saitek drivers, uninstall those and let windows install the default drivers, and try again. I have just noticed the images in your original post - those are not from the windows game controller panel (or not that I recognise). Please try to see if your axis is recognised by the windows game controller application. If those images are from some sort of saitek config program, you need to remove that.

You have too much going on in that test. Please try wit the default ini but with the PMDG737offsets ini parameter set to No. This will tell us if your problem exists when FSUIPC is installed but doing nothing (except populating its offset area). Also, did you try without the Honeycomb config tool? You could also try logging offset 0x3224 (altimeter reading) to see if that is correct, although I don't know what value is driving this in your displays. I don't have the PMDG aircraft, so I cannot test this here. Ok, I'm not sure we have updated to that. However, we only update when the headers have changed and someone has had an issue and asked us to look into it... The last update we did for the PMDG areas was for the PMDG 747 and the 737 NGXu around 20th April last year. What is this? Is this related? What are you doing with that source file?

Ok. Try with FSUIPC6 first. I will release this in the next day or two. Would also be good to know if the >32 button lua worked for you in FSUIPC6. I would presume not, with the lua interface + script being the same....

Ok. I was planning on releasing this first in FSUIPC6. Do you have or use that (i.e. with P3Dv4 or v5)? If not, its not an issue. I can make a provate release of this with FSUIPC7 for you to try (i.e. before I release as a beta).

i am not sure why you are showing us documentation from another product... As Pete has said, they look like control numbers, and not offsets. I don't know what they mean by 'must be sent to the simulator as a normal axis' though. You can see if thats the case by assigning a button or key (in FSUIPC) to the <custom Control> menu item (in the FSUIPC assignments dialog, giving the control number that you want to use. Why don't you first try this to see if they work? Then, of you want to send them from your vb.net application, which is presumably an FSUIPC client (otherwise why ask here!), you can use the general control offset at 0x3110. I see Pete has also replied....

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.