Board index FlightGear Development

Announcing FFGo: a new FlightGear launcher

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Thu Sep 10, 2015 10:36 am

Thanks. You can obtain the full list without stopping on errors (and silently ignoring empty pseudo-xml files, otherwise remove the two lines with the os.path.getsize() test) with this:
Code: Select all
diff --git a/ffgo/gui/mainwindow.py b/ffgo/gui/mainwindow.py
index 26e99a1..9c399b3 100644
--- a/ffgo/gui/mainwindow.py
+++ b/ffgo/gui/mainwindow.py
@@ -148,6 +148,8 @@ class App:
         self.toolsmenu = Menu(self.menubar, tearoff=0)
         self.toolsmenu.add_command(label='METAR',
                                    command=self.showMETARWindow)
+        self.toolsmenu.add_command(label=_('Test'),
+                                   accelerator=_('Ctrl-T'), command=self.test)
         self.menubar.add_cascade(label=_('Tools'), menu=self.toolsmenu)
 
         self.helpmenu = Menu(self.menubar, tearoff=0)
@@ -368,6 +370,20 @@ class App:
         self.setupKeyboardShortcuts()
         self.startLoops()
 
+    def test(self, event=None):
+        import traceback
+
+        for airport in self.config.airport_icao:
+            logger.debug("Looking at airport {}, found parkings:".format(
+                airport))
+            try:
+                parkings = self.read_airport_data(airport, "park")
+            except Exception:
+                logger.debug(traceback.format_exc())
+            else:
+                if parkings:
+                    logger.debug(*parkings, sep='\n')
+
     def onControlF_KeyPress(self, event):
         self.runFG(event)
         return "break"
@@ -377,6 +393,7 @@ class App:
         return "break"
 
     def setupKeyboardShortcuts(self):
+        self.master.bind('<Control-KeyPress-t>', self.test)
         self.master.bind('<Control-KeyPress-f>', self.onControlF_KeyPress)
         self.master.bind('<Control-KeyPress-r>', self.onControlR_KeyPress)
         self.master.bind_all('<Control-KeyPress-q>', self.saveAndQuit)
@@ -778,6 +795,9 @@ class App:
         """Read parking positions from XML file."""
         logger.info("Reading parking positions from '{}'".format(xml_file))
         res = []
+        if not os.path.getsize(xml_file):
+            return []
+
         with open(xml_file) as xml:
             root = self._get_root(xml)
             parking_list = root.find('parkingList')

which reveals only two errors besides empty files + the '&' errors I already mentioned:

  • Airports/K/P/C/KPCW.groundnet.xml: there is a ^P control char before Parking_2 on line 4;
  • Airports/T/J/S/TJSJ.groundnet.xml: unescaped '&' on line 15
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Thu Sep 10, 2015 11:51 pm

Hello,

Commit 8efe33b319e741d9e6de020a98e90683a6f547c3 in the Git repo improves parsing of parking and scenario XML files (cf. the Git log for details). To make sure there was no regression, I have compared the results before and after with all airports and all parking positions from the Airports.tgz file you linked to, and from my TerraSync dir + custom scenery folders. This revealed that Airports/K/A/C/KACV.groundnet.xml from your Airports.tgz file contains Parking elements with an empty 'name' attribute and no 'number' attribute:
Code: Select all
        <Parking index="0" type="gate" name="" lat="N40 58.32507" lon="W124 6.40665" heading="326.87" />
        <Parking index="1" type="gate" name="" lat="N40 58.59554" lon="W124 6.76349" heading="0" />

Maybe these need fixing? At least, FFGo won't produce empty entries for them anymore.

I also added the skeleton for doing tests (menu item and Ctrl-T keyboard shortcut), only activated when passing --test-mode (-t) to FFGo (the -t may be changed in the future if needed for something else...).

The patch adding the actual test code on top of the above commit is:
Code: Select all
diff --git a/ffgo/gui/mainwindow.py b/ffgo/gui/mainwindow.py
index ddccb01..180ef2a 100644
--- a/ffgo/gui/mainwindow.py
+++ b/ffgo/gui/mainwindow.py
@@ -374,7 +374,17 @@ class App:
         self.startLoops()
 
     def testStuff(self, event=None):
