John Dowson

I have just checked your details and they verify correctly here, in both the installer and in FSUIPC7. So, please follow the instructions on re-installing the VC++ redistributables from the provided README.txt,

That WASM log is from a different session to your FSUIPC7.log. I always need to see both files from the same session. Please remember always to attach both. And was Debug (or Trace) logging enabled in the WASM? Keep Debug logging on, as a minimum, for the time being. Other than that, your log files show that the WASM & FSUIPC7 are running normally, and you are sitting in the main menu having not loaded an a/c yet. That is a very old version, not the previous version. This version works for most people (i.e. everyone else!), I don't know what your issue is. Did you try disabling everything else (e.g. VRI device) for the time being, as advised?

Can you try downloading again and re-installing. This is very strange.....

Your logs show it crashing (or stopping) at different times. Very strange. Do you have anything else running? Maybe disable your VRI device (rename the driver) and stop anything else running for the time being.

I need to see your FSUIPC_WASM. log as well please...and also check for application events...

And can you activate Trace logging in the WASM please? Everything looks ok so far in the logs provided, Can you maybe also try setting the LvarScanDelay parameter in the FSUIPC7_WASM.ini to , say, 45 or so (min 30). This will delay the scanning of lvars until the A320 is fully loaded, which takes time.

Please NEVER post your key details in a public forum - this violates the license policy. I have removed them from your post, but If you post your key details again they will be banned from subsequent releases of FSUIPC7. You also posted in the wrong forum - please post in the FSUIPC7 / MSFS sub-forum for issues with FSUIPC7. Did you read the section 'Invalid Key Problems' in the Installation and Registration guide? If not, please do that first. Not sure what that means. Your question only just came through (for approval) for some reason.

So it is crashing? i.e. there is not process still running? Presume its also not in the system tray. no? Or is there a process still running/visible? I'm sorry but I am asking specific questions and you are continuing to be vague (continually just saying it has 'stopped'). I am trying to determine if the process is still running or not - it is either still running (but not working/doing anything) or has crashed - which is it? By 'stopped' do you mean has 'crashed'? Not sure what 'logbooks' is - did you check the application events? Of it has crashed (not just 'stopped'), then there should be an event logged. Try searching for it - or check the Advanced User Guide, P45: Your log files are showing different numbers of lvars found each time, and is stopping (or the log is ending) at different places each time. Very strange. Could you tell me how you installed the FBW A320, as previously asked - using the FBW installer or the MSFS Marketplace? And are you using the latest version? Maybe also test with anything else (e.g. MF WASM module) removed from your community folder - just leave the FBW A320 and the FSUIPC WASM modules for now.

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.