- Sun Jan 17, 2016 6:28 pm #495212 Hello all,

I'm posting this message to describe some major changes that are coming up in vPilot 2.0. I'd like to get feedback from the user base about these changes, both positive and negative. This is a pretty long post, but the changes are quite significant and I'd like to describe them fully and accurately so that I can get meaningful feedback from the user base.

The main reason for these changes is to make the whole model matching process work more smoothly and automatically. vPilot's rule-based model matching system with the pre-made downloadable rule sets was a step in the right direction for model matching on VATSIM, but a lot of users still struggle with it. Many don't understand that they can't simply download a rule set without actually having the corresponding AI traffic package installed, and they end up with lots of model matching errors. Some of them post on the forums and get straightened out, but I'm sure there are many that just get frustrated and move on, using a different client or just not flying on VATSIM at all.

Nico Kaan's VMRGenerator was another step in the right direction since it would only generate rules for aircraft that it actually found on your system by scanning folders that you configured it for. However, obviously, a tool like VMRGenerator is only useful if you know about it and know how to use it. Through the forums, we've pointed many users to VMRGenerator and helped them configure it and install the rule set that it generates. That's great, but still the concern is the people that just don't take the time to post on the forums. I considered bundling a tool like VMRGenerator with vPilot so that everyone would have a copy, but it would still be a mostly manual process of configuring the tool, generating the rule set, and then installing it in vPilot. The process really needs to be automatic.

So, for vPilot 2.0, I will be doing away with the concept of downloadable model matching rule sets. vPilot will fully automate the model matching process, and the user will not have to think about model matching at all. It will accomplish this by scanning your flight sim's config file to determine where models are installed on your system, and then scanning those model folders and building a list of all your installed AI traffic models. It will compare this list against a known list of model information and perform model matching on the fly. (See the end of this post for more details on how this will work.)

The only time the user will need to be involved is if they have multiple flight sims installed on their system. In such a case, vPilot will ask the user which simulator they want to scan for installed model information. There will be a way (as there is now) for users to use vPilot with more than one sim if they want.

One of the nice things about the way the model matching system currently works in vPilot version 1 is that vPilot doesn't need to know anything about which simulator you're using. It just needs a SimConnect connection and you're good to go. It trusts that the model matching rule sets that you've downloaded correspond to the models you actually have installed in your sim. For that reason, vPilot version 1 can run on any computer. It doesn't have to run on the same computer as the simulator. Because version 2.0 will need to be able to scan your flight sim aircraft folders, it will have to run on the same computer as the sim. Those of you that run vPilot on a remote computer, don't despair, read on.

There are a number of reasons why many vPilot users like to run vPilot on a computer other than the one that runs FSX/P3D. It may be because they run FSX full screen and it's a major pain to switch over to the vPilot window when necessary. Or they just want to be able to see the vPilot window at all times and don't have a second monitor. Some just want to reserve every last bit of CPU power on their sim machine for the sim itself.

To accommodate users that want to run vPilot on a remote networked machine, there will be a way to run two copies of vPilot, one on the sim machine, one on the remote machine, and they will communicate over the network and remain in sync with each other. The copy running on the sim machine will be running in "host mode" and the one running on the networked machine will be running in "remote mode". When in remote mode, vPilot is essentially acting as a remote control for the host copy. Any actions you perform in the remote window will be sent over the network and carried out on the host machine. You'll actually be able to use either the host or the remote copy to perform any actions such as connecting, filing a flight plan, squawking mode C, chatting with controllers or other pilots, etc.

If you are one of those users that runs vPilot on a remote machine in order to try to reserve every last bit of CPU power for the sim, you may be thinking that this is a bad thing since all the vPilot processing will happen on the sim machine with vPilot 2.0. However, I think you'll find that the difference won't be noticeable. I say that because by far the most CPU-intensive part of vPilot's processing is keeping the position of all AI aircraft up to date with smooth movement on screen. And even with the current version of vPilot, that processing still runs on the sim machine via TrafficProxy. The rest of vPilot's functionality uses almost zero CPU time. These days when pretty much everyone has a multi-core CPU, this is really a non-issue.

One nice side effect of this change is the fact that voice comms will be running on the host copy of vPilot, on the same machine as the sim. Many users that currently run vPilot on a networked machine have asked for the ability to keep the voice comms on the sim machine so that they can, for example, use voice command tools to control the sim and be able to hear VATSIM ATC through the same headset.

Note that when you launch vPilot 2.0 in remote mode, you will be able to have the remote copy take over voice comms from the host if you wish. In other words, with vPilot 2.0, you'll be able to have VATSIM voice audio handled on either the sim machine or the remote machine. And you'll still be able to configure your PTT (push-to-talk) key or button on either the host or the remote, just like you can in the current version.

So, that's it. Thanks for reading ... please take a minute and post your thoughts on these upcoming changes. I've only recently started work on this new version, so it'll be months before it's available, and there's still time to make changes to the planned functionality. Please limit your replies to feedback on the above. If you have suggestions for other changes or new features, please post a separate thread.

