Aircraft expansion that works in 2020 doesn't work in 2024 at all

[MSFS 2024] Bug Reports Aircraft
, ,
1

Version: 1.4.20.0

Frequency: Consistently

Severity: Blocker

Marketplace package name: Not applicable yet

Context: Community deployment, GA-8 Airvan

**Similar MSFS 2020 issue:*No problem

Bug description: The aircraft is structured as two packages:

  • sws-aircraft-airvan: the base aircraft
  • sws-aircraft-airvan0systemspulse: expansion pack containing modified XML and cfg files

The idea is tha airvan0systemspulse loads in the VFS after the base aircraft and that is why it was named this way. Its XML/cfg files are intended to replace the base aircraft’s ones as they come after it and in FS2020 it works OK.

In FS2024 though, only the base aircraft works correctly. Putting the FS2020 base and expansion packs in FS2024’s Community folder result in bugs such as code conflicts and inoperative systems. If the Expansion is merged into a single package with the base aircraft, everything works fine.

Am I not understanding the VFS correctly and therefore need to make the “SystemsPulse” version a full, stand-alone aircraft? Or is there a problem with the VFS in FS2024?

Repro steps: Install both packs side-by-side in Community of FS2020. Notice that the aircraft works well and you can trigger failures from the tablet (i.e. try the “Fuel Filter Blockage” and notice the respective “Check Fuel” light comes on). In FS2024 and the plane installed the same way gets you warning lights turned on and systems not operating as designed.

Attachments: Sent via PM

2

Hello @SWS-AlexVletsas

This is likely the same issue as discussed here: Simple FS2020 aircraft mod not working anymore with FS2024 after SU1 or SU2 - [MSFS 2024] Questions & Community Discussions / Aircraft - MSFS DevSupport

ModelBehaviorDefs folder is now VFS locked, unless the overriding package explicitly states which file it’s overriding: The Project Inspector

Regards,
Sylvain

3

Thank you @FlyingRaccoon, I will look into that for the FS24 version.

I should specify that the problem is with the FS2020 version of the aircraft running in 2024 compatibility, so I can’t do the override trick using the FS20 project editor.

4

Yes, this rule applies to all packages.
This was done to cover issues discussed here: [VFS] We need to find a way to stop this madness - [MSFS 2020] Questions & Community Discussions / Aircraft - MSFS DevSupport

I have raised the concern internally about situations such as yours.

Regards,
Sylvain

1 Like
5

@FlyingRaccoon that’s good to hear, again thanks for taking this into account. I do have a suggestion that may help with this.

In my project I used the Dependencies tag in Package Definitions:

	<Dependencies>
		<Dependency Version="0.1.0">
			<Name>sws-aircraft-airvan</Name>
		</Dependency>
	</Dependencies>

This could be an indication to “unlock” the files of the Airvan when this package is detected in 2020 and 2024. But to take it one step further, adding a second property could define what kind of dependency that is. I.e.

	<Dependencies>
		<Dependency Version="0.1.0">
			<Name>sws-aircraft-airvan</Name>
			<Type>Override</Type>
			<Priority>1</Priority>
		</Dependency>
	</Dependencies>

Using “Override” would indicate that the VFS should unlock the base aircraft files and this add-on will override any files that have the same name as the original package. The “Priority” property could be used to specify the priority of the add-on package relative to other packages.

  • If is omitted, then the base package will be locked, just like it is today.
  • If is omitted, then the package will assume a default priority of 1. If more packages have a priority of 1 set, then they will resolve in alphabetical order, like they do now.

Livery add-ons don’t need to have these properties at all.

Let me give a difficult example, where we have four airplanes and a livery:
PC-12 Legacy
This is our base aircraft, sws-aircraft-pc12
PC-12 Legacy SystemsPulse: Dependency Type: Override, Priority: 1
This is an expansion pack that will sit on top of Base Airplane and enable failures by overriding its files.
PC-12NG: Dependency Type: Override, Priority: 2.

-This will be an expansion pack sitting atop the PC-12 and adding a glass cockpit. 
-We want to re-use assets from the base pack, i.e. art assets such as the seats, exterior model and cabin walls, but also the common systems between the two planes.
-We set its priority to "2", which means that it will inherit the failures from the previous package:
-->It is looking to inherit the base PC-12, but because these have already been overridden by the expansion to the base pack, it will get the "failures" as well, wherever these are being used.

