John Dowson

It will be kept and included in the next official release, 7.4.7. No problem - cheers, John

No - you do not have to add this. The ipcReady.lua is always started if available, you do not add this to an [Auto] section. From the lua plugins document: Ok Ok

Maybe worth going back to your previous/last working ini and forgetting about the last one you attached, Use that, start FSUIPC7 and exit and then attach your files again, and I can look into any issues with those. Looks like we might need to remove some registry entries again - these look to be incorrect: Wrong GUIDs: N, x00, x04D8, xF30F, AGRONN B737 Yoke V2.2, -1, -1, 1, {NULL}, {F73B7EE0-4B37-11EE-8013-444553540000}, {NULL}, N, N N, x00, x044F, x0402, Joystick - HOTAS Warthog, -1, 2, 0, {NULL}, {F73ABB90-4B37-11EE-8003-444553540000}, {F73ABB90-4B37-11EE-8003-444553540000}, Y, Y N, x00, x0000, x0000, Fulcrum One Yoke, -1, 12, 0, {NULL}, {89A3AE10-D256-11EE-8002-444553540000}, {NULL}, N, N N, x00, x2356, x8046, Landing Gear Lever, -1, 5, 0, {NULL}, {F73B09B0-4B37-11EE-8008-444553540000}, {F73B09B0-4B37-11EE-8008-444553540000}, Y, Y Wrong GUIDs, multiple entries: N, x00, x16D0, x3530, Parking Brake, -1, 10, 1, {NULL}, {F73B09B0-4B37-11EE-8009-444553540000}, {F73B09B0-4B37-11EE-8009-444553540000}, Y, Y N, x00, x16D0, x3530, Parking Brake, -1, 12, 0, {NULL}, {89A3AE10-D256-11EE-8002-444553540000}, {NULL}, N, N ...etc No idea how your registry got into such a mess again. May be easier to remove everything and start again, but lets look at your files when using your previous working ini first... John

Should be fixed in the latest beta: FSUIPC7.exe

Sorry, but this makes no sense according to your current assignments in you latest ini: A=Cat3Design A320 FO Tiller V2 B=Cat3Design A320 FO Tiller V2 C=Joystick - HOTAS Warthog D=T-Pendular-Rudder E=VPC Panel #1 F=Landing Gear Lever G=throttleTek 3 H=LEFT VPC Stick MT-50CM2 J=Throttle - HOTAS Warthog K=Parking Brake M=<< MISSING JOYSTICK >> << MISSING JOYSTICK >> and these are now completely different from your previous working ini: A=AGRONN B737 Yoke V2.2 B=Joystick - HOTAS Warthog C=Cat3Design A320 FO Tiller V2 D=T-Pendular-Rudder E=VPC Panel #1 F=Fulcrum One Yoke G=T-Pendular-Rudder H=LEFT VPC Stick MT-50CM2 K=Cat3Design A320 FO Tiller V2 L=Throttle - HOTAS Warthog J=Landing Gear Lever M=throttleTek 3 FSUIPC does not change device letters, so you must have done this - why? And why are you specifying a 'preferred setup)? Once you have assigned a letter to a device, you should stick with that - so why is your "preferred setup" so different from the last ini you attached, but is the same as your last "working" ini? Are you manually editing the ini, or starting without an ini to generate a new one, then cutting and pasting?

Can you please attach your files - FSUIPC4.ini, FSUIPC4.log and the PFC.log or PFC,ini files. Also please see the provided PFC.dll User Guide and follow the steps there. I do not have nay PFC devices and do not use FSX, so you will need to trouble-shoot this yourself, but I can try and help... John

But how can you set thigs up in the cockpit if you do not have an aircraft loaded? You should not be trying to set anything for an aircraft when in the main menu... But then you need to open the fuel valve once the aircraft has been loaded, not when in the main menu - setting anything in an aircraft when in the main menu is not guaranteed to actually do anything.... The best way to initialise an aircraft on load would be to have a auto-started lua script, which will be started when the aircraft is initially loaded. You can also use ipcReady.lua for anything that applies to all aircraft, but for anything that is aircraft-specific you should have a specific script that is started from the the aircraft profile auto section. The WideServer component/thread in FSUIPC has always been started once an aircraft is loaded and ready-to-fly. Starting it earlier may not guarantee WideClient will work correctly, as this may also depend on other threads which are not stated until an aircraft is loaded. However, in the attached version I have added the ability to start the WideServer thread soon after the simconnect connection has been opened and the data requested, but I am not sure that this will work as you would like it. To use this feature, add StartEarly=Yes to the [WideServer] section of your FSUIPC7.ini file. John FSUIPC7.exe

Can you please attach your FSUIPC7.ini and FSUIPC7.log files.

