John Dowson

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

Go to your FSUIPC7 installation folder (if you don't know where that is, use the File -> Open Installation Folder... option in FSUIPC7). Open the file MSFSwithFSUIPC7.bat in an editor (e.g. Notepad++), find the following line: start mshta "%splash%" and uncomment, i.e. change to :: start mshta "%splash%" John

For dimmers does it really matter? I would have thought either would suffice, or even a rotary (i.e. non linear, 1 or 2 button in each direction) switch would perform just as well. Thats just my 2cents, so take it with a pinch of salt. Others with more experience in these matters will hopefully give a more informed opinion, but you may be better off (for hardware questions) asking over on cockpitbuilders.com. John

ok, thanks for reporting back.

I'll keep this change and will release this shortly. However, I think using an offset for this is a bit OTT, so I've also added an additional control Set MaxSteerSpeed which will be available in the next release. You can also use this in lua via the ipc.control function. John

Not at all. Sorry if it came across that way. Good! 1200 seems a large increment (especially if using repeat), but thats fine if it works well for you. As I said, for me I find around 500 works well (in the C208). John

So why can't you use that? You can also add an offset condition (to 0x0D0C and mask bit 3 [&8]) if you only want to keep your switch in-sink. See the Advanced user guide on how to add offset conditions. You could use the offset directly if you like. You can use either the Offset Word Setbits/Clrbits control, or the Offset Word Togglebits control, depending on how your switch works and how you want to implement. Probably the former, with the Setbits control on the press, and the Clrbits control on the release. John

Is that for overclocking? Shouldn't affect FSUIPC, but you never know. Maybe test without this (if possible). You say the crash is 'random'? Can you explain in a bit more detail, as the only log you provided ends after WideServer is started. But you also say that this occurs when WideServer is disabled. So maybe provide a bit more information on when it crashes (without WideServer), and show me another log file. I'm perplexed on this one....after the next (and each) crash, please check the event viewer and post anything reported there - as well as the your FSUIPC7.log file. John

Please see the provided README.txt: John

Yes, would be nice. But this is also not the best pause state to use - the others are usually better. I don't know why this is the default 'Pause' in MSFS. Its not really a 'pause', but a lat/long/alt hold (or so it seams...). To be honest, I'm not sure why folks are using this - better to remap and/or use the other pause controls. John.

? What way is that? I still don't know if you are trying to register FSUIPC7 or WideFS, but I presume the latter (as you posted in a WideFS registration related post). Anyway, as long as its now working.... John