John Dowson

Your log shows the lvars having the same values as the sim shows, except for ASCRJ_VAR_AP_SELHDG: 113766 [INFO]: ID=1553 ASCRJ_VAR_AP_SELMACH = 0.550000 113766 [INFO]: ID=1554 ASCRJ_VAR_AP_SELIAS = 40.000000 113766 [INFO]: ID=1555 ASCRJ_VAR_AP_SELALT = 10000.000000 113766 [INFO]: ID=1556 ASCRJ_VAR_AP_SELVS = 0.000000 113766 [INFO]: ID=1557 ASCRJ_VAR_AP_SELHDG = 0.000000 113766 [INFO]: ID=1558 ASCRJ_VAR_AP_SPDTREND = 0.000000 That looks to have the correct value in the log you showed. I don't understand how the sim can be showing a different value for ASCRJ_VAR_AP_SELHDG (assuming the screenshot was taken at the same time you listed the lvars)- FSUIPC treats all lvars the same, it just receives the name and value from the WASM, so if the value is 0 that is what the FS is sending. I also don't know why I don't see those lvars in the CRJ700 - I'll take another look next week.

Please show me your FSUIPC7.ini and FSUIPC7.log file, showing me your issue, i.e. with the LvarOffset section populating offsets for the lvars you say are always 0, together with your monitoring. Also, please issue a Add-ons->WASM->Log Lvars command, so I can see what lvars are available. I've just taken a look at the AS CRJ 550ER and I get 1752 lvars, and in the AS CRJ700ER I also get 1752 lvars, but I cannot see the lvars L:ASCRJ_VAR_AP_SELHDG or ASCRJ_VAR_AP_SELIAS in either aircraft. Are you sure they exist? If they don't exist, your FSUIPC7.log should show an error when trying to access them. John

I don't know where you got that impression from. It is quite clear on SimMarket, in the download forums here and on www.fsuipc.com which product is for which FS. You can also download and try-before-you-buy. There is a strict no refunds policy (SimMarket) as we do not do on-line license validation, so once a license has been issued it cannot be revoked. It is not possible to transfer a license. However, if you let me know your order number, I will verify your purchase and generate you a complimentary license for FSUIPC7. This may take a few days. In the mean-time, you can use the trial license, available here: John

Yes thre is. For anything relating to lvar access, set the loglevel ini parameter to Debug or Trace. You can also activate different logging levels in the WASM if you so wish. Other logging (i.e. FSUIPC) is controlled by the FSUIPC log flags. All software has bugs....I'm sure there are some in the I/F I have provided, but certainly not anything related to anything you have so far posted... I don't understand this rant. I really don't understand what your current issue is, it seems to vary from post-to-post. Maybe you could clarify. But, as I keep saying. I know nothing about the c# client dll, that should really be your first contact for support if that is where you have issues. If its with the lvars-to-offsets, then please post in this forum, but do not confuse the two completely separate pieces of functionality.

I don't understand this so cannot advise. As I keep telling you, for anything related to c#, use Paul's sub-forum. Yes, if you omit the size, it defaults to an 8-byte double. But are you sure that is a valid lvar? i.e. is it listed when you log the lvars? It doesn't appear in the MF spreadsheet in the ASCRJ tab... Note also that some lvars are read-only, so you cannot change their value. You seem to be keep coming back with more issues when the topic for this issue is now closed as far as I can see. Can I lock this topic now? If you have any other issues, you can create a new topic for that issue. John

