By Ross Carlson 887155
#495546
Nick Botica 999991 wrote:Just had an idea, can you use simconnect to grab the aircraft code if it's in the aircraft.cfg and use it if it's valid?


Yeah, there is a SimConnect variable that stores the type code from the aircraft.cfg file for the user's aircraft. I know I looked at that when I first wrote vPilot, but I don't recall why I decided against using it. I'll take another look at it.

I would still need to allow the user to override it, though, since pilots need to be able to file a slightly different code than what might be found there. (B738 instead of B737, etc.)
By Ross Carlson 887155
#495817 Slight change of plans. Originally I said this:

Ross Carlson 887155 wrote: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.


I've since changed the way it will work when running vPilot on a remote machine. Now, on the host machine (the machine running FSX/P3D) you will launch vPilot in "host mode". This mode will show a very simple window with a button to open your settings window, and some status indicators showing whether or not voice is running on the host, and whether or not a remote has connected yet.

As before, when you launch vPilot on the remote machine, you'll see the same window that you see now.
By Ross Carlson 887155
#495856 Re-reading this thread, I realize that I missed this question when you first posted it:

Charan Kumar 1078107 wrote: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?


I'm going to use the existing rule sets as the starting point for the database. When users run the new version, it will scan their installed models and send the list to the vPilot web server, so that I can periodically review the models that were found in the scan but didn't exist in the model database at that time, and add them to the database. (You'll be able to opt out of this if for some reason you don't want your list of models sent to the vPilot web server.)
By Reinhard Brantner 879395
#496115 Hi,

First of all: Great news. Thanks for driving vPilot into the next direction.

I would suggest a feature, which can be a result out of your collected database. It would be fine to collect all the models, which couldn't be matched during the session, in a special log file on my client, when I haven't currently installed the right models. So whenever a similar model or the default aircraft was used, this should generate a log entry. At the end of my session I want to be able to upload this file to a website, where this missing aircrafts are matched against your database. And as a result I get back as a proposal, which AI models you know, that would cover this missing aircraft on my machine. By that I can complete my AI traffic based on the missing models list.

Another fine feature for the client V2 would be, if I were able to undock the several sub elements of the client window. This means, that if I would be able to move and resize ATC, chat and input windows according to my screen layout, this would give great flexibility. And by defining these positions and size information in the config file, would allow to start with different setups.

Best regards
Reinhard
By Ross Carlson 887155
#496122
Reinhard Brantner 879395 wrote:At the end of my session I want to be able to upload this file to a website, where this missing aircrafts are matched against your database. And as a result I get back as a proposal, which AI models you know, that would cover this missing aircraft on my machine.


Interesting idea, and it wouldn't require uploading the file anywhere, since vPilot will already have a local copy of the model matching database.

However, that database does not include information about where to get each model, or the package that it comes from, so that would have to be added. In many cases that won't be possible. When vPilot scans your installed models, it will post a list of the unknown models to the vPilot server so that I can periodically review that list and add new models to the database. For those, I won't always know where you got the model. So, the database would only be able to contain download URLs for the popular packages like WoAI, MyTraffic, etc. It might still be useful to show a list of unmatched aircraft and whether or not there is a match in one or more of those popular packages, but I don't know if it would be worth doing since the database would be somewhat incomplete. I'll think about it, though.

Reinhard Brantner 879395 wrote:Another fine feature for the client V2 would be...


Please post any feature requests not related to the model matching and networking changes in a separate thread. I'd like to keep this thread on topic.
By Richard McDonald Woods 843615
#496277 Hi Ross,
I very much like your detailed proposals. However, just one comment...

The whole model matching processes were quite complex to understand, and I struggled to get things working. Since then, I have largely ignored model matching and have put up with the inevitable red Simconnect Error: messages produced.

So my comment is around ensuring that the deliverable is as simple and elegant as is possible so that the maximum number of users feel that it is easy-peasy to install and use. Please ensure that each user intervention required is really necessary so that the absolute maximum number of users use vPilot v2.

Thanks for your efforts,
By Reinhard Brantner 879395
#496398
Ross Carlson 887155 wrote:However, that database does not include information about where to get each model, or the package that it comes from, so that would have to be added. In many cases that won't be possible. When vPilot scans your installed models, it will post a list of the unknown models to the vPilot server so that I can periodically review that list and add new models to the database. For those, I won't always know where you got the model. So, the database would only be able to contain download URLs for the popular packages like WoAI, MyTraffic, etc. It might still be useful to show a list of unmatched aircraft and whether or not there is a match in one or more of those popular packages, but I don't know if it would be worth doing since the database would be somewhat incomplete. I'll think about it, though.

Hi,

As you provide rulesets for the popular AI packages already, my idea was just to scan those rulesets for a matching aircraft and providing a hint, that in the AI package of XXX is a suitable aircraft available. So no need for a specific download link.

Rgds
Reinhard
By Matthew Cook 1315950
#496802 Hey

Another thing for the server would be the use of 2 letter call signs as well as 3 letter call signs eg QFA and QF, UAL and UA, BAW and BA. A common problem i have is when pilots connect with these call signs, and Vpilot cant find a model because of that so you either get a A321 or a error.
By Ross Carlson 887155
#496810
Drew Romanovych 1255089 wrote:Hey Ross, Loving vpilot and being on Vatsim finally! any word on when 2.0 is coming out?


