I have pushed the “aircrafts and airports use counts” feature to
FFGo's Git repo. I am going to make the four periods configurable from the Settings dialog (see below) and change the default sort order for the airport and aircraft lists, but apart from these minor things, the feature should be complete as it is.
For native English speakers: I have a hard time finding a correct formulation for this kind of thing (these ones being tooltip texts):
Number of days for which the aircraft has been used at least once during the “aircraft stats show period” (cf. Preferences dialog)
Number of days for which the airport has been visited at least once during the “airport stats show period” (cf. Preferences dialog)
(ah, maybe “in which” would be better than “for which”, for a start---but that's what is in the Git repo for now) I have also considered:
The aircraft has been used at least once a day for that many days during the “aircraft stats show period” (cf. Preferences dialog)
(and similar formulation for airports) but I am not sure it is really better. Do you have better suggestions?
Because there are interesting use cases that require
different periods over which to compute the number of days an aircraft (resp. airport) has been used (resp. visited), I made all four periods configurable (excerpt from my ~/.ffgo/config file):
- Code: Select all
AIRCRAFT_STATS_EXPIRY_PERIOD=3652
AIRCRAFT_STATS_SHOW_PERIOD=365
AIRPORT_STATS_EXPIRY_PERIOD=3652
AIRPORT_STATS_SHOW_PERIOD=365
(these are the default values for these parameters)
As you can guess, this means that FFGo will keep the dates where you used each aircraft (resp. visited each airport) for 10 years (3652 days), and compute the “use/visit count” for each aircraft/airport over the last year only (365 days). For now, these values can only be changed via the config file, but they should be soon accessible from the Preferences dialog.
It was necessary to at least make the {AIRCRAFT,AIRPORT}_STATS_SHOW_PERIOD values configurable, because in order to easily see the aircrafts you currently use most, you would need a short period for counting (say, 3 months to 1 year), whereas if you want to easily see the aircrafts you have
never used, or the airports you have never visited, a longer period is necessary (a period of 36525 days, which is approx. 100 years, should be enough for such a use case). As these two periods were being made user-configurable, I decided to make the expiry periods user-configurable too.
As promised, the aircraft and airport “use counts” are displayed in new columns of the aircraft and airport lists, respectively. Clicking on the appropriate column header is enough to sort a list according to these values. Clicking a second time on the same column header reverses the sort order.
For the curious, the data is stored in $USER_DATA_DIR/Stats/airports.json.gz and $USER_DATA_DIR/Stats/aircrafts.json.gz, where $USER_DATA_DIR is of course ~/.ffgo everywhere except on Windows, where it is %APPDATA%/FFGo (i.e., it is the folder where FFGo's main config file is located). If you delete these files, they will be automatically recreated.
If you start FFGo with an aircraft or airport list that doesn't contain an entry for each element of the corresponding .json.gz file, the elements that can't be used by FFGo will be kept in memory and saved back to the .json.gz file when FFGo is quit or its config reloaded. So, there shouldn't be any risk of losing aircraft or airport “use/visit dates” just by removing/changing aircraft paths, or using an apt.dat.gz file that doesn't have all airports you previously had. Of course, if aircraft (name, path) pairs, or airport ICAO codes don't match, the resulting use counts won't be visible in FFGo's interface, but they will remain in the .json.gz files. Therefore, in case of a permanent change in, e.g., an aircraft path and/or name, for which you want to keep your use dates, you can do the renaming yourself in the $USER_DATA_DIR/Stats/aircrafts.json.gz file.
Which leads me to how the data is actually stored (sample airports.json.gz file):
- Code: Select all
{"format version":1,"airports":{"LFLS":[735998,736003],"EDDH":[735999,736001,736003,736004],"LFPO":[736003,736004,736005],"EDDF":[736004],"LOWI":[736003,736005],"EDDS":[736004],"EDDG":[736004],"LFOH":[736004],"LFML":[736005],"LSZS":[736003]}}
Hardly readable, eh? But this should be very fast to read for the computer. Fortunately, for you poor human being, it is possible to call FFGo with the --save-stats-in-pretty-form option; then, either quit FFGo or reload its config file (aka “reset” in FGo!-speak), and $USER_DATA_DIR/Stats/airports.json.gz will be written this way instead:
- Code: Select all
{
"airports": {
"EDDF": [
736004
],
"EDDG": [
736004
],
"EDDH": [
735999,
736001,
736003,
736004
],
"EDDS": [
736004
],
"LFLS": [
735998,
736003
],
"LFML": [
736005
],
"LFOH": [
736004
],
"LFPO": [
736003,
736004,
736005
],
"LOWI": [
736003,
736005
],
"LSZS": [
736003
]
},
"format version": 1
}
Looks better, doesn't it? But what are those funny numbers? Well, they are called
proleptic Gregorian ordinals and should be the fastest format IMHO to compute the use counts from the saved dates, for the chosen period (for instance, at FFGo startup). It is pretty simple, actually: January 1 of year 1 corresponds to the integer 1, January 2 of year 1 to the integer 2, and so on. If you run:
- Code: Select all
import datetime
print(datetime.date.today().toordinal())
in Python 3, you will find that today is number 736005. So, yesterday was 736004. You got it.
$USER_DATA_DIR/Stats/aircrafts.json.gz is in almost the same format. Here is an example obtained with the --save-stats-in-pretty-form option:
- Code: Select all
{
"aircrafts": {
"707\u0000/mm/flightgear-data/fgaddon/Aircraft/707": [
736004,
736005
],
"777-200ER\u0000/mm/flightgear-data/fgaddon/Aircraft/777": [
736003
],
"Citation-II\u0000/mm/flightgear-data/fgaddon/Aircraft/Citation": [
736004,
736005
],
"SenecaII\u0000/mm/flightgear-data/aircrafts-misc/SenecaII": [
736004
],
"ZLT-NT\u0000/mm/flightgear-data/fgaddon/Aircraft/ZLT-NT": [
736004
]
},
"format version": 1
}
As you can see, the general idea is the same, but in order to save the (aircraft name, aircraft directory) pairs as simple strings(*), I decided to separate the aircraft name and directory with the NUL character (\u0000) for maximum robustness. Thus, even aircraft names could contain spaces (or newlines or whatever) if FlightGear supported that...
Because of the expiry period, there is no risk of the lists getting bigger and bigger, eventually slowing down the FFGo startup. “Use dates” older than AIRCRAFT_STATS_EXPIRY_PERIOD days in the case of aircrafts (AIRPORT_STATS_EXPIRY_PERIOD in the case of airports) are automatically removed whenever FFGo is quit or its configuration reloaded. So, if you're an addict flyer and FFGo's startup seems to have gotten slower because of a huge number of entries (though I doubt it could be noticeable for any realistic use), just reduce the expiry periods, start and quit FFGo, and everything should be fine on the next startup.
The use counts are computed (from the dates) when FFGo is started, when its config is reloaded and when FlightGear is started from FFGo at the given airport, or with the given aircraft.
(*) This is the only type of key the
JSON format supports in its “objects”---similiar to Python dictionaries.