Scotfleiger

Morning Pete I will look at the LINDA code later for other use of the LFS calls. I concur with your caution. Leave things untouched at present. I have found a solution to my problem that works fine. Andrew

Just one addition point. The LFS use of relative pathnames does move with the new add-on aircraft file locations. However, I found I use relative pathnames in other places with io.open instructions and these still index to the fsuipc /modules folder. These are unaffected. Strange!

Hi Pete Sorry for any confusion. The loaded aircraft .air file location and the P3D root directory stored at 3E00 are correct. The absolute address in the root directory /modules I am now using is where LINDA stores its configuration and module data. New aircraft are stored in the add-ons folder in user\documents. The relative address .\modules\linda\aircrafts\ previously referenced the FSX/P3D root directory. Now this relative address starting point shifts to an unknown location when referred to in the LFS when the new add-on aircraft location is used in FSUIPC5. I was unable to determine where it was pointing which is why I turned to using the absolute address for the LINDA folders. There were no timing issues with 3C00 or 3D00 or 3E00. This was a false lead in my initial investigation. Thank you for your support. Andrew

Hi Pete I have solved my problem. It was caused by the new P3Dv4 add-on file locations and the impact of this on the LUA File System (LFS). The problem affected the reading of all P3Dv4 compliant add-on aircraft like the FSLabs A320X v2 (64-bit) and A2A's C172/C182. During initialisation, LINDA has previously located its key files using relative file addressing as: local dir_obj = lfs.dir ('.\\modules\\linda\\aircrafts\\') local dir = dir_obj () With the new P3Dv4 compliant add-on aircraft located in, for example, c:\users\documents\prepar3d v4 add-ons\FSLabs\simobjects\airplanes\FSLabs A320 IAE\A320.air I ended up with dir = nil and the initialisation failed. I have had to determine the absolute address: c:\p3dv4\modules\linda\aircrafts This works successfully in the above code statements and fixes the problem. I don't know how FSUIPC5 and the LFS is affected by the new add-on locations when it handles the relative addressing but it does not appear to operate as previously.

Hi Pete Thank you for your reply. I am afraid real world work have got in the way and I won't be able to absorb the information or continue my investigation for around week. Andrew

Hi Pete I have been doing some more analysis on starting P3Dv4.1 with the FSLabs A320X in comparison to other aircraft such as the A2A C172. The A320X is interrupting LINDA's initialisation and preventing correct operation as a result. The A320X start up timings through FSUIPC5 is quicker than the C172 between IPCREADY and the new aircraft change appearing at offset 0x3D00. The A320X takes 187ms while the C172 is 297ms; 110ms quicker. I attach 2 logs for these examples. LINDA starts when the ipcReady.lua is called and the Airplane set event caught event (lines 112734 and 106297 respectively) is defined by event.offset(0x32FC,"UW","onPlaneSet"). I have the event.offset set at the very end of the code so it should not occur before the LINDA completes its initialisation. What I can't work is why it is being triggered before expected. As a workaround, is there a way of increasing the timings between these events to say 300-400ms within FSUIPC5? FSUIPC5-A320XX.log FSUIPC5-C172.log

Thanks Pete for the info and advice. Yes it was a typo. It should read event.offset(0x3D00, "STR", "onPlaneSet") but I will be looking to change this based on above.

Hi Pete Thank you for the prompt answer. The user has confirmed that the UNC path was as it was stored on installation in his FSLabs add-ons.XML file. I don't believe now that the rouge forward slash actually affects the issue I am investigating. The forward and back slashes are treated the same as we have previously discussed. Anyway I have added code to replace it in LINDA. I have another question related to my investigation. When is a change of aircraft indicated by a change in offset 3D00? The FSUIPC5.log simply display the new aircraft as a single line. LINDA uses this to cause a re-start to load the required modules. For default aircraft this appears to occur once before ipcReady and LINDA starting. However, when FSLabs A320X (and possibly other Addons) is set as the default load, this appears to occur after LINDA has started but before its initialisation is completed. I need to understand the sequencing and add a delay in declaring this statement: event.offset(0x3D)), "STR", 99, "onPlaneSet")

