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 chris_blues » Mon Jan 25, 2016 2:07 am

WOW!!! :shock:

First, thanks a lot for taking so much time, to explain these matters! Also your mail from yesterday or so. Thanks, but it looks I'm too green for this python3 stuff... :oops:

Yes, using the deb-repo is certainly much more painless than this very complicated pip-business! These commands I had in my upgrade-script, I fiddled out with much trial and error. And it worked just fine for quite a while! Git never complained and it seemed all very nice - until now. :D

About the debian list, I'm not sure, what you want me to do there. (I also have no idea about the inner workings of debian packaging)
I'd certainly love to help you out, if I can!

Good night!
chris
Last edited by chris_blues on Tue Oct 11, 2016 3:30 am, edited 1 time in total.
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian stable 64bit - i7 8x2.8GHz - 20GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
Retired
 
Posts: 1577
Joined: Mon May 03, 2010 2:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian stable 64

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Mon Jan 25, 2016 9:50 am

Hi,

You have to choose one method and follow it until the end, asking at every step you don't understand. In the previous mail, I gave three good methods applicable to a Debian system (the last two easily adaptable to other distros):
  • Install my Debian packages. To do this cleanly, you have to install my GPG key into your apt keyring. I explained this part in the previous message. After this, you just need to add the /etc/apt/sources.list lines given at https://people.via.ecp.fr/~flo/projects ... n-packages and install ffgo as any other Debian package (for instance, 'apt-get update && apt-get install ffgo').

    What do you find unclear in that part? Installing my GPG key into apt's keyring is just one command---two if you are cautious not to run wget as root. I spelled out both possibilities (wget is just a command-line tool to download a file; it is available in Debian, of course).
  • The second method (towards the end of the message) is a transcript of an installation session. I inserted explanatory comments before most commands of this transcript. You'll see that there are actually very few things to do if you remove the comments. This method creates a Python virtual environment (what this means is also explained in INSTALL_en) and uses pip to install both CondConfigParser and FFGo into that venv. The method can be used exactly as is to install thousands of Python packages from PyPI (the Python Package Index).
  • The third method is almost the same as the second method, except that it uses FFGo directly from a clone of its Git repository, rather than installing it with pip. It is obviously the best to follow FFGo development, since you can test every commit pushed to FFGo's Git repo without having to wait for a release.
Then, for each of these two methods, I gave transcripts of how to update the installed software.

