Free Flight, Free Speech

FGDATA with Submodules. Install Scripts available

Hi, All

FGDATA with submodules offers a new feature. The install scripts.
Inspired in the methodology we implemented for terraGIT, and making a great usage of the <tag></tag> specifications in the aircraft.xml files, FGDATA with submodules now offers the possibility of installing collections or set of aircrafts in an easy and extensible manner.

SET up

To begin, install the FGDATA with submodules repository

Code: Select all

git clone git@gitlab.com:flightgear-fs/fgdata.git


OR, if you already have a copy of FGDATA with submodules (from either gitlab or sourceforge), simply

Code: Select all

git pull

This will bring you a copy of fgdata by the FGMEMBERS team which, unlike the official FGDATA has the ability to be expanded by installing any aircraft available in FGMEMBERS.

Simply, allow the directory obtained fgdata to be the flightgear root directory ($FG_ROOT), either by using a terminal during launching --fg-root=/path/to/fgdata/with/submodules, or with any launcher you use, including the Qt5 launcher.

Using the Installation scripts

in a git-bash terminal, enter the root directory of your fresh fgdata installation

Code: Select all

cd fgdata

Initially, your FGDATA copy will contain ONLY the ufo.
You will be in control of which aircrafts to install or deinstall; for which the install scripts will be your help

you can use the install/aircraft AcftName script to install one aircraft.
Simply

Code: Select all

install/aircraft extra500


per example, or any aircraftName.

Note that you can activate the flag -a or --allow-nongpl, to install a non GPL aircraft, like

Code: Select all

install/aircraft Optica -a


Removing an aircraft from your FGDATA is equally as simple, just use the correspoding deinstall script

Code: Select all

deinstall/aircraft Optica -a

The install/hangar scripts

In addition to install/aircraft, we have install/hangar available
A hangar will allow aircrafts from a hangar to be installed or de-installed rapidly and efficiently, examples


[/size]

Therefore, you can use this method to fully install fgaddon hangar (the FGMEMBERS versions of these aircraft) as follows

Code: Select all

install/hangar fgaddon --allow-nongpl


deinstallation works as expected too

Code: Select all

deinstall/hangar jmaverick


[size=150]Installing aircrafts by <tag>

The script install/tag allows you to install/deinstall aircrafts sharing the same tags, examples

Code: Select all

install/tag bizjet
install/tag jet --allow-nongpl
install/tag 1910s
deinstall/tag mitsubishi -a


