"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up.""Why not?" said Gurder."Dunno. It's frightened of heights, I guess."

you might want to mention that to the mint maintainers... regardless if you do or not, i'm glad you found a solution... i'm looking for them quite a lot lately...

"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up.""Why not?" said Gurder."Dunno. It's frightened of heights, I guess."

why use a PPA when the d&c script already has a method of acquiring OSG and keeping it up to date? it is quite easy, also, to adjust the script to use a different branch of OSG... that is what i did when i adjusted my local d&c to use OSG 3.4...

"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up.""Why not?" said Gurder."Dunno. It's frightened of heights, I guess."

wkitty42 wrote in Mon Nov 06, 2017 3:16 pm:why use a PPA when the d&c script already has a method of acquiring OSG and keeping it up to date? it is quite easy, also, to adjust the script to use a different branch of OSG... that is what i did when i adjusted my local d&c to use OSG 3.4...

... easy to respond ...

not work, the script s&c not install the OSG 3.4 because the Linux-Mint 18.2 is based on Ubuntu version 16.10 and the standard OSG is 3.2. The installer d&c found one OSG version that is not compatible to OSG 3.4 and stop the compilation.

ummm... no... the d&c script has a connection to the OSG repository... there is no install into the system's base layout... d&c builds OSG from the official OSG repository in the existing flightgear development tree where everything else related to flightgear is stored in their repos...

as you can see, i've checked out the OpenSceneGraph-3.4 branch and am compiling my flightgear with that...

Last edited by wkitty42 on Sat Sep 08, 2018 1:06 pm, edited 1 time in total.

"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up.""Why not?" said Gurder."Dunno. It's frightened of heights, I guess."

/home/hooray/sources/flightgear/src/GUI/CanvasWidget.cxx: In member function ‘virtual void CanvasWidget::draw(int, int)’:/home/hooray/sources/flightgear/src/GUI/CanvasWidget.cxx:203:5: error: ‘Extensions’ is not a member of ‘osg’ osg::Extensions* extensions = osg::getExtensions(0, true); ^/home/hooray/sources/flightgear/src/GUI/CanvasWidget.cxx:203:22: error: ‘extensions’ was not declared in this scope osg::Extensions* extensions = osg::getExtensions(0, true); ^/home/hooray/sources/flightgear/src/GUI/CanvasWidget.cxx:203:35: error: ‘getExtensions’ is not a member of ‘osg’ osg::Extensions* extensions = osg::getExtensions(0, true); ^

you can work around the problem by including <osg/GLBlendFunc> and using BlendFunc::Extensions instead.

But it's not just the osg::GLExtensions changes, but also other changes made recently:

/home/hooray/sources/flightgear/src/Viewer/PUICamera.cxx: In member function ‘void flightgear::PUICamera::init(osg::Group*)’:/home/hooray/sources/flightgear/src/Viewer/PUICamera.cxx:291:22: error: ‘class osg::Geometry’ has no member named ‘setNodeMask’ _fullScreenQuad->setNodeMask(SG_NODEMASK_GUI_BIT); ^/home/hooray/sources/flightgear/src/Viewer/PUICamera.cxx: In member function ‘void flightgear::PUICamera::resizeUi(int, int)’:/home/hooray/sources/flightgear/src/Viewer/PUICamera.cxx:339:5: error: ‘resize’ is not a member of ‘osg::Camera’ osg::Camera::resize(scaledWidth, scaledHeight);

I think they were discussing on the devel list making 3.4 a requirement - which seems more and more common lately, i.e. simply raising the required version number of a dependency to "deal" with such problems

Yes, James mentioned big hurdles trying to fix the problem(s) with OSG 3.2, even asking on the OSG mailing-list where OSG 3.2 was apparently considered obsolete and essentially unsupported, so since most distros seem to offer OSG 3.4, it is likely to remain a requirement from now on. I can't say if this is the final word, but it seems plausible.

For old Ubuntu releases that don't have OSG 3.2, someone mentioned the fact that people who want a recent FG on these systems use Saikrishna's (“saiarcot”) PPA most of the times, and that backporting OSG 3.4 to such releases would be “trivial”. The backported packages could be shipped in the PPA. The only thing is that Saikrishna may not want to maintain an OSG backport forever, so he or she (don't know, sorry) needs to ensure that the backported packages can be smoothly replaced by official ones when upgrading to next Ubuntu releases. If the first of these future upgraded-to releases has OSG packages with the same names and higher versions, this should be automatic.

Yes, James mentioned big hurdles trying to fix the problem(s) with OSG 3.2

I'm not sure that's the right description as OSG 3.2 was (and is) running fine for pretty much all in-sim rendering and OSG 3.4 is in fact causing trouble with the OSGText feature - it's more like James wants to do some new (launcher-related?) stuff which seems easier with 3.4.

So I think 'raising dependency to solve problems' is not an unfair description.

I’m struggling to fix the current issue with OSG 3.2, and the responses I’m getting on the OSG users list give me the feeling, they don’t have much interest in supporting it at all, for them it’s ancient history. So I’m wondering if we should finally say we require OSG 3.4.x.

Yeah I am aware of that balancing act, indeed. What’s prompted me to suggest this is not such much the particular software issue, but the response or really disinterest from the OSG user list - from their POV, OSG 3.4 is not ‘latest and greatest’, rather it’s the ‘long-standing and stable’, with OSG 3.2 being considered something out of support at this point.