This is really not complicated. In the pip-based methods:
  1. First, you choose a Python interpreter, for instance /usr/bin/python3.4, and create a virtual environment from this Python interpreter.

    The interesting thing, with this kind of workflow, is that you never need to install packages as root (except for the base stones such as 'python3' and 'python3-tk' which are part of the Python Standard Library, that you install normally as Debian packages, with your usual Debian tools). Therefore, using these methods, there is no risk of messing up your Linux system (contrary to people coming up with crappy installation scripts and telling you to run them as root and hope for the best).

    The virtual environment can be created as a simple user, like this:
    Code: Select all
    /usr/bin/python3.4 -m venv ~/venv-dir

    Think of '/usr/bin/python3.4 -m venv' as the name of a program (it just runs the main function of the 'venv' module). In the above command, you can freely choose the ~/venv-dir directory. It is just a directory that is going to contain the newly-created virtual environment once this command returns (so you shouldn't have anything inside it before running the command, otherwise that would be messy).

    (In yesterday's message, I used ~/my-venvs/venv1 instead of ~/venv-dir for the first case, and ~/my-venvs/venv2 for the second case. I use ~/venv-dir today to make the commands shorter, and thus hopefully easier to understand.)

    Note: /usr/bin/pyvenv-3.4 (which you can run as 'pyvenv-3.4' if you didn't change your PATH) is just a shortcut for '/usr/bin/python3.4 -m venv'. Thus, you may type:
    Code: Select all
    /usr/bin/pyvenv-3.4 ~/venv-dir

    to obtain the same effect as above: creating a venv in ~/venv-dir based on the Python interpreter /usr/bin/python3.4.
  2. Once you have a virtual environment (and you can have as many as you wish), you can install, upgrade and uninstall Python packages inside it as a simple user, like this:
    Code: Select all
    ~/venv-dir/bin/pip install package_1 package_2 ... package_n
    ~/venv-dir/bin/pip install --upgrade package_1 package_2 ... package_n
    ~/venv-dir/bin/pip uninstall package_1 package_2 ... package_n

    (You can also sort-of install from a directory that contains a Python source package contents prepared for setuptools, and this is what your bizarre command was doing at the same time as trying to install FFGo from PyPI. This is an advanced feature I didn't even mention in INSTALL_en, so forget about it. This parenthesis was just to explain what your script told pip to do.)

    Such installations are done in the venv, so the ffgo executable obtained after running '~/venv-dir/bin/pip install ffgo' will be ~/venv-dir/bin/ffgo. You may create an alias for this command in your ~/.bashrc or ~/.zshrc, or you can create a symlink from /usr/local/bin/ffgo pointing to ~/venv-dir/bin/ffgo if you want to save some typing afterwards, to be able to just run 'ffgo' from a terminal. But these are easy details, I don't think the problem is here (feel free to ask if it is).
Please read patiently and say what you don't understand here. Maybe don't ask about all unclear points in a row. Ask about the first thing you don't understand; after I explain it, maybe many other points will become clear by themselves.

Otherwise, if you have a microphone connected to your Linux box (Windows and OS X should do just as well), Mumble would allow me to explain you via voice. Maybe that would work better (plus, it would bring a great plus to your FlightGear experience if you haven't tried before, IMHO).

Regards
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 chris_blues » Mon Jan 25, 2016 2:56 pm

rominet wrote in Mon Jan 25, 2016 9:50 am:
  • Install my Debian packages. [...] What do you find unclear in that part?


No propblems here! I was just missing the key. Now it works like a charm! :)

  • The second method (towards the end of the message) is a transcript of an installation session. I inserted explanatory comments before most commands of this transcript. You'll see that there are actually very few things to do if you remove the comments. This method creates a Python virtual environment (what this means is also explained in INSTALL_en) and uses pip to install both CondConfigParser and FFGo into that venv. The method can be used exactly as is to install thousands of Python packages from PyPI (the Python Package Index).


That one is much harder to wrap my mind around. But I think I'm beginning to understand. We have an isolated virtual python environment, which is self contained, like a virtual machine running an isolated OS, only that it's "only" a scripting environment. Now, I'd have to install all software into this environment, which would be CondConfigParser, that pil-thing and, of course FFGo. Now I *could* open up a new virtual environment, and install completely different software there. Both virtual environments wouldn't be able to see each other - they're isolated.
Right so far?

  • The third method is almost the same as the second method, except that it uses FFGo directly from a clone of its Git repository [...]


This one is still a little far out for me, but I think, once I managed to get an instance of a venv with FFGo functioning, I'll start to understand this third approach. One step at a time... As I see it now, it seems that pip replaces the "make install", and installs it into the venv.

Then, for each of these two methods, I gave transcripts of how to update the installed software.
[...]
(You can also sort-of install from a directory that contains a Python source package contents prepared for setuptools, and this is what your bizarre command was doing at the same time as trying to install FFGo from PyPI. This is an advanced feature I didn't even mention in INSTALL_en, so forget about it. This parenthesis was just to explain what your script told pip to do.)


Hm, Then I wasn't as far off, as I thought. But this statement makes me reconsider what I said before, about the git installation... :roll:

[...] Please read patiently and say what you don't understand here. Maybe don't ask about all unclear points in a row. Ask about the first thing you don't understand; after I explain it, maybe many other points will become clear by themselves.


Yeah, that wasn't so much. Actually just a confirmation if I got it right this time... :D

Otherwise, if you have a microphone connected to your Linux box (Windows and OS X should do just as well), Mumble would allow me to explain you via voice. Maybe that would work better (plus, it would bring a great plus to your FlightGear experience if you haven't tried before, IMHO).


Well, that might be a problem. My neighbours tend to knock on the wall if I'm just having a telephone call - they're very noise sensitive... So I'd avoid that kind of conversation. Seems my voice carries very far....

Thanks again!
chris
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian stable 64bit - i7 8x2.8GHz - 20GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
Retired
 
Posts: 1577
Joined: Mon May 03, 2010 2:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian stable 64

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Mon Jan 25, 2016 7:04 pm

chris_blues wrote in Mon Jan 25, 2016 2:56 pm:No propblems here! I was just missing the key. Now it works like a charm! :)

Good. :-)
chris_blues wrote in Mon Jan 25, 2016 2:56 pm:That one is much harder to wrap my mind around. But I think I'm beginning to understand. We have an isolated virtual python environment, which is self contained, like a virtual machine running an isolated OS, only that it's "only" a scripting environment. Now, I'd have to install all software into this environment, which would be CondConfigParser, that pil-thing and, of course FFGo. Now I *could* open up a new virtual environment, and install completely different software there. Both virtual environments wouldn't be able to see each other - they're isolated.
Right so far?

All correct!

With an optionless venv creation command:
Code: Select all
pyvenv-x.y <venv-dir>
# Or, explicitely specifying the base Python interpreter:
/path/to/pythonx.y -m venv <venv-dir>

the venv created in <venv-dir> contains the Python Standard Library, plus pip and setuptools. You have to add everything else you need. This venv “knows his parent”: the base Python installation that was used to create it, the one containing the /path/to/pythonx.y executable in this example. Typically, the venv has symlinks pointing to its parent intallation.

It is possible to create the venv in such a way that it has access to all packages from the parent Python installation instead of only Python Standard Library + pip + setuptools. This can be useful when you need Python packages that are available as Debian (or $your_distro) packages but don't support installation via pip. But it is slightly more difficult to grasp, and since FFGo's Python dependencies can all be installed with pip, it is not necessary to use this here. Just keep in mind that this is possible. The way to create such a venv is as above, with the --system-site-packages option added:
Code: Select all
pyvenv-x.y --system-site-packages <venv-dir>
# Or, more explicitely:
/path/to/pythonx.y -m venv --system-site-packages <venv-dir>

Of course, in order to benefit from Python stuff coming from Debian packages, one would have to use /usr/bin/python3.4 or something like that (/usr/bin/python3.5...) as our /path/to/pythonx.y: because this is a Python interpreter coming from Debian packages, it “sees” the modules contained in the python3-pil.imagetk or python3-geographiclib Debian packages, for instance.
chris_blues wrote in Mon Jan 25, 2016 2:56 pm:
  • The third method is almost the same as the second method, except that it uses FFGo directly from a clone of its Git repository [...]


This one is still a little far out for me, but I think, once I managed to get an instance of a venv with FFGo functioning, I'll start to understand this third approach. One step at a time...

Right, just repeat the transcripts at the end of my message from yesterday, it should be very quick.
chris_blues wrote in Mon Jan 25, 2016 2:56 pm:As I see it now, it seems that pip replaces the “make install”, and installs it into the venv.

If you say “make install” as in “typical installation procedure”, then yes (but pip also supports upgrades, uninstallations, listing, which is not always the case with installation Makefiles). Otherwise, I am not sure what you mean, as neither CondConfigParser nor FFGo supports a “make install” command (FFGo supports “make” and a few others, but not “make install”).

chris_blues wrote in Mon Jan 25, 2016 2:56 pm:Hm, Then I wasn't as far off, as I thought. But this statement makes me reconsider what I said before, about the git installation... :roll:

Not sure what you mean here. The thing is: with the method I suggest, when you decide to use FFGo's Git repo, pip is used to install CondConfigParser in your venv (and maybe also Pillow, etc.), but you don't install FFGo per se---you use it directly from your clone of the repo, which must be kept outside the venv. In order to do this:
  • you have to run “make” after each 'git clone' or 'git pull' operation;
  • you may call the ffgo-launcher.py script contained in the repo.
And in order to make sure that ffgo-launcher.py can use the CondConfigParser and other dependencies you have installed in the venv, you should explicitely run it with the python executable contained in the venv's bin subdirectory:
Code: Select all
<venv-dir>/bin/python ffgo-launcher.py

That's all!
chris_blues wrote in Mon Jan 25, 2016 2:56 pm:Yeah, that wasn't so much. Actually just a confirmation if I got it right this time... :D

It seems we are making progress. :-)
chris_blues wrote in Mon Jan 25, 2016 2:56 pm:Well, that might be a problem. My neighbours tend to knock on the wall if I'm just having a telephone call - they're very noise sensitive... So I'd avoid that kind of conversation. Seems my voice carries very far....

Ah, doesn't sound easy. Ok, ok, no Mumble, then...

Regards
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 chris_blues » Tue Jan 26, 2016 12:06 am

rominet wrote in Mon Jan 25, 2016 7:04 pm:All correct!

That's a relief!!!! :)

chris_blues wrote in Mon Jan 25, 2016 2:56 pm:As I see it now, it seems that pip replaces the “make install”, and installs it into the venv.

If you say “make install” as in “typical installation procedure”, then yes [...]

That's it. This certain command installs the software into the created environment, as a "make install" would install some software into my OS.

chris_blues wrote in Mon Jan 25, 2016 2:56 pm:Hm, Then I wasn't as far off, as I thought. But this statement makes me reconsider what I said before, about the git installation... :roll:

Not sure what you mean here. The thing is: with the method I suggest, when you decide to use FFGo's Git repo, pip is used to install CondConfigParser in your venv (and maybe also Pillow, etc.), but you don't install FFGo per se---you use it directly from your clone of the repo, which must be kept outside the venv. In order to do this:
  • you have to run “make” after each 'git clone' or 'git pull' operation;
  • you may call the ffgo-launcher.py script contained in the repo.
And in order to make sure that ffgo-launcher.py can use the CondConfigParser and other dependencies you have installed in the venv, you should explicitely run it with the python executable contained in the venv's bin subdirectory:
Code: Select all
<venv-dir>/bin/python ffgo-launcher.py

That's all!


Ah ok, it doesn't exactly install into the venv, but instead use the code "out-of-venv" from my git-clone. That piece was missing!

After I set up my venv with pillow & Co, without FFGo, I do call FFGo from that environment. So my update-script would look sth like this:
Code: Select all
cd ffgo                 # example
git pull
make

and that's it.

chris_blues wrote in Mon Jan 25, 2016 2:56 pm:Yeah, that wasn't so much. Actually just a confirmation if I got it right this time... :D

It seems we are making progress. :-)


Indeed!

Zero'ing in on the runway, I would say... flaps to 20! :mrgreen:

Thanks a lot for letting me see!
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian stable 64bit - i7 8x2.8GHz - 20GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
Retired
 
Posts: 1577
Joined: Mon May 03, 2010 2:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian stable 64

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Tue Jan 26, 2016 2:58 pm

Hi,
chris_blues wrote in Tue Jan 26, 2016 12:06 am:That's it. This certain command installs the software into the created environment, as a "make install" would install some software into my OS.

Right. And the particular environment where it is installed is the one living in <venv-dir> when you run the command:
Code: Select all
<venv-dir>/bin/pip install package_1 ... package_n

which is why, until you are comfortable with pip, I suggest to use such a command rather than resorting to one of the shortcuts that allow writing the shorter:
Code: Select all
pip install package_1 ... package_n

When you use a syntax such as '<venv-dir>/bin/pip ...', you know that it is going to operate on, or report from the venv living under <venv-dir>. It may seem a bit long to type, but with shell completion and command history (Up arrow...), the advantage in clarity outweighs this little inconvenience IMHO (it's only bothersome for me when writing instructions, as I would like them to be as short as possible to avoid scaring potential users...).
chris_blues wrote in Mon Jan 25, 2016 2:56 pm:Ah ok, it doesn't exactly install into the venv, but instead use the code "out-of-venv" from my git-clone. That piece was missing!

After I set up my venv with pillow & Co, without FFGo, I do call FFGo from that environment.

Right, using <venv-dir>/bin/python to start the ffgo-launcher.py script located inside your Git clone of the repo (which itself is going to import many Python modules located in the Git clone).

Concerning Pillow, note that installing or upgrading it with pip will automatically compile it (it contains a lot of C code), which can only succeed if you have the appropriate C compiler (gcc works) and headers. On Debian, installing 'gcc libpython3-dev tcl-dev tk-dev' with apt-get or aptitude should be enough (at least, it was for me). On Windows, this is most of the times not necessary, because the PyPI site from which pip downloads packages by default contains binary distributions of Pillow for many Python and Windows versions.
chris_blues wrote in Mon Jan 25, 2016 2:56 pm:So my update-script would look sth like this:
Code: Select all
cd ffgo                 # example
git pull
make


Yes, but I would probably chain the commands like this:
Code: Select all
cd "$ffgo_git_dir" && git pull && make

or add 'set -e' at the top to make sure the script stops at the first error.

Additionally, such a script only updates FFGo. As for security updates on any OS, you should update your venvs from time to time IMHO. This can be done manually with:
Code: Select all
<venv-dir>/bin/pip list --outdated

followed by:
Code: Select all
<venv-dir>/bin/pip install --upgrade <pkg_1> ... <pkg_n>

for the packages you want to upgrade. There is unfortunately no pip command to upgrade all packages contained in a venv at once, because apparently the pip developers and users are still hesitating about the syntax to adopt concerning shallow vs. recursive upgrades, and whether to break compatibility in order to introduce the “optimal” behavior... (cf. pip issue 59). If you really want to automate this step, a script such as:
Code: Select all
#! /bin/sh
#
# Work around the absence of an 'upgrade-all' command in pip (2016-01-26)
#
# cf. <https://github.com/pypa/pip/issues/59>

set -e
progname=$(basename "$0")
venv_path="$1"

if [ -z "$venv_path" ]; then
    echo "$progname: empty venv path, aborting." >&2
    exit 1
fi

# awk '!/Could not|ignored/ ...
#   ignore warnings that may reported by 'pip list --outdated'
# xargs -n1
#   upgrade one package at a time: avoid that a failed upgrade blocks
#   all others
"$venv_path/bin/pip" list --outdated | \
    awk '!/Could not|ignored/ { print $1 }' | \
    xargs -n1 "$venv_path/bin/pip" install --upgrade

should do the trick. It takes one argument: a path to the venv in which you want to upgrade all packages (<venv-dir> in what I wrote above).

Edit: fix a bug in the above venv-updating script, replacing “pip” in the last line with “"$venv_path/bin/pip"” (I had tested the script on my main venv only, where it doesn't make any difference...).

There is one last thing to consider regarding upgrades. If your venv was built from /usr/bin/python3.4 for instance (with a command such as '/usr/bin/python3.4 -m venv <venv-dir>'), then it is somehow linked to its base installation: the one containing /usr/bin/python3.4. Thus, when your Linux distro removes /usr/bin/python3.4, of course you should expect the venv not to work anymore. Granted, it is a rare event in general, but I think it is a good idea to have a very simple venv-creation script that acts both as a reminder (which commands did I do to prepare this *@#]$ venv?..) and as a quick way to recreate it when needed, or to create another one for experimenting (venv creation is very, very fast). I sent you the script for my “main venv” by mail, but a simplified script creating a venv just containing FFGo's dependencies (suitable for using FFGo form Git) could look like:
Code: Select all
#! /bin/sh

set -e

target_dir="${1:-default-venv-dir}"
base_python="/usr/bin/python3.4"

if [ -e "$target_dir" ]; then
   echo "!!Warning!! '$target_dir' already exists. If you continue, its"
   echo "            contents will be deleted. Press Enter to continue,"
   echo "            otherwise interrupt the script with Ctrl-C."
   read dummy
fi

"$base_python" -m venv --clear "$target_dir"
"$target_dir"/bin/pip install --upgrade \
  pip setuptools CondConfigParser Pillow geographiclib

It takes one optional argument: the base path where you want the venv to be created (i.e., <venv-dir> in what I wrote above). This argument defaults to 'default-venv-dir' in the current directory, but you may provide an absolute path if you wish. Those who want to use pip-installed releases of FFGo instead of using it from the Git repo can just add 'ffgo' to the list of packages to install in the last line of the script.

chris_blues wrote in Mon Jan 25, 2016 2:56 pm:Thanks a lot for letting me see!

Wow. :wink:
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 Jan 27, 2016 7:00 pm

I fixed a bug in the venv-updating script in my previous message, replacing “pip” in the last line with “"$venv_path/bin/pip"”. I wrote this script yesterday for the message (I did the updates manually before). I had tested it on my main venv only, and there the change doesn't make any difference, which is why I hadn't noticed the problem before. Sorry if someone tried it and it didn't work.
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 chris_blues » Wed Jan 27, 2016 7:27 pm

Thank you! I think I got it now. Unfortunately I don't have time to check it all out right now, but I'll give it a shot first chance I get!
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian stable 64bit - i7 8x2.8GHz - 20GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
Retired
 
Posts: 1577
Joined: Mon May 03, 2010 2:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian stable 64

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Wed Jan 27, 2016 8:39 pm

Okay, thanks for your translation update!

I have released FFGo 1.9.1 (bugfix release). The changes in this version are:
  • Installing on Windows should create an ffgo-noconsole.exe executable (typically in C:\PythonXY\Scripts) that doesn't open any terminal window (“console”) when run (thanks to legoboyvdlp for testing).
  • Fix a bug in the Airport Finder: if the airport search text in FFGo's main window was non-empty, the “Choose selected airport” button of the Airport Finder dialog could fail to find the chosen airport.
  • Fix the “Open Log Directory” feature to hopefully work on Windows and MacOS X (in addition to Unix-like systems, of course).
  • Update the German translation (thanks to chris_blues)
As usual, you can get this release from FFGo's home page. Debian packages for jessie and unstable are available from there, along with the distribution-agnostic tarballs and zip files.

(and thanks to chris_blues' feedback, I have added instructions telling how to install the OpenPGP key used to sign the Debian packages [technically, the Release file, which itself contains hashes of all package files---signature and hashes verification is automatically done by apt, as for official Debian packages])
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

pushBackRoute=None

Postby pommesschranke » Thu Feb 04, 2016 8:40 am

did you maybe have a look at the FG sourcecode, what would happen with:

Code: Select all
   
<Parking index="0" type="gate" name="Dock_201" lat="N35 32.067139" lon="E139 47.537686" heading="60"  radius="44" pushBackRoute="None" airlineCodes="" />


ffgo says:
ERROR: while parsing '/home/mherweg/scenery/fgo/Airports/R/J/T/RJTT.groundnet.xml': invalid value for the 'pushBackRoute' attribute: 'None'

I did not do that on purpose. In the latest version of my converter script I changed it to:

Code: Select all
   
<Parking index="0" type="gate" name="Dock_201" lat="N35 32.067139" lon="E139 47.537686" heading="60"  radius="44" airlineCodes="" />


..when there is no pushback route.
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 » Thu Feb 04, 2016 10:27 am

Hi,
pommesschranke wrote in Thu Feb 04, 2016 8:40 am:did you maybe have a look at the FG sourcecode, what would happen with:

Code: Select all
   
<Parking index="0" type="gate" name="Dock_201" lat="N35 32.067139" lon="E139 47.537686" heading="60"  radius="44" pushBackRoute="None" airlineCodes="" />


I have looked at the code that reads groundnet files (flightgear/src/Airports/dynamicloader.cxx at lines 86-135 as far as pushback routes are concerned), but not at what the AI system does with it, sorry (I never use AI, except for AI scenarios).

As for the FFGo warning and your correction, they seem appropriate to me, as the 'pushBackRoute' attribute is supposed to be an integer.

Unrelated: I am currently making the airport chooser a generic chooser so that it can be used for the aircraft list (and any kind of list, too). Among others, this will allow to put a second column in the aircraft list showing the number of days during the last year where you started FlightGear with each aircraft. Sorting based on this column (by clicking on the column header) should satisfy your request of favorite aircrafts listing. I can do the same for airports too.
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 Feb 04, 2016 11:34 am

Regarding aircraft use count, one question remains open. As you know, FFGo can distinguish between identically-named aircrafts, for instance between the c172p from FGData and the one from the upstream repository at https://github.com/Juanvvc/c172p-detailed. The question is whether to use separate counts in such cases or only a global count for all aircrafts named "c172p", for instance. Arguments in favor of separate counts are:
  • makes it clear that FFGo treats them differently without having to compare their tooltips;
  • provides an immediate answer to the question “Which of the variants/forks of this aircraft did I use most during the last year?”
The main disadvantage, in my opinion, is that the use count for a given aircraft would be reset to 0 when the aircraft is moved to a different directory (since identification would be based on the combination of aircraft name and directory).

What do you think?

Edit: replace “c172p from FGAddon” with “c172p from FGData”
Last edited by rominet on Thu Feb 04, 2016 10:55 pm, edited 1 time 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 chris_blues » Thu Feb 04, 2016 2:51 pm

rominet wrote in Thu Feb 04, 2016 10:27 am:Sorting based on this column (by clicking on the column header) should satisfy your request of favorite aircrafts listing. I can do the same for airports too.

I think this is a brilliant idea! :)

rominet wrote in Thu Feb 04, 2016 11:34 am:The main disadvantage, in my opinion, is that the use count for a given aircraft would be reset to 0 when the aircraft is moved to a different directory

I vote: go for it! How often do we change Aircraft directories? In my case nearly never. My opinion is; the advantages clearly outweigh the disadvantage. Looking forward to this!

Cheers
chris
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian stable 64bit - i7 8x2.8GHz - 20GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
Retired
 
Posts: 1577
Joined: Mon May 03, 2010 2:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian stable 64

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Fri Feb 05, 2016 7:57 am

Okay, it's on its way, thanks for your input! I don't change aircraft directories often either, thus I think I'll go in the sense of your vote.
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 Feb 05, 2016 8:06 am

rominet wrote in Thu Feb 04, 2016 11:34 am:The question is whether to use separate counts in such cases


yes. I'm looking forward to it. then it will be very easy to see which aircraft I never tried.


I have another feature idea:
one ~/.ffgo/apt file for each FG Version.

when I switch between ffgo configs, I also switch betwen FG versions. I currently have 3 versions of FG installed
with currently 2 different apt.dat.gz files. I must admit that this is a very special use case, but on the other hand I think it is easy to implement.
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

PreviousNext

Return to Development

Who is online

Users browsing this forum: No registered users and 13 guests