Yes, you can do that. However, there is a limit on the index number, so be aware of that. I think it should be ok up to 2099... As a side note, I have been thinking about this issue for a while now. I am thinking of implementing an 'include' directive. So, you could do something like: [Buttons] (or [Buttons.<profile name>] Include=G1000 1=/// ... [Include.G1000] 1=... However, if/when I implement this, it will still be a manual process to: - create the include section. Basically, once you have assigned all functions to a specific item, you would need to manually remove these and create the include section yourself - You would then need to manually edit your profile section to add the include directive And I need to consider how to handle conflicts - should they augment or replace? And more complicated when you consider the general sections + profile sections (currently axes assignments replace, button + key assignments augment). There is also an issue with lvars - they really should be a/c specific, not profile specific. I will also add a mechanism so that lvars can be a/c specific, so that different LvarOffsets sections can be used for different a/c within the same profile. However, please note, I am not doing any development at the moment. I am on a holiday at the moment (or sort of...). I am only covering support and implementing bug-fixes. I am leaving any new development until mid-September . I will advise if/when I get around to looking at this in detail. Cheers, John

All offset addresses map to a physical memory area. Well, in most cases. There are a few offsets that are ghosted, i.e. mapped to a different memory area. However, this is only for a couple of specific offsets and does not apply to the free user offsets. These ghosted offsets are used when the offset size has increased but there is no space left in the standard offset area to increase the size.

Yes, of course. You have to do this for 2 reasons: - if you used A001, for example, then you would be overwriting the 4bytes set in A000 - 4-byte values must be aligned to a 4-byte boundary Yes, it matters. If it didn't, you wouldn't have to specify (and everything would be 8-byte doubles). You don't need to specify if its an 8-byte double, as that is the default. John

Those switches are outside the 32 button limit (0-31) supported by FSUIPC4. To use these, you need to use lua. Please see Hard-programmed how? If you've disabled controllers in FSX it can't be in FSX. If assigned in FSUIPC, you can clear them. However, note that if you have multiple assignments to those switches, they cannot be cleared by using the UI. You need to edit the FSUIPC4.ini file directly to remove the assignments. John

Try changing your[JoyNames] section to the following: Also, please update to the latest FSUIPC6 version, v6.1.4.

No, they are normal and can be ignored. They are messages from the WASM interface (WAPI) produced when trying to close down the connection to the FS gracefully by clearing the simconnect client data areas (CDAs), but the FS (and simconnect connection) is already closed/killed.

Yes, that would have been the issue. However, I'm surprised that there were no FLAPS_INCR or FLAPS_DECR controls logged as well, coming from FSUIPC, which is why I asked for the additional logging. However, if its now working then there is no need, but still strange... John

Yes - you can just rename your FSUIPC5.ini to FSUIPC6.ini (and move to the new installation folder, if changed). However, I don't think you need to upgrade your FSUIPC installation if not intending to update to P3Dv5. There are some new features in FSUIPC6, but the only change to the AS interface in FSUIPC6 is related to P3Dv5.

As I said: Buttons 21 and 22, as your images show - but the ini is a lot more readable for me, not sure why you posted those images.

You need to create the profile for the aircraft BEFORE you create the LvarOffsets section for that profile. Please see the User Guide for information on profiles. Not sure what this means. If its 0, you toggle it and it changes to 1. You toggle it again, and it changes back to 0. What affect this has on the aircraft is up to the aircraft model, which is outside the scope of FSUIPC.

Your log shows FLAPS_UP and FLAPS_DOWN controls being sent, and not FLAPS_INCR and FLAPS_DECR, which explains the issue - parially. Can you check your assignments in MSFS for the buttons you are using for the flaps in the T-45C, as these controls are not coming from FSUIPC. Also, your flaps in/dec are assigned to different buttons in different profiles. Can you please generate a new log for me, the same as before but also activate logging for Buttons & Keys. For the T-45C, your flaps are assigned to your Warthog Throttle.

Please enable logging for Events, produce a short log file where you just start MSFS, load your a/c then operate the flaps (inc + dec), then close down and show me yout FSUIPC7.log and FSUIPC7.ini files.

If you are assigning the axis in FSUIPC7, then yes, you need to remove/delete the axis bindings in MSFS. In fact, if assigning in FSUIPC7, we recommend initially starting with an empty controller profile in MSFS. To do this, simply create a new profile for you controller in MSFS, which will be empty by default. Note however, unlike in P3D, it is fine to mix and match assignments between MSFS and FSUIPC7, so you can keep the MSFS default profile if you like, but make sure to unbind anything you decide to assign in FSUIPC7, otherwise you can get dual and conflicting assignments.

Ah...if using 8 bytes, then the offset needs to be aligned on an 8-byte boundary, e.g. last digit must be 0 or 8. Similarly, if its 4 bytes, ir must be aligned on a 4-byte boundary, eg last digit 0, 4, 8, or C, and similarly for 2 bytes (last digit 0,2,4,6,8,A,C,E). I will add this to the Advanced User guide. Try the following: Then monitor 0x66D0 as a FLT64. John

What has changed, if anything? They should be recognised as buttons. What controller are you using? Have you installed any specific drivers or software for the controller? If so, try uninstalling and let Windows install the default drivers. Also, please show me your FSUIPC7.log, FSUIPC7.ini and FSUIPC.JoyScan.csv files. Also, note that the PAN VIEW axis control for the hat no longer works in FSUIPC7/MSFS. To assign a POV hat switch in FSUIPC7, you need to assign to the key control bindings assigned in MSFS. John

Thanks @forstmeier! Later: but difficult to download. You say via email request, but the links you provide do not offer any assistance - you are just presented with a sign-in dialog when you try to download. Due to this, I suspect there will be little interest, IMHO. Ok, didn't read the page carefully enough...now I see the email request...

Thanks @Paul Henty!

With a line number or something, yes, I could look into it. But I can't do anything with an access violation location in an app that I don't have. As the users that are getting this are developers, they should try with the debug-enabled versions of the WAPI/WAPID (and also your .net client dll) to see if they can get a stack trace, which would be more useful. I can provide the .pdb files if needed (or the WAPI/WAPID repos can be cloned to recompile to generate). I just don't think there is anything I can do at the moment with the info provided. John

Then you need to debug your application and get a stack trace to determine where the error is. You can use the debug versions of the WAPI and WAPID - both are open source and available in github. I cannot debug your application for you. Of course, if there were any issues in the WAPI/WAPID I would fix them, and if its an issue in Paul's client dll then he would look into that. But I do not support C# development - you are really in the wrong forum and should use Paul's .net client forum. If it turns out to be an issue in the WAPI (which I doubt as its been used quote heavily in FSUIPC now for quite a while) then I would take a look. But I can do nothing with an exception report from an app that I don't know. Yes. Trial license available from However, I really don't think its worth purchasing a license just for the lvars-to-offsets functionality. it would be vetter to resolve your issue.