2018.3 Release

[pb321]

Just realized the Aircraft (experimental) option (I think that is what is was called) is no longer available in the File tab on the menu in the latest (final) 2018.3.1. This was a good way to change aircraft or location (especially parking) without exiting the simulator and re-loading, and it seemed to work pretty well. I know the objective of this release was to provide a "stable" version of FG, and I also know that feature resulted in a few crashes (at least it happened to me on occasion), but it usually saved time when a change in location or aircraft was desired in the middle of a flying session. Will it be brought back or has it been eliminated from future consideration? Personally, it will be missed.

[wkitty42]

that was the aircraft hanger... yes, it is disabled in the release... it is a subsection of the new launcher and there are problems with using it as the hanger in the sim at this time... when those problems are corrected, it will be re-enabled in the sim so you can change craft without having to exit and restart the whole thing...

[Hooray]

Just realized the Aircraft (experimental) option (I think that is what is was called) is no longer available in the File tab on the menu in the latest (final) 2018.3.1. This was a good way to change aircraft or location (especially parking) without exiting the simulator and re-loading, and it seemed to work pretty well. I know the objective of this release was to provide a "stable" version of FG, and I also know that feature resulted in a few crashes (at least it happened to me on occasion), but it usually saved time when a change in location or aircraft was desired in the middle of a flying session. Will it be brought back or has it been eliminated from future consideration? Personally, it will be missed.

You are probably referring to the original "Aircraft Center" Canvas dialog?


If so, that was created by the core developer who developed the Canvas system (TheTom) at the encouragement of FlightGear core developer James Turner and it is internally using only Nasal scripting code and the built-in 2D rendering API called "Canvas": http://wiki.flightgear.org/Aircraft_Center

Curt mentioned plans on extending the "in-app aircraft center":
http://sourceforge.net/p/flightgear/mai ... /33451055/

As we move forward with FlightGear development and future versions, we will be expanding the "in app" aircraft center. This dialog inside flightgear lets you select, download, and switch to any of the aircraft in the library.

At the same time, Torsten began working on Phi: http://wiki.flightgear.org/Phi

And when a number of people pointed out the potential overlap in functionality (referring to the package manager at the time), the generally-communicated consensus among core developers was that the back-end would be common, ie. shared by all potential front-ends that people may come up with, no matter if people decided to use Canvas, Phi or Qt5:

New Canvas GUI

There is currently heavy activity towards a new UI. There will be the HTML5 based version, I am currently working on and an internal implementation based on well supported libraries. Most likely, both will use a common service layer to provide necessary data.
Neither of those will use Nasal or Canvas to render the UI elements.

Torsten

A number of people (including a few core developers, e.g. F-JJTH/Clement) began using Nasal and Canvas to revamp the legacy UI, but ended up being actively discouraged by numerous long-term contributors, including a number of senior core developers.

Originally, the concern communicated in public was that re-doing a UI via Nasal and Canvas would be a tedious "mammoth task" and would end up being a huge waste of time and other community resources.

Subsequently, a new Qt5 based launcher was being prototyped (and in turn, the built-in aicraft center got disabled, but is still functional), but other core developers requested that new Qt5 component to remain entirely optional:

https://sourceforge.net/p/flightgear/ma ... /34196458/
http://wiki.flightgear.org/Integrated_Qt5_Launcher

There's been a strong devision of opinion among a couple of core
developers with respect to the question whether a QT dependency is
desirable or not. In one of the hangouts, a couple of months ago, we had
the chance to discuss the pros and cons, when the most outspoken
developers regarding this issue were both present. We concluded that a
QT dependency was undesirable, unless it had a specific benefit. With
this in mind, I proposed to consider the option of allowing a QT
dependency in only one module (call it FGGui). For all practical
purposes, this would be a platform independent replacement of fgrun, but
because of the proposed modularity, it will appear to be seamlessly
integrated with FlightGear. Both developers representing the opposite
ends of the debate could live with this compromise.

