John Dowson

The next SDK update has some corrections (and updated documentation) on the MSFS key input events, so I will revise FSUIPC7's key handling when this is released. I'll see if I can also add back in the ALT key modifier so that the default MSFS key assignments can be used.

Sorry, what does this mean? Are you talking about assignments in FSUIPC7 or MSFS? If the former, all your assignments are stored in your FSUIPV7.omo file. For the latter, I presume that MSFS assignments are stored in a config file somewhere, although I don't know where. I wouldn't ascise changing this file manully though. There are many assignments that you can make in the sim but for which no events/controls are available via simconnect, upon which FSUIPC7 relies. If there is no control that suits your needs, you will have to do as advised above for the cabin lights, i.e. assign a different keypress to the Alt+C function (not using ALT modifier) in MSFS and then assign your button/switch to that keypress in FSUIPC7. Alternatively, if you are looking for a control to open the catering doors, you could try using the control TOGGLE_AIRCRAFT_EXIT_FAST to se if there is a parameter that works for that control for the catering doors.

I checked this in the C208 and it works as expected, although i found that I had to use an increment/decrement value of around 500. You should really try this again as it would be a better solution to overloading your button presses. If you have any issues, let me know which aircraft you are using and I'll take a look. John

@f-111sim Hi Rod, sorry for the delay, there were a few added complications... Please try the attached dll. I've cleaned-up the recognition of axes controls and added several new axis controls, including the ones you requested. The axes are functioning in that they are being sent to the FS, although I cannot confirm if working correctly or not as I'm not sure what those axes are supposed to do...! Please let me know if this is working for you. I have a few other updates (mainly documentation) to add and once done I'll release this version officially. John FSUIPC6.dll

The standard way would be to use the Toggle Cabin Lights control (or toggle bit 9 in offset 0D0C). However, this event/control doesn't seem to be working at the moment. The default ALT-L key press uses the TOGGLE FLASHLIGHT control which isn't available via simconnect, and you can't send this key press combination as the ALT modifier is not supported in SimConnect. Therefore, to assign this to a button or switch in FSUIPC, you would have to assign another known keypress (without using the ALT modifier) within MSFS to TOGGLE FLASHLIGHT, and then assign your button/switch to that keypress in FSUIPC.

Maybe you can check what event this is using (by activating logging for events (non-axis controls)), and compare to that produced by v5 or v4, as well as comparing to what occurs when you try this through your software. From what you are saying, it does seem like a change in 5.1. I'm surprised you are using the ' FSX 747-400, original panel' - did you copy this across from FSX and install into P3D? I have FSX-SE still installed somewhere, I can try adding that to my P3D installations (now only 4.5 & 5.1 though) to see if something has changed, but this would take me a while. I probably won't have time to do this for a few weeks with my current backlog, so may be better if you can investigate this and report back for the time being. John

Have you tried looking at the NAV1/2 flags in 0C4B / 0C5B to see which is active? Maybe in combination with the localiser/VOR flag in 0C4D / 0C70....

Btw, are you using GeForce Experence? If so, try de-activating the in-game overlay. Or if you are using MSI Afterburner or RivaRuner, try disabling those.

Just checked you logs and ini and they look good - no more registry issues or warnings, so it looks good to me. And all is detected correctly in your Joyscan.csv file. Let me know if you get any further issues.

I think the FSLabs Axxx series of aircraft have re-purposed the rotor brake control with various parameters for different functions. There is plenty of information on how to use these aircraft with FSUIPC over on the fslabs forums.

This is usually due to a faulty button that keeps firing. You can ignore this in the assignments panel by using the IgnoreThese ini parameter in your [Buttons] section - from the Advanced User manual:

Sorry, but do you have any issues? What am I looking for?

Is this aircraft specific or a problem with multiple aircraft? If specific, which airplane are you using? Also maybe try logging both events and axis controls (also open console to see the log messages in real-time) to see what axes movements are logged when this occurs.

No, I don't think that is an issue. You shouldn't do this really. No admin privileges are needed by FSUIPC7 or the installer. If any privileges are required then you will be prompted to authorise anyway. I will investigate that error nest week and get back to you. However, i've a feeling that it maybe due to one of your devices or device drivers. Check your connections and any usb hubs, make sure power management is disabled on all your hubs, and that all your drivers are up to date.

Why are you using DirectAxesToCalibs: Try disabling that by removing the line from your FSUIPC7.ini], although using this this shouldn't cause any issues. Can you a check if you have an event logged in the windows event viewer when FSUIPC crashes, and if there is an entry please post the details. If you disable WideServer, do you still get crashes?

It means that FSUIPC7 will not work when MSFS is running on an xbox console. It only works with MSFS running on a windows 10 pc. MSFS, like many games, runs on both xbox consoles and in a PC running windowa 10. If you are using MSFS on a pc then you are fine.

