Who's the boss?
Posted: Tue Sep 27, 2016 3:25 am
Who's the boss?
https://sourceforge.net/p/flightgear/ma ... /35393313/
OH!C'MON James
Be serious.
I am so confused.
Do we need to code and develop FlightGear to cater to the Launcher? Or should the Launcher mold itself, to the realities and the needs of Flightgear? Tell me who's the boss. Because it frequently seems that new features on FlightGear are implemented or vetoed on the principle of how they play with the Qt5 Launcher. It seems such launcher tells the game.
Implementing the ability to easily read and obtain and parse new apt.dat over the general one in Airports/apt.dat.gz is VERY VERY important flexibility for the software. And it should be immediately made priority.
Furthermore, you already received a pull request by Florent that succesfully implemented the functionality, and if not finished, at least he gave you a leap and to base your stuff on.
Instead, it seems to me you are doing all the talk required to veto this, and you go as far as implying that such feature is not launcher friendly? Are you serious? or am I missing something?
https://sourceforge.net/p/flightgear/ma ... /35393313/
James Turner in the devel.list wrote:Florent in the Devel.list wrote:> On 21 Sep 2016, at 21:48, Florent Rougon <f.rougon@free.fr> wrote:
>
> Is there another way to change scenery paths at runtime?
>
> It seems to me that runtime changes of scenery paths could be
> accomodated this way, including inside the Qt launcher:
> - read the apt.dat files from $FG_ROOT/Airports/apt.dat.gz as well as
> $FG_SCENERY/Airports/apt.dat[.gz] (the latter "expanded" for each
> scenery component, obviously);
> - run the "has the list of apt.dat files (where order matters) or
> their timestamps changed since the last navdb rebuild" check every
> time globals->clear_fg_scenery(), globals->append_fg_scenery() or a
> similar function is called. Rebuild the navdb when the test says
> yes.
> - make sure scenery paths are always modified through such functions;
> - possibly remove --apt-dat, or make it log a big warning message
> indicating it is only for power users if that makes you happy, etc.
>
> Is there a concrete scenario where this would fail?
>
> In my opinion, for performance reasons it is also preferable to keep the
> big monolithic $FG_ROOT/Airports/apt.dat.gz and only override *a few*
> airports with their specific $FG_SCENERY/Airports/apt.dat[.gz].
> Typically, these would be custom sceneries.
Supporting run-time changes is a nice goal, but not worth a huge amount of effort. Good interaction with the launcher is pretty important.
OH!C'MON James
Be serious.
I am so confused.
Do we need to code and develop FlightGear to cater to the Launcher? Or should the Launcher mold itself, to the realities and the needs of Flightgear? Tell me who's the boss. Because it frequently seems that new features on FlightGear are implemented or vetoed on the principle of how they play with the Qt5 Launcher. It seems such launcher tells the game.
Implementing the ability to easily read and obtain and parse new apt.dat over the general one in Airports/apt.dat.gz is VERY VERY important flexibility for the software. And it should be immediately made priority.
Furthermore, you already received a pull request by Florent that succesfully implemented the functionality, and if not finished, at least he gave you a leap and to base your stuff on.
Instead, it seems to me you are doing all the talk required to veto this, and you go as far as implying that such feature is not launcher friendly? Are you serious? or am I missing something?