Matching rules are not working

[Joachim Clemens]

Hi all,

I have the problem that my matching rules are not working correctly in vPilot.

Here is how my rules look like at the example of DLH:

Quote

<?xml version="1.0" encoding="utf-8"?>
<ModelMatchRuleSet>
...
  <ModelMatchRule CallsignPrefix="DLH" TypeCode="A319" ModelName="A319DLH5//A319DLH//A319DLH2//A319DLH3//A319DLH4" />
  <ModelMatchRule CallsignPrefix="DLH" TypeCode="A320" ModelName="A320DLH3//A320DLH//A320DLH2//A320WDLHWL2//A320WDLHWL3//A320WDLHWL4//A320WDLHWL5//A320WDLHWL" />
  <ModelMatchRule CallsignPrefix="DLH" TypeCode="A321" ModelName="A321DLH2//A321DLH6//A321DLH3//A321DLH4//A321DLH//A321DLH5" />
  <ModelMatchRule CallsignPrefix="DLH" TypeCode="A346" ModelName="A346DLH//A346DLH2" />
  <ModelMatchRule CallsignPrefix="DLH" TypeCode="A359" ModelName="A359DLH" />
  <ModelMatchRule CallsignPrefix="DLH" TypeCode="A388" ModelName="A388DLH//A388DLH2" />
  <ModelMatchRule CallsignPrefix="DLH" TypeCode="B744" ModelName="B744DLH//B744DLH2" />
  <ModelMatchRule CallsignPrefix="DLH" TypeCode="B748" ModelName="B748DLH2" />
...
</ModelMatchRuleSet>

However, vPilot seem to ignore some of them while others are working. Here are the matching results from the debug window:

Quote

[09:49:35.865] Model match result - Callsign: DLH06C - TypeCode: A321 - ModelName: Airbus A320 Neo Asobo AirTraffic 00 - Rule Set: AutoGenerated - Pass: 3
[09:49:35.868] Attempting to add aircraft to sim with callsign DLH06C and model Airbus A320 Neo Asobo AirTraffic 00
[09:49:36.300] Model match result - Callsign: DLH856 - TypeCode: A321 - ModelName: Airbus A320 Neo Asobo AirTraffic 00 - Rule Set: AutoGenerated - Pass: 3
[09:49:36.317] Attempting to add aircraft to sim with callsign DLH856 and model Airbus A320 Neo Asobo AirTraffic 00
[09:49:36.662] Model match result - Callsign: KLM23591 - TypeCode: B737 - ModelName: B738WKLMWL - Rule Set: D:\vPilot\vPilot Files\matching_rules_x-csl.vmr - Pass: 2
[09:49:36.665] Attempting to add aircraft to sim with callsign KLM23591 and model B738WKLMWL
[09:49:38.192] Model match result - Callsign: DLH1316 - TypeCode: A333 - ModelName: Generic Airliner Twin Engines Asobo 02 - Rule Set: AutoGenerated - Pass: 3
[09:49:38.194] Attempting to add aircraft to sim with callsign DLH1316 and model Generic Airliner Twin Engines Asobo 02
[09:49:38.274] Model match result - Callsign: CSN470 - TypeCode: B78X - ModelName: Generic Airliner Twin Engines Asobo 01 - Rule Set: AutoGenerated - Pass: 3
[09:49:38.277] Attempting to add aircraft to sim with callsign CSN470 and model Generic Airliner Twin Engines Asobo 01
[09:49:38.352] Model match result - Callsign: DLH6HT - TypeCode: A320 - ModelName: Airbus A320 Neo Asobo AirTraffic 01 - Rule Set: AutoGenerated - Pass: 3
[09:49:38.362] Attempting to add aircraft to sim with callsign DLH6HT and model Airbus A320 Neo Asobo AirTraffic 01
[09:49:39.273] Model match result - Callsign: DLH5PM - TypeCode: CRJ9 - ModelName: Generic Private Jet Asobo 02 - Rule Set: AutoGenerated - Pass: 3
[09:49:39.276] Attempting to add aircraft to sim with callsign DLH5PM and model Generic Private Jet Asobo 02
[09:49:39.445] Model match result - Callsign: DLH462 - TypeCode: B748 - ModelName: B748DLH2 - Rule Set: D:\vPilot\vPilot Files\matching_rules_x-csl.vmr - Pass: 1
[09:49:39.453] Attempting to add aircraft to sim with callsign DLH462 and model B748DLH2
[09:49:39.775] Model match result - Callsign: DLH21P - TypeCode: A320 - ModelName: Airbus A320 Neo Asobo AirTraffic 02 - Rule Set: AutoGenerated - Pass: 3
[09:49:39.782] Attempting to add aircraft to sim with callsign DLH21P and model Airbus A320 Neo Asobo AirTraffic 02
[09:49:40.157] Model match result - Callsign: DLH2BM - TypeCode: A21N - ModelName: Airbus A320 Neo Asobo AirTraffic 02 - Rule Set: AutoGenerated - Pass: 3
[09:49:40.172] Attempting to add aircraft to sim with callsign DLH2BM and model Airbus A320 Neo Asobo AirTraffic 02
[09:49:40.364] Model match result - Callsign: CFG2114 - TypeCode: B763 - ModelName: Generic Airliner Twin Engines Asobo 01 - Rule Set: AutoGenerated - Pass: 3
[09:49:40.366] Attempting to add aircraft to sim with callsign CFG2114 and model Generic Airliner Twin Engines Asobo 01
[09:49:40.425] Model match result - Callsign: UAL988 - TypeCode: B78X - ModelName: Generic Airliner Twin Engines Asobo 02 - Rule Set: AutoGenerated - Pass: 3
[09:49:40.428] Attempting to add aircraft to sim with callsign UAL988 and model Generic Airliner Twin Engines Asobo 02