This is strange as the installer first checks the steam location for the UserCfg.opt file in this location: %APPDAT%\Microsoft Flight Simulator\UserCfg.opt If this file exists, a Steam install is assumed, and if not then an MS Store installation is assumed. And your installation log shows that the following UserCfg.opt file was used: File D:\Users\Administrator\AppData\Roaming\Microsoft Flight Simulator\UserCfg.opt opened OK This IS for your Steam installation. Are you sure that you did not update the UserCfg.opt file from the MS Store installation, which would be here: %LOCALAPPDATA%\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\UserCfg.opt or possibly %LOCALAPPDATA%\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\UserCfg.opt

You are using an old and unsupported version of FSUIPC7, 7.4.1. Please update to the latest and only supported version, 7.4.6 and see if you get the same issue. If so, please re-attach your files. Please disable Log>Log Lua Separately and set Log->WAPI->Debug. and also attach your FSUIPC_WASM.log file. Google is not going to help you with FSUIPC errors... But are these errors actually causing any issues? I suspect that they are due to the fact that you are creating a lot of new lvars in succession and can safely be ignored. The line after these errors indicates that you have the lvars loaded successfully: If you want to remove the errors, you can add a small delay after you create each lvar (e.g. ipc.sleep(250)), to allow time for the updated lvar list to be passed back to FSUIPC, or create all the lvars in one calculator code statement instead: ipc.execCalcCode("0 (>L:DA62_Lt_Panel) 0 (>L:DA62_Lt_Flood) 0 (>L:DA62_Start_1) 0 (>L:DA62_Start_2) 0 (>L:DA62_Eng_1) 0 (>L:DA62_Eng_2) 0 (>L:DA62_Fuel_1) 0 (>L:DA62_Fuel_2) 0 (>L:DA62_AV) 0 (>L:DA62_Batt) 0 (>L:DA62_Alt1) 0 (>L:DA62_Alt2) 0 (>L:DA62_LPump) 0 (>L:DA62_RPump) 0 (>L:DA62_DI_Mode) 0 (>L:DA62_DI_Max) 0 (>L:DA62_DI_Alt)") John

Sorry, but this is still not clear... What is a "fake command"? You send "commands", also known as events or controls, via assignments to keys presses, buttons or axes, or using lua or by writing to offsets. All controls go via the SimConnect API. I have not used either, and am not sure what the 'npm fsuipc package' is...the WebSocket server will be the newer of the two, so maybe start with that... John

Way back in time. FSUIPC hacked into the sim to get the data for the offsets (before my time!), and was instrumental in developing the simconnect API. Once the the API was introduced, it was moved to use this, but also used some hacking for initial simconnect defects. From P3Dv4 and onwards, 95% of functionailiy has been via simconnect, abut some features still used other FS dll functionality, namely via the panels dll. For MSFS2020, everything comes via simconnect, or the embedded FSUIPC WASM module. These are all requested at sim_frame rate in FSUIPC How can things possibly work faster than the API allows? And there is always going to be a lag between setting and receiving the updated data - everything is asynchronous - you need to allow for this. Setting/updating are different channels than receiving. And the lg between the two depends on many things,,, Sorry, this is beyond me - what are "Token vars"? MSFS has various SDKs for different applications - take a look at those, FSUIPC is a 3rd-party simconnect application providing a uniform interface to multiple flight sims for 3rd party developers (amongst other things). We stopped hacking into the sim code after FSUIPC4, as this was a maintenance nightmare.... John

I am not sure what you are asking.... FSUIPC is a simconnect client, and is therefore restricted to the update frequency allowed by simconnect. Different data is requested indifferent frequencies - some in visual frame, some in sim frame, some in second, but always tagged (i.e. only received when changed). Most data is requested in sim frame (SIMCONNECT_PERIOD_SIM_FRAME), but also a lot in visual frame (SIMCONNECT_PERIOD_VISUAL_FRAME). If you let me know which offsets/simvars you are interested in. I can let you know the request frequency. But FSUIPC is a simconnect client, and has the same restrictions as all clients, And in MSFS2020, FSUIPC is an external client, not an embedded dll, so there is always going to be a lag in communication between an external app compared to an embedded dll. In summary, FSUIPC IS a simconnect client, and can only receive data via this interface. It does have an embedded/WASM component, but that is used only for lvar/hvar/calculator code. The data update rates are always going to be restricted by the provider, not the client. John

But did you change the script to remove the conflicting device? You cannot use the same script - it needs to be adjusted to the device that is giving the problem... I will look at your new files tomorrow or early next week and advise... John

Do you have an issue or question? Then why are you posting?

Not pedantic at all, more like a bug - I will look into this and update in the next release. looks like I'm trimming before removing comments, when it should be after... John