----------

Now for the details on how the automated model matching will work:

When you first launch vPilot 2.0, it will scan your registry to find which sim(s) you have installed. If you are running more than one sim, you will be prompted to choose which one you want to use vPilot with. vPilot will then scan the configuration files for that sim and find all the SimObjectsPaths definitions. It will then scan those folders looking for aircraft.cfg or sim.cfg files. It will then scan those files and build a database of all the models you have installed.

vPilot will also download a data file containing information about all known models. The file will be included with the installer, and it will be downloaded only if the version on the vPilot web server is newer than the version you have on your machine. This file will include a mapping of model name to the ICAO aircraft type code and airline code (if any) for all the models we know about. Initially this data file will contain all the models that are currently defined in the various model matching rule sets available for download in the current version of vPilot. (So it'll include all the models from World of AI, Ultimate Traffic, MyTraffic, default aircraft, etc.)

When vPilot scans your installed models, it'll send information about any models it doesn't know about to the vPilot web server. I will use that raw data to improve the database of known models over time. So as more people use vPilot 2.0, the automatic model matching will become more and more accurate. Initially it will be at least as accurate as it is now in version 1 (actually even more accurate) because the initial version of the known model database will contain all of the model information currently available for download in vPilot version 1. Plus, if it is able to determine the ICAO type code and airline code from the data in the aircraft.cfg file, it will be able to make use of that model even if it's not included in the known model database. (Something that vPilot version 1 cannot do by itself.)

For those of you that fly for a VA with your own set of models, you will still be able to load a custom model matching rule set into vPilot 2.0. vPilot will look for matches in your custom rule set(s) before it performs the automatic matching.

If vPilot finds more than one model that matches an aircraft you encounter online, it will choose one based on the order the model is defined in the simulator's config file. It will prioritize default aircraft last. In other words, if you have both WoAI's JetBlue A320 and MyTraffic's JetBlue A320 installed, it will use the one that comes first in your configured SimObjectsPaths definitions in your simulator's config file. Any custom rule sets will have the highest priority. Default aircraft and any aircraft installed in the "SimObjects/Airplanes" folder will have the lowest priority. This scheme will give advanced users a way to control the matching precedence when they have multiple AI traffic packages installed.

Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy
Senior Controller, Boston Virtual ARTCC

- Sun Jan 17, 2016 8:31 pm #495217 As a whole, I love the idea. One personal concern I have on my end is that I have spent hours specifically configuring which models I want.
I use WOAI, and I'm sure more than 90% of people that use it with VMRGenerator just run it without any manual modifications. What I have done is completely redid my AI_liveries.txt file to only include specific versions of models I want (I'm not a fan of special liveries being on most of the models of a plane's airline). I wonder if you could add a way to manually select which models are used (even through a text based config file) in order for the few of us that make changes manually to still have that ability/functionality.

Oakland ARTCC

- Sun Jan 17, 2016 9:04 pm #495218 Thanks for the feedback, Josh ... that's very helpful. I hadn't considered the fact that some people might want to deliberately exclude some liveries from being used.

I'll come up with an example to see if I understand what you're describing:

Let's say WoAI has 3 different Southwest 737 liveries. Two of them are "normal", (the purple and the brown) and one is the Shamu (killer whale) livery. You'd like to be able to set up vPilot to NOT use the Shamu livery. Is that right?

If so, I think you'll be fine with the new system because you can still load custom model matching rule sets, and any custom rule sets will take precedence over the automatic model matching. So you should be able to take the file that VMRGenerator made (using your AI_liveries.txt customizations) and load that as a custom rule set. In my example above, if you encounter an SWA 738, vPilot will first look in your custom rule set for a match, and it will find one referencing the two "normal" SWA liveries. It will choose one at random and create the aircraft using that model.

Does that make sense?

I wonder if you could add a way to manually select which models are used (even through a text based config file) in order for the few of us that make changes manually to still have that ability/functionality.

I think instead of having a text file that lists models to use, I would have a text file that lists models to ignore. That way when updates are made to the "known models" database, and/or when you install new models, you wouldn't have to remember to add them to the file. This approach would allow you to do what you want without needing to use VMRGenerator. What do you think?

Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy
Senior Controller, Boston Virtual ARTCC

[Don Desfosse 1035677]

- Sun Jan 17, 2016 9:34 pm #495220 Ross, thanks so much for embarking on this great improvement! One idea might be to allow the user to select model matching precedence from within vPilot, instead of relying on the order found in their .cfg file. If that's possible, maybe it starts with the order found in the .cfg file as a default, but allows the user to drag and drop / move the selections to set precedence, much like one can now do for model matching rulesets. This would eliminate having folks having to go into their .cfg files, which might be another reason some folks might not post for help and move on. Just a thought.

- Sun Jan 17, 2016 9:52 pm #495224

One idea might be to allow the user to select model matching precedence from within vPilot, instead of relying on the order found in their .cfg file. If that's possible, maybe it starts with the order found in the .cfg file as a default, but allows the user to drag and drop / move the selections to set precedence, much like one can now do for model matching rulesets.

I thought about doing just that, but I figured that the type of user who has multiple model sets installed AND wants to control their precedence is probably the type of user who is fine with adjusting the cfg file. I may still do it though.

This would eliminate having folks having to go into their .cfg files, which might be another reason some folks might not post for help and move on. Just a thought.

I think the number of people who meet those four criteria (multiple model sets installed, want to control the precedence, aren't comfortable with editing cfg files, and won't post for help) is extremely small.

Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy
Senior Controller, Boston Virtual ARTCC

- Sun Jan 17, 2016 10:21 pm #495225 Have you considered allowing the use of the "old" *.vmr rule set matching and the new auto-matching as a hybrid mode?
I for one have adapted my own little ruleset for VFR traffic based on callsign, and I wouldn't want to lose that.

VATSIM Germany



VATSIM Germany on Facebook | VATSIM Germany on Twitter

- Sun Jan 17, 2016 10:24 pm #495226

Have you considered allowing the use of the "old" *.vmr rule set matching and the new auto-matching as a hybrid mode?
I for one have adapted my own little ruleset for VFR traffic based on callsign, and I wouldn't want to lose that.

Hi Adam,

If you read the last few paragraphs of my original post (the detailed description of how the automatic model matching will work) you'll see that you'll still be able to load custom rule sets, and they will take precedence over any automatic model matching.

Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy
Senior Controller, Boston Virtual ARTCC

- Sun Jan 17, 2016 10:28 pm #495227 I would personally love the idea of automated model matching as from the day I transitioned from FSX to P3D meant a transition to vPilot, I couldn't connect to VATSIM due to the continuous model matching set errors. Yes, I read the documentation, and tried downloading and installing the AI package tens of times, but unfortunately, the problem persists until now.

- Sun Jan 17, 2016 11:16 pm #495228 Ross, I like your idea for handling exclusion. However,aybe some way to view all the models you have in order to know what to exclude?

Oakland ARTCC

- Sun Jan 17, 2016 11:22 pm #495229

Ross, I like your idea for handling exclusion. However,aybe some way to view all the models you have in order to know what to exclude?

Are you talking about something that would be the equivalent of the AI_liveries.txt file that VMRGenerator creates? If so, then there will be an XML file that contains information about all the models found during the scan. You could always look through that. (Or you could look through the auto-generated rules file that vPilot will create.)

Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy
Senior Controller, Boston Virtual ARTCC

- Mon Jan 18, 2016 7:01 am #495242 Great news! I'm curious, is the sole focus of v2 the new take on AI packages, or are you considering expanding/changing other features as well? For example, the tower view function that you've been bugged with a bunch of times, and that you haven't strictly excluded from future possibilities? I'm sorry for bringing this element without relevance to what you're actually asking for in this thread, but I couldn't see a better time or place to ask.

- Mon Jan 18, 2016 8:18 am #495244 The focus is the stuff mentioned in this thread, namely reworking the model matching and how vPilot runs over a network.

Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy
Senior Controller, Boston Virtual ARTCC

- Mon Jan 18, 2016 9:44 am #495246 In FSinn there was the ability to stop it from injecting traffic. This is useful, when flying shared cockpit in multiplayer on the network, otherwise multiple sets of traffic are injected on top of one another.
Also FSinn had a traffic radar, any chance of something similar?
Lastly, FSinn model matching, would use all aircraft you had installed, but in flight you could edit what aircraft you were seeing . I.e if you were seeing CAW332 as a B738 in the comair livery, you could change it to see them as a Cessna 172 etc, which is sometimes very useful, when it sets the incorrect aircraft to start with.

Kind Regards
Jason Adriaan

- Mon Jan 18, 2016 9:57 am #495247 Hi Ross,

thank you for trying to improve this even more, i have had very few problems with the model matching, except of course when the acft field is blank, or I think the pilot didn't file a FP, like a person observing or local VFR.

I am not fully clear about the exceptions, I tried reading it a few times, might be because it's 2am i am not getting it clearly. I don't worry too much about livery, but I am concerned about it loading my payware acft into the sim for traffic, as it takes more memory. So the PMDG, FSL, QW, CS stuff, I would like to avoid, so I like the idea of a text file that stays out of all program folders and only needs to be setup once and updates don't overwrite it. Kind of like the FSIGNORE file in FSInn.

If this is already covered, then I am good and will read thru docs when the new version, for which I thank you again, comes out.

Are you going to use the existing rule sets to build your web server data, or are you planning to collect data again when it comes time for building it?

When is your next Flight||VATSIM HitSquad Member, ZOA/ZAK/P1

- Mon Jan 18, 2016 1:59 pm #495255 Please limit your replies to feedback on the changes I've described in the original post regarding model matching and running vPilot over a network. If you have suggestions for other changes or new features, please post a separate thread so that they can be discussed without cluttering this thread.

Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy
Senior Controller, Boston Virtual ARTCC