MSFS20 ADE HF5 can't compile anymore

[Sueede]

Hi. I use v20.22.8157 ALPHA (Pro). As late as 2022-05-11 I edited an airport and all was well. Yesterday I started getting these messages: "Provided project definition file does not exist. ", see attached file. ADE sends the message "Package built." but no airport is compiled. I have sent a logfile.

It seems as though it searches in a folder that does not exist. I don't know if there is anything I can do on my side to correct this, as the project files are stored where they should be stored and I have succeeded as late as yesterday to build projects, but not get them compiled by clicking "Build project".

The other day I got a small compulsory update of SU9 but I have no way of telling if this is the cause or if it meant a change in the SDK. I compiled the last airports with the next to latest SDK. Yesterday I updated the SDK, but that didn't help.

I hope you can find a solution. And I also hope that Asobo stops messing things up with their updates,

Regards,
Tommy

 

[downscc]

Exactly same issue here as well, basically the same console output with same error and nothing built.

 

[GaryGB]

https://www.google.com/search?q=msfs+"Provided+project+definition+file+does+not+exist"+site:www.fsdeveloper.com&biw=1120&bih=536&sa=X&ved=2ahUKEwjf-Zvl8Lb4AhVAK0QIHb58Bu4QrQIoBHoECAIQBQ

https://devsupport.flightsimulator....ool-no-longer-operating-outside-of-sim-a.html

 

[scruffyduck]

I am trying to find out what that error message means. It appears to be MS Edition specific since I can get builds using the Steam Edition

 

[=rk=]

I already addressed this on a different thread. Apparently some people search "can't compile" and some people search, "won't build," thanks Asobo, for developing more words to say the same thing.

This message is most likely the new version of the FSPackagetool.exe won't build message, that changed slightly after the last update. If this is the case, the work around is to just start MSFS, then when ADE calls FSPackagetool.exe, it is already running and will perform the build.

 

[scruffyduck]

If this is the case, the work around is to just start MSFS, then when ADE calls FSPackagetool.exe, it is already running and will perform the build.

Sadly Not

I started the MS Edition, loaded a project into ADE and File > Build Project. I go the initial build message then immediately the Package Built message but no console window and no package created. My second attempt was probably due entirely to my installation and ADE itself and it ran the Steam edition generated a console window and hung ADE.

Maybe I am doing the wrong things

 

[=rk=]

Ok, got it. But does ADE assemble the equivalent of a "package sources" folder? Could one, as a workaround, do all the necessary edits in ADE, save it to package source format and then use DevMode to navigate to the ADE porject.xml and complete a build from there?

 

[rhumbaflappy]

Ok, got it. But does ADE assemble the equivalent of a "package sources" folder? Could one, as a workaround, do all the necessary edits in ADE, save it to package source format and then use DevMode to navigate to the ADE porject.xml and complete a build from there?

Yes.

 

[=rk=]

Well that's a route, then, but it looks like someone on the all caps "UNABLE TO BUILD" thread, has been trying that.

 

[Burner]

Good day all, I have also battled with this for a while now. What worked for me for some reason is I crated a folder in “C:\MSFS” called “xprojectfolderx”. I then moved my whole project folder to this folder. After this when I do a build project the start screen for MSFS2020 will pop up and then after a while the package will build successfully. Hope this helps some of you. (I use MS not steam)

 

[downscc]

My work around for this is to open my own console window in admin mode, and use the command line to navigate to <sdk>\tools\bin and run fspackagetool from there. No need to launch msfs. Execute fspackagetool without any suffix and it displays the usage help.

fspackagetool <path to project.xml> -outputdir <output directory>

 

[scruffyduck]

Ok, got it. But does ADE assemble the equivalent of a "package sources" folder? Could one, as a workaround, do all the necessary edits in ADE, save it to package source format and then use DevMode to navigate to the ADE porject.xml and complete a build from there?

ADE has two way editing which means the project can be edited with ADE and Dev Mode at the same time. Of course we can use the Dev Mode Build to generate a package but that misses the point that we should be able to use the external access to the internal compilers (fsPackageTool) to generate a build.

 

[=rk=]

the point that we should be able to use the external access to the internal compilers (fsPackageTool) to generate a build.

The presumption is that will be restored.

 

