Modernizing layout.json

Ideas
1

NB: this post is the 2nd part of this suggestion:[Support mounting compressed
archives in the VFS (Virtual File System): save up to 95% disk space and hours
of loading time (accumulated per
year)](https://devsupport.flightsimulator.com/idea/8352/support-mounting-
compressed-archives-in-the-vfs-vi.html). As suggested, some of the ideas below
might be relevant not just when the VFS supports mounting archives and this is
why I’m also posting this idea separately here.

Modernizing layout.json with wildcards

The add-on format requires using a layout.json file which contains the list
of all the files the add-on is using. It is meant to tell FS2020 which of the
files found into the folder and its subfolders are to load, and therefore
which files are to ignore. However, most of the time nearly all the files in a
folder must be loaded and sometimes all of the files in a folder must not
(docs, PDF). I’d suggest you support wildcards so that… you could replace
this…

{
  "content": [
    {
      "path": "ContentInfo/global-ai-ship-traffic-v2/Anzac Destroyer MSFS.JPG",
      "size": 248068,
      "date": 132752292850201898
    },
    {
      "path": "ContentInfo/global-ai-ship-traffic-v2/Arctic Princess LNG MSFS tanker.JPG",
      "size": 249930,
      "date": 132734818938055004
    },
    {
      "path": "ContentInfo/global-ai-ship-traffic-v2/Blue Marlin Heavyload Ship MSFS.JPG",
      "size": 393298,
      "date": 132747380300622415
    },
    {
      "path": "ContentInfo/global-ai-ship-traffic-v2/Blue Star Ferry Naxos MSFS.JPG",
      "size": 338063,
      "date": 132747391718720969
    }
    etc...
  ]
}

with this instead…

{
  "content": [
    {
      "path": "ContentInfo/global-ai-ship-traffic-v2/*.*",
    }
  ]
}

and exclude subfolders like this…

{
  "content": [
    {
      "path-exclude": "SimObjects/Boats/AI_Alice_Austen/extra_info/*.*",
    }
  ]
}

Most add-ons aren’t replacing files, they are just adding theirs, and there is
only 1 instance of each files to be mounted in the VFS. The size and date
should be only necessary when explicitly wanting to override another existing
file (using date). Otherwise size which is meant to validate the add-on
content is adding an unnecessary burden not only at authoring time (regardless
of mounting archives or not), but also at loading time if support for archives
is added, because the file size is already included in the archive directory
and file table headers. In using wildcards, you’d only keep the more verbose
form using size and date for the cases where add-on vendors are
specifically overriding a file with the same virtual path. This is the only
case where this information is necessary in order to triage which one is the
newest. [initially published
here…](https://forums.flightsimulator.com/t/support-mounting-compressed-
archives-in-the-vfs-virtual-file-system-save-up-to-95-disk-space-and-hours-of-
loading-time-accumulated-per-year/455828/3)

2

Hi there, As explained in https://devsupport.flightsimulator.com/t/4300, we
need the size of each file to be indicated in the “layout.json” file - any
proposal to remove it, such as using wildcards, would be a no-go at this
stage. I am unclear as to what the “path-exclude” could be used for - would
you have a use case in mind? Best regards, Eric / Asobo

3

Hi Eric, I’ve just answered on this other topic as well, but for the sake of
keeping this specific sub-topic answer at the same place, here is:

- The filter idea makes probably more sense when used in the context of an
archive, because in this case, the information set forth in the .json would
already be found in the archive directory header (file path, name, size,
flags, attributes, date). Having said this, the filter idea I’m exposing here
is also about having a practical inclusion/exclusion system, given that nearly
99% addons are only adding and not replacing files, and these files are all in
the addons subfolders, and some of these files (documentation pdf etc…) have
usually no reason to be referenced in the .json in my opinion. If the purpose
of setting the size in the json file is to preemptively reduce disk access
cost when loading the files, then if I understand correctly it is only when
the actual files are loaded. In this case, if this adds delays or access cost,
the same reasoning as above still remains: the informed user knows it is
easier to reference with a wildcard, but it can cause additional lookup and
loading time.

Something though which might still be applicable is in the case of not having
an explicit size set forth in the json file, FS2020 could still be able to get
the size from the filesystem and cache it in a separate file, like for example
I’m adding the following add-on archive in Community: ".\Community\RealityXP
Great Addon For FS2020" and upon loading when no size is found, FS2020 would
create a companion “RealityXP Great Addon For FS2020.layout.json”
automatically the first time it is loaded (this is just the illustration of
the idea of a companion auto-generated layout.json file here, not any expected
actual implementation of course).

4

Having said this, as a developer, you’re making me curious to know what “cost”
you could be saving in having the file size preset in a .json “directory”
compared to just getting the file size from the file system? I can see a
practical use case where for example you’re using and pre-allocating pools for
which you must know early on the different file sizes prior dispatching these
files in these different pools, is this for similar reasons you’d expect
having the file size early on?