John Dowson

First, you posted in the FAQ section where it explicitly says NOT for support requests. I have moved your post for you this time, but please take care to post in the correct forum for any future support requests. There are so many posts on this topic now. There are dedicated lua scripts for the Honeycomb Alpha and Bravo, please see If using the Bravo, to control the LEDs you can also use this: John

First, you are saying you are using offset 0x66D0, but your script is actually using 0x66E0 - just FYI. But the main problem is that you have wrapped the calls in a function - what is calling the function? If you are assigning the script to a button press, then you don't need the function, i.e. just ipc.macro("RJ85LNAVPress: press") ipc.writeSW(0x66E0,1) Otherwise, you could add an event.button() call to call the button on a button press - this would be more efficient as the script would not have to be recompiled each time it was executed. You are also setting this value as a signed word (SW). Thats fine, but if it is only holding 0/1, you could use an unsigned byte. John

This is a very general question that depends on many things (e.g. your devices!) that I can't really answer - its up to you! I suggest you check the Aerosoft forums, as there are many posts there on how to use/configure the Airbuses with FSUIPC... If you have any specific questions then I can look into it, but you really need to do the initial work yourself - I don't own or use those add-on aircraft. John

Hi Cristian, I suspect that that is controlled internally by the gauge, so would need access to lvars to control, which aren't available in FSUIPC7 yet. Is there any way to control this via MSFS assignments? If not, I'm afraid that this won't be possible via FSUIPC7 at the moment. John

Note that these scripts are no longer needed with FSUIPC6/7 as FSUIPC recognises up to 128 buttons natively (without the need for a lua plugin) since around May/June 2021 (FSuIPC6 version 7.1.0 and FSUIPC6 version 6.1.0). To assign to the buttons on the Honeycomb Bravo and Alpha controls, you can use the attached lua scripts. They need to be placed in your FSUIPC installation folder, and an entry added under the [Auto] section of your FSUIPC ini file to start the lua (or luas) automatically. These have kindly been adapted from the HidDemo.lua by @spokes2112: hidAlphaButtons.luahidBravoButtons.lua ALPHA buttons greater than 32 will be on joystick #64 with 32 additional buttons provided. (0x3340) BRAVO buttons greater than 32 will be on joystick #65 with 32 additional buttons provided. (0x3344) If you require further details, please see this FAQ entry here: John

It should be possible to adapt your script for MSFS. There are issues with the SimConnect_Text function in the MSFS SDK, so the lua functions that use these will also have issues. You can use (or adapt) this user contribution to request user keyboard input in MSFS: John

Can you please attach your screenshot, or, better still, just describe your issue. I cannot access that link. Presumably you pressed the Register button, no? If not, please re-install and do that. If you did press the Register button, and it says that your registration wasn't valid, then please ignore and try and start FSUIPC7 to see if it runs. If it runs ok, then let me know your order number and date of purchase and I will check here. If it doesn't run, then its almost certainly due to your VC redistributables either being corrupt or not installed. If that's the case, then you need to uninstall and re-install the VC redistributables. There have been MANY posts on this issue already (and also mentioned in the included README.txt, although it doesn't say that this causes a registration failure, but it has been known to do this in a small number of cases). If you have any difficulties, search this forum for similar issues where you will find further details. John

I'm not sure what you mean by 'offset tutorials'. It really depends upon what you want to do. The offset area is just a memory area that holds data from the FS that can be read, and also allows certain areas to be written to to update the FS. There is comprehensive documentation included in your windows documents FSUIPC7 folder. Please also see the User Contributions and FAQ section of this forum, which can give you an idea of the sort of things that people are doing with FSUIPC. John

I've not heard/read of this bug, and I have never found a need to do that, so I guess not.

As you know what causes this issue, you just need to eliminate that. i.e this: Why is it doing this? Where is this assigned? Maybe you can attach your FSUIPC7.ini file, and and Fsuipc7.log file generated with event logging activated and showing your issue. Also check that you have an empty profile assigned in MSFS, or at least that you don't have assignments in both FSUipc and MSFS for the same buttons/axes. John

Ok, then thats the exact issue in the thread (link) I posted, distinct from this issue.