Apparently, a lot of aircraft are matched to generic planes, while some are working correctly (e.g. DLH462 and KLM23591).

I did an additional test with a ruleset that I downloaded from someone else. Among others, it contains the following lines:

Quote

  <ModelMatchRule CallsignPrefix="DLH" TypeCode="A20N" ModelName="A20N DLH" />
  <ModelMatchRule CallsignPrefix="DLH" TypeCode="A320" ModelName="A320 DLH//A320DLH3//A320DLH//A320DLH2//A320WDLHWL2//A320WDLHWL3//A320WDLHWL4//A320WDLHWL5//A320WDLHWL" />

Note that the model "A320 DLH" and the A20N models are not installed for me. From vPilot I get the following for a particular A320:

Quote

[09:57:21.063] Model match result - Callsign: DLH21P - TypeCode: A320 - ModelName: A320 DLH - Rule Set: D:\vPilot\vPilot Files\matching_rules_x-csl-extended.vmr - Pass: 1
[09:57:21.064] Attempting to add aircraft to sim with callsign DLH21P and model A320 DLH
[09:57:21.245] Failed to create aircraft DLH21P using model "A320 DLH". The model may be corrupt or missing. vPilot will try to create the aircraft with a different model.
[09:57:21.639] Model match result - Callsign: DLH21P - TypeCode: A320 - ModelName: A20N DLH - Rule Set: D:\vPilot\vPilot Files\matching_rules_x-csl-extended.vmr - Pass: 2
[09:57:21.640] Attempting to add aircraft to sim with callsign DLH21P and model A20N DLH
[09:57:21.658] Failed to create aircraft DLH21P using model "A20N DLH". The model may be corrupt or missing. vPilot will try to create the aircraft with a different model.
[09:57:22.000] Model match result - Callsign: DLH21P - TypeCode: A320 - ModelName: Airbus A320 Neo Asobo AirTraffic 01 - Rule Set: AutoGenerated - Pass: 3
[09:57:22.001] Attempting to add aircraft to sim with callsign DLH21P and model Airbus A320 Neo Asobo AirTraffic 01

