John Dowson

This was because you had a VRInsight section in your ini - I have removed this in the ini file attached below. Looks like the name of your T.16000M Joystick has changed - it was just 'T.16000M' but is now 'T.16000M Joystick'. This is why your assignments to this device were not recognised. I have corrected for this in the ini attached below. if you are having problems with your lua, try debugging them. I they have errors on your new PC then they would have had errors on your old PC, or they are different scripts... In the log file you have the following: The lua errors should be obvious - you are using functions AB_MPL_LightSwitch, AB_OVH_Pushbutton and AB_MPL_LightSwitch which are not defined anywhere. This must also have occurred on your old PC, or it is a different script. And you only have assignments to keys F1, F2, F3, F4, F6 and F7. No assignments to F6 (116) or ctrl (17). FSUIPC6.ini

For future reference, please only attach files (.log files especially) once you have exited FSUIPC7. FSUIPC7 see's no sign of your device. I'm afraid that there is nothing I can do - you will need help from the vendor with this issue. John

Note also thar you can also run FSUIPC7 on client PCs, and have further devices connected there.

Thanks

i think this issue is related to your other issue (luas not being stopped), so I would like to know if it happens with the latest beta I posted in the other thread, and will investigate if it occurs in that, In fact, use the following version, as this has some additional checks/logging around the same code area: FSUIPC7.exe John

The next time this happens, can you please save the event (as a .evtx file) and attach it, together with your FSUIPC7.log file. I may need a crash dump file as well, but I will try to locate this without this initially.... Thanks, John

Add logging for offsets 0BB4 (ELEVATOR DEFLECTION PCT) and 0BC0 (ELEVATOR TRIM PCT) as S16 using the Log->Offsets facility, and maybe also 0BC2 (ELEVATOR TRIM INDICATOR) also as S16. Also activate logging for Axes Controls. When you get the issue and restart FSUIPC7 and everything is working as expected, zip up your FSUIPC7_prev.log and FSUIPC7.log files and show them to me. John Later: maybe also the spoiler positions, offsets 0BD4 and 0BD8 as U32. You can only log 4 offsets at a time, so maybe drop 0BB4.

Can you please try the attached version which has additional logging. Please activate logging for Extras, and send me the log file when this happens again. I suspect this issue is related to a timing issue where the plane parking state is received before the new camera state, but the additional logging will confirm this. Note that if you continue to have such issues, you can set the following in the [General] section of your FSUIPC7.ini file: KillLuasOnSimStop=Yes But don't set this for the time being.... John FSUIPC7.exe

Looks like I missed adding an additional check in the key assignments code that I added in the button assignments code for this issue - sorry about that, Please try the attached version, 7.4.3a: FSUIPC7.exe Note also that when assigning key presses, always Confirm before pressing Ok, otherwise the parameter will not be saved. John

FSUIPC handles up to 16 devices only (vie the windows API, + 3 additional PFC devices). Each device can have up to 12 axes and 128 buttons. FSUIPC does not do anything special with Leo Bodnar devices - they are just seen as another HID joystick type device. Many people use these cards with FSUIPC. Please try the trial license, available from a post at the top of this forum. John

Lua files, by default, should be placed in your FSUIPC6 installation folder. Line 191 is: event.flag(12,"AB_OVH_Ext_LANDING_retract") There is no such function called AB_OVH_Ext_LANDING_retract in the lua file, hence the error. Can you see the assignment to that button in the button assignments window? Can you set logging for Buttons & Keys as well as Events, and show me an FSUIPC6.log file showing your issue. Also, please attach your FSUIPC6.ini file every time you attach a log file - I need to see these both together to determine what is happening. Note that you also have another error in your log file: John

First you posted un the main support forum - please use the FSUIPC7 subforum for all issues/questions on using FSUIPC7. I have moved you post. If this is a COM USB device, I am not sure if this will be recognised as a standard USB joystick type device. Could you please attach your FSUIPC7,ini. FSUIPC7.log and FSUIPC7.JoyScan,csv files and I will take a look. Then better to ask the vendor how you can get this device recognised by FSUIPC7. Maybe there are additional drivers or software that you need to install?

