John Dowson

Please post in the specific sub-forum for FSUIPC7/MSFS for questions relating to this - I have moved your post for you. No, unfortunately not. For xbox, you have to use the WASM interface, and unfortunately this currently does not have the required features to enable FSUIPC7 to be ported to such a platform. We may look at a WASM module at some point, if facilities are provided, but more for enabling specif functionality and to communicate to an external FSUIPC process. But even then, it won't be usable on the xbox platform.

Many of the buttons on the G1000 are currently not controllable via SimConnect. This has already been reported to MSFS/Aspbp amd we are waiting for an update for this to be fixed.

I don't use or have this, so maybe someone else can help you with that. But, I assume its an earlier version of the GFDevP3Dv4.exe, to which Pete commented: So if you use that, you shouldn't use the GFDev64.dll, which is the one you need if you want to use FSUIPC with your device.

Ah, ok - thanks for reporting. Later...although I think the question on VNAV was about the 'Display Vertical Navigation Page' button, not the lateral hold.... ...or about the VNAV in the G1000, which doesn't seem to be controllable either

Ok. You can also try offset 0x0BE8 - Gear Handle Position (4 Bytes), writing 16383 for down and 0 for up.

Ok, thats good to know, thanks. I'll leave them in for the next build release. For FLC, I've added a new offset at 0x0B49, 1 byte, for sim variable 'AUTOPILOT FLIGHT LEVEL CHANGE'. However, this only appears to be read-only and not settable. I've already asked about this over on the Asobo forums (as well as VNAV/VNV) No, probably not at the moment. There seem to be quite a few functions of the garmins (especially the G1000) which are not available via SimConnect at the moment. Actually, looking at the older controls list (not yet added to MSFS or in their documentation), I can see these GPS_VNAV_BUTTON GPS_SETUP_BUTTON GPS_BUTTON1 (also 2,3,4,5) I'll add these back to see if they are recognized and do anything when I get a chance...

Ok, that's good. Make sure you are using the latest version I posted earlier in this thread.

Is that an add-on? I didn't think there was a Mooney included with any version of MSFS. Maybe try a default aircraft. I can't really help with add-on aircraft (that I don't have!).

Its probably sending a press on the up, and a release on the down. Try adding the Gear Down control on the release, under 'Control Sent when button released'. Did you try the checkbox 'control to repeat while held' in the buttons/switches assignment dialog? Yes, in axes assignments. Sorry, I can't help with that as I don't have or know this device. Is there anything in the driver you use for this? Otherwise, you could try looking at the lua Go-Flight Device (gfd) library. See the FSUIPC Lua Library document, from p35 onwards. You will need to GFDev64.dll to use this. There is also a test program called gfdDisplay.lua provided in the lua examples which you could try, although I have recently had a report of some issues with this (relating to BlankAll), which I've not had time to look at (and won't for the foreseeable future unfortunately).

I've added them back and they don't give any 'unrecognized' errors, which is a good sign. Not sure if they work or not though. Could you try the attached build and let me know. I've added back the following controls: AP Panel VS Hold AP Panel VS Off AP Panel VS On AP Panel VS Set AP VS Hold AP VS Off AP VS On AP VS Set FSUIPC7.exe

Which trim - elevator/pitch trim? How are you assigning - to the 'Elev Trim Up/Down controls? Do you have your button/switch/key set to repeat? Otherwise, if you have a spare axis, you could try assigning to the ElevatorTrim axis. Whats wrong with the 'Gear Down' control? Just tried this on the CJ4 and it works as expected. What aircraft are you using? John

Ah, was just going to suggest that you check that offset! Also, check 0x3458 where that variable is also stored as a float64, although the offsets document for that offset does say 'But see preferred offset 07E2'!

Yes, especially any of the offsets - see the included spreadsheet. Also ok to use this thread for such reports if they are TBM900 specific

No, an empty profile for each one. Should take all of 2 minutes!

