John Dowson

So its not in the task bar or system tray, but the process is still running? And there is nothing in the Event viewer? How strange.... Have you restarted MSFS? If not, please do that - in fact, please reboot and try again. If the problem persists, enable Debug logging in the WASM, and show me the FSUIPC_WASM.log together with your FSUIPC7.log generated at the same time. Also, which FBW version of the A320 are you using (stable, dev or experimental), and is it installed via the Marketplace or the FBW installer?

Do you mean that its still running (visible?) but doesn't react to any user input (even alt + F hide/show)? Or do you mean that your controls/assignments are not working? Please explain what you mean.... Try setting the WAPI LogLevel to Trace on your FSUIPC7.ini and show me the log produced. The WAPI runs in a separate thread so I'm not sure how that can cause the other threads to stop responding. Did you have a aircraft loaded and ready-to-fly?

Did it crash? If so, can you please can you please see if there is anything in the Windows Event log, and if so please show it to me. Please try with no ini (i.e. rename your current FSUIPC7.ini temporarily) and another test with your current ini but the WAPI disabled (by changing your FSUIPC7.ini to disable it).

As your question is on MSFS / FSUIPC7, you should use the dedicated sub-forum for this - I have moved your post for you. First, can you check your MSFS assignments and make sure that you don't have any axes assigned there. Did you have an aircraft loaded and ready-to-fly before attempting to assign or calibrate your axis? Unfortunately I don't have any PFC devices and am not familiar with the PFC driver and assignments using that. Maybe @Pete Dowsonwill be able to help... John

Can you also use this version instead - it has extra logging enabled around running luas: FSUIPC6.dll

Could you expand on this please?

Yes, it looks like the Q400_GF_COM1.lua exited for some reason, but BEFORE you activated debug logging. Could you try and repeat this test but with lua debug logging activated from the start? If you can generate such a log file it should hopefully show what is happening in that module and why/when it is exiting. Also, it seems its only occurring with certain aircraft, when you have many modules/lua scripts running, no? Maybe its hitting some inbuilt/hard-coded limit somewhere. Does this issue always occur in the same module (Q400_GF_COM1.lua)? If so, maybe also try re-ordering the order that the lua scripts are started to see if the error occurs in the same or a different module.

It is better to stop everything else and try to reproduce the issue with the minimum number of luas running - hopefully just the one. Did you not try stopping most or all of your other luas and just leave the Q400_GF_COM1.lua running? If not, please try that first and let me know if you still get issues. If not, then try adding things back, one-by-one, until the issue occurs. Ah, so the issue occurs with only one module running? So the event.timer function that runs every second shouldn't have been running, no? But even if it was and the log was huge, please zip it up and attach. I really do need to see the whole log, not just extracts. And no need to add such logging statements - you should just enable lua debug logging, as this will log each line executed. Yes, but I cannot tell if the button was triggered or not when you post selected extracts, which is one reason why I need to see the full log. From that extract, I do not know what logging was activated, for example. I would like to see a full log file of your issue with the simplest possible set-up, hopefully with just one lua running. And then reproduce here so I can investigate. John

Btw, I've just noticed this in the original log file you posted: Are you still getting these errors with the latest version of fSUIPC6, v6.1.4? If so, you should re-install the P3Dv5.2 client as this is usually a sign of some corruption somewhere. Also maybe try the attached lua to see if it suffers from the same issue. Its a pretty basic script that tries to reproduce your issue without any added complexity. You need to change the event,button call parameters for your GF device and button numbers. On my system, this script runs as expected.... eventTest.lua If that script also works on your system, I'll use that as a staring point and add more complexity until it can replicate the behavior you see, either on your system but hopefully (also) on mine, if there is an issue, so that I can investigate further. For the next iterations of the script, I will: - update to use multiple button and offset functions rather than the same function - update an offset in a button function to verify that the offset functions are triggered in such a scenario John

No problem, easy to miss. As long as its working how you would like it to work you should be fine. No time wasted, cheers, John

Have you added any .hvar files to the WASM installation for the aircraft that you are using? If so, I also need to see your FSUIPC_WASM.log file (with Debug logging enabled). If not, please see the Advanced User guide on how to access/use hvars. Some hvar files are provided, in a subfolder called HvarFiles, under your FSUIPC7 installation folder. However, you need to move these to the correct location, and also rename for the aircraft that you want to use them with. Btw, I moved your post to the FSUIPC7/MSFS support sub-forum. Also, you are using an old version of FSUIPC7, v7.2.2. Please update to the latest version, v7.2.8. Only the latest version is supported.