@shinzz Sorry but it is no longer possible for me to generate time-limited keys for FSUIPC4. I had some disk failures on my old Win7 system a year or so ago, and it looks like the keygen program for FSUIPC4 was lost then. Sorry about that. You will have to purchase a license if you want to try it. Please also note that this is a sub-forum for FSUIPC7 only. Please use the main support forum for any future questions pr issues with FSX / FSUIPC4. John

I will take a look....was an assignments window still open when you went back to the main menu? FSUIPC ignores some events when assignment windows/panels are open, and I was wondering if this could be the cause? I will check here and report back...when I have time. John

You can do this but you need to manually update the [JoyNames] section as your devices GUIDs will have changed. I have done this for you in the attached ini file if you could try it. Any issues, please re-attach your .log and .ini from the same session please. Note you also need to copy across your lua scripts to the new PC - mainly My320functions.lua as you have quite a few assignments to that one... John FSUIPC6.ini

Please see the Offset status guide for offsets free for general use: See section Adding Lvars to Offsets on page 46 of the Advanced User guide. No - that document is for specific additional offsets provided for PMDG aircraft only, populated via the PMDG SDK. There is no such data for the Fenix A320. John

key assignments to what? Can you provide steps to reproduce and I will check this here. John

I don't have the Fenix so do not know which offsets will work for this aircraft. However, to control things such as the landing lights, the HubHob site shows the preset for these use the lvars S_OH_EXT_LT_LANDING_L and S_OH_EXT_LT_LANDING_R, using values 0 = Retract 1 = Off 2 = On~ So you should add these lvars to spare FSUIPC offsets and then you can write to those offsets to control the lvar values and thus the landing lights. You can also send presets to the FS by writing the preset name to offset 0x7C50. You can also directly update lvars using that offset without the need of adding them to a spare offsets if you don't need the ability to also read the value of an lvar.

I will send you a trial license for FSUIPC4, but it may take a day or two before I get a chance to generate one for you. I will PM it to you when ready. John

That website shows how you inspect the aircraft code to aid in developing presets or to figure out how to make the assignment, As a preset already exists, you do not need to do this. What you need to do is assign your button to that preset. In the button assignments window, press your button, then check 'Select for Preset', click the Find Preset... button, then select the preset that you want to use. It should be pretty straightforward....

Sorry, but why would I need that? This is a payware aircraft, no? And I do not have al license for this.... Then why not just use the presets available? As you can see for the calculator code of that preset, you need to do more than just change the lvar value... John

Also, is this related to the other support issue you have raised with restarting a flight? When you do this, you are NOT going back to the main menu, and I am not sure what FSUIPC does when doing this without checking, i.e. luas may not be restarted. As I said in the other thread, I will check this behavior and see if it needs adjusting.

Sorry, but can you point me to what the problem is here? The log file shows everything being closed correctly before exiting: Not sure what us happening here: What were you doing? Looks like you are restarting after 79 seconds, then 20 seconds, then again after 29 seconds.... When you start a flight, it can take 1-2 minutes for all data to be received, all threads started and initialised, luas started, etc...it is just not worth me looking intto issues like this, sorry. Please provide more explanation when you attach a log, and highlighting the issue/timestamp where you think there is a problem. Also, please note that I have limited time for support at the moment due to personal issues (my wife broke her wrist a few weeks ago, so I have to do all the cooking, cleaning, shopping, dog walking, etc etc) and would appreciate it if you could only report any serious issues for the time being. I can look into strange timing issues when time permits, in a few months maybe... John

Ah, that restart.... this should be handled ok, but I will perform some more tests with this, as it is quite a quick turnaround and maybe everything is not terminated correctly before being restarted. It would be easier if this was easily reproduced, but I will try to reproduce here...when time permits... John

Ok, no problem, - and thanks for the update. John