In parallel, I prototyped a simple (and experimental) Nasal/Canvas based parser to see how feasible a Canvas based PUI replacement would be (proof-of-concept, i.e. under 500 LOC):
http://wiki.flightgear.org/Pui2canvas


Later on, the only core developer intimately familiar with the process of revamping the UI and the corresponding subsystems, simply conceded that he didn't want any competition, and was concerned about a Nasal/Canvas based alternative de-railing his own C++/Qt5/QQ efforts, so that he would stop his work should someone decide to continue working on a Canvas based option:

https://sourceforge.net/p/flightgear/ma ... /36199572/

My impression is that if you make a Canvas UI option, the Qt based solution will be still-born almost by default - because I won’t be able to create any enthusiasm or interest around it. Maybe I’m wrong about that, but for sure Canvas based approaches attract a lot more support and man-power very easily. And my guess each person who works on the Canvas based Ui is one fewer who might ever help out with the Qt based one. (That is not probably 100% true, but I guess there is some correlation)

So I have taken your proposal as your intention to build a full-fleged UI in Canvas, because you believe it will be better than what I’m proposing - which is fine, but again, I don’t see it a good use of people’s lives to do that work twice (again, if I’d been Miguel de Icaza, I would have joined in with KDE or gone to write something else, not started GNOME).

https://sourceforge.net/p/flightgear/ma ... /36199712/

Well let’s say the Qt UI is 1/4 of my time per week spent on FG (might be a little more, but I have lots of other things to work on), vs Thorsten’s time and 4 or 8 enthusiastic people he can recruit - I’m obviously going to fall massively behind in comparison - within three or six months they might build a complete replacement UI.

Subject: Flightgear source code terminates in GLExtension.cpp

disabling Qt may also affect the in-sim Aircraft Center... there are instructions somewhere (wiki?) on what to change in the sources to use the old Aircraft Center if it is desired in one's FG... it is only a coupld of lines, IIRC...

Yes, that's absolutely correct, even though I don't think I added those instructions to the wiki, but there should be a corresponding forum topic, it's a fairly simple change actually only involving a few lines of Nasal code.

As far as I know, the real issue however is that I don't think the package manager stuff received much/any testing by people not using Qt-enabled builds, so there may be plenty of issues that we are unaware of, because the original "Aircraft Center" simply got phased out when the Qt launcher got added.

Originally, the plans announced on the devel list/forum (respectively) stated that the new UI would use a common service layer back-end that could also be used by other front-ends, including Phi, but I am not sure how much of this ever materialized or not.

In other words, I am not sure if it's even supposed to be possible to use a non-Qt enabled build (e.g. via Phi) to download/install and manage aircraft/scenery or not ?

Then again, technically there is really no reason why the same back-end could not be exposed via a CLI (Command Line Interface) so that non-Qt5 builds/users can still make use of the package manager back-end, especially if everything works through fgcommands - besides, this could be a great asset from a troubleshooting standpoint, i.e. people could run all sorts of tests in a scripted fashion to see if their aircraft can be easily downloaded/installed and configured, without requiring an interactive UI.

This could work analogous to the package manager on any modern Linux distro.

EDIT: The instructions on re-enabling the original Nasal/Canvas based Aircraft Center are to be found here: Subject: Reinstating Canvas based Aircraft Center for non Qt builds

Subject: Aircraft Center | pui2canvas parser (devel-list follow-up)

As for Qt being optional, over the last two years on the mailing list, that position has obviously evolved. I'm only stating what I see. And that is that it will be only optional for a tiny subset of people. The majority will use it, probably without knowing, as it will be the default GUI shipped with FG.