Hi Reinhard, that does look strange, but I need to see the full log, not just an extract. Can you a;ways attach the full log as well in future please (and keep logging for Buttons & Keys, Events and Lua Plugins active, as well as monitoring the offsets to which you have attached an event.offset call). Also useful if you attach the actual lua script (so the logged line numbers correspond). Not sure I understand that log extract - could the button have been triggered (did you have button logging activated)? Again, please attach your full .log file. Did you test with just running this one module? If not, try to do that (i.e. exclude other modules for now) and, if the problem still persists when running just the one module it should be easier to track down. I'll do some tests here with multiple button and offset events registered in a lua (using one of my GF devices as well), to see if I can replicate any of this behavior. John

Yes, that makes sense as it also needs to initialise with the current value, as with event.offset, although it isn't mentioned in the documentation. I will update when I get a chance. Cheers, John

But this should not happen with event.button, only event.offset. Not sure what you mean by this...I will wait for your post in the other thread... If it is, it should be documented as such. event.button should not initialise, I haven't checked the others. Cheers, John

The event.offset function is documented as such in the FSUIPC Lua Library.pdf: So this is intended behavior. John

I'm not sure its by intent, and if it is it should be documented as such. I'll take a look at this later and get back to you. John

I'm not sure I fully understand...Do you mean on your physical throttle? So you would like to calibrate to use only the forward range on your throttle? If so, you can calibrate your axis value in a similar way as you would reverse them - see the section Additional parameters to scale input axis values in the Advanced User Guide (P38). Do you mean this thread: ? If so, I also mention this there. If this is not your issue, could you clarify please. In fact, it may be better to use that previous thread, as this may (hopefully) attract other DC-6 owners/users. Its also good to keep info about DC-6 throttle set-up in one thread.

That implies that you are not using a registered version. Re-install, and make sure you click the Register button towards the end of the installation process, after you have entered your registration details. John

No problem. Note that there is also documentation in French, but for FSUIPC4 (inly) - most (or a lot) of it should be applicable, but some things not. Available from the Downlinks -> Documentation section: John

There is a separate document for Profiles in Separate Files - this is the relevant part: Oh - and do not manually update the [LuaFiles] section - that is maintained by FSUIPC from scanning the installation folder. John

You are using UseProfiles=Files i.e. profiles in separate file. Your [Auto] section should therefore be in your FLYBYWIRE.ini file, and called [Auto] and not [Auto.FLYBYWIRE]. John

To determine where your Community folder is in a steam installation, you need to look in your MSFS UserCfg.opt file, which for steam installs is under YOUR USER ACCOUNT\AppData\Roaming\Microsoft Flight Simulator\UsrCfg.opt Look for the last line, which is your InstalledPackagesPath - the Community folder sit under there. If you are using FSUIPC7, it is also logged in your FSUIPC7.log file, at the beginning as the FS (or FS UNC) path. John

I have moved your post from the .net client dll support forum as it seems your questions are more related to FSUIPC offsets than anything to do with the .net client. To find an offset, please use the Offset status spreadsheet, included in the FSUIPC7 download zip. In that, you can find the brake left and brake right position in offsets 0x0BC4 and 0x0BC6 respectively, as well as various other offsets (e.g. 0x3416 & 0x3418 for axes input values) I don't think this is available. Check to see if held in any lvars, or if using the FBW A320, maybe ask about this on their support/discord channel.

Ok, but I've just released 7.2,8 with a few memory fixes, so you should update to that - includes an update to the WASM as well. Yes, good idea - I will do the same! Yes, looks an interesting beast, although I'm not sure when I'm going to find time to understand and fly this a/c proficiently - I get very little time for recreational flying these days... Cheers, John

No problem. There are still possible memory corruption issues in that version due to excessively long lvar names (>56 chars). I've corrected this now (currently testing) and will release a full version (including a WASM update) later today. This will be the official 7.2.8 release. There will be some issues accessing lvars/hvars with more than 56 characters, and I'm not too sure how to handle this yet, so further work will be required. I will update the Advanced User guide with details.