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 » Wed Feb 24, 2016 8:02 pm

Hooray wrote in Fri Feb 12, 2016 9:15 pm:Regarding all those installation instructions, you may want to consider moving them to the wiki, so that you don't have to deal with dozens of users separately :D

I have added installation “tips” to FFGo's page on the FlightGear wiki. It is obviously partially redundant with docs/INSTALL/INSTALL_en, but written differently, with a more practical perspective, that should hopefully be easier to follow for non-programmers. So far, it has Windows-specific instructions, instructions for installing via the Debian packages I provide, and generic instructions based on pip that should be adaptable to any Linux distribution (actually: to any system where Python can be installed, if one considers the part of the installation that is based on pip—i.e., once Python and Tkinter have been installed, basically).

Installations on MacOS X can certainly be done with the generic pip-based method, but someone knowledgeable with this platform would be welcome to explain to “simple” users:
  • how to install Python in a non-intrusive way for the system;
  • how to run pip in this particular installation (this one should be very easy: one just needs to know a path to the installed Python executable);
  • and how to create a shortcut to the resulting ffgo executable for convenience (I have stored something like that posted for ATC-pie, it can probably be adapted).
I'm ready to help such a person if she has questions—just ask them here. I seem to vaguely recall that custom Python installations on OS X go somewhere under /Library, but frankly, that was long ago and even if I don't anticipate any particular difficulty, it would be good to have precise instructions for people who are not very comfortable with that kind of things (having concrete, directly applicable instructions for each system is the whole point of this new set of installation instructions).

Since the FFGo wiki page seems to be more popular than docs/INSTALL/INSTALL_en (if I am to believe Google), I hope this new documentation will bring benefits that outweigh the burden of having several sets of partially redundant instructions.
rominet
 
Posts: 548
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Thu Feb 25, 2016 12:09 pm

A short note for users of Debian unstable: the Debian packages I provide still work (and are still installable), however if you try the pip+venv method in up-to-date unstable, you will probably not manage to create the virtual environment. The problem is not in my instructions, but AFAICT in the python3-venv package being currently broken (bug #815864) as an unfortunate side-effect, I assume, of the transition from Python 3.4 to Python 3.5.
rominet
 
Posts: 548
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Sun Feb 28, 2016 11:40 am

@pommeschranke:

You didn't reply to viewtopic.php?f=18&t=27054&start=120#p275078
Would you use it if I implemented such a scheme?

I did some timing tests to see how long it would take to compute the hash for apt.dat.gz. If a hash were used instead of a timestamp (currently, it is a timestamp stored in ~/.ffgo/timestamp everywhere except on Windows—which has it in %APPDATA%/FFGo/timestamp), then it would have to be computed every time FFGo is started to make sure that the apt digest file (~/.ffgo/apt everywhere except on Windows) used by FFGo is in sync with the apt.dat.gz file used by FlightGear. Therefore, this has to be fast. However, the only use it has is to tell us when apt.dat.gz has changed, therefore we don't need a hash with strong cryptographic properties (i.e., even though MD5 is not considered strong anymore for cryptographic applications, it is perfectly suitable for such a purpose). So, the measurements on my computer (done with Python's hashlib module):

SHA1 over the uncompressed contents of apt.dat.gz: 992 ms
MD5 over the uncompressed contents of apt.dat.gz: 768 ms
SHA1 over apt.dat.gz: 58 ms
MD5 over apt.dat.gz: 60 ms
Of course, continuing to use the timestamp technique, but storing the timestamp directly in the apt digest file header—as I proposed in the message linked above—would have a time cost close to 0 ms.

Since this would be added to the startup time of every FFGo run, I consider the first two a bit too heavy for the small benefit they bring. However, 58 or 60 ms added startup time don't sound unacceptable to me, although it would be (very) slightly noticeable.

The advantage of using a hash over a timestamp is that if you use several FGData Git branches (maybe managed with StGit) that have different apt.dat.gz files, then the apt digest file wouldn't in theory have to be rebuilt whenever you switch between these branches (assuming it is managed in Automatic mode, which has been the default in FFGo for some time). I said “in theory”, because that would only work when computing the hash over the uncompressed contents of apt.dat.gz (which as we saw is a bit too slow) if the apt.dat.gz file is rebuilt when you switch between your branches—this depends on how they are managed. With my setup using StGit to automatically patch apt.dat.gz for custom scenery layouts, apt.dat.gz is rewritten by StGit whenever I switch between my normal branch with all my changes and the official 'next' branch with vanilla apt.dat.gz. And unfortunately, this apt.dat.gz automatic rebuild certainly puts a new timestamp in the gzip header (property of the gzip format...), which means that unless I somehow managed to disable this gzip feature, FFGo would be unable to tell whether two apt.dat.gz files are identical in actual contents by just computing their hashes (over the compressed data, which is the way that takes approx. 60 ms and is thus quite acceptable). Therefore, for this particular application, hashes wouldn't bring any significant gain over timestamps unless there is a way to tell StGit to build .gz files with the same internal timestamp every time.

The real question is: will you use the --ffgo-apt-file option I proposed if I implement it? (I wrote it as --ffgo-apt-path in the message linked above: not quite decided on the name yet)

In case you have forgotten: I can provide you with a Python script that rewrites ~/.ffgo/config on the fly before starting FFGo, rewriting config "variables" such as those giving the path to the fgfs binary, FG_ROOT, FG_SCENERY, FG_AIRCRAFT... depending on a profile name passed on the command line. Combined with the --ffgo-apt-file option under discussion, that would allow you to easily switch between various FG installations without having to rebuild the apt digest file (“airport database”). This is assuming the timestamp or hash for apt.dat.gz is reliable, see the previous paragraph. If apt.dat.gz is not rewritten when you switch between branches (i.e., it keeps its timestamp from the last time you were in the same branch, or at least it keeps its hash), then it is fine: no rebuild of the apt digest file would be needed.