I have no knowledge on x-plane, but for smooth braking on a button in FSUIPC, regardless of version, see the following: John

This is way before my time, but I think that it is obvious that you cannot use a cfg file from 2004 in 2020.... Also changing from FSUIPC3 (FS2004) to FSUIPC7 (MSFS2020) is not an easy transition.. . That is basically 20 years apart, you cannot expect things to work the same way after so many years. I suggest you upgrade and just try things. There is a trial license for FSUIPC7 available in a post pinned to the top of this sub-forum if you would like to try it. John

Yes. and this issue has been known for a long time. There is already a thread on this in the Asobo forums...

When you get a lua error, the line number is given - just remember to check the previous line as well as the one given, as the error may be there (or even before!).

On line 14 (and 18) you have ipc.exit when it should be ipc.exit() It is a function and you are missing the brackets, so it is being interpreted as a variable, and thereofore an assignment is expected, hence the error (i,e, as its a variable, it needs to be followed by an '=' sign, but it is followed by 'else' instead).

I am not 100% sure, and it may depend on how you are sending this data, but I don't think FSUIPC will send any controls when the in-menu/dialog flag is set (offset 0x3365) and/or the ready-to-fly indicator (offset 0x3364) is non-zero. I don't think the CTD will be related to this, but there is no harm in trying - but maybe use offset 0x3364 together with 0x3365. Maybe also easier to use FSUIPC's offset logging facilities to log the values of these offsets (instead of FS-Interrogate), and if you also log events you can see when these are being sent (ir received) and what the values of those offsets hold at the time. John

This is interesting and explains why some key events sent via external apps (i.e. sent using the MSFS SimConnect SDK) sometimes don't work whereas the same (or similar) event assigned in MSFS do. However, FSUIPC know nothing about this key event mapping - it just sends the key event to MSFS using the MSFS-provided SimConnect SDK. It is therefore an issue with the SDK that events sent using this do not go through the same path as the ones sent internally. There are two ways to get around this. 1. use the Input Event directly. Direct access to Input Events was recently added to the SDK and Input Events are available for use (via assignments, offsets or lua) in FSUIPC7 since version 7.4.0. You can also list the available Input Events for the current loaded aircraft using the Log -> List Input Events menu option. Note that not all B:vars (which are the Input Events) may yet be exposed by the Input Events interface. MSFS have indicated that they intend to make all available, but this may not be the case. If the Input Event isn't available, then you will have to use the 2nd method, as it is not possible to control B:vars via calculator code (i.e. using a preset) for some reason... 2. If no Input Event is available/exposed to control the B:var, the only way to control/assign to this externally is by hacking the xml code. The idea here is to introduce an lvar whuch is checked in an update component (on a timer) and used to set the B:var. This is explained in various posts here, and also in the description of some HubHop presets, e.g. TBM930_BLEED_AIR_OFF. Also see https://forum.simflight.com/topic/97903-cockspur-mustang-c510-starter-and-ignition-was-fsuipc7-wasm-submenu-shows-disable-only/?do=findComment&comment=589316 John

As I said before, there is no access to B-vars directly - you have to hack the xml files to add an lvar (and timer) to control a B:var - I have showed how to do this in other posts, and there are also examples on the MF Hub-Hop site (e.g. see the details for the preset TBM930_BLEED_AIR_AUTO). Even calculator code cannot be used to trigger a B:var directly (although I have seen some AAOs snippets that try to do this....) However, there seems to be a close relationship between B:vars and Input Events - in fact, B:vars ARE Input Events (see https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm) - but maybe not all B:vars are available as actual Input Events (or via the Input Event interface). So, I prefer to use the term Input Events rather than B:vars, which you can access via the GUI for assignments, via offsets, and also via Lua. So any FSUIPC client can access them via offset 0x7C50. Please note that the prefix FSUIPC uses for Input Events is 'I:' and not 'B:'. For the actual B:vars themselves, there is not and never will be any direct access (e.g. via calc. code) as far as I am aware, and you will only ever be able to use these via the corresponding Input Events interface. I have also read somewhere (in the Asobo forums) that future MSFS releases will provided access to more B:vars via the Input Event interface, with the aim to provide access to all - at which point the distinction becomes irrelevant! All a bit confusing really....

Thanks @AirPanther. However, note that @Brahms is using FSUIPC7 so the offset for APU_EGTNeedle is 0x64E8 (still a FLT32, 4-bytes) - the PMDG offsets in FSUIPC7 are not exactly the same as in earlier versions. I did check the 'Offset Mapping for PMDG 737-700' pdf document but missed this somehow... I will move this topic to the FSUIPC7 sub-forum where it belongs. Cheers, John