Just a little update, roughly ~12 months later, it seems indeed that bugman was right: the position on using Qt5 for the in-sim UI seems to have evolved (though, not exactly in line with bugman's original assertion a year ago):

https://sourceforge.net/p/flightgear/ma ... /35863607/

I would say do the PUI fix for now, I am still very much undecided about which technology to use for in-sim GUI. I am somewhat inclined towards using the Canvas, because it avoids some rendering issues (but exposes a few more, + some performance ones) but the problem is I am fairly unhappy with the GUI / widget API in the Canvas right now - it does not satisfy my ideas about how simple + robust such an API should be. I need to evaluate if the current API can be improved or needs to be drastically changed.

The other issue is to use QtQuick rendered into OpenGL, which has a very nice robust and well-designed API, but adds some dependencies and complicates the rendering architecture, which makes me nervous about multi-window setups and other more esoteric OSG configs.

So, yes, I’d say do PUI for now, since this is worth a fairly quick fix as it’s the default airport.

Kind regards,
James

The original forum topics covering these developments (linking back to the corresponding topics on the devel list) can still be looked up here:

• Subject: New Canvas GUI
• Aircraft Center | pui2canvas parser (devel-list follow-up)
• http://wiki.flightgear.org/Pui2canvas

[Hooray]

To be fair, the proposal to re-instate the Canvas based aircraft center was also discussed on the devel list, and James stated:


https://sourceforge.net/p/flightgear/ma ... /35149755/

I can make it fall back, except: my impression is that creating a GUI in Canvas was an experiment which didn’t get far enough along to become viable.

Hence, the canvas-based aircraft centre is effectively a dead-end, even if it works - I’d rather make the Qt GUI more usable (since it’s easy for me).

Do note though, that this whole "dead-end" thing and the simplicity of working on a Qt based solution have de-facto turned out to be a "red herring", because we still have builds that lack Qt support, and because the launcher is still rather fragile, despite these discussions having taken place over the course of 3+ years meanwhile.

But primarily, the "fix" for builds not having/wanting the Qt5 based aircraft center boils down to 5 lines of code that you'll need to add to the menubar.xml:

Subject: Reinstating Canvas based Aircraft Center for non Qt builds

That should be trivial to do by looking at the original patch/diff that disabled the original Canvas based aircraft center: https://sourceforge.net/p/flightgear/fg ... 152d12c2a/

If this is something that people with non-Qt enabled builds want to try, I would suggest to edit $FG_ROOT/gui/menubar.xml according to the following (untested):

Code: Select all

 <item>
                        <name>aircraft-center</name>
                        <binding>
                                <command>nasal</command>
                                <script><![CDATA[
                                # https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Main/fg_scene_commands.cxx#l360
                                var haveQtLauncher = fgcommand("open-launcher");
                                if (!haveQtLauncher) {
                                        # https://sourceforge.net/p/flightgear/fgdata/ci/654a343bbb7eb51b387060515e3415e152d12c2a/
                                        canvas.loadDialog("AircraftCenter");
                                }
                                ]]></script>
                        </binding>
                </item>


Freel free to test/report back here and share if this works or not.

Obviously, it would also be possible to run the heuristics during startup and patch the open-launcher fgcommand using the addCommand() API.

[pb321]

Thank you, wkitty42 and Hooray. I checked FG 2018.1.1 and found the feature I refer to is called "Aircraft Center (Experimental)" on the File tab. Clicking it opens a dialog box with Summary, Aircraft, Location, Environment and Fly! icons on the left sidebar, allowing one to change Aircraft, Location and Environment parameters without exiting the program and re-opening it.

Should also mention the nicely improved cloud formations in 2018.3.1 and, when flying yesterday, saw a rainbow in FlightGear...that's the first time I've seen one in any Flight Simulator!

[legoboyvdlp]

Hi,
That sounds like the aircraft center now redirects one back to the QT launcher..?

The QT launcher has those features that you described.

[Hooray]

correct, the original Nasal/Canvas based "aircraft center" (that would work for everyone, even for people not having access to a Qt enabled build) got declared "experimental", and was disabled in menubar.xml so that the "new" Qt based "aircraft center" would receive wider testing:

https://sourceforge.net/p/flightgear/ma ... /35149755/

Part of the reason for making this change was to get some feedback on how using the launcher inside the sim works

At the time, the funny/weird thing that caused quite a bit of irritation was to declare one working feature "experimental and obsolete" (without coordinating this with the people involved in creating that feature originally), in favor of another Qt based feature (read: required to be optional), that should also be considered "experimental" according to the commit logs:

https://sourceforge.net/p/flightgear/fg ... 152d12c2a/

Enable the Qt gui inside the sim.

Needs a lot of testing, but aircraft can be installed / changed and
location adjusted from within the sim. After some number of times the
sim will crash.

Rest assured though, you can be pretty sure that any Qt-based features will be restored to working order by the corresponding developer, the Qt stuff has been getting quite a bit of attention over the years.

[pb321]

Good to hear that Aircraft Center (Experimental) will return in a future version! Thank you all!

[danielHL]

I've build 2018.3 from sources on Linux (because I wanted to test it, but I couldn't find any 2018.3 precompiled Linux downloads). During startup, when it shows "initializing subsystems", it immediately shuts down and reports the following on the terminal:

Code: Select all

lucio@fx:~/programmi/flightgear/exe$ bin/fgfs
FlightGear:  Version 2018.3.1
FlightGear:  Build Type Dev
Built with GNU C++ version 8.2
Jenkins number/ID 0:none
Settings migrated: Saved settings were migrated from a previous version of FlightGear. If you encounter any problems when using the system, try restoring the default settings, before reporting a problem. Saved settings can affect the appearance, performance and features of the simulator.
FGPropertyManager::GetNode() No node found for hydro/active-norm
Error: caught signal 11:
  /lib/x86_64-linux-gnu/libc.so.6 : ()+0x35fc0
  /usr/lib/x86_64-linux-gnu/libstdc++.so.6 : __dynamic_cast()+0x17
  bin/fgfs : ()+0x1f0565f
  bin/fgfs : SGTextureStateAttributeVisitor::apply(int, std::map<std::pair<osg::StateAttribute::Type, unsigned int>, std::pair<osg::ref_ptr<osg::StateAttribute>, unsigned int>, std::less<std::pair<osg::StateAttribute::Type, unsigned int> >, std::allocator<std::pair<std::pair<osg::StateAttribute::Type, unsigned int> const, std::pair<osg::ref_ptr<osg::StateAttribute>, unsigned int> > > >&)+0x85
  bin/fgfs : SGTextureStateAttributeVisitor::apply(std::vector<std::map<std::pair<osg::StateAttribute::Type, unsigned int>, std::pair<osg::ref_ptr<osg::StateAttribute>, unsigned int>, std::less<std::pair<osg::StateAttribute::Type, unsigned int> >, std::allocator<std::pair<std::pair<osg::StateAttribute::Type, unsigned int> const, std::pair<osg::ref_ptr<osg::StateAttribute>, unsigned int> > > >, std::allocator<std::map<std::pair<osg::StateAttribute::Type, unsigned int>, std::pair<osg::ref_ptr<osg::StateAttribute>, unsigned int>, std::less<std::pair<osg::StateAttribute::Type, unsigned int> >, std::allocator<std::pair<std::pair<osg::StateAttribute::Type, unsigned int> const, std::pair<osg::ref_ptr<osg::StateAttribute>, unsigned int> > > > > >&)+0x64
  bin/fgfs : SGTextureStateAttributeVisitor::apply(osg::StateSet*)+0x43
  bin/fgfs : ()+0x1f0571f
  bin/fgfs : SGTextureStateAttributeVisitor::apply(osg::Geode&)+0x98
  /usr/lib/x86_64-linux-gnu/libosgDB.so.100 : osg::Geode::accept(osg::NodeVisitor&)+0x89
  /usr/lib/x86_64-linux-gnu/libosg.so.100 : osg::Group::traverse(osg::NodeVisitor&)+0x33
  bin/fgfs : osg::NodeVisitor::traverse(osg::Node&)+0x69
  bin/fgfs : SGTextureStateAttributeVisitor::apply(osg::Node&)+0x4f
  bin/fgfs : osg::Group::accept(osg::NodeVisitor&)+0x58
  /usr/lib/x86_64-linux-gnu/libosg.so.100 : osg::Group::traverse(osg::NodeVisitor&)+0x33
  bin/fgfs : osg::NodeVisitor::traverse(osg::Node&)+0x69
  bin/fgfs : SGTextureStateAttributeVisitor::apply(osg::Node&)+0x4f
  bin/fgfs : osg::Group::accept(osg::NodeVisitor&)+0x58
  /usr/lib/x86_64-linux-gnu/libosg.so.100 : osg::Group::traverse(osg::NodeVisitor&)+0x33
  bin/fgfs : osg::NodeVisitor::traverse(osg::Node&)+0x69
  bin/fgfs : SGTextureStateAttributeVisitor::apply(osg::Node&)+0x4f
  bin/fgfs : osg::Group::accept(osg::NodeVisitor&)+0x58
  /usr/lib/x86_64-linux-gnu/libosg.so.100 : osg::Group::traverse(osg::NodeVisitor&)+0x33
  bin/fgfs : osg::NodeVisitor::traverse(osg::Node&)+0x69
  bin/fgfs : SGTextureStateAttributeVisitor::apply(osg::Node&)+0x4f
  bin/fgfs : osg::Group::accept(osg::NodeVisitor&)+0x58
  bin/fgfs : simgear::OptimizeModelPolicy::optimize(osg::Node*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x8b
  bin/fgfs : ACOptimizePolicy::optimize(osg::Node*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x31
  bin/fgfs : simgear::ModelRegistryCallback<ACProcessPolicy, simgear::DefaultCachePolicy, ACOptimizePolicy, simgear::OSGSubstitutePolicy, simgear::BuildLeafBVHPolicy>::readNode(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x26e
  bin/fgfs : simgear::ModelRegistry::readNode(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x139
  /usr/lib/x86_64-linux-gnu/libosgDB.so.100 : osgDB::readNodeFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x1c1
  bin/fgfs : ()+0x1f23f94
  bin/fgfs : simgear::SGReaderWriterXML::readNode(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*) const+0x11b
  bin/fgfs : simgear::ModelRegistryCallback<simgear::DefaultProcessPolicy, simgear::NoCachePolicy, simgear::NoOptimizePolicy, simgear::NoSubstitutePolicy, simgear::BuildLeafBVHPolicy>::loadUsingReaderWriter(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x90
  bin/fgfs : simgear::ModelRegistryCallback<simgear::DefaultProcessPolicy, simgear::NoCachePolicy, simgear::NoOptimizePolicy, simgear::NoSubstitutePolicy, simgear::BuildLeafBVHPolicy>::readNode(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x186
  bin/fgfs : simgear::ModelRegistry::readNode(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x139
  /usr/lib/x86_64-linux-gnu/libosgDB.so.100 : osgDB::readRefNodeFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, osgDB::Options const*)+0x1d1
  bin/fgfs : ()+0x1eaa59e
  bin/fgfs : simgear::SGModelLib::loadModel(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, SGPropertyNode*, simgear::SGModelData*, bool)+0x193
  bin/fgfs : ()+0x156734d
  bin/fgfs : FGAircraftModel::init()+0x483
  bin/fgfs : SGSubsystem::incrementalInit()+0x23
  bin/fgfs : SGSubsystemGroup::incrementalInit()+0x148
  bin/fgfs : SGSubsystemMgr::incrementalInit()+0x52
  bin/fgfs : ()+0x1a587df
  bin/fgfs : fgOSMainLoop()+0xce
  bin/fgfs : fgMainInit(int, char**)+0x9d1
  bin/fgfs : main()+0x20b
  /lib/x86_64-linux-gnu/libc.so.6 : __libc_start_main()+0xe7
  bin/fgfs : _start()+0x2a


Hi lucrus,

I hope you read this - I've got the same error and with the help of James I solved it.

I suspect you are also on debian testing or similar? Since a few days there has been a compiler/libc-update that makes the distro version of libopenscenegraph incompatible. The easy fix is to build it yourself for the time being. Follow the instructions at the wiki to build flightgear and osg accordingly.

1. Uninstall the system libopenscenegraph-dev with apt.
2. Get and build os like this:
   

   Code: Select all

   cd $FG_SRC_DIR
git clone https://github.com/openscenegraph/OpenSceneGraph.git
cd OpenSceneGraph.git
git checkout OpenSceneGraph-3.2.3
cd ..
mkdir osg-build
cd osg-build
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS_RELEASE="-O3 -pipe" -D CMAKE_C_FLAGS_RELEASE="-O3 -pipe" \
-D CMAKE_INSTALL_PREFIX:PATH="$FG_INSTALL_DIR" ../OpenSceneGraph.git
make
make install


3. Clear the build-sg and build-fg folders and rebuild simgear and flightgear as usual. Check that cmake finds your selfmade libosg in $FG_INSTALL_DIR and not the sytem library

Cheers,
Daniel

[kareembart]

When installing flightgear 2018.3.1 I get the following message. 2018.3.1\data\Ai\Aircraft\Buccaneer\instruments\port_coaming_panel.png an error has occured while trying to copy a file: the source file is corrupted.

[pavlin]

interesting..... I did not got this issue.

[Knüppelrührer]

I've just taken a trip LIMJ-LSZH and I am stunned, how FG has developped.

Especially in respect to the clouds. The impression of flying past and trough clouds is fantastic.

FSX looks so lame in this respect. It was never really doing overcast situations, except by "bombing" the layer with clouds, until no visible patch left with frame rate unnessarily down.
No fun for IFR.

Also I like the new C172-Cockpit! Outstanding.

An nice to find myself in the middle of AI-traffic. Is there a way to get vectors and clearances? Because between number 2 and number 3 for landing I had to make myself a hurried number 2.5...

I'd like to suggest, that the "back" button in the GUI is changed to "airport selection" or similar. Because it is not clear, that FG can be started directly from the airport of choice.
Going to Honululu and then changing airport via the menu means double the loading time.
For sure it can be started from the command prompt with options - but above might make it a bit more user friendly.

[V12]

New clouds in 2018.3.1 are realy perfect.
With FSX did You use FSXWX or some better payware like ActiveSky 2016 or some similar external weather engine ? I tested freeware FSXWX and perform very well - for example :



For more FSX screenshots check http://www.thejabberwocky.net/viewtopic ... 695#p24695

[Knüppelrührer]

Maybe it is worth trying addons - but why doing that, when there is flightgear?

The only benefit of FSX/Prepar3d are the highly developped payware aircraft.

But when I read, how much effort some guys putting into the aircrafts, this level will be exceeded sooner or later.

[LesterBoffo]

Thank you, wkitty42 and Hooray. I checked FG 2018.1.1 and found the feature I refer to is called "Aircraft Center (Experimental)" on the File tab. Clicking it opens a dialog box with Summary, Aircraft, Location, Environment and Fly! icons on the left sidebar, allowing one to change Aircraft, Location and Environment parameters without exiting the program and re-opening it.

Should also mention the nicely improved cloud formations in 2018.3.1 and, when flying yesterday, saw a rainbow in FlightGear...that's the first time I've seen one in any Flight Simulator!

Been there for a while..