The failures to add the models are of course expected, because the models are not installed, but in contrast to my ruleset above, the plane is correctly matched to a model instead of going directly to a generic plane.

Has any body an idea what may be wrong with my ruleset and/or how to further track down the issue?

Thank you in advance for your help!

[Joachim Clemens]

I did some further testing and I discovered that the problem seems to be specific for A320-family planes from DLH. Other DLH planes (e.g. A359 and B748) and other A320-family planes from other carriers (incl. EZY, CFG, SWR, AUA, THY) are matched correctly.

Furthermore, when I add a fallback line without CallsignPrefix to my matching rules, the A320-family aircraft from DLH are matched to this one. I also tried to specify only one model for the DLH A320 but with no success.

Does vPilot have some kind of cache that I can clean?

I start running out of ideas here.

Edited August 28, 2021 at 10:11 AM by Joachim Clemens

[Ross Carlson]

There is no cache. The custom rules are loaded from the VMR files each time vPilot starts up.

I would try loading a single VMR file (no other files at all) with a single rule matching a DLH A320 to a single specific model, and see what happens.

[Joachim Clemens]

Thanks for your reply!

I created a single VMR files with the following content:

Quote

<?xml version="1.0" encoding="utf-8"?>
<ModelMatchRuleSet>
  <ModelMatchRule CallsignPrefix="DLH" TypeCode="A320" ModelName="A320DLH3//A320DLH//A320DLH2//A320WDLHWL2//A320WDLHWL3//A320WDLHWL4//A320WDLHWL5//A320WDLHWL" />
</ModelMatchRuleSet>

Unfortunately, the result is the same:

Quote

[11:04:37.503] Model match result - Callsign: DLH856 - TypeCode: A320 - ModelName: Airbus A320 Neo Asobo AirTraffic 01 - Rule Set: AutoGenerated - Pass: 3
[11:04:37.506] Attempting to add aircraft to sim with callsign DLH856 and model Airbus A320 Neo Asobo AirTraffic 01
[11:04:35.885] Model match result - Callsign: DLH3RE - TypeCode: A20N - ModelName: Airbus A320 Neo Asobo AirTraffic 02 - Rule Set: AutoGenerated - Pass: 3
[11:04:35.887] Attempting to add aircraft to sim with callsign DLH3RE and model Airbus A320 Neo Asobo AirTraffic 02

I tried to work around it and define the fallback rules myself by adding a rule for the A320 with no callsign that maps to the DLH models:

Quote

  <ModelMatchRule TypeCode="A320" ModelName="A320DLH3//A320DLH//A320DLH2" />

Unfortunately, this doesn't work either. The DLH A320 are stilled mapped to generic planes. However, I observed that other fallback rules are working.

So I did another test by defining a DLH rule with other models:

Quote

  <ModelMatchRule CallsignPrefix="DLH" TypeCode="A320" ModelName="A320AUA5//A320AUA//A320AUA6//A320AUA2//A320AUA3//A320AUA4" />

Surprisingly, this works. Moreover, this rule is even used as fallback for similar A320 family types:

Quote

[11:20:21.976] Model match result - Callsign: DLH352 - TypeCode: A20N - ModelName: A320AUA2 - Rule Set: D:\vPilot\vPilot Files\matching_rules_x-csl.vmr - Pass: 2
[11:20:21.977] Attempting to add aircraft to sim with callsign DLH352 and model A320AUA2
[11:20:22.942] Model match result - Callsign: DLH1292 - TypeCode: A321 - ModelName: A320AUA - Rule Set: D:\vPilot\vPilot Files\matching_rules_x-csl.vmr - Pass: 2
[11:20:22.943] Attempting to add aircraft to sim with callsign DLH1292 and model A320AUA

Note that I had specific rules for those types in the VMR file at the same time:

Quote

  <ModelMatchRule CallsignPrefix="DLH" TypeCode="A20N" ModelName="A320WDLHWL2//A320WDLHWL3//A320WDLHWL4//A320WDLHWL5//A320WDLHWL" />
  <ModelMatchRule CallsignPrefix="DLH" TypeCode="A321" ModelName="A321DLH2//A321DLH6//A321DLH3//A321DLH4//A321DLH//A321DLH5" />

Another finding is that the DLH rule seems to be not the only one that is not working, even though being the most obvious in central Europe. For example the RYR rule is ignored as well:

Quote

  <ModelMatchRule CallsignPrefix="RYR" TypeCode="B738" ModelName="B738WRYRWL4//B738WRYRWL9//B738WRYRWL5//B738WRYRWL//B738WRYRWL6//B738WRYRW10//B738WRYRWL8//B738WRYRW11//B738WRYRWL2//B738WRYRWL7//B738WRYRWL3" />

Quote

[11:20:19.343] Model match result - Callsign: RYR92L - TypeCode: B738 - ModelName: B738W@CNWL - Rule Set: D:\vPilot\vPilot Files\matching_rules_x-csl.vmr - Pass: 3
[11:20:19.344] Attempting to add aircraft to sim with callsign RYR92L and model B738W@CNWL

Note that the model "B738W@CNWL" is specified in a fallback rule for the B738 with no callsign.

My current conclusion is that vPilot for some reason doesn't like the model names themselfs, since the same model name doesn't work in different rules while the rules work with different model names. However, I cannot see any obvious mistake there. Moreover, I also did a test where I specified only on of the multiple model names, but this didn't work either.

This looks really strange to me. Do you have any further ideas?

[Joachim Clemens]

It's working! I reinstalled vPilot and selected the option to clear all config files during installation. Now everything is working perfectly fine and as expected.

I probably should have done this earlier. But I was 99.9% sure that the fault is on my side, also since you confirmed that there is no cash file. So still no idea what was going on, but at least it works now.

[Ross Carlson]

If a fresh config file fixed it, then most likely what happened was that at some point in the past, you had these models loaded in a VMR file, but you didn't have them actually installed in the sim. This would cause model matching error messages to appear. vPilot stores a list of "erroneous models" and doesn't try to use them in the future.

However, vPilot clears the erroneous models list whenever anything changes about your installed models, so that it doesn't continue to assume a model is erroneous after you make any change to your models. So this shouldn't have happened, but maybe there's a use case that I didn't account for where a model could get stuck in the erroneous models list even after you install it or update it.

[Joachim Clemens]

This could indeed be a possible explanation. I didn't know about that feature.

The models in question should have been installed at all time, but I copied them around at some point and it could be possible that they were not present during a startup of sim and vPilot. This would also explain why the rule is working with other models from the model set, since these were not flagged as erroneous if vPilot didn't try to add them at the time they were not installed.

I noticed that I should have mentioned that I'm on MSFS. As far as I understand, vPilot does not scan for installed models here, does it? Accordingly, it is not able to detect when I make changes to the installed models, which could be a reason why the erroneous models list was never cleared. Maybe one can add a button to clear the list manually?

[Ross Carlson]

9 hours ago, Joachim Clemens said:

Accordingly, it is not able to detect when I make changes to the installed models, which could be a reason why the erroneous models list was never cleared.

Yes, that's right. When I originally added MSFS support, I disabled erroneous model tracking because of a quirk in timing with MSFS when you end your flight, it would sometimes delete any existing aircraft, and vPilot would try to re-add them, and it would cause false errors. I later added a workaround for that quirk, and then I re-enabled erroneous model tracking for MSFS. It didn't occur to me that the list would never get cleared because vPilot doesn't scan the installed models for MSFS. I will log this as a bug and think about a proper fix. I don't really want to add a button for the user to clear the list, because the list should be internal and not something the user needs to know or think about. I might not have a choice with MSFS, though, at least until I teach vPilot how to scan for installed models like it does with other sims. Another option is to have it auto-clear the erroneous models list for MSFS when vPilot starts up. So it'll still ignore erroneous models, but only for the duration of the current session.

