John Dowson

No, or at least not at the moment, as it may be these events causing the difference in increment values, as with the APU Start in the support request that Pete referenced. I'll look into this (when time permits) and get back to you. I've been without internet most of the day so have a bit of a backlog, so will probably take me a day or two to get around to looking at this, John

Could you activate event logging and produce a FSUIPC7.log file, showing the control being activated both when parking and when flying. Please also attach your FSUIPC7.ini. I'll take a look at your files, but if FSUIPC7 is sending the same controls (with a 0 parameter) then it seems like this is a problem with MSFS and needs to be raised to Asobo via zendesk. John

@ark1320 This was resolved in the 0.8.0.0.SDK release and the subsequent FSUIPC7 v7.0.2 release. Have you tried the latest release?

Please attach your FSUIPC4 installation log. Also make sure that you have installed both service packs 1 & 2. Also, if installing the beta of FSX-SE (build 63003), make sure you read this first: But the firewall will have no affect on the installation process. This doesn't matter. However, if you have a license, then to register your key you have to use the email address (as well as name) exactly as specified in your SimMarket email/account. John

Hi Rob, they are completely separate products, so installing and using FSUIPC7 will not affect you FSUIPC6 installation. However, due to using the same windows class names, you cannot run FSUIPC7 at the same time as FSUIPC6 (or P3Dv4/5, as FSUIPC6 runs as an embedded DLL in P3D). John

I've tried various things to try and reproduce this and can't, so could you please let me know how to reproduce. There seems to be no difference if a button is pressed or not when opening the FSUIPC UI.

I'll take a look, but if you could provide instructions to reproduce that would be helpful. There was a correction in this area from 6.0.10 to 6.0.11 to prevent axis being lost in certain circumstances, so maybe this has had an adverse effect in others.

This indicates problems with the VC redistributables installed on your machine. Please see the provided README.txt: MSVCP14.dll is from the 2015 redistributable, so should uninstall the 2015, 2017 and 2019 redistributables from your system (if installed) and reinstall again from https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads John

The only issue seems to be the event id being 0, but this is something that we just pass on from SimConnect so I'm not sure why. Also, I'm not sure if this is even useful, which is why I'm reluctant to investigate further (and with so many other things to do!). So basically I'll just update the offset documentation to describe the type, and also mention that the event ID doesn't seem to be correct, and consider this closed. John

No, not if you are happy with updated explanation of what the type value actually is! John

Ok. Its strange that this affects FSUIPC though if its not being used. I would have thought that any port conflicts would produce an error...and you can always change the ports used to get around this.... I guess I can try IVAO at some point to see what is happening, but I'm afraid that it will take me quite a while to get around to this.....

It seems that the 'type' field for offset B000 is not documented correctly. This actually holds the simconnect codes (not the lua codes), so they are 0x400 -> 16 = File 0xFFF -> 8 = ActiveSky weather 0x300 -> 4 = SimC message window text 0x200 -> 2 = SimC menu and for text types, the SimConnect_Text_TYPE enum is used: So a value of 512 (0x200) is a Simconnect menu, and 257 (0x101) would be white text. Does that make sense? I will update the documentation for this in the next release. Also seems that the SimConnect event Id is not populated (always 0). Is this needed? John

@737-SimGuy Could you add the following to the [General] section of your ini, repeat your tests and show me your .log file please: TestOptions=x8000 Thanks, John

I don't use (or know much about) IVAO. Does it use FSUIPC7? If not, it should not make a difference. Maybe ask about this on the IVAO forums. John

But you have no general axis assignments - you only have axis assignments in your PMDG profile. So only PMDG has any axes assigned. When you created the new profile for your Mjcq400, you could have done this based upon your PMDG profile which would have imported your assignments from that profile. However, it is always better to initially create your axes assignments in the general section (i.e. no profile). Then, when you create a new profile for an aircraft (or series of aircraft), you can import them from the general assignments and then adjust as needed for that profile.

Sorry, its P40 in the FSUIPC6 User Guide, for FSUIPC7 its on p35, section entitled Automatic running of Macros or Lua plugins. Ok, so you have already added the Lua to the [Auto] section (and in the correct format, as described in the manual)? If so, and its not working, you can activate logging for Lua Plugins and check your log to see if it is running and if there are any errors. You can also post it here and I'll take a look (with your FSUIPC7.ini file as well please). John

Yes, but there are various GPS systems as you state, and the GPS systems work differently, say, in the A320Neo compared to other aircraft. Maybe, but as I say it can be aircraft and/or GPS system specific.

Are you running the lua? The best way to run that style of lua would be to add it to the [Auto] section of your FSUIPC7.ini file. See p40 of the User Guide. John

It shows that you are still on version 7.0.0 - you should download and install the latest version which is v7.0.2. Your log file is so large as you also activated logging for reads & writes, as well as Axes controls - you didn't really need to activate those. Also, as its only a text file, you can always zip it up before attaching - although not needed now your issue is resolved. Otherwise your ini doesn't show much - you only have 3 button and one key press assignments (and no axes assignments).

I'll take a look at this and get back to you. John

Hi Emile, You can retrieve your registration details from your SimMarket account. John

😄 Ok, thanks for reporting back - was just about to take a look. I thought that applying toe brakes automatically disabled the parking brake though, but I guess that depends on the aircraft (and maybe the FS)

Ok, thats the one I tested with in the DA40 and I thought it was working. However, I've just checked again and you are correct - there doesn't seem any control available for this yet. Not sure how or why I thought this was working a couple of days ago....sorry about that. I've tried a few other controls & offsets but they all seem to operate on the electric master and not the engine master. And there seem to be no specific MSFS internal controls to handle this eother. I expect this is something implemented in the aircraft guage code and will need access to lvars (or other variable types) to control.

For AP issues with the A320, please also note the following post from Asobo: John

For AP issues with the A320, please note the following post from Asobo: John