I have started to adapt and improve the package to FG 2018 as mentioned in the forum above, but I am not sure about the outcome as I don't agree with every design decision made so far in FG kernel
Okay. This is now growing into a major source of frustration for me.
It seems some people believe the incorporation of the Truman into FG was badly handled. My recollection is:
I volunteered to do this, as I enjoy carrier ops and didn't want this great ship to hang around not making it into FG. When looking at the package, I found several things which I judged needed to be altered. To my recollection, these were:
1) Much of the supporting Nasal was running in a loop polling properties for e.g. JBD operation events. This is bad practice, wasteful and better accomplished with listeners which do not take performance on a per-frame basis and such inefficient Nasal structures have contributed much to the bad reputation Nasal in FG enjoys.
I subsequently decided to re-write the relevant parts myself, rather than send the package back and ask mhab to do it, explaining the nature of my change. I did it myself to not cause frustration, making someone else re-do lots of work.
2) There was a cruise ship included which had no GPL compatible license - I removed it from what went to FGData, explaining why the license is not compatible. Given the legal situation of FG, this decision is not negotiable and could not have been any different.
3) There were details (e.g. the wake shader) added to other carriers - I did not include those, explaining that there are people who run FG on legacy hardware, so we ought to leave one lowres carrier (the Nimitz) for them to use without forcing expensive effects onto every carrier.
4) The control GUI I brought up on the mailing list where the discussion evolved into a general scheme to re-do the control of AI objects with certain requirements posted, the net result of this was that I ended up re-writing the GUI of *all* carriers to support the new scheme. I've tried to in addition implement the 'click on object to move' controls as they were in the package. Arguments pro and con the scheme and explanations are found on the mailing list ad nauseam - this particular change is a result of a consensus among the developers and hence not just my whim.
In addition, while I was working with the carriers anyway, I decided to re-do the lights to use ALS procedural lights, which took a while tuning, I checked back and forth between rendering schemes that the visuals during approach from a given distance do not greatly differ, although they're not always identical. To my recollection I also added Richards approach guidance scheme to the Truman and polished the flightdeck.
There might have been the one odd smaller thing no mentioned here, but these are the main things I recall.
Even after re-thinking it, I would make each of these decisions the same way today. I do not feel I have wronged anyone, I'e tried to be open about the 'why', I've invested about ten times more work into this than I initially planned when taking on the review procedure - yet people continue to be unhappy.
The net result is a forked development which likely will be ported to every new FG version over and over and unhappiness on many fronts.
So please help me out here - what is it I should have done differently in all of this? What is the nature of the decisions which are not agreeable? What crucial step did I not do?
This is a genuine question - I really do not want to repeat the experience, contributing to FG should be as pleasant for everyone as possible (given that we have to compromise on some things).