Hello, Is there any fix to the current file name structure planned to not bump
into the 256 character limit. I changed the limit via the registry as an admin
to allow longer names but we are still getting decompression errors when
trying to install a mission package under the community folder using an exe to
build for 3rd party vendor sites. Some PC users might not want to mess with
their registry or do not have the knowledge to do so. The project editor
recommends a certain format to be followed for folder naming, but this quickly
adds up the character count. Is there any way to have 3rd party developers the
ability to setup their own library folders on the root drive to correct this
issue for flight simulator to read those files as well. If I recall, X-Plane
allowed you to setup folder shortcuts in the mods (community) folder and it
would read the files in that shortcut. Thanks! Jeff @ Adventum Simulations
Just getting to the root of the Community folder takes almost half of that
limit. IDK who decided to put the Community folder there but it was a terrible
idea.
Hello @AdventumSims Unfortunately this is a problem we also have to work with
and even if, by editing the registry or with other solutions, you bypass it,
it won’t be the case of people dowloading the packages. I’ve told the
developpers about this and we want to know if you could provide us an exemple
of a package path that give you this issue to see if your way of naming it is
a lot different to ours. Best regards, Yohan
Wouldn’t be possible to have the MSFS installer setting the LongPathsEnabled =
1 automatically ?
Let’s have a look, where the community folder can be: 1. Default Setup,
System Drive
C:\Users\15-char-netbios\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages\Community\
2. Default Setup, Different Drive
F:\WpSystem\S-7-6-21-xxxxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-nnnn\AppData\Local\Packages\Microsoft.FlightSimulator_3wekyb8d3bbme\LocalCache\Packages\Community\
3. Own package Folder → mostly shorter 
Pick up the worst case with setup
2) Of the MAXPATH_LEN of 260, there are now 108 chars left. Our Example
Company is called “MySweetCompany”, we are creating “LandingChallenges” at
“KLGA, LaGuardia”. Following the SDK and MSFS default missions, we are at
following mission folder, where the FLT, images and localized soundfiles are
stored:
mySweetCompany-LandingChallenges-KLGA-Laguardia\Missions\mySweetCompany\LandingChallenges\Laguardia
100 Chars just to the base folder. 8 chars left. We have localized sound
files. They are located in sound\, i.e. sound\en-US\. This are 12 chars and
we are already 4 chars over the limit of MAXPATH_LEN. When I have a look to
the localized soundfile names, they need to be named like the TT: definition,
we have “laguardia_Mission_30.wav”, another 24 chars. In total, we are at 288
chars when using the recommendations or specifications from SDK. Renaming our
company to “Sweet”, which is not possible because of Marketplace and MCP
limitations, we come to 270 chars, which is more than MAXPATH_LEN, too. To
reproduce the issue is very simple, just install the sim on a different drive
with defaultpackage path, setup a landingchellange as specified in the SDK. Of
course it is possible to deviate from the naming of the SDK and take LC
instead of LandingChallenges, then you are at the above example with 258
characters and then shifts the issue to the image file names or possibly
SimStates. And with SUnn the SDK becomes more restrictive, as we have seen
with the Airplanes and the localization and it does not work again. The main
problem is actually that Windows Explorer does not support long paths even
after the registry hack. In every own installer this could still be built in
and has already been done. Whether the simulator can then handle this without
errors, is then on another page. However, the best solution would be to put
the community folder in a directory much shorter than the 108 characters if
the simulator is on another disk. BuffyGC
@BuffyGC is suggesting the idea to be able to put the community folder in a
shorter path, if on a different drive. I always thought this was already
working this way: UserCfg.opt is referencing the root path (for ex. Z:\MyFs),
then FS2020 is creating and reading from, a “Community” sub-folder in there.
So in practice it looks like it is already allowing using much shorter “prefix
path” to the community folder, or is there any other limitation to the file
path length in this case? @Yoanito If I understand previous answer to the
topic I’ve posted earlier (FS2020 can’t deal with pathname…), FS2020 is
already using the long file name prefix, so the path “resolving” shall boil
down to basically: - It could be using the UserCfg.opt root prefix path as-
is, in other words calls to the file system are using:
- \?\Z:\MyFsFiles\Community\mySweetCompany-LandingChallenges-KLGA-Laguardia\Missions\mySweetCompany\LandingChallenges\Laguardia
- Or it could be using the canonical root prefix path when issuing file
system calls, because the canonical path is setup in the file system to
“point” to the actual real UserCfg.opt root prefix (as with a junction/link):
- \?\F:\WpSystem\S-7-6-21-xxxxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-nnnn\AppData\Local\Packages\Microsoft.FlightSimulator_3wekyb8d3bbme\LocalCache\Packages\Community\mySweetCompany-LandingChallenges-KLGA-Laguardia\Missions\mySweetCompany\LandingChallenges\Laguardia
I’m thinking in both cases, whatever the add-on file path length, it should
still be able to represent and access these path (up to 32K chars) from a file
system call perspective isn’t it? So is the real problem more about the
“installers” or any other “installation” tooling, only because most wouldn’t
seem to be supporting the long file name prefix? Or are there still other
“long file names” problems still remaining in FS2020?
@Yoanito Unfortunately this is a problem we also have to work with and
even if, by editing the registry or with other solutions, you bypass it,
it won’t be the case of people dowloading the packages.
Otherwise, there is still another option I’d like to suggest, and besides it
is also supporting a number of other intrinsic advantages for the end-user,
one of these is that it could also solve distribution, installation and long
file names support for add-ons, in one very simple implementation:
https://devsupport.flightsimulator.com/t/4300
With earlier Sim versions there were issues with images and sound files, how
it behaves under SU10/SU11 is unknown to me. My own installer that I offer
within the BTI can handle long names. The issue is more the packages that are
not shipped with installers, but as ZIP/7Z/RAR. 7Zip can handle long names for
example if you extract from the product via menu. If you try it by Darg&Drop;
from the 7Zip interface, 7Zip unpacks into the Temp Path and tries to copy
with Explorer into the Community Folder and it fails. The Windows Explorer can
max. 260 characters, regardless of the registry hack. Likewise, removing the
package via Explorer is impossible because it cannot access the “long” names.
Many users don’t use the possibility to put the packages in an own folder
(\GAMES\MSFS or similar) but use the default path because the consequences are
not known at the first installation. BuffyGC
I haven’t noticed any issue where there would be a missing image or sound when
using previous versions, I didn’t know there could be. I wouldn’t be surprised
if that was the case, it could have explained a number of CTD too maybe?! Your
comments about 7z though, is further supporting the idea to be able to mount
these archives in the VFS directly as-is. In effect, regardless of possible
doubts about performance*, it seems to me that any potential overhead issue is
basically a non issue, in the case where you can’t even load the files because
of their long file names. There are certainly much better ways, even an Asobo
own “pack” format eventually, but .7z/.zip have the benefit of convenience for
everyone, be it 3rd party dev or end-user, because they are ubiquitous, well
defined and robust formats, and as importantly there is a lot of existing
tooling already to manage and create them, starting with OS embedded zip file
support which most end-user should be more or less familiar with nowdays IMHO.
* @EPellissier: Although it is true that using archives would (significantly)
reduce the hard drive footprint, it is unclear to me if “loading compressed
data + decompress” would really be faster than “loading uncompressed data”.
There may be some overhead in terms of memory requirements too.
Hello @Yoanito Here are some examples of the installer issues with the MS
Store version of Microsoft Flight Simulator.
The main issue is the entire
workaround process needs to be eliminated. I believe asking customers to use
workarounds or additional steps to get products installed has a negative
effect. A root folder base for community mods or addons is essential for this
to get around the long path issues currently with the sim. Asobo is requiring
long naming conventions for their folder structures, but Windows supports this
in a limited fashion. We can easily tell customer to set their install paths
to a different folder, but should a user need to do this in order to enjoy
products from third-party vendors. It is a big ask to our customers to
completely reinstall Microsoft Flight Simulator to enjoy our products. The
product should support minimal interaction for its users to install flight
simulator to a default location and allow for easy installation of third party
content whether it is freeware or payware. Thanks, Jeff @ Adventum Simulations
Hi @AdventumSims, Is the installer shown in your screenshots based on a custom
tech/library or are you using some “mainstream” solution such as
Installshield, NSIS, WiX or other? Best regards, Eric / Asobo
Hello everyone After discussing about it internally we feel like some things
need to be clarified about the Long-path problem : In-game, the long path is
supported, the VFS will not have any problem with files with long-path. If you
got this kind of errors coming directly from the VFS please send us a
screenshot with repro steps. If you got trouble when trying to copy/paste the
package folder inside community to test it for example you can use the windows
command
robocopy "source folder path" "destination path" /MIR
wich support longpath, and if you want to make an installer you should read
the doc of your solution to see if it support longpath. In summary, if your
issue about longpath come from a custom installer or manually copy/pasting in
the windows explorer we can’t do much about it except the two recommendations
above. Best regards, Yohan
It’s good to know that at least MSFS itself shouldn’t have any issues with
Long paths in the VFS and, in fact, the issue is more likely dependent by the
kind of installer used. Assuming the installer allows custom scripting to
change the final install folder with it, one way to fix this might be to pre-
process the destination folder ( assuming it’s the Community folder ) and
something like this, I’m using a pseudo-code since every installer has its own
scripting language:
destinationPath = "\\?\" + detectedCommunityfolder
Assuming you’ll then install your package in the Community folder directly
using the destinationPath, this should prevent any errors happening during the
actual file copy, since the “\\?\” in front of the pathname should convert
it into a form compatible with Long file paths. I’m not 100% sure if this ALSO
requires the LongPathEnabled = 1 key in the registry but, maybe, you might set
up that one as well from the installer, assuming its scripting language allows
writing to the registry. Another approach you might undertake, is NOT
installing anything in the Community folder, install in a more standard
location, like C:\Program Files\MyCompany\My-package-name, and just create a
Symbolic Link to it in the Community folder, so you will reduce the risk of
being affected by longer path names. This is probably easier and better for
users, but has ONE shortcoming, and it REQUIRES the Community folder to reside
on a drive formatted as NTFS, because Symbolic links to folders are not
supported on Fat32/ExFat filesystems.
Hello, Thanks to all who participated in the thread and the Asobo team for
your responses. We will go back and apply the suggestions here to see if it
solves our issues. Cheers! Jeff @ Adventum Simulations
Hello, Just a quick comment. A temp folder creation and using robocopy worked
like a charm. The issue has been solved. Thanks again for the guidance.
Cheers! Jeff @ Adventum Simulations