(a list of all tags currently available: https://gitlab.com/flightgear-fs/fgdata ... stall/tags)


Extending the install scripts via collections

Collections is any list of Aircrafts per line
You can create your own collection and adding the file either in install/collections/ or install/collections-nongpl respectively.

Once the list exists, example:
https://gitlab.com/flightgear-fs/fgdata ... ollections

You can use the install script as follows

Code: Select all

install/collection iahmcol-favorites -a


The collection base-legacy contains the aircrafts that were downloaded by default in versions before FG3.x, and thus

Code: Select all

install/collection base-legacy


Will give you that legacy experience, per example


would be an example of using such list via deinstall, too

This has been posted by It0uchpods to widely inform the community on Curtis' Forum



That's evidence the post exists, in case it is removed automagically by some sort of information censorship

Best,
IH-COL

In response to Thorsten and Richard's comments in the forum here, I'll paraphrase the Gentoo Philosophy, adapted to our situation

Every user has work they need to do. The goal of GentooFGMEMBERS is to design tools and systems that allow a user to do that work as pleasantly and efficiently as possible, as they see fit. Our tools should be a joy to use, and should help the user to appreciate the richness of the LinuxFlightGear Flight Simulator and free software community, and the flexibility of free software. This is only possible when the tool is designed to reflect and transmit the will of the user, and leave the possibilities open as to the final form of the raw materials (the source code.) If the tool forces the user to do things a particular way, then the tool is working against, rather than for, the user. We have all experienced situations where tools seem to be imposing their respective wills on us. This is backwards, and contrary to the GentooFGMEMBERS philosophy.

Put another way, the GentooFGMEMBERS philosophy is to create better tools. When a tool is doing its job perfectly, you might not even be very aware of its presence, because it does not interfere and make its presence known, nor does it force you to interact with it when you don’t want it to. The tool serves the user rather than the user serving the tool.

The goal of GentooFGMEMBERS is to strive to create near-ideal tools [Like FGDATA with submodules and terraGIT]. Tools that can accommodate the needs of many different users all with divergent goals. Don’t you love it when you find a tool that does exactly what you want to do? Doesn’t it feel great? Our mission is to give that sensation to as many people as possible.

IAHM-COL wrote:In response to Thorsten and Richard's comments in the forum

You've not actually addressed any of the issues that I raised by quoting those goals.

* What does FGData with submodules achieve that you can't achieve by having the aircraft in their own folders. If anything having fgdata without the aircraft makes it easier to use FGM aircraft in their own folder.

* One of the reasons the aircraft were removed in the first place was to allow the user to be able to choose their preferred version of the models. If FG shipped with aircraft in FGData it would be more confusing to always have these when you want to replace them with alternatives.

* More ideal would be a set of URL's for the hangars that could be placed into the launcher's "Aircraft Hangar locations" for each of the types that the script supports; e.g. http://example.com/aircraft/jet?allow-nongpl http://example.com/aircraft/base-legacy or http://example.com/aircraft/iahmcol-favorites?a

* It's something that I believe is for advanced users; i.e. those who can operate a command line and git, and understand how FGData works and what it means to have aircraft stored there.

I could see myself using the install script to grab a selection of aircraft. Also I just realised that I'm not sure if the script handles versioning correctly.

I'm not sure if the script allows selection of the right version of FGData - it should do that automatically otherwise you'll have to switch manually to match the currently installed FlightGear.

Also the script should use the right versions of the models to match the currently installed version of FlightGear - otherwise you may end up with incompatible aircraft. The launcher does this using the package manager within FlightGear core (i.e. to use the current version models, when present, in preference to simply the latest models)

Developer and users are different entities with different needs to achieve their goals most efficiently. If one tool can satisfy both, that would be great. But that is not always feasible. Sometimes a tool with much extra functionality for developers is not really suitable for users. Should we in that case deprive the developers of the functionality? Or would it be better to have a separate tool for the users?

Now when someone comes up with a greatly beneficial tool for developers, it sounds rather besides the point, when someone else comes up with an argument: "But it is not good for users".

I think for this discussion it is highly beneficial to strictly distinguish whether it is about developers or users.

Kind regards, Vincent

Richard wrote:

IAHM-COL wrote:
You've not actually addressed any of the issues that I raised by quoting those goals.

etc

I'm gonna give you a chance.
Are you thinking things all the way through?

[hint]

Just connnect the dots

IAHM-COL wrote:I'm gonna give you a chance.
Are you thinking things all the way through?

Thanks. Enjoyed a bit of dot to dot work. Makes a change and a welcome relief at the end of a fairly hectic week..

Apart from that, and apologies if I'm being stupid but I have absolutely no idea what you mean about thinking all the way through.

I share the same basic goals of making things easy to use, and having the freedom to choose what to use. I don't agree with some of this on a technical level; but it's not up to me to choose what other people want to use - I just provide my opinion.

My original posting on the main forum was simply to frame the announcement in what I believe to be accurate terms; i.e. these scripts are probably not for the average user. As Vincent said there is a huge difference between developers (who obviously are advanced users in my naming scheme) and users.

I'd be very happy if everyone could operate a command line and git; but there is a (probably vast majority) of users for whom the command line is a mystery.

My preference is to keep fgdata separated from my aircraft folders; I think it works better like that; however I'm not completely qualified to say much about the operation of the install script (apart from that it looks like it could be useful to advanced users).

Richard wrote:

IAHM-COL wrote:I'm gonna give you a chance.
Are you thinking things all the way through?

Thanks. Enjoyed a bit of dot to dot work. Makes a change and a welcome relief at the end of a fairly hectic week..

Glad you enjoyed it.

On the other hand. I don't necessarily fully disagree with some things you've said. but others itch me badly.

Firstly,
I don't tell people: <<This is too hard for you>>.
Each one decides his/her own limitations.


Secondly,
precisely, the advantage of letting aircrafts to be tracked by FGDATA via submodules IS the fact that FGDATA is tracking versioning control.
Putting the aircrafts as an addon makes managing versioning control Way more cumbersome.

For FGMEMBERS we list aircraft releases when people want to go to the website and click to download.
https://github.com/FGMEMBERS/717/releases

That would do on that level for backward compatiblity

But for FGDATA with submodules, your suggestion that the install script should track versioning system breaks the principles of good programming:

1. A good tool should do what it does well. and only that*
2. KISS (keep it simple stupid)


In this case the install script (tool #1) manages installing one or several aircrafts. The versioning tracking is done by git (tool #2)

If in doubt how this is done, feel free to ask me, but the general principle is that your previous versions are tag released, and one can git checkout any of these tag releases (or the FG way a branch --roll-eyes--)

once you have checkout a past tag release, then your aircraft commits are frozen where they were at that time, thus by default the install script would install that past version. not a new one (ie, not the HEAD of master of a given submodule)
That is backward compatibility support out of the shelf. And modularity in design. The Linux way, basically.

Finally, off course if you jump to any tag release in the past you won't get a feature just introduced (such as the install or deinstall scripts). That's the way it is; we improve the future. not the past.

But off course real advanced users or people in need that ask in support communities like this one can get help and do some sort of git magic

such as

https://gitlab.com/flightgear-fs/fgdata/tags



Effectively installing FGDATA git, then switching to the version FG2016.4 with submodules (by checking out the tag release) and then installing properly versioned aircrafts.

The commands is where magic resided. allowing git to bring literally a future feature into the past.
Since the install script does not mess with versioning systems, just implements a tool, then it will just work.

______________

*

Dough McIlroy wrote:This is the Unix philosophy: Write programs that do one thing and do it well.