John Dowson

👍

First, you posted in the main support forum. As your question is relayed to FSUIPC7 / MSFS, I have mived your post to the FSUIPC7 sub-forum. Please use this sub-forum for any support requests for FSUIPC7. Yes - we refer to this as compound button conditions, and is described in the Advanced User manual, starting on page 21. You can assign separate actions for key/button press and release. See the user guide - or just try it. There is a trial license available in a post at the top of this forum. John

No. That file is the interface to the WASM module and any changes would require a WASM rebuild, as well as code changes. I have only just increased the lvar limit from 2044 to 3066 lvars. This should really be more than enough and I am not planning on increasing this again - at least for the foreseeable future. John

For FSX, you were using FSUIPC4. For P3Dv5 (and P3Dv4) you will need FSUIPC6. This is a separate/distinct product and you will need to purchase a new license for FSUIPC6 (available from SimMarket). Your WideFS7 key is still valid for FSUIPC6. You will automatically get a discount on checkout if you purchased FSUIPC4 on its own, however the discount is not available on bundle purchases (i.e. if you purchased FSUIPC4 as a bundle with WideFS7). John

Done.

Please try the attached version (I gave not updated the WASM version number - I will do this when I release officially with the next FSUIPC7 release): FSUIPC7_WASM.wasmlayout.jsonmanifest.json Download and use those files to replace the ones in your ..\Community\fsuipc-lvar-module and ..\Community\fsuipc-lvar-module\modules folders. John

First, you have posted in the FSUIPC7/MSFS support forum. As you are using FSUIPC6, you should post in the main support forum. The documentation for 6.1.9 domes with the FSUIPC6 installer. The separate documentation package is out-of-date (I only update that occasionally). Please re-run the 6.1.9 installer to get the latest documentation for FSUIPC6. This functionality is for FSUIPC7 only - it is not available in FSUIPC6. That is on page 36 of the Advanced User manual - as I said, re-run the FSUIPC6 installer. No. As I said I only update this occasionally. The separate documentation package is only provided for people who want to look at the documentation without installing FSUIPC6. All current documentation for each FSUIPC version comes with the FSUIPC installer - you should not download or use the separate documentation package if using FSUIPC - just use the documentation that comes with the version toy download. John

Yes, this is definitely the case - . I will need to rebuild/update the WASM. I will post a version here for you to test when done.

I think thus was because you are a new user and your first post needed approval. You should be ok now. Note, however, this post is quite old now and many things have changed. You no longer need the lua scripts for the Alpha/Bravo for FSUIPC to recognise the buttons > 32 - FSUIPC now recognises up to 128 buttons natively (see my precious comment). John

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