PC-12NG SystemsPulse: Dependency Type: Override, Priority: 3.

This is a failure add-on to the PC-12 which adds failures specific to the NG. It will override anything below it with the same name.

PC-12 Livery Packs: Dependency name: sws-aircraft-pc12, Dependency Type: Not specified, Priority: Not specified

These livery packs require the base PC-12 to be sold and installed, but will come after all the other modules.
6

@FlyingRaccoon for your information, I was able to make a 2024-native expansion for my aircraft by overriding .js and modelbehaviors using the SDK instructions. I had to move code from my interior/exterior into the ModelBehaviors folder and then summon them as templates in the SimObject.

  • I noticed that I couldn’t overwrite the interior/exterior behaviors.xml files in the SimObject container. Is that intended behaviour?
  • I could overwrite .cfg files without issue -which is good!

Thanks, Alex

7

It depends on what you are doing really.
There are subtleties with compiled behaviors for example.
With 2020 behaviors, everything is evaluated when the aircraft is loaded and VFS paths will be identical for PackageSources and Packages files.
When compiling behaviors, multiple files and components end up aggregated in a single output xml file in Packages. This is the VFS file that will be used and need to be overriden, but it doesn’t necessarily match the PackageSources file layout.

For example, let’s imagine you want to create a package to mod the Da62 cockpit with the Passengers preset loaded.
If you only copy and modify Cockpit_Behavior.xml from the Function_Interior attachment, package build will output a Cockpit.behavior.xml but will not do anything.
This is because the Passengers preset does not reference the Function_Interior attachment directly, it references the Function_Interior_Cabin_Passengers attachment.
So when the original Da62 package is built and its behaviors are compiled, the content of the Function_Interior behaviors are aggregated in the output of the Function_Interior_Cabin_Passengers behaviors: cabin.behaviors.xml → this is the one you need to override but your mod package didn’t output this file.

In this case, you will need to copy the Function_Interior_Cabin_Passengers attachment source files as well, so that the behavior compilation will also compile the passengers cabin behaviors using your modified cockpit behaviors.

When in doubt, you can check which file is loaded through the Behaviors tool:

image
image1278Ă—582 232 KB

Regards,
Sylvain

1 Like
8

I see now. Essentially Compiled behaviours will “merge” the base behaviours into the final XML file that inherits from it.

Is that why when opening the VFS I see (for example in the Carenado NGX) that there’s an XML file that has all the animations and clicks packed in it, but formatted like the old FSX code?

9

I’m not sure what you mean by “formatted like the old FSX code”.

Compiled behaviors are packed and most strings are hashed:

image
image884Ă—518 19.9 KB

1 Like
10

This is like the FSX/ACES Modeldef schema.

image
image1446Ă—981 104 KB

But we’re veering off-topic. I’m hoping for a fix to the FS2020 expansions working with backwards compatibility, but my questions are answered and a FS24 native solution has been found.

Again, thanks a lot!

2 Likes
11

@FlyingRaccoon sorry to drag you back into this, but it looks like the cfg files aren’t being overwritten with the FS2024-native expansion pack.

My base aircraft has a Systems.cfg under “SimObjects\Airplanes\SWS_GA8_Airvan\Common\Config” with 41 LocalVars and 10 LocalVars_Ex1 registered for state saving.

My expansion aircraft has a “Copy” type asset. In the folder “SimObjects_Failures\Airplanes\SWS_GA8_Airvan\Common\Config” it has a systems.cfg with 38 registered LocalVars and 166 LocalVars_EX1.

My issue is that the expansion pack’s systems.cfg file doesn’t register the additional variables.

The second problem, I have added two new XML files to the modelbehaviordefs folder which seem to be ignored.

I have sent the project with a PM in case you can assist.

12

Hello @SWS-AlexVletsas

I don’t think that’s related to the issue you reported in this topic originally.
Please create a dedicated topic so we can track this issue separately.

Regards,
Sylvain

1 Like
13

Hello @SWS-AlexVletsas

This has been changed in SU4 beta and only core Asobo and Working Title template folders should now be locked.

Regards,
Sylvain

1 Like
14

Hello Sylvain,

I saw the change notes and you beat me to i. Just to be clear, this only applies to 2020 planes’ backward compatibility, correct? If I understand it is mot related to the other issue I reported regarding the FS24 native expansion pack.

15

No, this applies to 2024 as well.

We don’t have an explanation yet for the other issue you reported.

Regards,
Sylvain

1 Like