I am experiencing CTD while compiling most of my aircraft packages (MB-339,
SU-31, F-35, F-14, T-45) while on seems to work (LONG-EZ). I have cleared the
package and _PackageInt folders. File structure seems correct… still, CTD
after a second or two after the BUILD PACKAGE command. File structure seems
correct according to the latest SDK changes.
Upon further investigation, at least two of the packages that had the issue
work fine if I remove the aircraft.loc file either entirely or from the
localization folder. SU-31 package: if .loc file is where it should be
→ CTD upon package building. If .loc file is misplaced → warning message,
package NOT VALIDATED (understandably). if loc. file is removed, no issues →
package works fine (but it has no localization) MB.339 package: if .loc
file is where it should be → CTD upon package building. If .loc file is
misplaced → warning message, package NOT VALIDATED (understandably). If loc.
file is removed → package is built but ONLY THE MAIN VARIANT OF THE
MB.339 is shown (the others are not, package contains 3 aircraft variants).
I cannot see the difference with packages that do work (for which the .loc
files were also placed correctly in the localization folder). These are all
payware packages so localization files were provided by Microsoft.
Just to provide more details… basically for all of my projects cause CTD in
Developer Mode if, and only if, the .loc file is placed in the localization
folder. If no .loc file is included, no CTD - package is validated and no
issues. Whatever the reason, only the Long-EZ seems to work as it should.
After quite a bit of investigation, maybe I have found where the
localization problem was: Some of my projects were configured so that in the
package definition file the Asset Dir was set with a “.” (dot) in front of the
path name E.g. ".\SimObjects\Airplanes\IndiaFoxtEcho_F35C" Removing the “.”
in front of the path name seems to solve the problem. I realized this as the
MSFSLocalization Manager crashes when trying to create files on those paths.
The problem in having multiple planes with the same panel.cfg still stands at
the moment.
Hello @Indiafoxtecho Are you editing those
paths manually? From what I can see, the Project Editor prevents you from
setting such a path. Regards, Sylvain
Yes - those were done manually (basically a copy-paste of my vey first
project). It worked just fine with the previous sim version BTW (and creates
problems only with the .loc file). The CTD problem is solved… the multiple
planes with the same panel.cfg problem still stands and confirmed: namely, we
had several aircraft project which had multiple SimObjects (as they slightly
different fm and engines) and were sharing the same xml avionicsby aliasing
the panel.cfg using the legacy approach (example below from our F-35B and C
that were using the F-35A panel and XML gauges): [fltsim]
alias=\IndiaFoxtEcho_F35A\Panel Now the variants do not show up anymore in
game after building the package. They seem to show only if the panel folder is
duplicated (which seems unnecessary).
Yes, packages were edited manually - basically a copy-past of the first
projects we did. Please note that the “.” was not a problem before (and it
still is not unless you have the .loc file)… so the crash is probably due to
the localization “unpacking” process. Now that I know it, it is not a big
deal, but it may be worth mentioning. The problem of multiple aircraft sharing
the same XML gauges still stands - namely before the update you could alias
panel cfg using: [fltsim] alias=\IndiaFoxtEcho_F35A\Panel as panel .cfg. Now,
existing packages work in the sim, but in new ones the alternate versions do
not show up in the sim. I will make a separate post on this.
@Indiafoxtecho Would you be able to provide us with the package you built with
SU11? As far as I can see the F35 package that is already available to users
works fine on SU11 so it must be that the package built with SU11 is different
from the currently available one - it probably explains why the F35B/F35C do
not appear in the sim and comparing the two packages should allow us to
understand & fix the issue. Best regards, Eric / Asobo
As an additional note, the fact that the MB.339 variant do not show up anymore
seems related to new constraints - panel.cfg aliasing does not seem to work as
it did before… EDIT - to add more detail: previously if the package was
using only XML gauges, and you had multipleversions of the aircraft (say
F-35A, B and C), they could share the same panel.cfg and gauges by aliasing
the panel.cfg - no panel.xml was needed. Now the package does not get
validated, and the additional variants do not show in the game.