[scruffyduck]

I believe I may have found something that causes this message when using the MS Edition

It may be related to ADE itself although I do not know why it started happening with SU9/SDK 18

Here is what I am doing.

First I created a new project with ADE from a stock airport. Saved it and built it (I dropped the project.xml onto fspackagetool.exe but a build inside ADE is the same as far as I can tell). I got the usual windows and dialogs and a successful build.

Next I copied the entire project folder from the location it was created in to a backup folder. I repeated the build using the project.xml file from the backup. The error window appeared after a while and the build failed.

I can replicate this. projects build from their creation folder build. projects built from a project that is moved to another folder fail.

Project folders should all be relative paths based on the root folder storage location and that is how ADE does it. BUT it seems that there may be a full path somewhere.

Again I repeat that this behaviour is not seen in builds made with the Steam Edition - no error occurs

So if you have this error with the MS edition can I ask if the project being built has been moved from its creation folder or other wise indirectly referenced to the creation folder

If you have this situation you might be able to replicate it for me.

Thanks

 

[scruffyduck]

OK - I have missed something reported in at least one other place. That is there must be no spaces in the project path. My backup Folder was F:\Active_Data_Set\ADE\ADE Users. The bad build truncated the path by removing the last part leaving F:\Active_Data_Set\ADE\ADE

This caused the failed build. I renamed the backup folder to F:\Active_Data_Set\ADE\ADE_Users and the backup project built fine. Apologies if this is all 'old stuff' and I am playing catch up. I knew about this since ADE won't create a project with spaces in it.

The apparent workaround if you get the message above it to check and rename the project path to ensure there are no spaces.

 

[scruffyduck]

I contacted ASOBO about this and they report that the issue with the MS edition is investigated by Microsoft - this is due to how Game Services now launch MSFS through a launcher that does not forward arguments properly.

This explains why we can get different build results and errors depending on the sim version. They have different launchers which makes sense.

 

[GaryGB]

Hi Jon:

I also used an ADE 2020 Alpha 21 HF5 project name with proper naming syntax, and when I clicked "Build Project" in ADE, the new MSFS splash screen launched for my MS-Store version of MSFS; ...but eventually the project still successfully compiled / displayed a mini-console results message.

GaryGB

 

[downscc]

OK - I have missed something reported in at least one other place. That is there must be no spaces in the project path. My backup Folder was F:\Active_Data_Set\ADE\ADE Users. The bad build truncated the path by removing the last part leaving F:\Active_Data_Set\ADE\ADE

This caused the failed build. I renamed the backup folder to F:\Active_Data_Set\ADE\ADE_Users and the backup project built fine. Apologies if this is all 'old stuff' and I am playing catch up. I knew about this since ADE won't create a project with spaces in it.

The apparent workaround if you get the message above it to check and rename the project path to ensure there are no spaces.

Jon, I changed my project path from e:\ADE20 Projects\ to simply e:\ADE20 and running fspackagetools.exe creates the airport without my user model. It persists in throwing an error on the model asset with the error message including this: "Input: E:\ADE20 Projects\.... etc.

I cannot find where this latent reference exists. I deleted the model information and re-did the User Model Manager but something is still referencing the old pathname. Ideas?

UPDATE: Holy Moly, it took some time and a lot of "well let's try this, and let's try that" but I've removed the latent references to the old path name. Under the project root directory (in the projects folder) there is a folder _PackageInt with a number of sub-folders including some that are nested. The solution I found was to delete ALL files in the _PackageInt folders/subfolders but DO NOT delete any folder. Just delete files. Started working as good as new with new project folder name.

 

[GaryGB]

Hi Dan:

You may wish to make a ZIP backup of your entire project and any partial builds of your scenery using:

ADE Menu Project > Backup.

Then, check to see whether the _PackageInt sub-folder chain is cleared of all files when you "Clean" the project using MSFS SDK DevMode GUI ...before testing a "Build" of the project after it is re-constituted via ADE.

Also, you may wish to examine your 3D model glTF file in NotePad or NotePad++ to see if E:\ADE20 Projects\ is written into any URI path.


FYI: URI path versus physical (and logical) file mis-match issues may confound MSFS' package compiler, and fspackagetool DevMode console error reporting for URI issues is not very detailed or robust for these issues.