For instance, here are three configs I have on my system for this script (they are part of the script, but this is easily changed if needed):
  1. For the Debian packages of FG 3.4:
    Code: Select all
    CONF_34 = {"ffgo config":
               {"--fg-root": "/usr/share/games/flightgear",
                "FG_AIRCRAFT": ("/mm/flightgear-data/aircrafts-misc:"
                                "/mm/flightgear-data/Aircraft-3.4.extra"),
                "FG_BIN": "/usr/games/fgfs",
                "FG_WORKING_DIR": os.path.expanduser(
                    "~/flightgear/tmp/working-dir/3.4")},
               "envvar prepend": {}}
  2. For self-compiled FG from Git 'next' (normal build suitable for flying):
    Code: Select all
    CONF_GIT = {"ffgo config":
                {"--fg-root": os.path.expanduser("~flo/flightgear/src/fgdata"),
                 "FG_AIRCRAFT": ("/mm/flightgear-data/aircrafts-misc:"
                                 "/mm/flightgear-data/fgaddon/Aircraft"),
                 "FG_BIN": os.path.expanduser(
                     "~flo/flightgear/install-git/bin/fgfs"),
                 "FG_WORKING_DIR": os.path.expanduser(
                     "~/flightgear/tmp/working-dir/git")},
                "envvar prepend":
                {"LD_LIBRARY_PATH":
                 os.path.expanduser("~flo/flightgear/install-git/lib") + ":" + \
                 os.path.expanduser("~flo/flightgear/install-git/lib64")}}
  3. The same but using a debug build (as you can see, it is derived from the previous config, “CONF_GIT”):
    Code: Select all
    CONF_GIT_DBG = CONF_GIT.copy()
    CONF_GIT_DBG["ffgo config"] = CONF_GIT_DBG["ffgo config"].copy()
    CONF_GIT_DBG["ffgo config"]["FG_BIN"] = os.path.expanduser(
        "~flo/flightgear/install-git.debug/bin/fgfs")
    CONF_GIT_DBG["envvar prepend"] = {
        "LD_LIBRARY_PATH": os.path.expanduser(
            "~flo/flightgear/install-git.debug/lib") + ":" + \
        os.path.expanduser("~flo/flightgear/install-git.debug/lib64")}
Then I declare these three profiles like this:
Code: Select all
CONFIGS = {"3.4": CONF_34,
           "git": CONF_GIT,
           "git-dbg": CONF_GIT_DBG}

which allows me to call the script (currently called flo-ffgo-launcher) like this:
Code: Select all
flo-ffgo-launcher 3.4 [args...]

or
Code: Select all
flo-ffgo-launcher git [args...]

or
Code: Select all
flo-ffgo-launcher git-dbg [args...]

depending on which particular FG installation I want to use, where [args...] stands for optional arguments that flo-ffgo-launcher is going to pass to ffgo-launcher.py (the script shipped with FFGo, that is typically used to start FFGo from a clone of its Git repository).

@everyone:

I have pushed to the Git repository:
  • a simple pressure converter accessible from the Tools menu. This can be used to convert between “altimeter setting” in inches of mercury (inHg) and “QNH” in hectoPascals (hPa). This kind of tool is often called a “QNH converter” on the Internet—but I think this is improper naming.
  • an entry in the Help menu that creates a dedicated window showing the output of 'fgfs --fg-root=... --help --verbose'. This can be used to easily see which fgfs options are available to put in FFGo's Options Window for the particular FlightGear version you have chosen in FFGo's setup (I mean, the configured FlightGear installation; you don't explicitely configure the FlightGear version of course: you choose an fgfs executable, the FG_ROOT path that goes with it, etc., and FFGo detects the FlightGear version from these elements, as usual).
rominet
 
Posts: 548
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Mon Feb 29, 2016 3:48 pm

rominet wrote in Thu Feb 25, 2016 12:09 pm:A short note for users of Debian unstable: if you try the pip+venv method in up-to-date unstable, you will probably not manage to create the virtual environment. The problem is [that] [....] the python3-venv package [is] currently broken (bug #815864)

Two possible workarounds for this problem:
  1. Easiest workaround: create your venv with the --without-pip option and manually install pip inside this venv. There are several ways to install pip, here is an easy one:
    • First, download the get-pip.py script from pip's home page. Let's assume you saved the script as ~/tmp/get-pip.py.
    • Then create your virtual environment in <venv-dir>:
      Code: Select all
      /usr/bin/python3.5 -m venv --without-pip <venv-dir>

      Edit: I had initially forgotten to include the --without-pip option in the previous command.
    • Finally, install pip in this venv using the downloaded get-pip.py script:
      Code: Select all
      <venv-dir>/bin/python ~/tmp/get-pip.py
    This is it. You can now run:
    Code: Select all
    <venv-dir>/bin/pip list

    or
    Code: Select all
    <venv-dir>/bin/pip --version

    or
    Code: Select all
    <venv-dir>/bin/pip install FFGo Pillow geographiclib

    etc.
  2. The second method consists in building Python yourself. This is a very classical build+install process:
    • Download and uncompress the upstream tarball.
    • Read the top-level README file, which should tell you everything you know for that.
    • The rest depends on how you want to compile Python and where you want to install it, but basically something like this should do the trick:
      Code: Select all
      cd <Python-source-dir>
      ./configure --prefix=/opt/python3
      make

      make test
      # Sometimes, one or two tests don't pass for various reasons.
      # For instance, with Python 3.5.1, the tests 'test_httplib'
      # and 'test_ssl' don't pass on my system. To obtain a
      # "successful" build nevertheless, one can exclude specific
      # tests like this:
      #
      #   make test EXTRATESTOPTS="-x test_httplib test_ssl"

      # Of course, you would need write permissions to /opt/python3
      # for this command to work.
      make install

      After this, you should have working python3, pip3 and pyvenv executables in the /opt/python3/bin directory (as well as python3.5, pip3.5 and pyvenv-3.5, which are equivalent). You can then create a venv with:
      Code: Select all
      /opt/python3/bin/python3 -m venv <venv-dir>

      But since this installation is completely disconnected from the Python installations shipped by your distribution, you can even safely install FFGo directly in this installation without creating a venv, like this:
      Code: Select all
      /opt/python3/bin/pip3 install FFGo Pillow geographiclib

      This will create the ffgo executable in /opt/python3/bin.
(yes, FFGo works fine with Python 3.5)
rominet
 
Posts: 548
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby pommesschranke » Tue Mar 01, 2016 11:33 am

rominet wrote in Sun Feb 28, 2016 11:40 am:The real question is: will you use the --ffgo-apt-file option I proposed if I implement it? (I wrote it as --ffgo-apt-path in the message linked above: not quite decided on the name yet)


yes

Why do we need an additional script that rewrites config file ?
that sounds like a workaround for a missing feature.
I can load & save configs in FFGo. but that also changes the content of the lower left window. :-(

The way I use ffgo:
I make changes in the lower left window by adding cmd lines or commenting them out.
those changes get lost when I load a different config via File->Load :-(

so instead I just change
"path to executable" and FG_ROOT in the preferences.
pommesschranke
 
Posts: 1100
Joined: Sat Apr 27, 2013 7:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Lubuntu 18.04

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Tue Mar 01, 2016 6:03 pm

pommesschranke wrote in Tue Mar 01, 2016 11:33 am:
rominet wrote in Sun Feb 28, 2016 11:40 am:The real question is: will you use the --ffgo-apt-file option I proposed if I implement it? (I wrote it as --ffgo-apt-path in the message linked above: not quite decided on the name yet)


yes

OK.
pommesschranke wrote in Tue Mar 01, 2016 11:33 am:Why do we need an additional script that rewrites config file ?
that sounds like a workaround for a missing feature.

This is true. The problem is that correctly managing profiles requires a structured configuration format, and the format inherited from FGo! for the part of ~/.ffgo/config that is located above the line reading:
Code: Select all
xxxxxxxxxxxxxxxxxxx INTERNAL OPTIONS ABOVE. EDIT CAREFULLY! xxxxxxxxxxxxxxxxxxxx

is not structured (it is just a series of VARIABLE=value assignments). That might change in the future, but given:
  • the pain/gain ratio;
  • the fact that nobody asked for it before AFAIK, and;
  • the fact that the wrapper script included below does the job reasonably well and is quite powerful(*)
this has never reached the top of my TODO list.
pommesschranke wrote in Tue Mar 01, 2016 11:33 am:I can load & save configs in FFGo. but that also changes the content of the lower left window. :-(

Well, this is the expected behavior: the contents of the Options Window (what you called “lower left window”) is an integral part of the config (look at ~/.ffgo/config for yourself). Therefore, loading a config file must replace this part by what is defined in this config file.
pommesschranke wrote in Tue Mar 01, 2016 11:33 am:The way I use ffgo:
I make changes in the lower left window by adding cmd lines or commenting them out.
those changes get lost when I load a different config via File->Load :-(

If the parameters you change are not among those that are defined in the Preferences dialog, then the best way for such things (unless doing a "one-shot" experiment) is to use conditional sections in the Options Window. This is fully explained in FFGo's conditional config documentation, and I gave a bunch of examples in the first message of this thread, as well as more recently in this message. It allows to very simply pass arguments to fgfs conditionally, depending on variables that are either explicitely defined by you in the Options Window, or are external, i.e. automatically defined by FFGo (the aircraft name, the aircraft directory, the selected airport, the selected carrier if any, the list of scenarios are all external variables; and there are a few more, cf. FFGo's conditional config documentation). For example, if your Options Window starts with:
Code: Select all
{ my_variable = "foobar"
  a_list_variable = ["some", "list"]
  some_boolean = True }

then you can have conditional sections like this:
Code: Select all
[ my_variable == "foobar" ]
--some-fg-option
--other-option=with-value # You may have comments here
# or here
--third-option

[ aircraft == "Citation-II" and some_boolean ] # You can have comments here, too
--other-fgfs-arguments
# etc.

# And here (parentheses below used for clarity only, you can remove them)
[ airport != "LFOH" or ("some" in a_list_variable) ]
--yet-another-set-of-fgfs-arguments
--I-guess-you-got-it-now

and between both parts (the braces-delimited header for defining non-external variables, and the conditional sections), you can put any unconditional fgfs options (similar to .fgfsrc).

The syntax for such CondConfigParser conditions is very Python-like. Are you aware of this feature?
pommesschranke wrote in Tue Mar 01, 2016 11:33 am:so instead I just change
"path to executable" and FG_ROOT in the preferences.

These settings are available in the Preferences dialog, therefore overriding them in the Options Window is not a very good idea, because FFGo and FlightGear won't have a consistent view for them. For instance, FG_ROOT is used to determine the list of available airports that FFGo shows you. If you override the FG_ROOT setting from the Preferences dialog using --fg-root=... in the Options Window, then FFGo may list airports that FlightGear won't be able to find, because the FG_ROOT/Airports/apt.dat.gz files under each of the two FG_ROOT paths may differ. Conversely, FFGo's airport chooser could omit airports that FlightGear would be able to find.

Therefore, when you want to change settings that are available from the Preferences dialog, I don't advise doing that in the Options Window. But you can easily do this with the flo-ffgo-launcher script I mentioned, so I will include it here:
Code (flo-ffgo-launcher): Select all
#! /usr/bin/env python3
# -*- coding: utf-8 -*-

# flo-ffgo-launcher --- Wrapper for ffgo-launcher.py
# Copyright (c) 2015, 2016, Florent Rougon
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice,
# this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright notice,
# this list of conditions and the following disclaimer in the documentation
# and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.
#
# The views and conclusions contained in the software and documentation are
# those of the authors and should not be interpreted as representing official
# policies, either expressed or implied, of the flo-ffgo-launcher project.

import sys
import os
import argparse
import locale

progname = os.path.basename(sys.argv[0])


# Note concerning FG_AIRCRAFT: it may be insufficient to change the order of
# its elements below (and thus the order of the --fg-aircraft options passed to
# fgfs). cf. <http://wiki.flightgear.org/$FG_AIRCRAFT> and
# <http://forum.flightgear.org/viewtopic.php?f=4&t=28444&p=271683#p271683>.

CONF_34 = {"ffgo config":
{"--fg-root": "/usr/share/games/flightgear",
"FG_AIRCRAFT": ("/mm/flightgear-data/aircrafts-misc:"
"/mm/flightgear-data/Aircraft-3.4.extra"),
"FG_BIN": "/usr/games/fgfs",
"FG_WORKING_DIR": os.path.expanduser(
"~/flightgear/tmp/working-dir/3.4")},
"envvar prepend": {}}

CONF_GIT = {"ffgo config":
{"--fg-root": os.path.expanduser("~flo/flightgear/src/fgdata"),
"FG_AIRCRAFT": ("/mm/flightgear-data/aircrafts-misc:"
"/mm/flightgear-data/fgaddon/Aircraft"),
"FG_BIN": os.path.expanduser(
"~flo/flightgear/install-git/bin/fgfs"),
"FG_WORKING_DIR": os.path.expanduser(
"~/flightgear/tmp/working-dir/git")},
"envvar prepend":
{"LD_LIBRARY_PATH":
os.path.expanduser("~flo/flightgear/install-git/lib") + ":" + \
os.path.expanduser("~flo/flightgear/install-git/lib64")}}

CONF_GIT_DBG = CONF_GIT.copy()
CONF_GIT_DBG["ffgo config"] = CONF_GIT_DBG["ffgo config"].copy()
CONF_GIT_DBG["ffgo config"]["FG_BIN"] = os.path.expanduser(
"~flo/flightgear/install-git.debug/bin/fgfs")
CONF_GIT_DBG["envvar prepend"] = {
"LD_LIBRARY_PATH": os.path.expanduser(
"~flo/flightgear/install-git.debug/lib") + ":" + \
os.path.expanduser("~flo/flightgear/install-git.debug/lib64")}

CONFIGS = {"3.4": CONF_34,
"git": CONF_GIT,
"git-dbg": CONF_GIT_DBG}


def processCommandLine():
params = argparse.Namespace()

parser = argparse.ArgumentParser(
usage="""\
%(prog)s [OPTION ...] CONFIG [FFGO_ARG ...]
Start FFGo using the profile specified with CONFIG.""",
description="""\
This program rewrites '~/.ffgo/config' with some particular values obtained
from CONFIG. See CONF_34, CONF_GIT, and CONF_GIT_DBG in the script code to see
how it works. It can also modify particular environment variables depending on
the chosen CONFIG before starting FFGo.

Each configuration must be defined as a value of the CONFIGS dictionary
defined in this script. The CONFIG argument must be a key of the CONFIGS
dictionary. The value for that key determines which configuration to use. For
instance, with:

CONFIGS = {"3.4": CONF_34,
"git": CONF_GIT,
"git-dbg": CONF_GIT_DBG}

passing "git" as the CONFIG argument will select the configuration defined by
the CONF_GIT variable (itself defined in this script).

Before the rewriting of '~/.ffgo/config' is started, this file is always
backed up as '~/.ffgo/config.flo-ffgo-launcher-bak'.""",
formatter_class=argparse.RawDescriptionHelpFormatter,
# I want --help but not -h (it might be useful for something else)
add_help=False)

parser.add_argument('config', metavar="CONFIG", choices=("3.4", "git",
"git-dbg"),
help="""name of FFGo/FlightGear configuration""")
parser.add_argument('ffgo_args', metavar="FFGO_ARG", nargs='*',
help="""arguments to pass to FFGo""")
parser.add_argument('--help', action="help",
help="display this message and exit")

params = parser.parse_args(namespace=params)

return params


def updateConfigFile(config):
origFilePath = os.path.expanduser("~/.ffgo/config")
if not os.path.isfile(origFilePath):
return

tmpFilePath = "{}.{}-new".format(origFilePath, progname)
CUT_LINE = ' INTERNAL OPTIONS ABOVE. EDIT CAREFULLY! '.center(80, 'x')

try:
with open(origFilePath, "r", encoding="utf-8") as origFile, \
open(tmpFilePath, "w", encoding="utf-8") as tmpFile:
foundCutLine = False

for line in origFile:
if line.strip() == CUT_LINE:
foundCutLine = True

if not foundCutLine:
for prefix, value in CONFIGS[config]["ffgo config"].items():
if line.startswith(prefix + "="):
tmpFile.write("{}={}\n".format(prefix, value))
break
else:
tmpFile.write(line)
else:
tmpFile.write(line)

os.rename(origFilePath, "{}.{}-bak".format(origFilePath, progname))
os.rename(tmpFilePath, origFilePath)
finally:
if os.path.isfile(tmpFilePath):
os.unlink(tmpFilePath)


def computeEnvironment(config):
newEnv = os.environ.copy()

for var, value in CONFIGS[config]["envvar prepend"].items():
try:
currentVal = os.environ[var]
except KeyError:
newEnv[var] = value
else:
newEnv[var] = value + ":" + currentVal

return newEnv


def main():
global params

locale.setlocale(locale.LC_ALL, '')
params = processCommandLine()

updateConfigFile(params.config)
newEnviron = computeEnvironment(params.config)

program = os.path.expanduser("~flo/src/python/ffgo/ffgo.git/ffgo-launcher.py")
os.execvpe(program, [program] + params.ffgo_args, newEnviron)

sys.exit(0)

if __name__ == "__main__": main()

Running 'flo-ffgo-launcher --help' gives basic indications on how it works. To edit your profiles, you'll have to edit the script itself, but it's rather simple, you'll see. You'll also have to edit the line towards the end:
Code: Select all
program = os.path.expanduser("~flo/src/python/ffgo/ffgo.git/ffgo-launcher.py")

that defines the path of the ffgo-launcher.py script to run (this one is part of FFGo).

Beware that the forum software's SELECT ALL function doesn't work well, I believe. However, selecting the script contents yourself from the code block should work fine.

Maybe I'll implement this profile thing in FFGo, but for now this script is your best option IMHO. It only overrides a few specific variables in the top part of ~/.ffgo/config, therefore I consider it quite safe even though I agree it is a kind of a workaround for missing “profile management” in FFGo.

(*) You can selectively modify environment variables depending on the chosen profile, and it's very easy to mechanically derive a profile from another profile, only changing a few things. This was easy to implement because it is done in Python code you can freely edit, but such flexibility would be hard, if not impossible to present in a GUI-only way.
rominet
 
Posts: 548
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Wed Mar 02, 2016 9:31 pm

Interesting finding...
Code: Select all
~/flightgear/src/fgdata % date
Wed Mar  2 22:04:05 CET 2016
~/flightgear/src/fgdata % stg branch
heli
~/flightgear/src/fgdata % ll Airports/apt.dat.gz && sha1sum Airports/apt.dat.gz
-rw-r--r-- 1 flo users 27350016 Feb 21 12:14 Airports/apt.dat.gz
57c622f93402ffa2447281e00f476938bdb07b29  Airports/apt.dat.gz
~/flightgear/src/fgdata % stg branch next
Checking for changes in the working directory ... done
Switching to branch "next" ... done
~/flightgear/src/fgdata % ll Airports/apt.dat.gz && sha1sum Airports/apt.dat.gz
-rw-r--r-- 1 flo users 27183797 Mar  2 22:04 Airports/apt.dat.gz
515944a5927700aca75f80c3d03476f4e0ee99a0  Airports/apt.dat.gz
~/flightgear/src/fgdata % stg branch heli
Checking for changes in the working directory ... done
Switching to branch "heli" ... done
~/flightgear/src/fgdata % ll Airports/apt.dat.gz && sha1sum Airports/apt.dat.gz
-rw-r--r-- 1 flo users 27350016 Mar  2 22:05 Airports/apt.dat.gz
57c622f93402ffa2447281e00f476938bdb07b29  Airports/apt.dat.gz
~/flightgear/src/fgdata % stg branch frougon
Checking for changes in the working directory ... done
Switching to branch "frougon" ... done
~/flightgear/src/fgdata % ll Airports/apt.dat.gz && sha1sum Airports/apt.dat.gz
-rw-r--r-- 1 flo users 27350016 Mar  2 22:05 Airports/apt.dat.gz
57c622f93402ffa2447281e00f476938bdb07b29  Airports/apt.dat.gz
~/flightgear/src/fgdata %

This means that, when switching to another branch of the FGData repository (managed by StGit or Git only) causes Airports/apt.dat.gz to be changed (custom scenery additions, or returning to the official apt.dat.gz from FGData in its 'next' branch), then:
  • the apt.dat.gz timestamp (mtime) is set to the current date and time, but;
  • the actual file contents doesn't change compared to how it was previously on the same branch (i.e., no timestamp internal to the gzip file spoiling the hash because of recompression—probably there is no recompression at all in such a case, which would explain)
As a consequence, the approach using a hash of apt.dat.gz instead of its timestamp to detect when it has been modified is viable.

Now I'm thinking of maybe implementing this whole profile thing directly in FFGo (no wrapper script), migrating the config file to JSON format for the currently-top part corresponding to profile data, and to raw CondConfigParser format for the bottom part of current ~/.ffgo/config. It is still open whether this bottom part should be shared by all profiles or be profile-specific.
rominet
 
Posts: 548
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Tue Mar 15, 2016 12:20 am

Hello,

I am pleased to announce the release of FFGo 1.11.0. The main changes since version 1.10.1 are:
  • New Pressure Converter dialog (see screenshot below). This dialog, accessible from the Tools menu, allows one to quickly convert a pressure value from inches of mercury (inHg) to hectopascals (hPa) and vice versa. This is useful when the QNH value obtained from METAR or ATIS (the “altimeter setting”) is not in a unit that is directly usable with your aircraft's instruments.
  • Help menu: new entry (Show available fgfs options) to show the output of 'fgfs --help --verbose'. This allows one to easily see (a subset of) what can be put in the Options Window (command-line options such as --enable-fullscreen or --disable-hud-3d). See screenshot below.
  • Fix state management for the runway and parking buttons. With the default, empty config (FG_ROOT config parameter not filled, etc.), clicking on either the runway or the parking button was possible, but triggered an error (a harmless one, though). FFGo now ensures that said buttons are disabled when appropriate.
  • Use a color suitable for prolonged reading when displaying potentially long texts (e.g., the FFGo help file accessible from the Help menu, or Show available fgfs options in the same menu).
  • Improve the documentation concerning FFGo installation (docs/INSTALL/INSTALL_en and FFGo's page on the FlightGear wiki). Among other changes, there is now a precise description of how to install MagneticField on Windows. Thanks to jaxsin for testing things on Windows and reporting.
  • Don't attempt to run FlightGear if Config.FG_bin (config parameter that defines the FlightGear executable) is empty or whitespace-only. Rather, display a helpful message.
  • Add commented-out property settings for anti-aliasing to the default FlightGear options. The commented-out lines are:
    Code: Select all
    --prop:/sim/rendering/multi-sample-buffers=true

    and
    Code: Select all
    --prop:/sim/rendering/multi-samples=4

    as mentioned on the Anti-aliasing page of the FG wiki. Thanks to jaxsin for the suggestion.
  • Update other comments in the default FlightGear options:
  • Improve or polish several dialog boxes, tooltip texts and labels.
  • Update the German translation. (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.

Screenshot of the Pressure Converter dialog:
Image
Screenshot of the first page displayed by Show available fgfs options from the Help menu:
Image
rominet
 
Posts: 548
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby chris_blues » Tue Mar 15, 2016 1:07 am

Congrats for the new release! Reading about the new --options again, it occurred to me to simply expose my options list, so that maybe you or someone else may find some options worthwhile, maybe even integrate some into the standard FFGo options window. I really don't know, which one of them would be such a thing, so here it comes in all its glory: :D
Code: Select all
--terrasync-dir=/path/to/scenery/terrasync/
--enable-terrasync

# Walker Addon:
#--config=/media/FG/git/install/flightgear/fgdata/Aircraft/Generic/Human/Include/walker-include.xml
#--enable-rembrandt

--callsign=foo-bar
## for testing mp issues with 2 FG instances:
#--multiplay=out,10,127.0.0.1,5000 --multiplay=in,10,127.0.0.1,5001 --callsign=Test1
--enable-real-weather-fetch
#--enable-fullscreen

--season=winter
#--timeofday=dawn
#--timeofday=morning
#--timeofday=afternoon
#--timeofday=evening
#--timeofday=dusk
#--timeofday=midnight

--prop:/sim/paths/use-custom-scenery-data=true
--prop:/sim/view/config/default-field-of-view-deg=75
--prop:/controls/gear/brake-parking=1
--prop:/sim/ai-traffic/enabled=false
--prop:/sim/traffic-manager/enabled=false
--prop:/sim/atc/enabled=false
--trim
--prop:/sim/rendering/multi-sample-buffers=true
--prop:/sim/rendering/multi-samples=4
#--com1=122.750
--bpp=32
--prop:/sim/menubar/autovisibility/enabled=1
--prop:/sim/rendering/transition-shader=1

--prop:/sim/rendering/multithreading-mode=AutomaticSelection
--httpd=8080

#--log-level={bulk,debug,info,warn,alert}
#--log-level=bulk
#--parkpos=AVAILABLE

I've generalized some personal items, but that's about it. Hope this is helpful to someone...

Cheers
chris

P.S. maybe that time-of-day thing would fit nicely in a small dropdown?
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian testing 64bit - Athlon II 2x2.6GHz - 8GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
 
Posts: 1526
Joined: Mon May 03, 2010 1:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian 8 64

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Tue Mar 15, 2016 10:19 pm

Hi chris,

Thanks for sharing your options. I don't want to add too many in the default config, to avoid making things look too complicated to new users, and also because with time some options become deprecated or undesirable, and I suspect people keep the options around that they don't use "just in case"... till the end of times. :wink:

Some of the options you gave are already present (and commented out, as all options of the default config currently). This is the case for --enable-terrasync, --terrasync-dir, --callsign, --enable-fullscreen, --season and --timeofday.

You have a commented-out loading of properties for the “Walker Addon”: dunno, never tested that.

One that looks interesting to me is:
Code: Select all
## for testing mp issues with 2 FG instances:
#--multiplay=out,10,127.0.0.1,5000 --multiplay=in,10,127.0.0.1,5001

I've never done that, but I suppose one instance uses 5000...5001 and the other 5001...5000, right? This is clearly intended for aircraft developers, but as the recent ec130b4 thread showed, it is something that can be quite useful from time to time (of course, I would use two different user accounts to start the two FG instances, otherwise there is a high risk of corrupting files such as the navdata cache and the autosave file, I think).

--enable-real-weather-fetch: I think this is the default as long as you are connected to the Internet -> not needed anymore IMHO (which is why I removed it from the default config, as it was present in FGo!).

--prop:/sim/paths/use-custom-scenery-data=true: as far as I can tell, this is not used anywhere in FG (anymore).

--prop:/sim/view/config/default-field-of-view-deg=75: interesting...

--prop:/controls/gear/brake-parking=1: what is it useful for? Always start with parking break regardless of the aircraft defaults?..

--prop:/sim/ai-traffic/enabled=false: seems redundant with, and more "internal stuff, don't touch yourself unless you know what you are doing" than --disable-ai-traffic. If someone knows better, please speak up.

--prop:/sim/traffic-manager/enabled=false: hmm, what is the difference?

--prop:/sim/atc/enabled=false: no idea either. Is it to disable the interactive, text-based ATC stuff present in FG (and not working very well AFAIK)?

--trim: what does it do? 'fgfs --help --verbose' only says “Trim the model (only with fdm=jsbsim)”. Yeah, thank you so much.

--prop:/sim/rendering/multi-sample-buffers=true
--prop:/sim/rendering/multi-samples=4
Both are in the new default config for version 1.11.0 (commented out).

--bpp: OK...

--prop:/sim/menubar/autovisibility/enabled=1: interesting. I am used to activate this via the in-sim menu, but this has the annoying problem of being reset every time one upgrades FG. I suppose this way prevents this little upgrade annoyance.

--prop:/sim/rendering/transition-shader=1: Hmm, what does it do?..

--prop:/sim/rendering/multithreading-mode=AutomaticSelection: maybe good for you, but probably too intrusive/risky for defaults IMHO (or, well, maybe with "AutomaticSelection" it is just a long and complicated way of saying "please give me the default" :lol:).

--httpd=8080: unless you are connecting to this HTTP server from another computer, I recommend you to use --httpd=127.0.0.1:8080 instead. Less exposure to the wild and hostile world... (I don't use it personally, because I believe it has a significant impact on frame rate, unfortunately)

--log-level={bulk,debug,info,warn,alert}
OK, there is also --log-class to go with these. Help -> Show available fgfs options in FFGo 1.11.0 can be useful to know which classes are allowed here...

--parkpos=AVAILABLE: this was a nice idea, but IIRC the work needed for that has never been finished. Any evidence of the contrary?

As for the dropdown list for --timeofday, well, not sure this warrants the space that would be needed in the interface. It's relatively easy to enter in the Options Window, and quite easy to change in-sim. Also, with the new behavior of the t/T key in FG, one can get hugely better granularity than just dawn/morning/noon/etc. and with realtime visual feedback, at that. Did ou try it recently? :)
rominet
 
Posts: 548
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby chris_blues » Wed Mar 16, 2016 10:25 pm

rominet wrote in Tue Mar 15, 2016 10:19 pm:You have a commented-out loading of properties for the “Walker Addon”: dunno, never tested that.

This starts the walker, built into $FGDATA. It's a nice feature for those aircraft, that don't already got it installed by default.

rominet wrote in Tue Mar 15, 2016 10:19 pm:One that looks interesting to me is:
Code: Select all
## for testing mp issues with 2 FG instances:
#--multiplay=out,10,127.0.0.1,5000 --multiplay=in,10,127.0.0.1,5001

I've never done that, but I suppose one instance uses 5000...5001 and the other 5001...5000, right? This is clearly intended for aircraft developers, but as the recent ec130b4 thread showed, it is something that can be quite useful from time to time (of course, I would use two different user accounts to start the two FG instances, otherwise there is a high risk of corrupting files such as the navdata cache and the autosave file, I think).

Yes exactly. This is the one instance to test mp stuff. I always open the other one in my old FGo installation, which got the numbers (5000 5001) reversed. Now I can see the mp model of the other instance.

rominet wrote in Tue Mar 15, 2016 10:19 pm:--enable-real-weather-fetch: I think this is the default as long as you are connected to the Internet -> not needed anymore IMHO (which is why I removed it from the default config, as it was present in FGo!).

Well this one was a workaround for local weather, which is nowadays called detailed weather. Some settings needed this option to be set. I don't remember why or what - and I never bothered to check, if it's still needed...

rominet wrote in Tue Mar 15, 2016 10:19 pm:--prop:/sim/view/config/default-field-of-view-deg=75: interesting...

On my 1920x1080 screen this looks much better. I can see some instruments without having to fiddle in the property-browser. Because every time you look around (aka move the view), when you click it snaps back to forward view and default-field-of-view. If it's set to sth else (most aircraft set this to some value) I only see the top-most instrument borders and a lot of scenery...

rominet wrote in Tue Mar 15, 2016 10:19 pm:--prop:/controls/gear/brake-parking=1: what is it useful for? Always start with parking break regardless of the aircraft defaults?..

Exactly! Very annoying, if you fire up FG, and during the time it starts up, you go have a pee, or do sth else, come back and see your aircraft pointing into the sky. While you've been gone it has rolled backwards down the runway, the airport greens, and down the cliff... :evil:

rominet wrote in Tue Mar 15, 2016 10:19 pm:--prop:/sim/ai-traffic/enabled=false: seems redundant with, and more "internal stuff, don't touch yourself unless you know what you are doing" than --disable-ai-traffic. If someone knows better, please speak up.
--prop:/sim/traffic-manager/enabled=false: hmm, what is the difference?
--prop:/sim/atc/enabled=false: no idea either. Is it to disable the interactive, text-based ATC stuff present in FG (and not working very well AFAIK)?
--trim: what does it do? 'fgfs --help --verbose' only says “Trim the model (only with fdm=jsbsim)”. Yeah, thank you so much.
--prop:/sim/rendering/multi-sample-buffers=true
--prop:/sim/rendering/multi-samples=4
Both are in the new default config for version 1.11.0 (commented out).
--bpp: OK...

These all are from various experiments, wiki pages, forum discussions etc. How to make sure, this AI/ATC/other stuff won't interfere with my flight...

rominet wrote in Tue Mar 15, 2016 10:19 pm:--prop:/sim/menubar/autovisibility/enabled=1: interesting. I am used to activate this via the in-sim menu, but this has the annoying problem of being reset every time one upgrades FG. I suppose this way prevents this little upgrade annoyance.

Spot on. I was annoyed and since then this line has stayed with me...

rominet wrote in Tue Mar 15, 2016 10:19 pm:--prop:/sim/rendering/transition-shader=1: Hmm, what does it do?..

Hmm, IIRC this was some experimaental shader back then. Don't know if it even exists anymore. Maybe it has grown into ubershader, maybe it's still there.

rominet wrote in Tue Mar 15, 2016 10:19 pm:--prop:/sim/rendering/multithreading-mode=AutomaticSelection: maybe good for you, but probably too intrusive/risky for defaults IMHO (or, well, maybe with "AutomaticSelection" it is just a long and complicated way of saying "please give me the default" :lol:).

This is an OSG-switch. It enables FG to use more than one CPU, GPU etc... Putting it on automatic is the safe way. You could put it to sth like enable CullPerThread and such, but that's the line I never crossed. I was warned not to touch sth other than automatic, unless I was a 3d/OpenGL guru, who knows what he's doing. Well obviously I'm not! :)

rominet wrote in Tue Mar 15, 2016 10:19 pm:--httpd=8080: unless you are connecting to this HTTP server from another computer, I recommend you to use --httpd=127.0.0.1:8080 instead. Less exposure to the wild and hostile world... (I don't use it personally, because I believe it has a significant impact on frame rate, unfortunately)

I don't see any difference in performance with this. I got a router, so there won't be any port-forwardings to this host anyway. I usually fly with my desktop machine and have a browser open on my laptop, to see some useful data, airport data, frequencies...

rominet wrote in Tue Mar 15, 2016 10:19 pm:--log-level={bulk,debug,info,warn,alert}
OK, there is also --log-class to go with these. Help -> Show available fgfs options in FFGo 1.11.0 can be useful to know which classes are allowed here...

--parkpos=AVAILABLE: this was a nice idea, but IIRC the work needed for that has never been finished. Any evidence of the contrary?

Yes, a pity this didn't make it to completion. This is IMHO one of the most useful additions I could think of. Spawn your aircraft on a suitable parking spot. The optimist in me voted for keeping this option... :roll:

rominet wrote in Tue Mar 15, 2016 10:19 pm:As for the dropdown list for --timeofday, well, not sure this warrants the space that would be needed in the interface. It's relatively easy to enter in the Options Window, and quite easy to change in-sim. Also, with the new behavior of the t/T key in FG, one can get hugely better granularity than just dawn/morning/noon/etc. and with realtime visual feedback, at that. Did ou try it recently? :)

No, haven't played much with this, but this big list of options, with only one of them uncommented is very annoying. On the other hand I'm much too lazy to always look up the possible values. A dropdown would take up a very small box, whereas these lines take up much more...

Anyway, thanks for your comments - made me think about cleaning up a little on my options list...
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian testing 64bit - Athlon II 2x2.6GHz - 8GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
 
Posts: 1526
Joined: Mon May 03, 2010 1:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian 8 64

Re: Announcing FFGo: a new FlightGear launcher

Postby jaxsin » Thu Mar 17, 2016 12:45 am

The --trim option for JSBsim is for when the airplane is initially placed on the runway or ground I believe. I have a local airport that is sort of on a hill in FG and when the Cessna is loaded you get a trim error message in console. So it seems to have to do with placement on un-level surfaces? Not really sure, erik would be the one to ask.
jaxsin
 
Posts: 396
Joined: Mon Dec 28, 2015 3:54 pm

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Fri Mar 18, 2016 9:31 am

I'll probably add the #--multiplay=out,10,127.0.0.1,5000 --multiplay=in,10,127.0.0.1,5001 example to the default config, because I think the more aircraft developers know about it, the better their models are likely to be MP-wise.

Just for the record, related to --enable-real-weather-fetch: I still believe it is not useful anymore, but according to llsouder, --disable-real-weather-fetch is useful to have --metar work...

chris_blues wrote in Wed Mar 16, 2016 10:25 pm:
rominet wrote in Tue Mar 15, 2016 10:19 pm:--prop:/sim/view/config/default-field-of-view-deg=75: interesting...

On my 1920x1080 screen this looks much better. I can see some instruments without having to fiddle in the property-browser. Because every time you look around (aka move the view), when you click it snaps back to forward view and default-field-of-view. If it's set to sth else (most aircraft set this to some value) I only see the top-most instrument borders and a lot of scenery...

For a similar purpose, I use this patch to allow easy saving and reloading custom persistent views with keyboard shortcuts. So, usually when starting with an aircraft, I save the default view with Windows-F1, then my preferred “general” view with Windows-F2 and a few other views that seem useful, then restart FG (the patch in its current state only saves views when FG is quit). Starting from this point, I can recall the aircraft default view with Ctrl-F1, my preferred “general” view with Ctrl-F2, and so on. This is very convenient, especially for views that take time to tune, as when you want to watch the cabin temperature in the c172p.
Note: all views are saved per-aircraft in $FG_HOME/aircraft-data/<aircraft>-views.xml.
chris_blues wrote in Wed Mar 16, 2016 10:25 pm:if you fire up FG, and during the time it starts up, you go have a pee

I see :lol:. Especially if, like the extra500, it then says you threw x thousand dollars out of the window!

Concerning --prop:/sim/menubar/autovisibility/enabled=1: since you are unlikely to want to switch it on or off depending on the particular aircraft/flight/etc., one good way IMHO to declutter your FFGo Options Window is to put this setting in a file such as $FG_HOME/YourName/my-preferences.xml that looks like this:
Code: Select all
<?xml version="1.0" encoding="UTF-8"?>

<PropertyList>
  <sim>
    <menubar>
      <autovisibility>
        <enabled type="bool">true</enabled>
      </autovisibility>
    </menubar>
  </sim>
</PropertyList>

and then load this file with the following fgfs option:
Code: Select all
--config=/home/you/.fgfs/YourName/my-preferences.xml

This way, such settings can even by trivially shared with other launchers or used on the fgfs command line, by simply passing --config=/home/you/.fgfs/YourName/my-preferences.xml. For the record, the complete contents of this file in my case is:
Code: Select all
<?xml version="1.0" encoding="UTF-8"?>

<PropertyList>
  <sim>
    <menubar>
      <autovisibility>
        <enabled type="bool">true</enabled>
      </autovisibility>
    </menubar>
  </sim>
<!-- Inspired by <http://forum.flightgear.org/viewtopic.php?f=25&t=26145> -->
  <gui>
    <map>
      <aircraft-heading-up type="string" userarchive="y">0</aircraft-heading-up>
      <centre-on-aircraft type="bool" userarchive="y">true</centre-on-aircraft>
      <draw-data type="bool" userarchive="y">false</draw-data>
      <draw-fixes type="string" userarchive="y">1</draw-fixes>
      <draw-flight-history type="bool" userarchive="y">false</draw-flight-history>
      <draw-navaids type="string" userarchive="y">1</draw-navaids>
      <draw-traffic type="string" userarchive="y">1</draw-traffic>
      <magnetic-headings type="bool" userarchive="n">true</magnetic-headings>
      <transparent type="string" userarchive="y">1</transparent>
      <!-- <zoom type="int" userarchive="n">5</zoom> -->
    </map>
  </gui>

  <input>
    <keyboard>

      <key n="265">
        <name>F9</name>
        <desc>Toggle pilot list</desc>
        <binding>
          <command>nasal</command>
          <script>multiplayer.dialog.toggle()</script>
        </binding>
        <!-- Commented out for now
             binding>
             <command>dialog-show</command>
             <dialog-name>chat-full</dialog-name>
             </binding -->
      </key>

    </keyboard>
  </input>

</PropertyList>

(I have put only one keyboard shortcut here, but I think it is a good way to override most keyboard shortcuts without having to patch $FG_ROOT/keyboard.xml—which obviously causes hassles if you are using the FGData Git repo, or when just upgrading FG).

About --httpd=8080 or --httpd=127.0.0.1:8080:
chris_blues wrote in Wed Mar 16, 2016 10:25 pm:I don't see any difference in performance with this.

It seems you are right on this point. At least static testing with the 707 on the 02 runway at LEBL in FG 2016.2.0 doesn't show any noticeable difference in fps for me. That is good news. :)

All in all, I think I may add commented out options to the default config for:
  • The --multiplay option allowing to test multiplayer stuff with one computer only and without going through the MP servers;
  • the --httpd option to start Phi;
  • Maybe an example of --disable-real-weather-fetch in conjunction with a --metar=... sample option, for those who want to repeatedly practice landings or whatever they want in particular weather conditions.

I don't want to add too many, otherwise it is likely to frighten newcomers if they think they have to read and understand all these things (plus, it's a kind of a pain to translate, as you know :wink:, and such comments/options are likely to remain in users' configs for a very long time even after being deprecated on the FG side).

I don't claim the rest is useless, not at all, but IMO its place is not in the default config (and I don't claim you claimed it all had to go in the default config!). I'm thinking that, if you want to share these other options with other users, e.g., the one that may save your life when you have to pee or so :lol:, then maybe a section such as “User selection of options” or “User favorites”, or “User tips”, at the end of http://wiki.flightgear.org/Command_line_options would do well. Contrary to the official documentation of these options—which doesn't necessarily exist for properties, BTW—you would be free to explain your use cases in all their glorious context. :lol:

Concerning the dropdown list for --timeofday:
chris_blues wrote in Wed Mar 16, 2016 10:25 pm:No, haven't played much with this, but this big list of options, with only one of them uncommented is very annoying. On the other hand I'm much too lazy to always look up the possible values. A dropdown would take up a very small box, whereas these lines take up much more...

One possibility to use less space is to write it as:
Code: Select all
--timeofday=noon # dawn,morning,noon,afternoon,evening,dusk,midnight

Granted, you have to do a bit more than just add or remove a comment char (#) in this case, but this saves a few lines.

But I also have a space problem with your suggestion. On my 1920x1080 screen, the FFGo main window fills the whole screen in font size 12. There isn't much space to add anything without reducing something else or making things look ugly. And I don't like the idea of having to check several tabs or windows in order to choose or verify the essential parameters before starting FG. I have no problem with the Airport Finder or GPS Tool or whatever dialogs I added recently, because they have no influence whatsoever on the fgfs parameters, thus you don't have to check these Windows before starting FG.

One way to add the feature while respecting these constraints, if it's really deemed useful to be able to set the time of day via a GUI control, would be to have a separate window reachable from a menu that, by default, wouldn't influence the --timeofday option at all, but would override it when the user does "click click" in the window in question to select a particular time of day. This would certainly work, but I don't see much gain compared to just starting FG and changing the time via Environment -> Time settings...
jaxsin wrote in Thu Mar 17, 2016 12:45 am:The --trim option for JSBsim is for when the airplane is initially placed on the runway or ground I believe. I have a local airport that is sort of on a hill in FG and when the Cessna is loaded you get a trim error message in console. So it seems to have to do with placement on un-level surfaces? Not really sure, erik would be the one to ask.

Uhhhm, okay... Thanks for your comment.
rominet
 
Posts: 548
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby chris_blues » Fri Mar 18, 2016 12:41 pm

rominet wrote in Fri Mar 18, 2016 9:31 am:All in all, I think I may add commented out options to the default config for:
  • The --multiplay option allowing to test multiplayer stuff with one computer only and without going through the MP servers;

What came to mind here is, that you also need two different callsigns for that to work. I usually take "test1" and "test2". Maybe should be mentioned in the comment.

rominet wrote in Fri Mar 18, 2016 9:31 am:But I also have a space problem with your suggestion. On my 1920x1080 screen, the FFGo main window fills the whole screen in font size 12. There isn't much space to add anything without reducing something else or making things look ugly.

:shock: You use it fullscreen? I have FFGo take up about half of the screen horizontally and 100% vertically. and I have plenty space. Maybe the font size... I have it set to zero(default).
Anyway, I don't mind too much if you don't want to put it in the gui. Just an idea. :)

I hope tonight I'll have time to respond to your mail... :roll:

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

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Fri Mar 18, 2016 2:07 pm

Roger concerning the need for two different callsigns for the --multiplay trick. I'll put it in the comment.
chris_blues wrote in Fri Mar 18, 2016 12:41 pm: :shock: You use it fullscreen? I have FFGo take up about half of the screen horizontally and 100% vertically. and I have plenty space. Maybe the font size... I have it set to zero(default).

Yes, I need font size 12 approximately(*), and this takes the whole screen (of course, you can reduce the window size, as the layout is implemented with a proper layout manager instead of pixel-positioning, but if you reduce it too much, it becomes too narrow to see full lines in the Options Window or the Output Window—there are scrollbars but relying on them a lot is very inconvenient).
chris_blues wrote in Fri Mar 18, 2016 12:41 pm:Anyway, I don't mind too much if you don't want to put it in the gui. Just an idea. :)

Okay... It's not completely ruled out. In fact, looking a bit better, there is some space that could maybe be used without affecting other areas: the large ribbon that gives the status with respect to the fgfs process (whether it is running or not; last exit status or killing signal). One would have to think a bit to find the less odd-looking place for a time setting here... Otherwise, the separate dialog I mentioned.

For now, the priorities are:
  1. Some RL stuff;
  2. Profile management. I have already started to think about it (wow). One part that needs some thought is where to draw the line between general settings and profile-specific settings. And to avoid user confusion, this will require splitting the current Preferences dialog into two, let's say General preferences and Profile-specific settings—something like that. As a consequence, some of the documentation and help messages will have to be updated. And another Profiles menu entry will be needed too, I think, to allow creating, deleting, renaming and reordering profiles, as well as to allow switching to a new profile (in case you don't remember, the main purpose of these profiles is to allow convenient testing of several FG versions without having to use the wrapper script I sent to update the config on the fly, and without the need to rebuild the apt database/apt digest file “often” when switching between FG versions/installations). If pommesschranke is still interested, I can send a patch for the --ffgo-apt-path option in the meantime, which should be easy to add, but as profiles would make it obsolete, I preferred not to add it to FFGo.
After that, we'll see...
chris_blues wrote in Fri Mar 18, 2016 12:41 pm:I hope tonight I'll have time to respond to your mail... :roll:

There is no hurry... :wink:

Regards

(*) Making font sizes configurable is the first thing that made me work on FGo! rather than use FGRun. I had patched FGRun to change the font sizes, but this was very intrusive, as the pixel-positioning made it necessary to modify many, many places, and this had to be done for each new version, which was clearly unacceptable for me. I don't know if there would have been a better way, but being a Python fan, FGo! became the obvious choice despite my moderate dislike for Tkinter (and I immediately found FGo!'s UI design/“philosophy” much to my taste). </mylife>
rominet
 
Posts: 548
Joined: Sat Nov 01, 2014 1: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 1 guest