Hi Pete LINDA uses offset 3C00 to return the full pathname for an aircraft. In P3Dv4.1 using FSUIPC 5.121c I have found the pathname includes a forward slash (/) in the pathname between "simobjects" and "airplanes". All other separators are back slashes (\). Eg. "C:\users\owner\documents\prepar3d v4 add-ons\fslabs\simobjects/airplanes\FSLabs A320 IAE\A320.air". This issue only appears to affect the new released FSLabs A320X v2 for P3Dv4.1. When loading the A2A aircraft, also installed in prepar3d v4 add-ons, the problem does not occur. This may be related to a bug in LINDA using P3Dv4.1/FSUIPC5 with changing aircraft that I am investigating. As an interim, I have replaced the forward slash for a backward slash. I may be back!

Update: The original user with the multiaxis.lua crashing problems reports that it is not fixed by 5.121a. Of note is that the multiaxis.lua is started within the [auto] block and not using normal LUA procedures or via ipcReady.lua. He reports that if he disables ipcReady.lua by renaming it then the crash does not occur on changing the aircraft. Doing disables the LINDA LUA core code by failing to start it. I have pointed him to this thread as LINDA itself is operating normally.

You were too quick for me. I was aiming to submit report on your return but other things got in the way. One user has just reported that 5.121a does not exhibit the crash. I will seek more information. Remind me. What were those? Are you saying this was not a problem in some preceding version of FSUIPC? My memory is not good but you made some changes when we were working on the LUA issues in the summer. Sorry the user did not capture the event logs and I only set up a test with 5.113. LINDA are always changing aircraft as that's what LINDA is for. I have not had the problem reported before and there have been not updates to LINDA since July when we were finalising the FSUIPC5 issues.

Hi Pete One of my users has been reporting issues with FSUIPC5 when changing aircraft when multiple LUA files are in use. The user is using the Lua file multiaxis.lua which allows axes to be swapped when a joystick button is pressed. The command is communicated via the offset 0x66C0). There appears to be a conflict with LINDA when called, normally, via ipcready.lua and the [auto] section loading Lua multiaxis. Renaming ipcready.ipc prevents the crash but this means that LINDA LUA modules not being loaded. [auto] 1=lua multiaxis [LuaFiles] 1=ipcReady 2=linda 3=AirbusX_Thr1 4=AirbusX_Thr2 5=FSUIPC5_test 6=Multiaxis [Axes] 0=JX256,F,L5:V,0,0,0 -{TO SIM: luaValue Multiaxis }- [Buttons] PollInterval=25 ButtonRepeat=20,10 1=R2,4,Cx42000BC0,xC0010100 -{offset sword decrement, offset 0BC0 (Decr=256, Limit=-16383)}- 2=R2,5,Cx32000BC0,x3FFF0100 -{offset sword increment, offset 0BC0 (Incr=256, Limit=16383)}- 3=P3,3,Cx030066C0,x0000FA88 -{offset dword set, offset 66C0}- 4=U3,3,Cx030066C0,x000100E3 -{offset dword set, offset 66C0}- With P3Dv4, LINDA 3.0.2 and Multiaxis.lua running, P3Dv4 crashes on aircraft change with the Event Viewer (see attached) showing a crash in FSUIPC5.dll. I am not sure whether this problem is associated with the LUA thread management changes you made earlier. These tests were carried out with FSUIPC 5.112. The user also reported the same crash with FSUIPC4 4.971 (log attached). FSUIPC5.ini FSUIPC5-crashOnAircraftChange.log Multiaxis.lua MULTIAXIS_crash.txt FSUIPC4_Crash_LINDA_302_FSUIPC_471.log

Hi Pete Based on what you said, I decided to delete and rebuild my fsuipc5.ini. The normal axes and the POV axis saved correctly. Obviously, something was corrupted. You spotted my dyslexic keyboard. It is 5.121 I'm using.