-        pass
+        for airport in self.config.airport_icao:
+            logger.debug("Looking at airport {}, found parkings:".format(
+                airport))
+            parkings = self.read_airport_data(airport, "park")
+            if parkings:
+                logger.debug(*parkings, sep='\n')
+
+
+        from pprint import pformat
+        logger.debug(pformat(self.config._readScenarios()))
+
 
     def onControlF_KeyPress(self, event):
         self.runFG(event)


I didn't include the:
Code: Select all
--- a/ffgo/gui/mainwindow.py
+++ b/ffgo/gui/mainwindow.py
@@ -788,6 +798,9 @@ class App:
     def read_parking(self, xmlFilePath):
         """Read parking positions from XML file."""
         logger.info("Reading parking positions from '{}'".format(xmlFilePath))
+        if not os.path.getsize(xmlFilePath):
+            return []
+
         s = set()
         root = self._get_root(xmlFilePath)

part, because these empty files are erroneous and should really be either completed or removed IMHO.
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby wkitty42 » Fri Sep 11, 2015 9:29 pm

parking was discussed in the developer's list in the last month or so... IIRC, there is a wiki page that contains the information as to what craft are allowed to park where... this is one of the reasons why craft's xml file has a property telling what kind of craft it is...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Sat Sep 12, 2015 9:57 pm

Hello,