That's interesting. Thanks Trev, I'll take a look at those when I get a chance.

I'm sorry but I just don't have time at the moment. I would have to look them up and work out what the mapping is (from the FSUIPC and P3D documentation), just as you would. I've shown you what is wrong with your initial post, so hopefully you have enough information to do this yourself. Otherwise I can take another look when I have time, but I'm very busy on MSFS issues at the moment, and can't see myself having much time for this type of query for the next few weeks at least.

Ok, good. Glad you solved it, but it would be helpful if you could explain what your issue was and how you solved it, in case others have the same problem.

65890 is AP_PANEL_VS_HOLD, which is not available in MSFS, at least according to the documentation. In fact, it seems that non of the AP VS controls are available, except for the incr/decr and var set metric. I'll try enabling the old VS controls (ON,OFF, Set Hold), including the panel versions, here to see if they are recognised. If so, I'll add them back in and let you know. Otherwise I'll report to Asobo.

@bjoerntiemann Your calibration looks a little strange: The idle position is at your axis minimum value. Do you not want a reverse zone? For the separate throttle controls, the 'idle' position is the null zone between forward and revers. If you don't want a reverse, you should check the 'No reverse Zone' checkbox rather than setting the idle position to the start of the axis. Otherwise, you probably want an idle zone around the -12000 mark, with a small null zone, something like Throttle1=-16384,-12384,-11884,16383 Throttle2=-16384,-12384,-11884,16383 Also, is there any reason that you are assigning to the separate throttle controls for engine1 and engine2, rather than using the single 'Throttle' control? You could try switching to see if that makes a difference, but it shouldn't really (apart from maybe the calibration slopes). You could also check your axes calibration in windows game controllers, to make sure the full range of movement of the axis is being used by windows. Other than that, I don't know what to suggest.

Really - even with a slope of -15? For my throttle, that gives me half the throttle axis movement range for manual use, and the other (top) half to select between the gates. Maybe you can show me your FSUIPC7.ini file and I'll check your calibration. Do you have the full range of movement on your axis (-16383 to +16384)?

Well, activating those in the UI sends the TOGGLE_STARTER1 and TOGGLE_STARTER2 events. However, sending these via FSUIPC shows no movement. They do move with 'Engine Autostart' though. Ok, so sounds like they are working but the visuals are not updated. You can report this in the MSFS forums. Yes, just tried these and they seem to work. In fact, the Turbine Ignition Toggle function seems to toggle between CRANK and NORMAL. However, turning that switch in the UI shows no events. No, neither can I! I'll look into this more tomorrow and if I can't find anything I'll report to Asobo.

The simvar used (NAV LOCALIZER) documented the same, as 'Localizer course heading in degrees' - maybe this needs reporting to Asobo? I guess I could subtract the magnetic variation before populating the offset if needed.

Have you assigned and calibrated the throttle in FSUIPC7? Make sure you assign to 'Send direct to FSUIPC calibration' and calibrate with no slope active. If there is then too little movement in the upper range, to select the gates, try adding a negative slope, which will make the initial (manual) range more sensitive, but give you more movement to select between the gates. Try different slopes to see which feel good for you.

So this is not correct, and the additional axis scanning I added for you to prevent this now makes no difference? If so, I'll remove this, as it shouldn't be needed anyway. And this is also no longer correct. Do you only get this issue when you restart after you have received the TransmitClientEvent errors and FSUIPC later crashes? If so, its that issue (i.e transmit client event failures) that needs to be resolved, and I wouldn't worry about this other problem for now. And as mentioned in the other post, you should clean your registry as it seems to be in quite a mess.

Yes. It may be easier to disconnect your devices, remove all entries (back-up your registry first), and then re-connect them to get the entries regenerated. Make sure you are using the "JoyLetters" facilities first. If you don't know what this is, just set: AutoAssignLetters=Yes in the [JoyNames] section of your FSUIPC7.ini file.