Aircraft File 3C00 Offset

[Scotfleiger]

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!

 

[Pete Dowson]

4 hours ago, Scotfleiger said:

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.

That path name is untouched by FSUIPC, it is received from SimConnect and placed in offset 3C00 intact, with no attempt whatsoever to change it EXCEPT to see if there's a UNC path to it which can be used -- so that it can be accessed from a Networked PC.

But in the case of the example you quote, there is evidently no UNC path, so the string you see is most certainly intact, as supplied by SimConnect.

5 hours ago, Scotfleiger said:

This may be related to a bug in LINDA using P3Dv4.1/FSUIPC5 with changing aircraft that I am investigating.

Oh, didn't you check the offset itself? Or just look at the FSUIPC5.LOG. It logs EXACTLY what it places in 3C00 when it does, i.e. when it is told by SimConnect and given the path.

e.g like this:

 281145 E:\Prepar3D v4\SimObjects\Airplanes\B737_800\Boeing737-800.air

Very strange it is different from aircraft ot aircraft. Is it, maybe, to do with the AIR file being in a Documents Add-Ons folder? If so, and if it is in the original Simconnect supplied path, then it is either a bug in P3D4, or, more likely, in the <AddOn.Component> entry relating to that add-on aircraft in its AddOn.xml file.  I expect the <Path> parameter includes the /, making it an error in the aircraft's installer.

Perhaps, since P3D presumably treats this as okay (unlike Lua) I should check for and change such entries in paths within FSUIPC. They may occur in other requested paths too.

Pete

 

 

[Scotfleiger]

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")

[Pete Dowson]

3 hours ago, Scotfleiger said:

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 also replaced them in FSUIPC, but as it isn't urgent it will just be a "hidden bonus" in the next update  -- at least for FSUIPC5. Not done it for FSUIPC4 yet.

3 hours ago, Scotfleiger said:

When is a change of aircraft indicated by a change in offset 3D00?

The change of aircraft is signalled by the count in offset 32FC being changed. And that is done at exactly the same time as the AIR filepath is placed in 3C00,  which is logged (see my previous message). This is when SimConnect signals an "AircraftLoaded" event, which is the earliest I can detect it.

3D00 is the aircraft name, which isn't available till later, when most of the other Sim Var changes are received. Sim Vars depend upon the sim engine all being geared up and running, whilst the events signal actions the sim is taking.

3 hours ago, Scotfleiger said:

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

Sounds like the A320X is taking a longer time to load. Why not use the proper indication of an aircraft change, 32FC? I realise you probably then need to see the aircraft name, but at least you can be ready for it. (Of course, an aircraft reload might signal an aircraft load event too, so you can't wait indefinitely for an aircraft name change. Put a time limit on that. But at least it won't be a delay on new aircraft loading.

Check the logs yourself, see when the AIR file is logged compared with the aircraft name.

3 hours ago, Scotfleiger said:

event.offset(0x3D)), "STR", 99, "onPlaneSet")

0x3D? Is that just a typo here, not in your program, I hope?

Pete

 

[Scotfleiger]

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.

[Scotfleiger]

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

[Pete Dowson]

13 hours ago, Scotfleiger said:

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.

C172:

     2329 C:\Users\Owner\Documents\Prepar3D v4 Add-ons\A2A\SimObjects\Airplanes\A2A_C172\C172.air = 32FC inc and 3C00 being set
     3157 VRI MCP2A ("MCP2 Airbus") detected on port com3
    98250 Aircraft loaded: running normally now ...
    98250 User Aircraft ID 1 supplied, now being used
    98938 System time = 19/10/2017 22:41:50, Simulator time = 20:38:11 (19:38Z)
    98954 Aircraft="C172R default" = 3D00 being set
   105875 Weather Mode now = Theme
   105954 Starting everything now ...

so that looks like 103.625 seconds from 32FC and 3C00 being set and ipcReady being executed, and the latter is 7 seconds exactly after the aircraft name is set in 3D00..

A320:

     6984 C:\Users\Owner\Documents\Prepar3d v4 Add-ons\FSLabs\SimObjects/Airplanes\FSLabs A320 IAE\A320.air = 32FC inc and 3C00 being set
     7094 VRI MCP2A ("MCP2 Airbus") detected on port com3
   100187 User Aircraft ID 1 supplied, now being used
   104812 Aircraft loaded: running normally now ...
   105516 System time = 19/10/2017 22:29:12, Simulator time = 14:35:55 (13:35Z)
   105516 Aircraft="FSLabs A320X IAE - FSLabs" = 3D00 being set
   107344 Weather Mode now = Theme
   112500 Starting everything now ...

