Bugs in 1.2.1

Is Virtual Radar Server not behaving itself? If so then please report it here.
Locked
agw
Posts: 2241
Joined: Fri Feb 17, 2012 3:20 am

Bugs in 1.2.1

Post by agw » Mon Mar 04, 2013 2:14 am

They're bound to be there - let me know when you find them :)

Jondan
Posts: 4
Joined: Sun Mar 10, 2013 8:55 pm

Re: Bugs in 1.2.1

Post by Jondan » Sun Mar 10, 2013 9:08 pm

I've just updated my program to this version from I think 1.1.2 and I can't get the database writer plug in
to work. it says Database 'Disabled'.
How do I enable it again ? It worked fine before the the upgrade.
Thanks

agw
Posts: 2241
Joined: Fri Feb 17, 2012 3:20 am

Re: Bugs in 1.2.1

Post by agw » Sun Mar 10, 2013 9:30 pm

If it's saying that the plugin is disabled because it could not be loaded then it could be because it's an old version. The 1.2.0 version of the plugin needs to be installed.

However, if the plugin is loading and in the Tools | Plugins screen its saying that its status is disabled then just click the Options button next to the plugin and tick the Enabled box. I can't think why it would have reverted to disabled though, unless the configuration folder's content was erased or renamed.

Jondan
Posts: 4
Joined: Sun Mar 10, 2013 8:55 pm

Re: Bugs in 1.2.1

Post by Jondan » Sun Mar 10, 2013 10:24 pm

Thanks for your prompt reply.

Changed option button to 'Enabled' only from 'Only update dbases .......' button and/or both checked.
Now appears to be working normally - upgrade obviously changed my previous settings !
Thanks

SWR
Posts: 14
Joined: Mon Mar 25, 2013 5:34 pm

Re: Bugs in 1.2.1

Post by SWR » Mon Mar 25, 2013 5:39 pm

I don't know if this is a bug.

11. The aircraft list will now use operator flags named after the aircraft's ICAO when the aircraft has no operator.

At Airbus plant flights (they use callsigns like AIB...) the Airbus operator flag isn't shown in the aircraft list.
You mean that the ICAO Code of the callsign is use to show the operator flag, if the aircraft has no operator?

agw
Posts: 2241
Joined: Fri Feb 17, 2012 3:20 am

Re: Bugs in 1.2.1

Post by agw » Mon Mar 25, 2013 6:11 pm

SWR wrote:At Airbus plant flights (they use callsigns like AIB...) the Airbus operator flag isn't shown in the aircraft list.
You mean that the ICAO Code of the callsign is use to show the operator flag, if the aircraft has no operator?
Normally the operator flag image is the BMP file that matches the OperatorFlagCode for the Aircraft record in the database. So if the aircraft record has "AIB" in the OperatorFlagCode field then it'll display the AIB.BMP image from the operator flags folder against that aircraft.

If for some reason you either don't have an aircraft record or there's nothing in the OperatorFlagCode (usually because the aircraft belongs to an operator that doesn't have an ICAO code) then it will now also display any image that matches the ICAO of the aircraft in the operator flags folder. So if the aircraft's ICAO is 4C1234 and there's an operator flag image named 4C1234.BMP in the folder then it'll get displayed.

The intention was to be able to show operator flags for small business jet fleets or private aircraft, things like that. In this case I imagine that there probably isn't a database record for the aircraft at all as the aircraft is still being built. If this is true then it might be better to add the record manually and give it an OperatorFlagCode of AIB. If you're using a program to populate your database (e.g. SBSPopulate) then I think some of those have a mechanism to add records by hand, and also to refresh the record with details from GAS once the plane has been delivered and they've got a record of it.

Using the ICAO from the callsign isn't a bad idea but it would be misleading when you have flights where an operator is flying with another airline's callsign. VRS doesn't use the callsign to determine which operator flag to show.

jfm
Posts: 82
Joined: Thu May 10, 2012 4:09 pm

Not Finding Routes

Post by jfm » Wed Mar 27, 2013 8:40 pm

I am currently watching callsign "ACA016" with "Route: Unknown" on my VRS. I went to the website to add "ACA016" and see that it does not exist (as expected). But I also checked "ACA16", which does exist. Is the expectation that routes should be double-entered in cases like this, or should there be some logic added to VRS and/or the route submission website? And what about "AC16"?

agw
Posts: 2241
Joined: Fri Feb 17, 2012 3:20 am

Re: Bugs in 1.2.1

Post by agw » Thu Mar 28, 2013 9:39 pm

Yes, it's a tricky one. I don't want the routes getting spammed up with miscodings or every variation of a flight number. I would say enter it as per the flight schedules - in this case ACA16 - and I'll add code to VRS to try to work around simple cases like this. In cases where they entered the IATA code instead of the ICAO code, one or two airlines do this routinely but most use their ICAO, so for most airlines you should just enter the ICAO. I think VRS can be made to deal with those kinds of miscodings too.

agw
Posts: 2241
Joined: Fri Feb 17, 2012 3:20 am

Re: Bugs in 1.2.1

Post by agw » Fri Mar 29, 2013 2:45 pm

On the subject of flight routes, I've been having a look at the database and at callsigns in ADSBHub and it is a bit of a mess when it comes to leading zeros on flight numbers. It looks as though it is common practice for leading zeros to be added with some airlines but it is not consistently applied - some pilots enter leading zeros, some don't and the number of leading zeros usually pads the flight number to 3 digits but not always. In the database some routes are in there more than once with varying numbers of leading zeros.

To address this I have changed VRS to search on the callsign as transmitted by the aircraft, if that fails then it splits the callsign into code and flight number, trims leading zeros from the flight number and tries again. If the callsign has no code portion (e.g. WJA flights) then it will prepend the operator ICAO from the database to the callsign for both steps. I have unit tests on all of those bits, I'm fairly happy that it's working as planned.

The routes submission site will be changed to remove leading zeros from the flight number portion of a callsign as it is entered, so on entering a callsign of "QTR001" the site will change it to "QTR1". It will understand the difference between ICAO and IATA codes in callsigns, so AB1023 won't get changed to AB123, but AB0123 will.

Finally I have written a script to clean up existing codes in the master routes database so that routes with leading zeros are renamed to have the leading zeros taken out of them. Where there is a clash with an existing route with no leading zeros the script archives and discards one of the routes, preferring user-submitted routes over routes taken from ACARS logs. Where both routes are user-submitted the script prefers the newest route.

The script also detects some garbage routes that have come from ACARS logs (e.g. "BAWBAW", "BASHT3" etc.) and discards them.

Once I'm happy that everything looks OK I'll be applying the script's changes to the master database and simultaneously releasing 1.2.2 of VRS to deal correctly with leading zero flight numbers. The change to the routes submission site will go live some time before then - for the time-being it doesn't matter if you enter routes with leading zeros as the script will eventually rename them for you. The route files are now built at 00:30 GMT/BST so the release will probably happen shortly after then, so that on downloading 1.2.2 the route files will not contain routes with leading zeros.

jfm
Posts: 82
Joined: Thu May 10, 2012 4:09 pm

Re: Bugs in 1.2.1

Post by jfm » Fri Mar 29, 2013 7:44 pm

agw wrote:On the subject of flight routes...
Thanks agw! Sounds like a great solution.

Locked