No idea really, it'll be a while still.
By Ryan Parry 965346
#496877 Could you explain how the scanning and model matching works a little better in regards to a custom rule set having precedent over the scanned one? Are you saying it will create one no matter what, but try to pull matching from the custom set first and then the scanned set? If so, could you include an option to turn that off completely, please? I don't want vPilot scanning my system, that's one of the things I hated about FSINN. I really enjoy the current method of model matching and I have spent a tremendous amount of time incorporating an insane amount of detail into my ruleset, I really don't want any interference with that. I see where this could be beneficial to some though, so I think an option to disable it would be smart.
By Ross Carlson 887155
#496881
Ryan Parry 965346 wrote:Could you explain how the scanning and model matching works a little better in regards to a custom rule set having precedent over the scanned one? Are you saying it will create one no matter what, but try to pull matching from the custom set first and then the scanned set?


That's right, if you have custom rule sets loaded, vPilot will look for a match in your custom rules first, before looking at the rules that it generated as a result of scanning your installed models.

Ryan Parry 965346 wrote:If so, could you include an option to turn that off completely, please? I don't want vPilot scanning my system, that's one of the things I hated about FSINN.


Why did you hate that feature? I can't say for sure since I never used FSInn, but I suspect you'll find that vPilot's scanning of your models is very unobtrusive and infrequent. The scan only happens in one of three circumstances:

1) You run vPilot 2.0 for the first time.
2) vPilot detects new folders in your SimObjects paths. (Meaning new models have been installed.)
3) You trigger it manually, such as if you want to use a different simulator on the same machine.

Ryan Parry 965346 wrote:I really enjoy the current method of model matching and I have spent a tremendous amount of time incorporating an insane amount of detail into my ruleset, I really don't want any interference with that.


Since the custom rules will take precedence, nothing will change for you. All the time you've invested creating custom rules will continue to pay off with version 2.

Ryan Parry 965346 wrote:I see where this could be beneficial to some though, so I think an option to disable it would be smart.


It's too early to tell, of course, but I suspect you are in a minority in this regard. Most users just want model matching to be automatic. That's why I'm making this change to begin with. I must resist the temptation to add features that are only helpful for a small number of users ... that path leads to bloatware and/or confusing user interfaces.

That being said, disabling the automatic rule generation would be pretty simple, code-wise, and very low-impact, UI-wise (just a checkbox in the settings) so it wouldn't be a big deal. However, you're basing your request for disabling the scanning on your negative experience with FSInn, so my inclination would be to determine whether or not you would have the same dislike for this feature in vPilot as you did for FSInn. So if you could elaborate on what you hated about FSInn, that would be very helpful.
By Ryan Parry 965346
#496884 Thanks Ross!

My issue with FSINN was every time I started it up I had to sit and wait, and wait, and wait, and wait, while it scanned everything. This issue was sort of solved by buying an SSD, however anybody still using a HDD is going to sit and wait a while. If I installed a new aircraft I had to put a file in the aircrafts folder telling FSINN to ignore that aircraft, otherwise it would try to use it as an AI model. Trust me, having an NGX AI model on final to KLAX is a bad idea :lol: In addition, there was some program you had to run that made a bunch of changes to the registry in order for it to work properly.

I guess it does all boil down to how your version of this works in comparison. If the scan is quick, unobtrusive, and doesn't try to stick a payware aircraft as an AI model, it might not even be a big deal.
By Ross Carlson 887155
#496887 Yeah, it'll be much different with vPilot. As I mentioned above, it'll only do the scan when something changes, like after you install a new aircraft or a new AI traffic package.

How long would you say it took for FSInn to run the scan, after you switched to an SSD?

On my current test system, which is a mid-line i7 on an SSD, it takes about 5 seconds to scan all my models, and I have about 7,000 models installed. (A few thousand WoAI, and a few thousand from MyTraffic6, plus the P3D default models.)

Regarding using complex add-on aircraft for model matching, that shouldn't be a problem because vPilot will only use a model if it either a) knows about the model from the model matching database (and complex models won't be in that database) or b) it can determine the type code and airline code by reading the "atc_model" and "atc_parking_codes" fields from the aircraft.cfg file, and match the values against a list of known type codes and airline codes. When I look at the PMDG models, they do not include an entry in their aircraft.cfg files for atc_parking_codes, so vPilot won't be able to use them anyway.

I think I'll still need to have a way for users to exclude certain models from being used for matching, to ensure that you can prevent a complex add-on from being used in case the add-on author does include valid atc_model and atc_parking_codes values. I'm thinking vPilot could show you a list of all the folders it found, and you can uncheck the ones you know you don't want to be used for matching. This will only need to be done once, of course, and updated if you add new models.
By Ryan Parry 965346
#496888 Well, it would depend. If I installed a single livery, it would pick up the change in maybe 15 or so seconds max, but if I installed new aircraft with new liveries it would take significantly longer. Really, it would scan pretty quickly, it was when it identified a change that it slowed down and became a problem for me. I think that had to do with the fact that it was changing around the entries it made in the registry. Even though I had the file telling FSINN to ignore an aircraft, that only prevented it from being used, not being scanned and added to the registry.