So starting everything 105.516 seconds after 32FC and 3C00 are set, and 6.984 seconds after 2D00 is set.

I don't understand where you are getting your figures from, or why they matter?

14 hours ago, Scotfleiger said:

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. 

Triggered even before the event command is executed!? No, that isn't possible. How will it know which function to call, or even register the offset to be monitored? Please use the trace facilities to work out what your code is doing.

Just to illustrate what I say above, here's part of a log on my PC where I'm monitoring 32FC, 3C00 and 3D00:

    60684 E:\Prepar3D v4\SimObjects\Airplanes\B737_800\Boeing737-800.air
    61184 Monitor IPC:32FC (U16) = 1
    61184 Monitor IPC:3C00 (AsciiZ) = [62]"E:\Prepar3D v4\SimObjects\Airpla"
    61184 Monitor IPC:3D00 (AsciiZ) = [0]""
   371750 User Aircraft ID 2 supplied, now being used
   371766 Aircraft loaded: running normally now ...
   372094 System time = 20/10/2017 14:06:29, Simulator time = 08:22:45 (07:22Z)
   372156 Aircraft="Boeing 737-800"
   372172 Monitor IPC:3D00 (AsciiZ) = [14]"Boeing 737-800"
   372172 SimRead: 3D00="TITLE"
            STR256: "Boeing 737-800"
   562649 Starting everything now ...
   562727 ASN active function link set
   562727 Ready for ActiveSky WX radar with additional data
   562805 LUA.0: beginning "E:\Prepar3D v4\Modules\ipcReady.lua"

Pete

 

[Scotfleiger]

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

[Scotfleiger]

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.

 

 

[Pete Dowson]

38 minutes ago, Scotfleiger said:

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

Sorry, I don't understand. are you saying that the location I'm given by SimConnect, i.e.

c:\users\documents\prepar3d v4 add-ons\FSLabs\simobjects\airplanes\FSLabs A320 IAE\A320.air

is wrong, that in fact the aircraft files are not there?

How is this the "absolute address"

c:\p3dv4\modules\linda\aircrafts

Surely new aircraft aren't stored there!

Confused!

42 minutes ago, Scotfleiger said:

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.

Ah!  You are saying that the current folder, the one you assume by using 

.\modules\linda\aircrafts\

is not necessarily (and possibly never is?) P3D's root folder? 

FSUIPC determines P3D's absolute location during inititialisation (from its own path), and uses that in all its needs rather than any relative folder locations. Of course, the lua lfs library will simply assume that the current folder is the one to base relative addressing on. I thought it was always dangerous to make such an assumption. Other add-ons running in the same process can easily change it.

Anyway, if you've arrived at a good solution, then fine.  I'm not sure how that relates back to what you thought were timing problems with 3C00 and 3D00 offsets being populated.

Pete

 

[Scotfleiger]

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

[Pete Dowson]

26 minutes ago, Scotfleiger said:

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.

Thanks for the clarification. That's probably a wise move in any case. I don't think it has ever really been guaranteed to be the sim's folder. I suppose if this has been assumed by lots of plug-ins I could automatically set it as the current folder before loading them, but I'd be a little worried about possibly then mucking something else up.

Pete

 

[Scotfleiger]

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!

[Pete Dowson]

2 hours ago, Scotfleiger said:

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!

Indeed, yes, very strange. Of course the LFS was written by a separate contrubutor. From my Lua docum,entation:

"Additionally, the third-party file system library, lfs (LuaFileSystem) by the Kepler Project is also built-in. A
separate document is supplied describing this library".

So it  was never part of the main suite of standard libraries as documented in the official Lua books. Possibly he/she did things differently.

I do actually build the source into FSUIPC -- it is compiled into it. Would it be worth me taking a look? I could compare what io.open does with what lfs.dir does and maybe adjust it accordingly. What do you think?

Pete

P.S. I've just read the description of lfs.dir, and it it more complex than I thought. It simply returns an object and it's the object which returns the path. What paths does it iterate, all the sub-directory paths in the  path you give it in lfs.dir? So it the initial overall path going to be derived there, I don't need to worry about the iterative part?

Are there other lfs functions which may also be affected? Should, for instance, "currentdir" always return the Modules folder path, or the original "true" current directory you've come up against. It can't really i suppose because then chdir would be useless. Thinking along those lines perhaps it would be dangerous to change lfs.dir's behavious, in case it was deliberately changed by chdir?

Looking further through it, i would say it could be a can of worms, perhaps better left untouched after all!

.

 

 

 

 

[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