John Dowson

Check your AutoSave settings (Options->AutoSave). Change the number of how many files to keep to 1 (it is probably using the default of 5). John

Ok... you could have mentioned this earlier... This is the old topic: In which my last comment was: i.e. you should have posted in that topic and we could have resolved this a lot quicker! I will PM you a new key later today or tomorrow. For the time being, you can download and use the trial license/key file, available in a sticky post at the top of this forum. John

It should be 1024. I suspect that it is a logging statement somewhere that doesn't have a buffer big enough (using sprintf rather than sprintf_s as I should...!). I will look into it and get back to you. 3066 is currently the maximum of lvars available via the WASM, as this is also restricted by the number of LVAR CDAS: #define MAX_NO_LVAR_CDAS 21 // 21 is max and allows for 3066 lvars - the max allowed for the 3 value areas (8k/8) is 3072 So you have already hit the limit. No. First, the WASM.h file is shared between the WASM and the WAPI and any changes to that file would require both the WAPI and the WASM to be recompiled. Second. as the current limit is actually defined by MAX_NO_LVAR_CDAS, this would also need increasing (you need 7 LVAR CDAs for each lvar value CDA created). MSFS seems to load/keep lvars from previously loaded aircraft, as well as from aircraft just installed in your Community folder. It is recommended to clear your Community folder of aircraft not being used (as well as anything else) before you start MSFS/ Lots of people use the MSFS Add-on Linker program (freeware) to do this.

As long as the alt key combination isn't already being used by the application as a menu short-cut, then you should be fine using the alt key as a modifier. It is the windows / win key that is problematic these days and shouldn't be used.

Ok, but maybe you could post the solution you used ai that it can help others which have this aircraft.

its John - Pete retired a few years ago... I'm not sure...I was going to suggest giving the focus to a different window other than vPilot (if it is being used as a hot-key), but that seems to be what you are doing... You could try with using the Alt modifier rather than Ctrl...Alt modifiers have a special meaning (usually keyboard shortcuts for windows' menus and menu items) and may bypass the "ding"... otherwise, you could try disabling the beep in windows - see https://bznep.ourproperty.co.uk/articles/disable-sticky-keys-warning-beep-in-windows-10/ John

Yes - you can add/subtract a number to the scaled value to shift the centre position... however, that will also shift the max/min values being outputted. It sounds like you want the input values from 16384 to 14300 to be scaled to -1 to 0, and for values 14300 to -16384 to be scaled to 0 to 1. That is not possible (i.e. separate scaling for +ve and -ve vales) using axis scaling - you would have to write a lua script. You could try just adding to the scaled value to shift the centre. This would, however, give a value > +1 for max thrust (effectively reducing the +ve thrust range and making it more sensitive) and won't reach -1 for reverse thrust, but may be useable. So if you are currently using a scaling factor of *-0.06103888176 (you don't say!), you could try *-0.06103888176,+0.872856. It may be better to change the scaling for the positive thrust only, and so use *-0.0326115,+0.4663 - that should give you a full forward thrust range between 14300 and -16384, but would only give a small negative thrust range when between 14300 and 16384. You could maybe also try explicitly setting a lower value when entering the reverse range using the right hand side of the axis assignment dialog... But for proper control (with appropriate scaling for forward/reverse thrust), you would need to use a lua script.

You could also try directing the key stroke using the windows class name - again, see the WideFS technical guide. To find the class name of the window, you can download and use Spy++. John

...of course, there will be added complications if you dont want to use the -1 to 0 range to control reverse thrust... Maybe better to calibrate only for the 0-1 range for forward thrust, and if you have a detent button in the thrust axis for reverse you can assign that to set a value of -1 to activate reversers... Otherwise, you can assign your axis to write the axis value to an offset but not use the lvar offsets, but use a lua script to get the offset value (using event.offset) and then scale/adjust the value accordingly and set the lvar value in the lua script....

Ok, so then it is not an integer and you should use a 4-byte floating point number, e.g. [LvarOffsets.HA420] 1=L:THROTTLE1_SET=F0xA000 2=L:THROTTLE2_SET=F0xA004 and use/assign to the Offset Float32 Set/1000 control. Then, depending on the input axis values max/min, you would then need to add scaling (via editing the FSUIPC7.ini) to convert the numbers to the -1 to + 1 range. So, if the input range was -16383 to +16383, the Offset Float32 Set/1000 control will output -16.383 to +16.383. To scale that to a range of -1 to +1, you would need to multiply by 1/16.383, ie. use a scaling factor of *0.06103888176. If the input range is 0-16383, you would also need to subtract to get the negative range, and also scale by 1/8.192, which would be a scaling factor of *0.1220703125,-1 (as the multiplication must come first).

There shouldn't be too much of a lag...you could maybe try increasing the poll rate in the lua, although the default of 10ms should be enough. It may also depend on what the assignment to the button flags are doing. If, for example, they are updating lvars, you could try increasing the lvar update frequency (in the WASM). This defaults to 6Hz, but can be changed to Frame ort VisualFrame for faster lvar updates. I also provided a version that uses event.button although not as flexible as yours - I have attached it for your reference: RotariesEvent.lua The interval between a press and release is usually determined by the hardware driver software, There is the PollInterval ini parameter, which tells FSUIPC how often to read/poll the state of the joystick buttons. However, as this defaults to 20ms (40 times per second) I doubt that this would have any affect, and the limit wo;; be set by the driver...