Seems there is something funny happening, as your Bodnar cards have the same product and vendor ids, but different serial numbers. When both are connected, both GUIDs are attached to one card: However, they seem to be acquired ok with the correct GUIDs So assignments should have gone to the correct device. You seem to have yoke assignments to both your E (yoke) and C (2nd TQ6) devices): eg That also has a throttle assignment to your E device (yoke) on axis Z.... So, it seems that the assignments to the two bodnar devices are being confused somehow. I'm not sure whats happening, or how you got into this situation. I'll take a look and discuss with Pete, but this will take a while (i.e. next week sometime). You could try the following (make a backup copy of your ini first): manually edit your FSUIPC4.ini, and change any assignments that you know are for your yoke (i.e. that have the letter 'C') to a letter 'E'. And also check your assignments to the 'E' device, and change those to 'C' if they're for the 2nd TQ6. Then repeat your tests. It would be interesting to know if the corrected devices and axes are recognised with those changes. John

Hi Enrico, sorry for the delay with this one... Could you try the attached version please v7.0.4e. In this version, you can add a new ini parameter to the [General] section: AdjustNavForMagVar=Yes When this is present, the magnetic variation (from offsets 0x0C40 and 0x0C42) will be added to the Nav1/2 values in offsets 0x0870 and 0x0844 (whenever either is received). FSUIPC7.exe John

Just checked your logs and inis. For your test 3, the one where the yoke was not working, you used the C152II Calypso. This is using your Cessna_Piper profile. The axes assignments in that profile are: i.e. the elevator/aileron are assigned to the 'C' bodnar device, which you removed, not the 'E' one. Thats why its not working. John

You are using an old unsupported version of FSUIPC4 - latest version is 4.975 / 4.975a. Can you please update.

It is not resolved, but it is a known issue with MSFS, which is why it was closed. Thus issue is caused (as far as I am aware, but please check the Asobo forums for a more detailed problem description) when there is an assignment to a *_SET command (in MSFS, including ley presses assigned to such commands) to a button that continually fires, such as those on the Honeycomb or the Thrustmaster Warthog. Assigned in FSUIPC? Do/did you have it on repeat? I have no idea what you are talking about here. Which version of FSUIPC was that? What was it called and what did it do? There is nothing I know of relating to this in FSUIPC5/6/7. I can keep this open, but as this is a known MSFS issue, there is nothing I can do in FSUIPC to prevent this. John

That's one of the new events/controls added from the 0.9.0.0 SDK. If its being triggered all of the time, you can ignore by using the DontLogThese ini parameter (see the Advanced User Guide), now also available in profiles so that this can be tunes for each aircraft. There's also a tool in the User Contributions section to determine which controls to add to this for each aircraft - this was written before the DontLogThese ini parameter was added to profiles, but may still be useful for determining which controls to add. See John

There is a known issue introduced since December where using more than 10 devices can cause a CTD - see https://forums.flightsimulator.com/t/immediate-ctd-opening-control-options-1-12-13-0/338558. I guess this may be a cause for some folks. However, there is also the SimConnect data issue (link previously posted) which I think is the main cause, especially when this occurs after several hours into a flight. Both issues need to be resolved by Asobo, and anyone experiencing such issues should raise a zendesk issue with Asobo and attach any windows crash event logs.

The offset status document will be in your windows documents folder in a subfolder called FSUIPC7. This document has not been fully updated for FSUIPC7 yet, and so a specific spreedsheet called offsetStatus-vx.xx.ods is also included in the downloadable zip file. Sorry, don't understand this - google translates as 'how can I configure the funeral with an IOcard'! John

👍

If using the FBW mod, make sure you also try with the vanilla A320.

Looks like it 'adds improved recording and replay features to FS' , from here. You can disable it by editing your dll.xml and changing the <Disabled> entry for that module to True.

Yes, thats the case. Only one timer per lua plug-in. Yes, as re-running a script kills the thread in which the original was running. John

Well, I added them for you to try this - the AUTOBRAKES ACTIVE flag at offset 0x0C46 sounds like what you are after, but I haven't checked if this is populated in the A320. Both offsets are read-only.

They are bools, so 1 or 0.