John Dowson

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

Hi Barry, could you attach you FSUIPC7.ini file please and I'll take a look. If you could also activate logging for events and buttons, load an aircraft and produce a short log file (FSUIPC7.log) exhibiting your issue and also attach then that would be helpful. John

That would run with one unknown parameter of '/Water /+Q' - try "<P3DRoot>\makerwys.exe" "/Water" "/+Q"

Which aircraft is that then? There are many MSFS aircraft, but I didn't realise there was a default one.... But they are just the controls/events exposed by SimConnect. I don't know if any of those general GPS button assignments are linked to anything, but that would depend on the aircraft and GPS system in use. What GPS button in which aircraft are you trying to operate?

I'm not sure what you have done but you have no axes assignments at all, either general or profile specific. Please try setting up your axes again in your profile. Before doing this, you should change this ini section: To this: [Profile.747] 1=PMDG 747 This will then match any aircraft with 'PMDG 747' in the title to your profile (as you have the default ini paramater ShortAircraftNameOk=Substring set) There was a correction from v6.0.10 to v6.0.11 that should have prevented assignments being lost when not importing general assignments into a profile. Maybe you did this with v6.0.10 before installing v6.0.11?

Strange. The same python SDK has been included with FSUIPC5/6 for many years without issue. Lets see what they say. Malwarebytes also seems to have some false positives with FSUIPC7, but I think with the .bat file.

When installed, its integrated into FSUIPC7. Run FSUIPC7, and look in the Add-ons->WebSocket Server menu, There's an Online Help menu entry that takes you to http://fsuipcwebsockets.paulhenty.com/

If you have installed the web-socket server, there should be a menu entry that takes you to the on-line manual.

Then I'm sorry, I don't know what the issue is or could be.

Then maybe its just the character set? For the FSUIPC SDK, you need to compile with a multi-byte character set, not unicode. John

I'm not sure what 'GPS button' you are referring to, or in which aircraft. Best to just try and see.

Ok, I can now confirm that 64-bit compiled programs work ok with the 32-bit WideClient.