John Dowson

Could you please attach your FSUIPC_WASM.log file from when you had this hang - if still available. Please attach that the next time, and also enable WAPI Debug logging (Log->WAPI->Debug) as it looks like its something to do with the WAPI / WASM. Can you tell me when you are starting FSUIPC7? Your log file shows this was manually started, but you have quite a few reconnection attempts. Maybe better to update your InitialStallTime ini parameter to 15 (currently 5). Note also that your trial license has expired, so you will not have access to licensed functionality anyway. The event is an AppHangTransient event. I think this is more likely to do with your system that FSUIPC. As it is transient, if you leave it running. does it recover? Can you see anything related to FSUIPC in the MSFS console window (you need to enable devmode to see this)?

When you say "all planes", do you mean aircraft with a propeller? This is standard behavior (for prop planes) - see, for example, here: https://www.boldmethod.com/learn-to-fly/aerodynamics/why-you-need-right-rudder-on-takeoff-to-stay-on-centerline-during-takeoff/ So basically that is how prop. planes behave - you should not have this issue with Jets. If you do not like this realism, you would need to set auto-rudder in the MSFS assistance options. John

That is strange - I don't get that here. If Windows Defender reports an error, I would normally report this, but as I don't get this at the moment (and I am up-to-date), maybe you can report this here: https://www.microsoft.com/en-us/wdsi/filesubmission/ John

License sent via PM. License sent via PM. John

That is not quite correct. What I mean is that for the intermediate positions, you need to define the same range twice, once with Up and the increment control, and another time with Down and the decrement control. So you need 6 ranges - one each for the top/bottom (one with Up,/increment, the other with Down/decrement), and two each for the two intermediate positions, one with Up/increment and the other with Down/decrement.

These ranges sound very weird...for example, for range 1, how can you enter in down from a 16383 value? And also your ranges 1 and 5 overlap. Maybe your axis is reversed? i.e. bottom position positive, top position negative. For such axis, then the opposite of what I said applies about the top / bottom ranges. As I said, your top/bottom ranges only need to send one control (incr or decr) when entering either up or down, all other ranges need a control sent on both up and down.... Anyway, glad its now working. I have also just got a license through for this aircraft from Just Flight, so I can install and take a look in more detail, but this will have to be at the weekend. John

But why? Note that you are using ranges in the reverse way than me - your range 1 is the top range, and is equivalent to my last range, and your range 3 is the bottom range (unless your axis is reversed, in which case you should reverse it anyway....). So check you are sending the correct incr/decr on up/down control respectively, depending on if it the start or end the range... I'm not sure what the issue is if the flaps and wing sweep really are two separate controls. This was/is confusing as your were talking about flaps events to control the sweep earlier, but then reported that they were controlled via lvars (or by using mouse macros). If they really are distinct controls, what I said earlier should work, although not having the aircraft I cannot check and verify here. I have asked Just Flight for a press-copy/developers license to investigate this. If I get one, I can take a look in more detail. Otherwise, I am not sure there is much more to add to what I have already said. John

Then use four ranges...no matter how many ranges, the procedure, irrelevant of the control, is the same: - for the first range, you would assign to a decrement control when entering the range in Down - for the last range, you would assign to an increment control when entering the range in Up - for all other ranges, you would assign to an increment control when entering the range in Up, and a decrement control when entering the range in Down Think about it!

The OP for that post was using lua scripts via FSUIPC7, so that is/was an FSUIPC issue. If your callouts are nothing to do with FSUIPC7, I cannot help. If your callouts are via MSFS (and not FSUIPC7), then I really cannot help with this - use the Asobo forums, as I said, If using FSUIPC7, please make sure you are using the latest version, 7.4.13, released a couple of days ago. John

That really depends on how and what those altitude alerts / callouts are triggered by - can you explain? Are you referring to MSFS functionality, in which case you should probably ask on the Asobo forums, or are you using FSUIPC7 in some way for these alerts / callouts? John

Are not the flaps and wing sweep controls independent then? Can you try assigning your flaps lever to just the flaps set control, and remove the events sent on ranges. you can maybe also try to calibrate your flaps to the detents, as shown in the user guide. Doing this, is this not sufficient for the flaps lever control? For the wing sweep, assign the axis to (unused) and define 3 ranges (for the 3 positions), lets call them 1, 2 and 3. For range 1, you need to send the F3_Sweep_Decr macro when entering the range in Down. For range 2, you need to send the F3_Sweep_Incr macro when entering the range in Up. and the F3_Sweep_Decr macro when entering the range in Down For range 3, you need to send the F3_Sweep_Incr macro when entering the range in in Up Can you try this please and let me know how that goes.

Note also that separate on/off presets are good for assigning to a switch or sticky button, but for a standard button or key assignment, you may be better off using toggle presets: M_LH_Fuel_Toggle#(L:switch_fuel_left, bool) ! (>L:switch_fuel_left, bool) (>K:TOGGLE_FUEL_VALVE_ENG1) M_RH_Fuel_Toggle#(L:switch_fuel_right, bool) ! (>L:switch_fuel_right, bool) (>K:TOGGLE_FUEL_VALVE_ENG2) John