[Joachim Clemens]

2 hours ago, Ross Carlson said:

I don't really want to add a button for the user to clear the list, because the list should be internal and not something the user needs to know or think about.

Yes, I agree that it would be better if the user doesn't need to think about that.

2 hours ago, Ross Carlson said:

Another option is to have it auto-clear the erroneous models list for MSFS when vPilot starts up. So it'll still ignore erroneous models, but only for the duration of the current session.

This sound like a feasible option to me until model scanning is implemented. In fact, this would make users think about cleaning up their matching rules if vPilot keeps complaining about missing or corrupted models, while it will not be too disturbing since it only happens once per model per session.

Another option that came to my mind is to delete the list of erroneous models when the model matching rules are changed. However, this would require vPilot to keep track of the rules. Or maybe one can tie it to clicking one of the buttons for adding or deleting rule sets. This would at least have helped in my case but is of course also not completely fail-safe.

2 hours ago, Ross Carlson said:

at least until I teach vPilot how to scan for installed models like it does with other sims.

I don't know how this is implemented for other sims, but for MSFS a reasonably reliable way to scan for installed models is to look for "aircraft.cfg" files in the Community and Official folders and then search for "title=". This is at least how I implemented it in my script for generating the model matching rules. Let me know if you need more information!

[Ross Carlson]

40 minutes ago, Joachim Clemens said:

In fact, this would make users think about cleaning up their matching rules if vPilot keeps complaining about missing or corrupted models

