John Dowson

I'm sorry you feel that way, but I cannot help if you do not provide me with the information I need. I really don't know what I said to upset you, I am only trying to help. There are obviously issues with your install. But you can still run and use FSUIPC. And download documentation for the time being. And we can sort out your installation issues, if you have the patience and provide me with the information I need to help you, and follow my advice. Please re-run the installer, but de-select the auto-start component and see if that works. And then send me your installation log, or tell me what the installer did. ...and let me know what install type you have - steam vs MS Store vs Boxed?

First thing tomorrow now....

You can get into issue using other peoples ini files if you don\t know what you are doing, i.e. an expert in the format and functionality of the various ini sections and how they are related. And the set-up of a throttle is very dependent on the aircraft you are using, which you don't even mention. There are also sections in the FSUIPC user manuals on how to set-up and calibrate devices for default aircraft. Have you tried following these? What FS and version of FSUIPC are you using? Do you really expect any help with such a general question and without any relevant information?

You are hijacking a topic not related to your issue, so I doubt you will get a response. If you think this is an FSUIPC issue, please create another topic, but also please supply more information and show us your files (log and ini to start with). But, as you issue seems more related to a specific add-on, so best to try the support forums for that aircraft first. John

Not 100% sure what you mean, but I'm happy when a user solves their own problem 🙂👍

Ok, thanks. It was just a test to see if they were actually registering somewhere else as a button press, which it seems they are. Yes, but the device is recognised (in the lua), but the issue is that it is not picking up the button state changes for some reason. There is also another current topic open for the exact same issue but for the Alpha. Presumably you can see the buttons < 32 and assign to them as usual, no? And Axes assignments are ok? The log file you attached is interesting. There is a discarded state change for each subsequent update, so it looks like it may have flagged momentarily and then rest, and the changes discarded. Maybe try increasing the poll rate to see if this is the case.

That's an FSUIPC7 log file which just tells me that you ran FSUIPC7 once (and was still running or had crashed when you pasted that log fragment). In the zip file you downloaded, as well as the installer there were two documents, a README.txt and and Installation and Registration pdf. Please read (or at least take a look) at those documents. Also, the install log file will be in the folder with those documents, where you extracted and ran the installer. Please check that. The install log is also copied to your FSUIPC7 installation folder. If its not there, I can only think that it is a permissions issue. However, as it can put other files there, this is very strange. Also, if you are installing in a windows protected folder, please try installing somewhere else. Or is 'C:\FSUIPC7\' your actual install location? If so, that is good and shouldn't cause issues. Also, when you run FSUIPC7, you do know that it sits in your system icon folder? If you run it and can't see anything, look there - or use the default hot-key (ALT + F) to show the FSUIPC main window. This is all explained in the documentation. If, for some reason the documentation hasn't been installed, download it from the download secrion of this forum (for the time being) and I'll check your installation log file once posted. John

One small thing...you don't need to, and shouldn't, edit or change the [LuaFiles] section in the FSUIPC ini file. This is auto-generated and managed by FSUIPC. You can get into issues if you manually change this section, so best not to. If you drop in a new lua, better to restart FSUIPC to get this added, or maybe one of the reload functions (from button/axes assignments dialog) will do this, not sure without checking.

All the things you need to try have already been said.... What have you tried? What is your install - MS Store or Steam? Have you checked you EXE.xml file? Did you actually select to auto-start FSUIPC7 with MSFS? Is your FSUIPC7 actually installed in that location? Where is your install log? I'm sorry, but there are so many posts on this now, and I am repeating the same thing again and again. Please try all the suggestions previously posted.... I know I need to create a FAQ topic for this as it is a relatively common problem, but I just don't have time at the moment... You should always search for similar posts before posting (which you did) and try what is suggested there (did you? You do not say what you have tried) and then, if you still need to post, ALWAYS attach the relevant files. I do not know your system. I cannot help unless you provide sufficient information. For any installation issues, always your InstallFSUIPC7.log file, the FSUIPC7.log file (if there is one), and for auto-start issues, please attach your EXE.xml file and tell me what your MSFS install type is - Steam, MS Store or boxed. Thanks. John

This was to log the activity - I didn't expect it to work. However, you log file shows that you started MSFS but didn't start a flight. Please load an aircraft and start a flight and then test those buttons. Also, please close down FSUIPC before attaching the log so I can see the full log file. Someone else has also recently reported the same issue but for the Bravo. Could you also try temporarily re-enabling the default profile for the Alpha in MSFS, and see if those switches are recognised there - or see if they are recognised by MSFS.

You need to create an empty profile in MSFS for all your controllers (except keyboard and mouse). If you create a new profile for each of your devices, it will be empty by default. You can then assign mainly in FSUIPC, but still have the ability to add an assignment in MSFS if needed (as some controls are only available in MSFS and are not yet working via simconnect/fsuipc).

Btw, doesn't MSFS have native support now for the Honeycomb Alpha and Bravo? If so, can you check if those rocker switches are seen by MSFS when assigned there. Just to confirm those switches are working. i.e. switch back to the default MSFS assignment profile to test. I know there are issues with 'always on' switches, but it would be useful to confirm those switches are actually working.

Yes, just paste the contents if you can't attach. Don't worry - I'm getting used to being called Pete by now! John