You initially reported that your FPS dropped when you try to create a mouse macro. Now you seem to be saying that your FPS is dropping when you have more than a total of 20 commands in your mcro files (presumably you are still talking about mouse macros, no?)? This just doesn't make sense. Mcro files don't do anything, and a macro itself only takes effect once invoked. As Pete says, you need to clarify what your actual issue is and provided further information.

Hi Rod, Yes, I should be able to add them so that they can be assigned, but only as 'Send to FS as normal axis'. There will be no calibration or offset area for these axes. These must be newer controls that aren't yet flagged in FSUIPC as axes controls. I'll look at this in the coming days and post an updated version of FSUIPC6 for you to try/test. John

@ark1320, @pilotjohn I've added this feature in the attached build. To use, you must specify the offset (starting with 'x' not '0x') as the MaxSteerSpeed ini parameter, i.e. MaxSteerSpeed=x66C0 The offset should hold (and is read as) a signed word (2 byte) integer. The maxSteerSpeed will be updated on every change of this user defined offset, so you can have a profile-specific auto-started lua to set this for your profile, or a long running lua monitoring the aircraft name (or stall speed) and updating the value when this changes. I've not had time to do too much testing so please report back once tried. John P.S. Changes to the MaxSteerSpeed are logged when Extras logging is activated. FSUIPC7.exe

Ok. That has been reported to Asobo. Ok. I can add [AUTOPILOT ALTITUDE LOCK VAR:3] if required. What about [AUTOPILOT ALTITUDE LOCK VAR:2] ? Its not an issue to add new offsets which can then be used for specific aircraft. However, I can't change the behavior of existing offsets if they are still functioning for other aircraft. I don't like the idea of allowing any simvar to be requested via lua - it would be very problematic. Its far clearer to identify any needed simvar and add it to the offset area. The long term plan is to provided access to lvars via an internal WASM module, and have an inter-process communication mechanism between the WASM module and the FSUIPC7 application. Whether this i done via a SimConnect client data area or using standard windows communication protocols is still to be decided, and depends on what facilities are provided on the WASM side. This is one of the larger development areas still to be addressed. John

La instalación de FSUIPC7 es independiente de la instalación de MSFS. La única dependencia de la instalación de MSFS es el 'Desktop shortcut' (que inicia MSFS junto con FSUIPC7). Si no tiene MSFS instalado en su PC, no lo instale desmarcando la casilla de verificación en la página final del procedimiento de instalación.

Sorry, I have no idea. Something must have changed. All the link/batch file does is start MSFS and then start FSUIPC7 after a short delay. What happens when you start MSFS directly (using the MSFS provided shortcut or start menu entry)?

@johnk515 Yes, that is what that lua script does. Try it - you will need to adjust the button numbers first. The alternative way (not sure if its any easier!) is to add the assignments via the ui and then overload the assignments by editing the ini file, to add the extra press/release controls as indicated in my last comment. To use this method, you will need to use the updated FSUIPC7.exe provided (still not officially released) as this has the necessary additional pause control added.

If by 'indexed variables' you mean standard simconnect variables that are indexed (i.e. in an array), then I don't understand your worries as they are no different from standard un-indexed sim variables. The A320Neo is known to function quite differently than most other aircraft, with many controls/events and sim variables currently not functioning for that aircraft. Reported here? Reference would be useful. Many AP variables (and controls) are currently not working, especially for the G1000. Maybe. But using offsets is tied to a specific control (or simvar) that may not be working for that particular aircraft. You have to choose a method that works for the controls provided for each aircraft. If they do not respond to the 'generic' controls, then other mechanisms should be used. If available, any simvar can be added to the offset area on request. No. Only simvars known to FSUIPC and published in the offset area can be accessed. If there are simvars not currently requested by FSUIPC that you require, then I can add these upon request. Thats local variables, or lvars, not simvars. There is currently no access to lvars in FSUIPC7, pending facilities to be provided. A simvar is a simvar, indexed or not does not make a difference. The included offsetStatus spreadsheet contains the simvars used for each offset (where applicable), together with a list of available simvars not currently held in the offset area (at the end of the document, after the offset list). Please take a look at these. For the definitive list of available simulator variables, please see the MSFS SDK documentation. Note also that they are documented in two sections, one is the complete list of simvars, and the other is the list available via SimConnect. FSUIPC7 obviously (?) uses the latter, although I have had some success requesting variables in the former not in the latter, i.e. simvars not yet documented as being available via SimConnect.

@Ray Proudfoot Interesting! My usual test flights usually involve Bilbao (from/to/or via Asturias, Vitoria or Vigo) and I've never noticed an issue, though I only fly during daylight (no lights) and normally GA. For the Dynamic Lighting issue, presumably SIMStarterNG also handles this, which I think you also use, no? But I guess that only handles the initial state, not changing during a session. I've had SIMstarter a while now but not gotten around to setting it up yet (too much time developing rather than flying!), but was planning to use it to switch settings between flying in photo scenery vs autogen.