It's worth noting that it's not only custom matching rules that can cause erroneous models. It could also happen if someone deleted one of the stock models that vPilot uses for automatic model matching. And I've seen cases where the user installs custom liveries in the community folder, and this causes some stock liveries to stop working. I don't yet know how this happens, which is one of the reasons I haven't implemented MSFS model scanning yet, since I don't fully know how files in the community folder interact with and sometimes override files in the official folder. My plan is to reach out to our Asobo dev contacts and get the official word on how it all works (or see if it's well-documented in the SDK), I just haven't had the time yet.

40 minutes ago, Joachim Clemens said:

Or maybe one can tie it to clicking one of the buttons for adding or deleting rule sets.

I briefly considered this as well, but it would only work when the user adds or removes a rule set. It wouldn't help when an already-added rule set was modified, which is of course a common case. It also wouldn't help for the situation I mentioned above where a stock model becomes invalidated by a package installed in the community folder.

40 minutes ago, Joachim Clemens said:

I don't know how this is implemented for other sims, but for MSFS a reasonably reliable way to scan for installed models is to look for "aircraft.cfg" files in the Community and Official folders

That's how it works in the other sims, and that's how it'll work for MSFS, once I gain a full understanding of how the two folders interact. I also need to know how to deterministically locate the Community and Official folders, because they can be anywhere. I think that can be done by reading the InstalledPackagesPath value from the UserCfg.opt file from %appdata%\Microsoft Flight Simulator but I'm not sure if that file is always present in all versions of MSFS. I think it is, just haven't researched it yet.

Edited August 30, 2021 at 08:18 PM by Ross Carlson

[Joachim Clemens]

10 hours ago, Ross Carlson said:

It's worth noting that it's not only custom matching rules that can cause erroneous models. It could also happen if someone deleted one of the stock models that vPilot uses for automatic model matching.

Good point, I haven't thought about that.

10 hours ago, Ross Carlson said:

And I've seen cases where the user installs custom liveries in the community folder, and this causes some stock liveries to stop working. I don't yet know how this happens, which is one of the reasons I haven't implemented MSFS model scanning yet, since I don't fully know how files in the community folder interact with and sometimes override files in the official folder. My plan is to reach out to our Asobo dev contacts and get the official word on how it all works (or see if it's well-documented in the SDK), I just haven't had the time yet.

As far as I know, you can basically override all files from the base installation using packages in the Community folder. This is of course useful, e.g. for improving existing things (G1000/G3000 mod, early versions of the FBW A32N), but it can obviously break things as well. An official statement from Asobo would be the great here! The best case would be if the sim can report which models are installed, but it probably also doesn't know if one is corrupted unless it tries to add it to the scene.

The last time I checked, the model aspect was not documented in the SDK docs. But it has been a while since I had a look at it.

11 hours ago, Ross Carlson said:

I briefly considered this as well, but it would only work when the user adds or removes a rule set. It wouldn't help when an already-added rule set was modified, which is of course a common case. It also wouldn't help for the situation I mentioned above where a stock model becomes invalidated by a package installed in the community folder.

Yes, this is indeed correct. As I said, a more sophisticated solution would be to keep track of changes in the vmr files, e.g. by caching the rules or checking the MD5 sum or modification date. But at least the first one is more complicated to implement and all those solutions wouldn't cover changes to the stock models.

11 hours ago, Ross Carlson said:

That's how it works in the other sims, and that's how it'll work for MSFS, once I gain a full understanding of how the two folders interact.

As far as I know, the Community folder basically has priority over the Official folder. But at least for scenery, there is also a separate file in AppData that handles the load order.

11 hours ago, Ross Carlson said:

I also need to know how to deterministically locate the Community and Official folders, because they can be anywhere. I think that can be done by reading the InstalledPackagesPath value from the UserCfg.opt file from %appdata%\Microsoft Flight Simulator but I'm not sure if that file is always present in all versions of MSFS. I think it is, just haven't researched it yet.

I can only speak for the MS store version and here you have the UserCfg file. Maybe it's worth to have a look at the FBW installer. The location of the Community folder is done in this file starting around line 178: https://github.com/flybywiresim/installer/blob/master/src/main/index.ts

As a fallback, one can ask the user to specify the location of the folders manually if it cannot be determined automatically.

[Ross Carlson]

13 minutes ago, Joachim Clemens said:

The best case would be if the sim can report which models are installed

I requested that in our very early discussions with Asobo, but it hasn't been added. I wasn't really expecting it anyway.

14 minutes ago, Joachim Clemens said:

As a fallback, one can ask the user to specify the location of the folders manually if it cannot be determined automatically.

That would run counter to vPilot's design goal of being as automatic as possible. I'm sure there's a correct way to discover the location of the folders, I just haven't put any time into it yet. The Asobo guys have been great about helping me out, I'm sure they'll be able to tell me what to look for, if it's not just a matter of parsing the UserCfg.opt file.

[Joachim Clemens]

2 hours ago, Ross Carlson said:

I requested that in our very early discussions with Asobo, but it hasn't been added. I wasn't really expecting it anyway.

Any other deterministic way to detect the models would be fine as well.

2 hours ago, Ross Carlson said:

That would run counter to vPilot's design goal of being as automatic as possible.

Yes, I agree with that. But at the moment, there is no automation at all 😉 (No offense, I'm aware of the issues.)

2 hours ago, Ross Carlson said:

I'm sure there's a correct way to discover the location of the folders, I just haven't put any time into it yet. The Asobo guys have been great about helping me out, I'm sure they'll be able to tell me what to look for, if it's not just a matter of parsing the UserCfg.opt file.

Yeah, it doesn't make sense to implement something that is not fail-safe or may be changed in the future. This would be frustrating for you as a dev as well as for the users.

But good to hear that Asobo is general very supportive here. And given that MSFS can still be considered to be very new, I'm really satisfied how well vPilot works with it.

[Ross Carlson]

5 hours ago, Joachim Clemens said:

But at the moment, there is no automation at all

Sure there is ... it's just not very good. 

[Georgios Gatzakis]

the idea of deleting

On 8/30/2021 at 7:11 PM, Ross Carlson said:

Another option is to have it auto-clear the erroneous models list for MSFS when vPilot starts up. So it'll still ignore erroneous models, but only for the duration of the current session.

this sounds like a good stop gap solution 🙂 ... Gladly i found this thread and solved the same issues. It was definately caused by the erroneous model list.

thanks and best Rega