I have released FFGo 1.2.1 (shortly after FFGo 1.2.0, which had an annoying bug when Pillow wasn't installed). It contains the improvements mentioned in the previous messages, plus log rotation at startup, a bunch of log messages added before opening the various files, and a few more things that are best explained in the ChangeLog or in the log of the Git repository.

I wanted this release to come out quickly because the logging stuff and handling of exceptions raised from a Tkinter callback should make the user experience less painful when something doesn't work exactly as it should. The new logging code should also be useful when trying different configurations/fgfs options.

Happy flying!
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Sat Sep 12, 2015 10:05 pm

@wkitty42:

Yes, I followed that discussion about parking metadata indicating the type of aircraft that is supposed to park at a given parkpos. Maybe I'll use that in a later version, for instance sorting the parking positions by aircraft class in the parkpos popup... if I find a decent way to do that with Tkinter.

Thanks.
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby pommesschranke » Fri Sep 18, 2015 12:05 pm

feature suggestion:

I have 2 folders for aircrafts, and sometimes different versions of the same aircraft.
in FFGo I cannot see which is which.
pommesschranke
 
Posts: 1117
Joined: Sat Apr 27, 2013 8:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Kubuntu 22.04

Re: Announcing FFGo: a new FlightGear launcher

Postby wkitty42 » Fri Sep 18, 2015 7:57 pm

if you hover over the craft in the list, does it popup the path like it does in the new --launcher in fgfs?
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Fri Sep 18, 2015 9:53 pm

I know about the annoyance of having duplicate aircrafts in several directories and not knowing which one FG is going to load. I have already answered this here... No, there is no popup showing the directory the aircraft will be loaded from. The problem is that FG doesn't simply scan FG_AIRCRAFT from left to right in order to find the aircraft. As I have verified, it is possible to have two aircrafts both in FG_ROOT/Aircraft and in one of the components of the value of --fg-aircraft, and with the very same config, FG loading one of the aircrafts from FG_ROOT/Aircraft and the other one from the component of --fg-aircraft. I have written on flightgear-devel about this but nobody answered. The next step is to analyse FG's source code to understand how the aircraft directory is chosen. I'll get to it, please be patient.

I have done so for the processing of --parkpos and thus simplified/improved FFGo's algorithm for finding parking positions. This only affects the code path used when "Airport data source" is set to "Scenery", which is now the default in the Git version. The previous default was adapted to very old FG versions (up to 2.4 according to http://wiki.flightgear.org/About_Scenery/Airports) but contemporary FlightGear only looks in $FG_SCENERY/Airports/I/C/A/ICAO.groundnet.xml files to determine parking positions AFAICT. Besides, it stops at the first match found (scanning FG_SCENERY from left to right), even if it doesn't declare any parking position. I have modified the algorithm used in FFGo to mimic this behavior. The code also has access to all parking metadata (coordinates, radius, flight type, airlines codes...) in a dedicated class.

Currently, it is only used to sort the parking positions by flight type and name, as in:
Image
and
Image
(there are two other screenshots, for EDDF and EDDH in the same directory)

You may notice that the algorithm for sorting parking names in the same flight type category is improved, ensuring that A9 comes before A10, which itself comes before A10a, A10b, A11, etc. (the previous algorithm used simple string sort where "A10" < "A2" because "1" < "2"...).

Since TerraSync is enabled by default in FG, I have changed the default value of FG_SCENERY so that all this parking stuff works in the default configuration, after the first scenery download for a given airport.

Correction: TerraSync is not enabled by default in FG, I was bitten by the setting in autosave_3_7.xml. At least, it will work if the user enables TS... and shouldn't harm if the directory doesn't exist.

I now recommend users to set "Airport data source" to "Scenery" and will include an interactive question to propose this once if the option is set to the old default. Passing --prop:/sim/paths/use-custom-scenery-data=true to FlightGear as suggested earlier (inherited from FGo!) is harmless but also useless, probably since FG 2.6.

I am also contemplating changing the default setting for "Airport database update" to "Automatic", as it seems to work fine here and should be useful when users upgrade their FG installation. Have you tried it (Settings -> Preferences -> Miscellaneous)?

After that, I'll probably do a release and look more closely into this little aircraft path problem. :wink:

@pommesschranke: did you see the escaping problems I mentioned above concerning your generated groundnet files?
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby pommesschranke » Sun Sep 20, 2015 9:48 am

Hey!

that sorted display of parkings is really cool!
and very good timing, because my next release of Airports.tgz will contain not only "gate" but also "ga"and various values for radius.
Thank you very much for testing all the airports!
I will have a closer look into the 5 buggy airports that you found.

i just did a git pull for FFGo, and noticed this:

FileNotFoundError: [Errno 2] No such file or directory: '/SDB5/home/d-laser/download/FFGo/ffgo/data/pics/thumbnail-not-avail.png'
pommesschranke
 
Posts: 1117
Joined: Sat Apr 27, 2013 8:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Kubuntu 22.04

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Sun Sep 20, 2015 10:37 am

Glad to see you like it!

pommesschranke wrote in Sun Sep 20, 2015 9:48 am:FileNotFoundError: [Errno 2] No such file or directory: '/SDB5/home/d-laser/download/FFGo/ffgo/data/pics/thumbnail-not-avail.png'

This image is shipped in tarballs but not in the Git repository, where it would be redundant with the source in .xcf format. You have to follow the instructions from the section "Installation from the Git repository" of INSTALL_en. Basically, once you have installed a few things (currently GNU Make and gettext, rsvg-convert and imagemagick), you just have to run "make" from the top-level directory. Tell me if you have any problem doing this.

(otherwise, it is possible to copy the possibly-outdated files from a recent tarball to the expected place, but this is ugly and at some point you will have outdated translations or problems like that, since the .mo files should be generated from the up-to-date .po files, which is one of the things this "make" call does)

Once this is done, I suggest to run FFGo with the ffgo-launcher.py script from the top-level directory (it doesn't really make sense to install the software after each 'git pull' and 'make'; just run it in place).

I did the changes mentioned in my previous message (changed two default settings + interactive, optional migration for those who have the old defaults). Close to a release. :wink:
Last edited by rominet on Tue Sep 22, 2015 10:25 pm, edited 5 times in total.
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Sun Sep 20, 2015 11:02 am

BTW, here are the updated patches to test all the airports with Ctrl-T:
Code: Select all
diff --git a/ffgo/gui/mainwindow.py b/ffgo/gui/mainwindow.py
index 9670b68..f785465 100644
--- a/ffgo/gui/mainwindow.py
+++ b/ffgo/gui/mainwindow.py
@@ -471,7 +471,17 @@ want to follow this new default and set “Airport database update” to
         return res
 
     def testStuff(self, event=None):
-        pass
+        for airport in self.config.airport_icao:
+            logger.debug("Looking at airport {}, found parkings:".format(
+                airport))
+            parkings = self.readParkingData(airport)
+            for flightType in sorted(parkings.keys()):
+                logger.debug(flightType + ":")
+                logger.debug(*[ "  " + str(p) for p in parkings[flightType] ],
+                             sep='\n')
+
+        from pprint import pformat
+        logger.debug(pformat(self.config._readScenarios()))
 
     def onControlF_KeyPress(self, event):
         self.runFG(event)

EDIT: updated the patch to apply on top of commit 3dbbac13a60b397b117ef56bace8d76545a69287

plus, if you still need to ignore empty pseudo-XML files:
Code: Select all
diff --git a/ffgo/fgdata/parking.py b/ffgo/fgdata/parking.py
index 9d9ce99..abed482 100644
--- a/ffgo/fgdata/parking.py
+++ b/ffgo/fgdata/parking.py
@@ -114,6 +114,10 @@ def readGroundnetFile(xmlFilePath):
     logger.info("Reading parking positions from '{}'".format(xmlFilePath))
     res = {}
 
+    import os.path
+    if not os.path.getsize(xmlFilePath):
+        return res
+
     tree = ElementTree.parse(xmlFilePath)
     root = tree.getroot()
 


You can apply them with
Code: Select all
git apply /path/to/patchfile

from the top-level directory. Then simply run:
Code: Select all
git reset --hard

to return to the state of FFGo's HEAD commit (i.e., discard the patches).
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby Philosopher » Mon Sep 21, 2015 2:25 am

Regarding the aircraft loading: IIRC paths for aircraft are cached in the property tree in the autosave file in $FG_HOME (if you'll open it up you'll probably see what I mean: there's hundreds of paths there on mine). You probably need to clear that cache if $FG_AIRCRAFT changes (maybe this should be done automatically? I do not know - but if aircraft are installed after the cache entry for the craft is set, then the older entry will be used by default).
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Mon Sep 21, 2015 9:20 pm

Hi Philosopher, thank you for your input!

[ Before any real fix, users can pass FlightGear the following options:
Code: Select all
--log-class=general
--log-level=info
and look for something like:
Code: Select all
aircraft-dir = "..."
in the FlightGear Output Window.
]

I didn't dig enough into the FG aircraft loading code to be able to say it with certainty, but I think what you just described could well explain the results of my little experiments trying to determine the aircraft path search order.

From my point of view (maybe missing something, please correct me if I'm wrong), this aircraft "cache" feature appears to be buggy:
  • Users can reasonably expect to manage FG_AIRCRAFT as FG_SCENERY. They install a new/modified version of an aircraft they already have, making sure this new version comes first in FG_AIRCRAFT, restart FlightGear and... the old version is loaded and they don't know why. In short, it is counter-intuitive.
  • A cache is supposed to speed up access to a resource, or to avoid "excessive" access to said resource, in a transparent way. Unfortunately, this "cache" doesn't seem to be transparent.
  • Moreover, according to the link given by Hooray in this message from 2013, this "cache" was introduced in 2007 because scanning the aircraft dir(s) apparently caused a delay on the order of 20 seconds at FG startup for the (famous) developer who wrote the feature. But since starting FFGo, loading 34074 airports and 705 aircrafts (without any cache) on a computer bought around 2008 does not even take 1 second, either Python + Tkinter is extremely fast compared to C++, or the "cache" is not really justified. :wink: It was even written in the message from 2007 that "as Andy rightly points out, $ ls $FG_ROOT/Aircraft/*/*-set.xml is very fast, and there might just be some bad (and easy to fix) code"...
That is, as I see it now, the real cause for these complaints, because without the "cache", it is very easy to eliminate duplicates in FFGo's aircraft list when an aircraft is present in several directories scanned by FlightGear (I've had a patch ready for several months).

Otherwise, if the FG behavior in this respect is deemed satisfactory and users just have to live with it, I can probably try to parse the autosave file in order to predict the path the aircraft will be loaded from, and fall back to the current behavior if that fails (format change, etc.)... which would require to run "fgfs --version" and parse the result or ask the user to fill one more thing. Hmm.
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Tue Sep 22, 2015 8:25 pm

Hello,

I have released FFGo 1.3.0. The main changes in this version are the following:
  • Improve gathering and handling of parking data. All of the parking metadata is available internally through a Parking class. Errors in groundnet files generate warnings on the terminal and a popup window if particularly serious. Refactoring of this part of FFGo.
  • Better sorting of parking positions in the parking popup menu (by flight type first, then by name using a better algorithm than before, so that A9 comes before A10, which itself comes before A10a, A10b, A11, etc.). Here, “flight type” corresponds to the 'type' attribute value of Parking elements in groundnet files: ga, cargo, gate, mil-fighter, mil-cargo, vtol.
    cf. screenshots in this message.
  • Change the default for “Airport data source” to “Scenery”. This reflects FlightGear's current behavior when processing --parkpos and should provide much better parking data for people using TerraSync. The old default didn't make use of the TerraSync data, which was a pity.

    As indicated in ffgo/data/help/help_en, it is necessary to have downloaded data for the desired airport in one of the FG_SCENERY components before parking positions can be shown for this airport with the new default setting.

    Actually, “Airport data source” is a misnomer. What it really means is “Parking data source”. But since it corresponds to the APT_DATA_SOURCE parameter in the config file, and has been so for years (in FGo!), I'll leave it as is for now and just try to describe the effects as clearly as possible in the associated tooltip.
  • When “Airport data source” is set to “Scenery”, stop at the first groundnet file found in FG_SCENERY for the selected airport, even if it doesn't declare any parking position. This is what FlightGear (3.7) does, therefore doing otherwise and offer, in case of redundant FG_SCENERY components, parking positions that FlightGear won't find is not a good idea IMHO.
  • Change the default for “Airport database update” to “Automatic”. I think this is more likely to improve user experience than to degrade it.
  • Interactive dialogs proposing to change the “Airport data source” and “Airport database update” settings to their new defaults. Each question is asked only once (if applicable). Give an empty value to ALREADY_PROPOSED_CHANGES in the config file if you want to see the questions again.
  • Don't special-case FILTER_APT_LIST in Config.update(). It seems counter-intuitive to me that the “Reload config” button reloads everything from the config file, except the FILTER_APT_LIST setting (which corresponds to the “Show installed airports only” entry of the Settings menu). Remove this special case.
  • Enabled/disabled state for the “Update list of installed airports” menu entry. Since this menu entry is only applicable when “Show installed airports only” is selected, enable or disable it as appropriate.
  • Fix button size (“Reload config” & Co). In non-English translations, some buttons were too narrow for the text to fit. This should be better now.
  • Print the Python and CondConfigParser versions in the About dialog box. This should make it easier to help users or even to help them help themselves. ;-)
Debian packages are available, as indicated on FFGo's home page.
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Wed Sep 23, 2015 8:56 am

Note to those using the Git repository

For some time, 'make' after cloning the Git repo couldn't succeed without prior running 'make update-pot'. I have fixed this by including FFGo.pot in the repo. This will avoid having .po files that differ between the repo and your working directory.

In short, if you have installed things as indicated in the “Installation from the Git repository” section of docs/INSTALL/INSTALL_en, then all that is needed after:
Code: Select all
git clone https://github.com/frougon/FFGo.git
is to run:
Code: Select all
make
Then you can start FFGo using the ffgo-launcher.py script in the top-level directory of the repo.

It is also recommended to run 'make' after every 'git pull', although if you don't, the only problems you could have now are possibly-outdated translations and images (FFGo-specific thumbnails, icons). So, no need to panic if you once forget. :)
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

PreviousNext

Return to Development

Who is online

Users browsing this forum: No registered users and 5 guests