John Dowson

This is expected. Why is this frustrating? If you have FSUIPC open, you do not need to access P3D. FSUIPC blocks visibility of your devices (all controllers including keyboard and mouse) while it is active so that you can assign to these without them having an effect on the sim. John

WideClient is 32-bit (all versions). Its seems unclear if this would work with a 64-bit client. You can re-compile against the 64bit SDK and try it. But 32-bit clients work fine with all versions of FSUIPC and WideFS, so you can just stick to 32-bits unless you have other reasons to move to 64-bit. Sorry I can't give more information. I'll do some testing on this at some point as I'd also like to be clear on this (i.e. 32-bit/64-bit client with 32/64 bit WideFS or FSUIPC) but I have a lot to do at the moment (and for the forseable future!) so haven't really got time to check this any further at the moment. If you do rebuild you client as a 64-bit one, please let me know if it works ok with WideFS/WideClient. John

What version of FSUIPC7 are you using? The use of the numpad keys was corrected with the release of the MSFS SDK 0.8.00 and updated in FSUIPC7 v7/0/2 release on the 28th November. If not using that version, please download and try with that. I'm not sure I understand this question. Yes, there is no access to lvars at the moment, but SPEED_SLOT_INDEX_SET is an event/control, which you can send using lua via ips.control and provide the parameter needed. John

Yes, probably on a 6 hz sampling rate but depends on the data item. Yes, each lua runs in its own thread. That's strange... Does the control actually work on the aircraft you are using? If so, what happens when you send an invalid value - is it just ignored? The offset just holds the value of the associated simulator variable. But it doesn't make much sense that its being updated to an invalid value for that aircraft.

No, sorry. All the drivers and additional freeware we provide are available in the download links section here or on www.fsuipc.com. John

If its not seen in the assignments panel, then its probably not recognised as a joystick type device. You can post your FSUIPC7.log file and FSUIPC7.Joyscan.csv file and I'll take a look. If its recognised as a Hid device, then you could access it using lua. there is a demo lua script provided that you can use and adapt (HidDemo.lua) as well as documentation (both installed in your windows Documents folder under a folder called FSUIPC7).

Its in the SDK folder, UIPC64_SDK_c_version2.zip.

But that is probably an old version now. You should download and install v7.0.2, released yesterday. Not really. This is why we provide profiles, so you can configure your assignments for the controls or features that work for the aircraft in that profile. Sorry, I don't know Xplane 11, and FSUIPC doesn't support it. I think thats XUIPC by a different developer. John

Yes, as the control is sent to the FS and the offset is updated when we get this information back to tell us that the offset has been updated. Most probably due to the event not being connected yet - from the MSFS SDK: Internally, not all events are mapped to the relevant SimObjects If that should be possible with the aircraft, you can raise a zendesk ticket with Asobo.

Where is this, on the DA40, for example? The ignition switch (ELECTRIC MASTER: Off - On - Start) in the DA40 is using the Toggle Master Battery Alternator event (with param 1) for Off <--> ON, but there doesn't seem to be anything for On ->Start (apart from the generic Engine Auto Start or Ctrl + e). Is it this what you are looking for?

FSUIPC7 should in no way affect any assignments you have in MSFS. Check that you are still using the default Keyboard profile in MSFS, and search by input to see if your arrow keys are still bound. If you run MSFS without FSUIPC7, does this problem go away?

There is currently no access to lvars. In such circumstances (i.e. no event seems to be triggered), you can look at the MSFS assignments to see if there is anything that works there. Then assign this to a key press (or key press combination) in MSFS, and then assign the key press to your button in FSUIPC. Just looked at the DA40, and there is a Toggle Master Battery control which seems to work for this aircraft (if thats what you are after). John

They do - they all use the Fuel Selector Set control. The offset for the other indices (2, 3, 4) use the Fuel Selector n Set contols (n=2,3,4). I'm not sure why there is no generic fuel tank selector 2..4, but you can use the other indexed offsets instead as they use the same control. John

If using PM, you should ask on the PM support forums really. @Enrico Schiratti may be able to help. John

What aircraft are you using (A320 or B787 perhaps?)? Those controls were reported as working (by two users) in this post: You should also maybe look into the use of the _SLOT_INDEX controls, which switch between managed and selected AP modes. See this post: https://forums.flightsimulator.com/t/simulator-events-for-switching-between-managed-and-selected-mode-in-the-a320/323838 And also this may help: John

@Karl_Yoghurt The latest release of FSUIPC7, v7.0.2, contains AUTOPILOT ALTITUDE LOCK VAR:3 at offset 0x0818 - this may contain the value you are after (the altitude displayed on the FCU in the A320). See https://forums.flightsimulator.com/t/a320-fcu-variable-autopilot-altitude-lock-var-vs-displayed-altitude/307093/3 John

This has now been corrected in FSUIPC6 v6.0.11 and FSUIPC7 v7.0.2, both to be released shortly. John

Did you click the Register button? If not, re-install and try again. If you did, what did the pop-up say?

This is rather odd! I will look into this when time permits. John

This is also where offset conditions can help. With an offset condition, the offset (in this case, a bit in an offset) would be checked and if the condition matches (i.e. on or off) then the control is sent, if not the control is not sent. Doing this will automatically sync your switch with the VC panel switch after the first change, if not already synced.

Hmm, ok. Probably was a corrupt weather file that p3dwx replaced (or corrected), although I'm not familiar with p3dwx. Thanks for reporting back,

This is usually due to a corrupt weather file. Try adding NoWeatherAtAll=Yes to the [General] section of your FSUIPC6.ini file. If that works, you have a corrupt weather (*.wx) file, or more usually the wxstationlist.bin file - try deleting that from your APP Data Roaming P3D folder if it is there. It will be regenerated the next time you run P3D. Failing that, please check your windows Event Viewer to see if there are any crash reports, and if so please post the details. John

Adding to what Pete has said, I think you just need to re-organise your luas. I would have thought that if this was really an issue, then it would have been asked for long ago by the LINDA developers. And this is not a simple change, for the reasons described by Pete. John

But a fast response is no good if useless!

Hi Al, sorry, but I don't understand why you would need this. The [LauFiles] section just contains the lua files found, and will be those that can be assigned to via the controls drop-downs. Its the activation or use of the files that is important, and this is already handled by the [Auto.xxx] profiles section (or profile-specific assignments). Or are you saying that a limit of 128 lua files is restricting? I find that hard to believe.... And even if I did implement something like this, how would I know which lua file was for which profile? That would only be possible if using profiles in separate files (but even then problematic...would need profiles in separate folders!). Sorry, but I don't see an issue here or how it can be improved. John