Sure. I'll generate one for you and post it here, but probably tomorrow or Monday now (as the time-limited key generation is still only working on my win7 system which is currently not available...). John

Please post your Installation log file (InstallFSUIPC7.log), which should be in your installation folder. The Installation guide, included in the zip AND in your FSUIPC documents folder, explains where things are installed and how the installer works. Documents are installed under your Windows Documents folder in a sub-folder called FSUIPC7. If it cannot install there for any reason (usually permissions), it should fall-back to install in a subfolder of your FSUIPC7 installation folder. But, its the install log which will tell me what is installed where, so please show me that.

Maybe remove it for now and test without. The logging shows that the presses aren't being registered for some reason. As well as testing without your vjoy devices, you could also uncomment the logging of the discards change: to Also, the 'button = false' line is in the wrong place really - should be: So please test with that and without vjoy and report back. I haven't used vjoy for quite a while now so I'll take a look and see if thats interfering (which it most probably is as its also using the virtual button offsets....). John

No, you don't need to change that as the Alpha and Bravo are different devices (have different Product Id). That is only used if you have two devices that are the same, i.e. same vendor and product ids. I'm not sure what you issue is. Someone else recently reported the same problem but with the Alpha. The strange thing is that the logging is showing the same entry each time: 46219 LUA.2: BRAVO Buttons= 8E040000 2AAA However, the script should only log when this has changed: Could you add the following line to your bravo script please (in bold below): Also, add offset logging for 3344 as type U32 in hex (from the FSUIPC7 log menu). Then generate another FSUIPC7.log file and show me that. I see you are also using two vjoy devices. They may also be using the same offset range (Alpha uses 4 bytes from 0x3340, Bravo 4 bytes from0x3344). Thanks, John

Sorry, was getting confused and was referring to FSUIPC7. There is no exe for FSUIPC6. I have PM'ed you a key file. Please place that in your FSUIPC6 installation folder.

I have had a few reports of the installer not creating the key file. Usually its a permissions issue and installing in a different folder solves the issue, although you can also create the key file manually. It is recommended to install FSUIPC6 outside of your P3D add-ons folder if possible, and just use that location for your add-on.xml file.

enter '3340'. Please see the User guide

Yes, sorry - you did say this in your original support request. I have checked your registration details here and they are good. Can you run FSUIPC7 by double-clicking the FSUIPC7.exe window? Or do you get an error? If so, it is probably due to your VC++ redistributables being corrupt. You need to uninstall any of the VC++ redistributables from 2015, 2017 & 2018, then re-install the combined package (both x64 an x86) from https://support.microsoft.com/en-in/help/2977003/the-latest-supported-visual-c-downloads

Ok. Then I think that the wnd window maybe getting the focus back (and so keyboard input events) when it is being updated. No keyboard support has been added to the wnd window, so any keyboard input relies on basic windows functionality. Keyboard input certainly isn't forwarded to the FS, but I'm not sure (without investigating) if the input would fall back to FSUIPC, but probably not (due to your issue). I'm sorry, but this is something that I will need to look into. I'm very bust at the moment, but this is now on my list to investigate. I will get back to you once I have had time to look at this in more detail. Hopefully later next week. John

Please read the Installation and Registration document that is included in the zip. It will rell you where things are installed. All the FSUIPC7 documentation is installed in a FSUIPC7 folder under your windows Documents folder. Find them, and at leat take a look at the User Guide. Transponder mode (or state) is in offset 0x0B46 and has been reported as working for both read and write, with values 0 = Off, 1 = Standby, 2 = Test, 3 = On, 4 = Alt, 5 = Ground (see the additional offsets document spreadsheet for details) To use this, assign to the 'Offset Byte Set' control with the appropriate value you want to use, or the cycle incr/decr controls with the appropriate parameters (depending on how you want to operate). See the Advanced User guide for further details. John PS there was/is also a README.txt in the zip you downloaded - did you not see that?

Thats because you are logging lua plugins separately (one of your Log options), so its logged in a separate file - which you also included! Do you mean that the text in the wnd window is flashing? Strange....or do you mean the usual windows flashing that occurs when there is new input? Did you try, as I have asked, giving the window focus back to the FS or FSUIPC before activating the button? If not, please do so and let me know the result. But also, looking at your ini, you don't have any assignments at all in FSUIPC. So are your assignments in MSFS? If so, MSFS MUST have the focus to receive these. So, as I have said, please try giving the focus back to MSFS BEFORE you issue a command, to see if that works. The 'keyboardFocus=Yes' will not affect assignments in MSFS - you need to assign in FSUIPC for that to take affect. It seems to me that your problem is that you have assigned in MSFS, which means that MSFS must have the focus to receive the keyboard input, and when you start the lua script it creates a new window which, by default, accepts the keyboard input but does not handle it. But I need you to do the tests previously mentioned to confirm this. I could. maybe, look into either changing input focus back to the previous window once a wnd call creates a window, or look into forwarding keyboard events from the wnd window back to MSFS or FSUIPC so they get handled. But, first, I need to understand if this is what the actual issue is, so please follow my instructions and report back. John

No, that is not possible. Please see the Advanced User guide for the format of the button assignments.