Upcoming changes to vPilot, feedback requested

[Ross Carlson]

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.

[1275389]

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.

[Ross Carlson]

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?

[Don Desfosse]

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.

[Ross Carlson]

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.

[Adam Trzcinski]

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.

[Ross Carlson]

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.

[hagop haladjian 1158037]

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 docomeentation, and tried downloading and installing the AI package tens of times, but unfortunately, the problem persists until now.

[1275389]

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?

[Ross Carlson]

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.)

[Magnus Meese]

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.

[Ross Carlson]

The focus is the stuff mentioned in this thread, namely reworking the model matching and how vPilot runs over a network.

[Jason Adriaan 1274456]

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

[Charan Kumar]

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?

[Ross Carlson]

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.

[Ross Carlson]

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.

 

vPilot 1.1 It already has observer mode which prevents you from getting a duplicate of your own aircraft during shared cockpit operations. Why would you want to block ALL aircraft? You shouldn't get duplicates of other aircraft unless you are on VATSIM *AND* you are connecting via FSX multiplayer. (Don't do that.)

 

Also FSinn had a traffic radar, any chance of something similar?

 

Feel free to post that suggestion in another thread. I'd like to keep this thread on topic.

 

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.

 

I never used FSInn, so I'm not sure how that worked. If you wanted to change the model shown for a given aircraft, how did you do that exactly? Did you enter the actual name of the model, or did you just give it a new type code? (I [Mod - Happy Thoughts]ume the latter.)

 

I have definitely considered having a way to override the type code for an aircraft since pilots often get that wrong when they connect, or they're using an old client that might broadcast the type code as ZZZZ, etc.

[Pavel Brodsky]

Ross,

those are great ideas. But when you will be able to use voice on one of two computers at one time, would it be difficult for you to enable fully independent voice for both clients? There is a LOT of people who build/have built home cockpits for two crewmembers and it would be just awesome if we could have two fully independent set of radios - so that each pilot can tune whichever frequency he wants and transmit on whichever frequency he wants - so that for example both pilots can transmit simultaneously, one with ACC controller while the other one is arranging oceanic clearence, etc. (or VFR flying in controlled airspace where one pilot is talking with Tower, while the other one is informing local untowered VFR airport nearby about their position). I know those are not very often used scenarios, but they are certainly possible in real world, and sometimes they are used.

 

Best regards,

Pavel

[Jason Adriaan 1274456]

I never used FSInn, so I'm not sure how that worked. If you wanted to change the model shown for a given aircraft, how did you do that exactly? Did you enter the actual name of the model, or did you just give it a new type code? (I [Mod - Happy Thoughts]ume the latter.)

 

I have definitely considered having a way to override the type code for an aircraft since pilots often get that wrong when they connect, or they're using an old client that might broadcast the type code as ZZZZ, etc.

 

Basically, you could see a list of all the traffic by Callsign, and for each aircraft , you could get a drop down menu of all the traffic/liveries you have, and pick one for that aircraft.

[Peter Allnutt]

Another vote to consider a local override to display a model of choice. Not only is this useful when someone has entered the wrong ICAO code, or reports ZZZZ, it is also useful in the world of GA when several people all turn up in the same model. You can then change them in to the colour scheme they are flying (if you know it). There are usually no airline codes to aid the matching for GA aircraft to help with livery selection.

 

This really needs to be thought about for the automatic model matching rules too. VMRGenerator doesn't process aircraft.cfg files if the atc_parking_codes/CallSignPrefix field is blank. This is often the case for GA aircraft (both full blown flyable models and for some AI ones) and thus no rule is made.

 

You state we'll still be able to have a local rules file, are you planning on changing the format of these? Will we just be able to continue to use any we have without alteration?

 

TIA

[Ross Carlson]

Ross,

those are great ideas. But when you will be able to use voice on one of two computers at one time, would it be difficult for you to enable fully independent voice for both clients?

 

It's not two separate clients, it's one client, with a "remote control" view on the remote computer.

 

To do this right would actually be quite complicated. There would need to be some way for vPilot to know which radio (COM1 or COM2) each pilot was using. There's no way to do that via SimConnect (since FSX/P3D were not designed for multi-crew ops) so there would have to be some proprietary vPilot API that would link to switches in the cockpit hardware. We could get around this by having the pilot ALWAYS on COM1, and the co-pilot ALWAYS on COM2, but that's a hack.

 

Then there would have to be a way of configuring a separate audio device and a separate PTT for each pilot.

 

Totally doable, but a lot of work, for a very small subset of the user base, so I don't see it happening.

[Ross Carlson]

Basically, you could see a list of all the traffic by Callsign, and for each aircraft , you could get a drop down menu of all the traffic/liveries you have, and pick one for that aircraft.

 

Uhm ... so for me that dropdown would have several thousand entries. No way I'd ever scroll through that looking for a specific model. Am I missing something?

 

Some sort of model search box would make much more sense, I think.

[Ross Carlson]

Another vote to consider a local override to display a model of choice. Not only is this useful when someone has entered the wrong ICAO code, or reports ZZZZ, it is also useful in the world of GA when several people all turn up in the same model. You can then change them in to the colour scheme they are flying (if you know it). There are usually no airline codes to aid the matching for GA aircraft to help with livery selection.

 

One thing I've been considering is to have vPilot not choose the same model as one that is already in use, unless there are no other suitable matches. So if you have 5 different C172 paint schemes, and two of them are in use already, it'll pick one of the other three at random. Same for airliners with multiple schemes like JetBlue, Southwest, etc. That will help with the issue you mentioned. Note that I'm not saying I won't provide a way to choose a specific model ... just mentioning a way to help prevent several aircraft appearing in the same paint job.

 

This really needs to be thought about for the automatic model matching rules too. VMRGenerator doesn't process aircraft.cfg files if the atc_parking_codes/CallSignPrefix field is blank. This is often the case for GA aircraft (both full blown flyable models and for some AI ones) and thus no rule is made.

 

vPilot's automatic model matching will work differently. It will use a database of known model info in order to determine what the callsign prefix and aircraft type code are for each model it finds on your machine. If it finds a model that isn't in the model database, then it'll use the atc_parking_codes line to see if it contains a known airline code. So it will make use of any GA models you have as long as they're in the model database. As I mentioned in the original post, when it scans your installed models, it will send information about any models that aren't in the database to the vPilot web server, so that I can manually look at the data and add entries to the database. The updated database will be downloaded to your machine the next time you launch vPilot, and that model will be available for matching from then on.

 

You state we'll still be able to have a local rules file, are you planning on changing the format of these? Will we just be able to continue to use any we have without alteration?

 

So far I haven't come across any need to change the format, and I'd certainly like to keep it the same if possible since I know lots of users and VAs have created custom files already.

[Peter Allnutt]

Some sort of model search box would make much more sense, I think.

From memory FSInn went Manufacturer->Model->Paint Schemes. There wasn't one huge list.

 

Thanks for the other feedback too Looks like good progress to me.

[Alex Ridge]

Can we have proper sets where

 

B73H = Boeing 737-800 with winglets

B738 = without

B752 = Boeing 757-200 without winglets

B75W= with winglets?

 

Is this possible? I imagine some more fundamental code will need updating??

[Ross Carlson]

Can we have proper sets where

 

B73H = Boeing 737-800 with winglets

B738 = without

B752 = Boeing 757-200 without winglets

B75W= with winglets?

 

Is this possible? I imagine some more fundamental code will need updating??

 

That's just a matter of making sure the model database has the right type code for each model.

 

However, I think you might be asking a bit much of the users if you expect them to use B73H for their 738 with winglets.