Free Flight, Free Speech

D-ECHO wrote:Well but why wasn't it a fix for old fgs then?

Sure. For 1 plane, (where your include file is within the structure)? yes.
For an expansion pack (where your include file is not within the planeS structure, but within the Pack structure)? No. I don't think you'll solve connecting your plane to an expansion pack this way. And, clearly, such solution is not expandable to a plane collection depending on your pack.

On the "expansion pack" alternative, you need simgear/fgrun to be fixed, not the plane

KL-666 wrote: Someone should write a letter to someone at the other end to request decent change logs.

Kind regards, Vincent

For starters (and being a bit of the devil's advocate), one could look here

commit log for simgear
commit log for flightgear
commit log for fgrun

Granted, we all know (and we all agree), sourceforge's GUI stinks, and it's no way competition to the neat GUI for GitHub (and even GitLab). But ultimately, one can, after the haggle, find some of the information.

On this sense, this commit by James Turner on July 2016 could be what brought the simgear updates into fgrun, such that fgrun interacted with the newest simgear smoothly again (hypothesis)

fgrun Commit 312a8 diff

I honestly do not think that Alan's comment over the "else if" structure was making a major difference.

Yes, those commit logs are all nice for looking up the technical details of a functional change. But if the functional change is nowhere described, then it is like finding a needle in a haystack. Stitching together scattered commits and try to second guess the functional purpose from that. And even more important oversee the consequences.

No, i am used to a different working procedure. If someone changes something of which he knows the impact can be great, he writes a short functional description pointing out the possible consequences. This way the knowledge is preserved and other people's time is not wasted. They only need to check the functional sheet to determine: Oh, that affects me, let's check the commit logs on that. Or, oh, nothing for me there, fine, then i can continue my current work.

Kind regards, Vincent

I agree....

Even a simple statement like..

We've updated FG to FG 2016.99, If you've a texture in your 3d model that's not a power of 2 size, then this will cause the plane to crash, solution is to resize textures to 2x2 4x4 8x8 16x16pixels etc.

You don't even have to wait for a release before you announce something like this, you could do it before hand and give plane developers the chance of bringing their plane up-to-date with the new FG standard.

It's only courtesy to plane developers to give them a heads up.

forcing them to go on a mailing or have nightly builds isn't the way.

I also can't but agree with you guys in that assesment.

Also interesting to note: After changing simgear in such a way (and consequently updating the new Qt5 launcher to follow), you get members of the community report a bug in FGRun (the other launcher). Something changed recently that makes planes (some of them) fail to show to the launchers.

All we heard is

"Nothing has changed. The planes are the problem here"

Oh, and to add: Some of us are labelled as paranoid because we insists there is a problem in the way the launchers were not seeing the planes. Particularly FGRUn. So, instead of taking our report as a bug that needs to be addressed, we are treated as Hooray's version of "the user".