John Dowson

If this was the case, then it looks like you either had a bad calibration configured, or maybe dual assignments (i.e. assigned in MSFS and FSUIPC7. By starting with a fresh ini, you will have lost all of your assignments in FSUIPC7 and will have to start again. If assigning in FSUIPC, please check that you do not also have assignments in MSFS as this can create conflicts. I recommend starting with an empty profile for your controllers in MSFS if assigning in FSUIPC. Yes, please do. John

What isn't working - all the assignments or just the trim wheel ones? This is correct, as documented. I don't know. What aircraft are you using? Maybe the trim control doesn't work for that aircraft? Have you tried in a different aircraft? For any issues, logging is your friend. Try activating logging for Buttons & Keys, Events and also Lua Plugins. You can see what is being logged as it happens by opening the log console (Log->Open Console). You can post/attach your log here and I can take a look. John

Yes, still an issue with xbox 360 controller being recognised, an empty device name, and the same id being assigned two two devices....very strange... Could you try the attach FSUIPC7.ini. This may work, if it allows matching on an empty name string - not sure: FSUIPC7.ini Please try that and report back. Also (if that works or not), could you add the following custom logging (Log->Custom) parameter: x200000 Then exit FSUIPC7, restart, exit again, and show me the generated FSUIPC7.log file.

This will be the issue. You are assigning your button to the back space key, so this is sent to the FS when you press the button. If you have removed the Back Space assignment in MSFS, then this is not going to have any affect when MSFS sees the key press. I presume this was still when you had this assigned in MSFS, no? You can do one of two things: 1. Add back the Back Space key assignment in MSFS, or 2. Assign your button to the control/event that the back space was assigned to in MSFS. This will then send the control directly, and no need for the key press assignment in MSFS (i.e. better). I would recommend keeping the default MSFS key assignments - you only need to remove these if/when assigning keys in FSUIPC. Any further issues, please show me your FSUIPC7.ini file, and an FSUIPC7.log file generated with logging activated for Buttons and Keys as well as Events. John

You didn't include the first line, which is essential, and you also had additional spaces. Please try the attached. John removexboxcontroller.reg

If they are not in the SDK, then probably not. You could take a look at the PDK, but I doubt even that would provide such information (its probably something you would need to derive, somehow, from the appropriate BGL file. Otherwise, seems like a question for P3D support - try asking on their forums. Sorry I can't be of more help, John

Hmm, very strange... Yes please.

Ah, ok. I will take a look when time permits... John

Also check that the mixture control and/or propeller pitch isn't being changed/affected, and check that you don't have any dual assignments, i.e. when assigning in FSUIPC, make sure the MSFS assignments are empty, or at least there are no conflicting assignments.

Hmm, strange. Not sure which version that was, but could you try the attached please, keep the same logging (registry logging) as earlier, let me know if it crashes or not and show me your FSUIPC7.log file as well (crash or not). Thanks. Thanks for the kind offer but really no need - all part of the support service! John FSUIPC7.exe

I don't know why your xbox controller is being given the same GUID (by windows) as your Yoke: Can we try without the xbox controller? Disconnect it (unplug if wired, power off if not) first, then remove the registry entries for this device. To do this, first run regedit and backup your registry (always do this before making registry changes). Then, save the following text as a .reg file (e.g. removeXboxController.reg): Then double click the file (in windows explorer) to tun it and remove the xbox controller registry entries. These will be recreated when you next connect the controller. Once you have done that, reboot, download and use the attached FSUIPC7.ini file (i.e. use this to replace your current one). Then run MSFS/FSUIPC7 (still without connecting your xbox controller) and see if things look ok. If not, show me those 3 files again (FSUIPC7.ini, FSUIPC7.log, FSUIPC7.JoyScan.csv). If everything looks ok, try connecting your xbox controller again - do this with FSUIPC7 shutdown. Once connected, start FSUIPC7 and check your assignments again, Any issues, show me the 3 files. John FSUIPC7.ini

What behavior do you expect when the airspeed decreases? Would you expect the same/similar behavior, i.e. when decreasing below 220 gradually decrease to 70%? Wouldn't this cause issues when landing?

Should be reasonably straight-forward with a lua script. When you say 'a linear increase in P3D from 70% to 100% throttle' what sort of increase do you mean? How long would you want this increase to take to get from 70% to 100%? Presumably a 1% increment delta over this period would be sufficiently 'linear', no? I can take a look at this for you when I get time - maybe on Sunday if I get a chance... John

So the throttle input values are the same, conditions are the same (i.e. wind speed and direction), but you cannot achieve the same airspeed? This does sound strange... The title says 'Until FSUIPC is Disconnected' - does this mean that if you assign the throttle in MSFS and have FSUIPC7 running but not controlling the throttle, you still get the same issue? And if you stop FSUIPC7, you then get increased power? What if you run FSIOPC7 with no assignments (i.e. temporarily rename your FSUIPC7.ini file)? Please clarify. Maybe you could also verify the input throttle values are the same when assigned in MSFS as when assigned in FSUIPC7. To do this, activate logging for Axis Controls in FSUIPC, open the logging console and monitor the parameters to the "Throttle Axis Set Ex1" event. Do this when throttle assigned in MSFS and when throttle assigned in FSUIPC7 and see if the parameter values for those controls look roughly the same.

Yes - didn't we discuss this before? Or maybe that was someone else...anyway, its fixed (in next release) and attached below, John A32NX FBW.hvar

You shouldn't have done this as all your previous assignments are still available. This occurs if your GUIDs change. Rather than re-assigning everything, you can just update the [JoyNames] section to match the new GUID. I can help with this. Looks like something strange is going on - your xbox 360 controller os being given the same GUID of your CH Eclipse Yoke for some reason. Don't you have an xbox 360 controller as well? Can you please respond to this question (may help): What changed from when it was working until now? I will take a look in detail tomorrow and get back to you. John

This is not quire correct. A variable (simvar or A:var) is a variable, that can be read-only or read-write. A control is an event, an action that changes something. An event can update one or more simvars, but there is no direct translation (in many cases) between an event and the simvars that it can change, although this can sometimes be determined. If you look at the FSUIPC offset document for FSUIPC 4/5/6, in the write column you will see something like Ok-SimC and Ok-SimE. The former implies that the simvar is updated directly (the simvar must be writeable) while the latter indicates that an event/control is sent for the write operation. I have an idea to allow the user to add any simvar (including a specific simvar index) to a free offset, and maybe also allow already allocated offsets to be re-purposed to hold different simvars. This will be for reading, but I could also allow writing/updating if the simvar is writeable. This functionality is the next piece on my list to look into. Depending on how busy support keeps me, I should be able to start looking into this in detail in a couple of weeks. John

Ah....logging in FSUIPC should have indicated this... Glad you finally fixed this issue. John

Only your CH Pedals are now recognised correctly: The name for the yoke cannot be read correctly - it is blank for some reason. This is the second time this week I have seen this issue, no idea what is causing this at the moment. What changed from when it was working until now? How many devices do you have? Id it just the CH yoke and pedals, or do you have another device? I ask as you have assignments to devices B, C, D and E which all look like they are assigned to the yoke, and you have no assignments at all to your pedals. Did you previously lose your assignments to the yoke and then re-assign for some reason? Can you show me your FSUIPC7.log and FSUIPC7.JoyScan.csv files please. John

There are no standard controls for EFIS commands. Which aircraft are you using? The A320 or FBW A320? You most probably need to look at the available lvars and hvars for the aircraft you are using. You can use the MobiFlight hubhop resource (https://hubhop.mobiflight.com/#/list) to see that the MobiFLight preset uses and try to use that, or you can install the MF WASM module, use the provided MF event files (in your FSUIPC7 EventFiles folder) and use the MF presets directly. I could help you set-up one button/function if you like and you can take it from there. I am currently looking at adding additional functionality to FSUIPC7 to make calculator code (such as that provided by the MF preset list) easier to use. John

Is FSUIPC7 still running when you attached that log or did it crash? If the latter, can you temporarily unplug/disconnect the Fanetic device to see if it is the empty name causing this. If FSUIPC7 is running ok, do you have any more issues? John

Yes, you could try that if all the information you need is available in the MakeRunways output files. Be aware that these are large as they contain all airports/runways, so you might find that this will take a while processing such a large amount of data... Good luck if you try this! Cheers, John

FYI, he condition lever controls/events are now recognised in the latest MSFS / SDK release and will be available in the next FSUIPC7 release, v7.2.16, hopefully to be released by the end of the week or possibly early next week. John

FYI, he condition lever controls/events are now recognised in the latest MSFS / SDK release and will be available in the next FSUIPC7 release, v7.2.16, hopefully to be released by the end of the week or possibly early next week. John

Sorry, but I have no idea what the MSFS control txt file you are referring to is - can you please explain? The Documents/FSUIPC7 folder should contain the FSUIPC7 documentation. One of the file in there will be the Controls List for MSFS Build 999.txt file if that is what you are referring to. However, note that this is created on-the-fly, once you have an aircraft loaded and ready-to-fly (or maybe once an active simconnect connection is established, which maybe earlier). John