Hi Pete With FSUIPC5 (including latest 5.112), I have found that the POV (joystick HAT) is not saving to the FSUIPC5.ini [Axes] section when using Axis Assignment / Send to FS as normal axis / Pan View (see attached image). When I open the FSUIPC dialog again and operate the HAT, the field is blank. I had had to manually edit FSUIPC5.ini to add the line: n=3P,0,F,66416,0,0,0 -{ TO SIM: PAN_VIEW }- (where n is the next entry line) FSUIPC5.ini attached as after OK clicked. FSUIPC5.ini

FSUIPC5 installs into the /modules folder of your P3Dv4 installation. It should automatically find where P3Dv4 is installed.

The fsuipc4.log.ini file is created automatically the first time you run the Flt Sim with FSUIPC. If things go wrong, the usual recommendation is to delete the ini file and let it be recreated.

Another alternative is to try LINDA which provides most required functions for various aircraft including all PDMG via FSUIPC that can be combined into single functions to do the multiple actions you require.

Is EZCA (EzDok Camera) compatible with P3Dv4? If you would like to send a copy of your 777 module, I can run the tests here.

Hi Francis/Pete DINPUT8.DLL has nothing to do with LINDA or, I believe, FSUIPC. If you do a Google search there are many posts on the DLL but with little explanation of what it does. The best I can find is: Dinput8.dll - dll file called "Microsoft DirectInput" is a part of Microsoft® Windows® Operating System program developed by Microsoft Corporation. Some applications or games may need this file to work properly. If dinput8.dll is missing, whenever you start the application/game you may experience various kinds of errors. To fix those errors, please read the Recommended Solution below. I would suggest you disable all your add-ons and enable each in turn to find out which one is causing your crashes. Andrew aka Scotflieger (not Scottflieger)

I understand. I would strongly recommend you move your code to a file named user.lua in the same folder. This will mean it will not be overwritten when the next PMDG777 module is released. It will also allow us to isolate the problem. I am unable to support non-standard LINDA code. You can declare functions with the same name as in the actions.lua and these override (replace) those in the actions.lua code with the same name. The FSUIPC LUA debug is heavy on tracing but will isolate the actual line concerned. LINDA verbose logging is less onerous and will help more quickly to determine whether LINDA is at fault. The following logging is not associated with LINDA although it refers to actions.lua: 54476 LUA.0: On part dans la fonction INIT777 de la fonction Timer car 66FF=10 envoyÈ par la fonction InitVars. On passe ‡ INIT777 qui fera la situation test. 54476 LUA.0: Lancement fonction INIT777. actions.lua. 54476 LUA.0: C:\P3D4\SimObjects\Airplanes\PMDG 777-200LR\B777-200LR.air 54476 LUA.0: C:\P3D4\Modules\ 54476 LUA.0: C:\P3D4\sound\ 54913 LUA.0: On part dans la fonction Situation test. INIT777 actions.lua. 54913 LUA.0: On part dans la fonction Situation test. Situation test actions.lua. 54913 LUA.0: Linda :C:\Users\Francis\Documents\Prepar3D v4 Files\

Francis, I support LINDA and Pete has asked me to assist. There is much more going on here that I do not recognise, especially the detailed progress logging in French. I suggest you temporarily remove some of the extra functions to isolate the issue. I would also suggest you turn on Verbose logging in LINDA to see whether it is at fault as Pete suggests. I do have one issue as one of your LUA add-ons uses a file called actions.lua. This is also the name of the key LINDA aircraft module code and may result is some unknown adverse effects. If the problem is one with LINDA then I would ask you to report it at https://www.avsim.com/forums/forum/429-linda-support/

Hi Pete Is there a reason for programs listed in the [Programs] block taking a long time to start and especially to close when P3D is started and quit? It can be 5-15 seconds after quitting the sim that these programs finally close (AS16 and LINDA). During the process the programs report "not responding" and manual shutdown is blocked. This can be problematic when trying to get up and running after a crash. It appears to affect both FSUIPC 4 and 5. I recall that you had to extend some delays recently.

Double check that you don't have assignment within the Sim Controls axes section.

I believe the same issue was appearing in FSUIPC4 but was not an issue as I was not performing the multiple restarts I was doing when trying to get my code working with FSUIPC5. For consistency I suggest both FSUIPC variants should be kept the same.

You learn something new every day. Thanks Pete for clearing that up for me and Tom.