One other useful testing technique is to use the Add-ons->WASM->Set Lvar... menu item - you can use that to set the lvar to different values and see how the throttle behaves - for example, try setting L:THROTTLE1_SET to 16383, and see if that moves the throttle 1 to full throttle, then try 8192 and see if that is 50% throttle...

Do those lvar values change as you apply thrust? If so, you could try logging the lvar values for min/max thrust to see what values they hold. Otherwise, I would expect that they would duplicate/pass through the value to the standard Throttle Set control, which expects a range from 0 - 16383. If so, you would need to store as a 2byte unsigned word (UW) and assign to the Offset Word control. If the axis you aree assigning has a range of 0-16383 then no scaling is necessary, otherwise you would also need to scale, depending on the axis input values (which you can see in the axis assignment panel). John

An offset in an offset area that is designated as 'Free for general use' in the FSUIPC Offset status document. Such offset areas are: 0x66C0 - 64 bytes 0xA000 - 512 bytes 0x2544 - 184 bytes 0x2644 - 68 bytes ...etc

I don't see how this can be so temperamental...it is very strange that some users are having so many issues with the auto-start... You should check the FSUIPC7.log file to see if any errors are reported when this occurs...FSUIPC has no control over the gauges, it will only control the inputs, when assigned, so I can't see how this is related to FSUIPC... John

This does sound very strange...and I can't see how FSUIPC can have anything to do with this as it does not delete anything and does nothing with mouse clicks, unless recoding a mouse macro. I will test this later, but could you show me your FSUIPC6.ini file as well as an FSUIPC6.log file generated when you experience this strange issue... John

Latest version is 7.3.6. When re-installing, you do not need to re-register or re-validate your registration if re-installing into the same folder - you can just Skip. But I cannot understand your issue - you must be running FSUIPC7 from a different folder that does not contain your key file. Please download and install the latest version. If you accept the defaults, it will install in the same folder (it will run the uninstaller first to uninstall the current version) and your key and ini file should be preserved. John

There is a list of standard controls in your FSUIPC7 documents folder, called Controls List for MSFS Build 999.txt. However, many standard controls do not function with PMDG aircraft. You can check the Mobiflight preset list (see https://hubhop.mobiflight.com/presets/) which will show you the available presets. You can either assign to these directly in FSUIPC7, ot you can look at the preset code to see what that uses - many PMDG functions are controlled via specific parameters to the Rotor Brake control. These should also be documented in the PMDG SDK, and I believe there is a list/spreadsheet available somewhere (try google). Otherwise you can try LINDA, as suggested by @Scotfleiger. Not sure what you mean here...that sounds like two different aircraft. Just set-up a profile for each.

Ok, but which lvars? Looking at your ini, you have assigned to lvars THROTTLE1_SET and THROTTLE2_SET as single bytes: What is the range that those lvars accept? Unless its only 0-255, you should increase the size to 2 bytes (UW) or 4 bytes (UD). And if they accept negative values, then they also need to be signed. And your assignments are just setting the axis value, with no scaling: as the raw axis value will range from either 0 - 16383 or -16283 - + 16383, you will need to scale the axis value to fit in a single byte. That is explained in the post you referenced. To set this up, first determine the range of values that those lvars hold/accept, and size the offsets accordingly. Then assign your axis to those offsets with the correct control for the size of the offset. You may then need to add additional scaling depending upon the values received and the values expected - to do this, see the section on scaling input axes values on P41 of the Advanced User guide. John Later: also please update to the latest FSUIPC7 version, v7.3.6. You are using 7.3.3, and only the latest version is supported.

I don't think so - the PMDG 737 seems to use parameters for the Rotor Brake control for the custom controls. Take a look at the PMDG presets on the MF HubHop site (https://hubhop.mobiflight.com/presets/), or you can look at the preset calculator code for the PMDG presets in the events.txt file (which will be in your FSUIPC7 installation folder). I doesn't have to receive both signals, but how you assign to such buttons/switches will depend on the signals received. Also, assign to a button repeat will not function correctly if no release on a button is received, so you cannot assign to repeat. John

Try activating logging for Lua Plugins and Events, and see if you can figure out what is happening. As this script also use Linda, I'm not sure I can help that much. Try logging to see if anything stands out, but it may be worth posting in the User Contributions thread for this script to see if the author can help you. John

Why is vPilot always waiting for text input? That seems strange... Have you tried explicitly bringing the vPilot window to the foreground using the Focus command (see the WideFS technical guide)? If not, maybe try that... John

The easiest way to achieve this is to add the lvar to a free FSUIPC offset and then assign to the FSUIPC offset inc/dec or set controls. See the section Adding Lvars to Offsets on page 46 of the Advanced User guide. Try following that and post again if you have issues. John

I have moved your post to the FSUIPC7 / MSFS support forum. Auto-save in FSUIPC7 works in the same way as autosave in other versions of FSUIPC. However, FSUIPC just relies on the SDK provided functions for this feature. Some folks seem to be able to use this feature without issues with MSFS/FSUIPC7, while others have issues. Best to try it before you buy - there is a trial license available in a post at the top of this forum. John

Ok, thanks for the info. Ok, so the Ex1 controls work for the throttle in the Fenix - that is good to know, thanks. John