John Dowson

All your settings are saved in your FSUIPC.ini file (so FSUIPC5.ini for FSUIPC5, FSUIPC6.ini for FSUIPC6, etc). You can also save your .key file (which contains your registration details) and any .lua or .mcro or .dll files that you use. Also, before you do this, make sure that you are using the JoyLetters facility. Your device GUIDs may change if you re-install windows, and it will be a lot easier to remap your settings if you are using JoyLetters.

I don't think that would work due to the way the WASM will automatically reload lvars on an aircraft change. Its a lot easier to handle if the WASM module already had the lvar lists available, rather than filtering on a call post-load....

You can use as many event files as you need. I was just thinking that you could split the events into different files, so AS1000 events in one file, AS3000 in another, etc. Then, if using something like SimStarter, you could just load the files for the events needed for the loaded aircraft. However, there is no issue having all events available for every aircraft.

I can increase to allow however many are needed, although updating to handle more than 1024 lvars is a bit more work. I can do this (in a later release), but before doing this I would also consider other possibilities to maybe reduce the number of lvars requested to those that are actually being used. Something like I proposed in the Announcement:

The joy ids used are assigned by windows and taken from the registry. They do not need to be consecutive. Do you actually have an issue?

How many lvars does the CRJ have? The WASM currently supports up to 876 lvars, I can increase this to 1024. I am planning to make a new release in the next few days anyway - with a few extra functions in the API (mainly a creatLvar function needed by FSUIPC), I will update to handle 1024 lvars in this release. John

Did you try just clicking Yes to allow FSUIPC to run? If it continues to mistrust the FSUIPC4.dll, see this FAQ entry: John Later: I see Pete replied at the same time!

As @jaxx says, please check you are using the correct version. If you still have the lua scripts active, the buttons will still be recognised but you will get two buttone presses - one for the "real" button and one for the virtual one (with device number 64 or 65). Of course, the UI will only show one of these, but if you 'ignore' the initial onw shown and press the button again, you will see the other. To prevent this, you should remove the lua scripts when using the 7.1.0a beta version and just use the "real" button for assignment.

P is the action (Pulse). B is the joystick - you are using "JoyLetters" so the assigned letter is used. The mapping from joyletters to ids is stored in the [JoyNames] section of your FSUIPC7.ini file. 35 & 32 are the button numbers K123/K122 are the keys (F12/F11) 8 is the shift parameter (normal) PB is <Action><Joy#> , or maybe better as <Action><JoyLetter>

The license applies to all versions. If you need the new functionality to directly assign more than 32 buttons, then yes, thats the version you need. However, the license is the same for all versions. Attached is a trial license valid until 10/04/2021. Just download and save into your FSUIPC7 installation folder. Note that this license will NOT validate in the installer. John FSUIPC7.key

I haven't really thought about this, but its open source, no restrictions, use an adapt as needed. Thats fine - I have no issues with using/changing or redistributing. A comment on the original source would be nice, but I'm also not bothered about that either really - use, change and re-distribute ad you like. I also have more of an idea how this can be used in managed c or, more generally, by any other language. I am aiming to upload a new dll library project in the next few days, that will use the currently provided API but expose them in a dll so that they can be accessed in other languages.

As Pete says, please see the documentation. If you are having issues, please show me your FSUIPC7.log and FSUIPC7.ini files.

Thanks - I added the links.

What is 69632 - is that a custom control number? I have no idea what that is or how you would access via FSUIPC, unless it is one of the values added to the PMDG offset area. Are there changes to the SDK that require an update of the PMDG offset area? Maybe if you can show me the latest SDK header file I can compare it to the one we used the last time we updated the PMDG offsets, to see if it has changed.

But where are they getting the values from? You also say so I presume the offsets are holding the correct values. To make sure, you can log them using the Offset logging facility. If the offsets are correct, there must be something going on with how your external display is getting these values.

If you are assigning in FSUIPC, best to start with an empty profile in MSFS for that device. If you create a new profile in MSFS, it will be empty by default, so just do that for each of your controllers (except mouse and keyboard, and also leave the default profile for the xbox one or 360 controller if you have one of those). What do you mean 'nothing happens'? You should assign when you have an aircraft loaded and ready-to-fly.

Which aircraft? And as @Djeezsays, make sure you are using the latest official version ot one of the beta's (7.0.8, 7.0.9a or 7.1.0a)

Ok, thanks for letting me know.

Better to keep your TBM as profile specific. You can copy your TBM axis profile section to the general axis section, then that can be used by other/all aircraft (not in a specific profile) and also change as needed (without affecting the TBM). You can then import those assignments when you create another new profile (although you can do this also by specifying a new profile based upon your TBM one). It is always a good idea to have at least the main axes defined in your general axis section. If you experience your issue again (i.e. axis controls not wprking), then please show me your latest FSUIPC7.ini and .log files from that session.

Is anyone using this beta release? If so, I would appreciate some feedback. Thanks.

Not much activity here - is anyone using this? Any feedback would be appreciated, both positive and negative. If nobody wants/needs the access to the additional buttons, I can drop this update for FSUIPC6.

What do you mean by ' FSUIPC7 is sending 4 Digits only from the FS'? The COM1/COM2 frequencies in offsets 0x034E & 0x3118 are in BCD format (4-digits only). Try offsets 0x05C4 & 05C8 which contain the frequency in HZ as 32-bit ints.

Well, there is always some logging, but yes, you can activate the axis controls logging when you start your landing procedure. You could also maybe log offset 0x0366 (as U16), SIM ON GROUND, which will then add a log entry when you touch-down so I can tell when your ground steering starts.

Yes - FSUIPC6 is installed in the folder you chose (or accepted) during the installation process. It will default to your previous installation location, if either FSUIPC5 or FSUIPC6 is already installed. If not previously installed (which would be your case if you just installed P3Dv5) it will default to either the location of your add-on.xml file (if it does, you should change this) or maybe c:\FSUIPC7 (I can't remember if I made that change to FSUIPC6, sorry). But, this is all explained in the provided Installation and Registration document - please see that. John

There is no point attaching a log file without axis logging enabled - it doesn't show me anything! And its very strange that you say that it sometimes is working and sometimes is not working...there must be something different going on in each of these situations, and you need to try and work out what is causing this. The logs can help. So, as I said, please activate logging for axis controls. This can generate large log files, but don't worry about that (you can always zip them up to show me them). Then, try and capture a log for when it is working and for when it isn't (with same aircraft/assignments). Then compare the logs to see if they reveal anything. You can also zip them up and post them and I will take a look. It may also help if you keep the log/console open so you can see the log in real-time. You can also start a continuation log (so that the landing sequence is isolated in its own log file), but if you do this I still need to see all the log files generated, not just the last one.