👍

If it is running, you will see a message box to that effect. No - it isn't getting that far. But the first time you ran it, it uninstalled your current version, no? So you must have seen something. When you did this, did you give the UAC panel permission to run the installer? Seems like there is a windows issue where the UAC permissions isn't being displayed to run the installer. No idea why this is. Can you right-click the installer and go into the Properties and check the settings there. If you can't see anything, can you show me a screen-shot of the Security tab, and maybe also Compatibility and General tabs. I'm away for a couple of hours now, I will check later today. Maybe also try googling as to why a UAC permissions panel fails to display. Do you have an account that can be elevated to admin privileges?

There are no specific logging functions for lvars. To see what lvars are available, and what values they currently have, just list them (Add-ons -> WASM -> List Lvars). Did you send the offsets to the log file? As your next post indicates that these lvars work, I would expect there values to change. Try listing them. So that toggles an lvar value and triggers and event. I don't understand that - there are no such lvars as C510L_Fuel_1 or C510L_Fuel_2, so those presets will create those lvars and set the value - is that what you want? Otherwise, simplify to the following, which matches the gauge xml code: M_LH_Fuel_On#0 (>L:switch_fuel_left, bool) (>K:TOGGLE_FUEL_VALVE_ENG1) M_RH_Fuel_On#0 (>L:switch_fuel_right, bool) (>K:TOGGLE_FUEL_VALVE_ENG2) M_LH_Fuel_Off#1 (>L:switch_fuel_left, bool) (>K:TOGGLE_FUEL_VALVE_ENG1) M_RH_Fuel_Off#1 (>L:switch_fuel_right bool) (>K:TOGGLE_FUEL_VALVE_ENG2) John

That is nothing to do with FSUIPC, and is only an informational message. Do you not see any errors, or anything relating to the FSUIPC installer? Did you check your AV? Please do that. So you don't see anything when you run the installer? The first thing that should happen is that windows UAC should ask permission to run the installer - do you see that? Anything else?

Stops when? Or are you saying that it runs the uninstaller, to uninstall the previous version, and then stops? If so, it sounds like it is crashing for some reason. Can you check both the windows Event Viewer for any crash reports (under Windows Logs -> Application), and also check any anti-virus software that could be blocking the installer. What folder are you trying to install into (or where was your previous version installed)? Have you extracted the installer from the zip file? John

What do you mean by 'offset log'? There is no such thing. There is the myOffsets.txt file, which is not a log, but a list of simvars (or a-type variables) to add to offsets. You may be able to add lvars to this, as lvars are now supported by the SimConnect SDK, but I haven't tested (or documented) this yet so I am not sure. To add lvars to offsets, you should use the [LvarOffsets] section of the ini file (see Advanced User guide). Sorry, what does this mean? Do those lvars work to control the fuel valves or not? Btw, it is a good idea to test lvars before using them, using the provided facilities (e.g. Add-ons->WASM->Set Lvar...,).

Well, they won't as you never pitch down for than 20 degrees. I released the next version of FSUIPC7 last night, so the pressure is off, and I am going to have a few days off (well, not off, but more relaxed!). But I don't really have anything else to say on this subject that I haven't already. I don't understand why your original code doesn't always display to one dp (it does here), but I am not going to worry about that. Use any of the three options - your original code, original code + conversion to 1dp, or my code. They are all pretty much the same except for the difference I have already pointed out. Cheers, John

Yes, those are the ones that I couldn't find anything for, as I said: and later: As there is nothing obvious, the next step would be to inspect the xml code to see how that works. I will take another look, but not until the weekend. John

Sure - license sent. John

License sent. John

I tried using a pre-compiled lua and get the following error: *** LUA Error: D:\FSUIPC7\Lua\soundTest2.lua: bad header in precompiled chunk This error is normally due to mismatched compiler versions, but I compiled with 5.1.4 and this is also the version that is built-in to FSUIPC7, so I am not sure what the issue is here. I will update the documentation (for the next release) to state that this is no longer possible. Regards, John

That was pitch-down - I went to the extremes to test! The maximum pitch-up I tested was around 50 degrees: Hmm, strange - I am not sure why, but the code I showed you should always restrict this to 1dp. John

I do not understand the following: 1. why do you have FLAPS_DET, FLAPS_DETENT_SET and FLAPS_UP assigned to ranges on your flaps axis? I would have though just assigning your your flaps axis to FLAPS_SET would be sufficient. 2. why are you also assigning to FLAPS_SET & FLAPS_UP in your wing sweep axis? I thought the wing sweep would be independent of the flaps 3. the ranges on your sweep controls look very strange, as well as the entering/leaving assignments, especially this one on the minimum axis value: 5=2S,B,-16384,-16384,65595,0,M3:1,0 -{ Entering=FLAPS_UP, Leaving=Macro F3_Sweep_Decr: F3_Wing_Decr }- Ok, that's interesting - could I see this explanation please? What type of variables? Can you not use these variables rather than mouse macros? Could you possibly attach a screenshot of the wing sweep and flap controls so I can see how these operate? Thanks, John