AFAIK, MSFS' SDK compiler may opt to simply not build / output 3D models into BGLs if there are URI errors.

It is not clear if a change in URI functionality via a MSFS update has 'yet' been publicly released to all users.

Whereas official MSFS web pages regarding reported changes in URI functionality may have been deleted / hidden:

https://forums.flightsimulator.com/t/sim-update-8-release-notes-1-23-9-0/496878


...other web pages appear to have posted (prior ?) details of the Microsoft Flight Simulator Sim Update VIII Beta:

https://www.avsim.com/forums/topic/614806-sim-update-8-beta-release-notes-beta-is-live-now/

Google Search

https://www.fsdeveloper.com/wiki/index.php/Blender2MSFS

Under Textures:

"Note that when using the glTF separate option, the exporter will automatically copy/convert your textures into the PNG format. If you don’t specify a directory in the “Textures” input, those textures will be generated in the same folder as your glTF model. Note that the textures folder utilises relative paths from the model file. This means you can use “../textures” as an input, which will automatically copy the textures to a MSFS conform location. That said, be aware that the relative path is NOT copied to the URI of the textures. This is a rigid requirement of the sim, but it leads to your model not being able to properly render in other glTF render engines."

NOTE: ..\Textures should be spelled as ..\Texture for compliance with SDK criteria in all FS versions.

Use of a / (forward slash) character in a 'path' is OK if coding in Python / other languages ...but not in Windows.


https://jomardi.wordpress.com/tag/msfs-2020/

Under RELEASE NOTES 1.23.9.0:

"For glTF model texture lookups, only use the filename part of the image URI instead of the full relative path. This makes it so exporters can conform to the glTF specification without breaking texture lookups and vice-versa."


https://store.steampowered.com/news...Microsoft+Flight+Simulator&enddate=1651180518

Under SDK Devmode:

"For glTF model texture lookups, only use the filename part of the image URI instead of the full relative path. This makes it so exporters can conform to the glTF specification without breaking texture lookups and vice-versa"


BTW: Incidentally noted under the same 'SDK Devmode' section quoted immediately above ...was this:

"The size-on-screen computation for LOD selection has been made more accurate for close-up models. In practice, this means higher-resolution LODs will be switched to sooner, and LOD0 will always be displayed when the camera is inside the bounding sphere of the model".

Hmmm... this may mean that those purposely using large un-textured objects to expand the extent of BoundingBoxes for 3D models to allow greater visibility of ex: airport lights at a distance, might find that their 3D model size- versus visibility distance- behave differently than it did in prior versions of FS.

PS: Please tell us if your 3D model was last exported into a glTF immediately prior to use in your MSFS project, utilizing MCX, or if instead your 3D model was last exported into a glTF from a 3D modeling application via either 3DSMAX or Blender exporter plugins.


Be aware that a Blender MSFS glTF exporter plugin by (Asobo ?) may behave 'different' from other exporters:

GitHub - AsoboStudio/Microsoft-Flight-Simulator-2020-glTF-Blender-IO

Contribute to AsoboStudio/Microsoft-Flight-Simulator-2020-glTF-Blender-IO development by creating an account on GitHub.

github.com

https://developer.blender.org/T96112

glTF File Export with MSFS Exporter broken in 3.2 and 3.1 Builds of Blender

"Proxy management is now removed from Blender.

Seems the addon needs to be updated, but it is not managed by Blender team or Khronos team."

Proxies - Blender 4.2 Manual

docs.blender.org

Library Overrides - Blender 5.1 Manual

docs.blender.org

GaryGB

 

[downscc]

Thanks for the comprehensive reply Gary, however, I don't use the in-game developer mode. The UI is too much like a game with all the widgets and gadgets and I guess one just eyeballs where everything goes. I'm not going to play that game. As a retired engineer and once-upon-a-time familiarity with AutoCAD and later 3D modelling I'm much more comfortable with the ADE UI and easy (much easier than that DEV UI) access to object parameters.

I prefer to compile within a console window directly invoking fstoolspackage.exe and my problem with changing a path name is limited to that point of view. I was pretty happy to have found the solution was the deletion of files in the _PackageInt folders. This has nothing to do with the model, it's the same that I've been using since original ADE alpha release.