FlightGear wiki - User contributions [en]

Fedora Packages and Compiling

2026-01-14T23:32:14Z

The FL3dd0x: /* Required packages for the development 2024.2 release */ nlohmann-json is now needed for next

{{DISPLAYTITLE:Fedora Packages and Compiling}}

Users on <tt>apt</tt>-based systems can use the script <tt>download_and_compile.sh</tt> to download required development packages and compile FlightGear. Systems using <tt>dnf</tt> for package management cannot use this script. Once required packages are loaded using <tt>dnf</tt>, the <tt>download_and_compile.sh</tt> script can be used to compile and build FlightGear is desired

Here are the packages needed to build and use SimGear and FlightGear on Fedora along with some examples of build scenarios for reference.
== Simply Use the Current Release ==
If one wishes to simply use FlightGear in its current supported form without re-compiling, the Fedora FlightGear packages are fine.

As of march 2025, the fedora 41 repository provides the current release 2024.1.1. To use simply download the Fedora FlightGear packages. It is not necessary to load these packages in order to compile and install your own versions from source, but it also is compatible with and does not prevent development work if they are installed.
sudo dnf -y install FlightGear
sudo dnf -y install FlightGear-data
sudo dnf -y install FlightGear-Atlas # Optional

This installs FlightGear commands such as <tt>fgfs</tt> in /usr/bin and FlightGear's data, <tt>fgdata</tt>, in /usr/share/flightgear.
==Building FlightGear==
If, however, one wishes to build various versions from source, several development packages are required.

Different packages may be needed for different versions of FlightGear. Also the FlightGear distribution contains several other commands in ''flightgear/utils'' that may require additional packages.
===Required Packages ===
These required packages are needed in addition to the basic configuration provided by a Fedora 41 Workstation initial installation.

=====Required packages for the current 2024.1 release=====
sudo dnf -y install cmake
sudo dnf -y install gcc-c++
sudo dnf -y install boost-devel
sudo dnf -y install gtkglext-devel
sudo dnf -y install openal-soft-devel
sudo dnf -y install OpenSceneGraph-devel
sudo dnf -y install libcurl-devel
sudo dnf -y install plib-devel
sudo dnf -y install freeglut-devel
sudo dnf -y install c-ares-devel

=====Required packages for the development 2024.2 release=====
2024.2 uses an updated version of OpenSceneGraph. If the Fedora-provided OpenSceneGraph-devel has been loaded, there is no conflict as we will tell the build system which to use.
sudo dnf -y install mesa-libGL mesa-libGL-devel
sudo dnf -y install mesa-libGLU mesa-libGLU-devel
sudo dnf -y install glfw glfw-devel freeglut freeglut-devel
sudo dnf -y install freetype freetype-devel
sudo dnf -y install gdal gdal-devel
sudo dnf -y install json-devel
And 2024.2 wants, but does not specifically require Qt5
sudo dnf -y install qt5-qtbase-devel
sudo dnf -y install qt5-qtdeclarative-devel
sudo dnf -y install qt5-qtsvg-devel
sudo dnf -y install qt5-linguist

==Build Examples==
The required development packages listed above are sufficient for building SimGear, FlightGear, loading fgdata and installing a running flight simulator. FlightGear has several additional packages that may require additional development packages. using cmake and following its errors make it fairly straight forward to find and install additional packages for these additional FlighhtGear components.

The following sections describe example scenarios for compiling and installing various versions of FlightGear.

Note that one shell variable is used in these examples to control the number of parallel processes allowed by make. Using this parallelism speed up the compilation process. Place this in your $HOME/.bashrc.
export nproc=`/usr/bin/nproc`

Two main versions are described.
<pre>
Version 2024.1.1 is the current release version. One may wish to experiment and build patched versions to maintain compatibility with existing binary downloads. However it may be useful to use later development versions and contribute to the ongoing FlightGear development.

Version 2024.2, or next, is where features beyond 2024.1 continue development.
</pre>

===Current release version 2024.1===
This example gives the simple case of a single private version in your HOME directory.
mkdir $HOME/fg2024.1
Two methods exist to get the required source code. Tar archives or the FlightGear git repository.

====Use .tar files====
The FlightGear web page Download section https://www.flightgear.org/download/ provides access to the tar files.

These tar files unpack into directories named simgear-v2024.1.1, flightgear-v2024.1.1, and fgdata_2024_1.

These directories can be named anything you wish as long as the names are used consistently. Here I will rename the extracted directory names to be consistent throughout all the following examples.
cd $HOME/fg2024.1
tar xzf simgear-v2024.1.1.tar.gz
mv simgear-v2024.1.1 simgear
tar xzf flightgear-v2024.1.1.tar.gz
mv flightgear-v2024.1.1 flightgear
cd $HOME/.fgfs
tar xJf FlightGear-2024.1.1-data.txz

====Use the git repository====
If you are going to compile and build your own version of FlightGear, possibly fixing a personal bug or adding a feature, please consider joining the community of developers and contributing. To start, it is best to use the GitLab repositories rather than tar files so that you might contribute in the future.

For 2024.1, we clone a single branch of the repository to have a similar configuration as with the tar files.
cd $HOME/fg2024.1
{{simgear clone | opt = --single-branch --branch release/2024.1 | post = simgear}}
{{flightgear clone | opt = --single-branch --branch release/2024.1 | post = flightgear}}
{{fgdata clone | opt = --single-branch --branch release/2024.1 | post = fgdata}}

==== Building 2024.1 ====
Once the code is loaded we can build. Editing and re-building can proceed without need to re-fetch the source. Using a ''git pull'' command can be use in each repository to keep up to date.

The general technique is to make a separate empty build directory, use cmake to configure and then compile and link. This avoids cluttering up the source directories with build files. Also, you can have several different configurations with the same source: fgbuild-release, fgbuild-debug, fgbuild-test, etc.
mkdir fgbuild
mkdir sgbuild
mkdir install

cd $HOME/fg2024.1/sgbuild
cmake ../simgear -DCMAKE_INSTALL_PREFIX=$HOME/fg2024.1/install -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)
make install
cd $HOME/fg2024.1/fgbuild
cmake ../flightgear -DCMAKE_INSTALL_PREFIX=$HOME/fg2024.1/install -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)
make install
FlightGear should now be installed in the specified local install directory. Set your path to find the new executables.
export PATH=$HOME/fg2024.1/install/bin:$PATH
The build procedure looks for the fgdata files in a few different places controlled by cmake.
One can specify a specific location for fgdata when configuring flightgear:
cmake ../flightgear -DFG_DATA_DIR=$HOME/my-fgdata ...
If no such fgdata directory is specified to cmake, it looks for a directory called fgdata at the same level as the specified flightgear source directory. This is the method used above in the example build. The fgdata directory is found at ../fgdata:
cmake ../flightgear ...
Finally, if not otherwise found, cmake sets the fgdata directory to be a sub directory of the place where flightgear and simgear are to be installed. In an example where fgdata was not installed at ../fgdata as above, the fgdata directory will be found in $HOME/fg2024.1/install/lib/fgdata:
cmake ../flightgear -DCMAKE_INSTALL_PREFIX=$HOME/fg2024.1/install ...
In any of the cases, messages output by cmake as it runs will tell you what directory was selected for the flightgear data directory. Development is under consideration for future versions to allow portions of the fgdata data to be dynamically downloaded from the internet.

===Next development version 2024.2===
This version is for development of new features beyond the frozen features in 2024.1. This is the version where new ideas are developed for a future release. Join the FlightGear development team. Discuss changes with core developers on the developer mailing list. Depending on the state of development, this version may have bugs, may not work, or even may not compile.

Make sure that the required packages listed above beyond those needed for 2024.1 have been installed.

The big addition is that this version uses a local build of the OpenSceneGraph package. So there is an additional build directory for OpenSceneGraph.

Note also that we download the full Flightgear repository rather than a single branch as we did for 2024.1. This means that the full range of git commands such as switching branches are available.
mkdir $HOME/fg2024.2
cd $HOME/fg2024.2

====Use the git repository ====
git clone https://gitlab.com/flightgear/openscenegraph.git openscenegraph
{{simgear clone | post = simgear}}
{{flightgear clone | post = flightgear}}
{{fgdata clone | post = fgdata}}

====Building 2024.2====
mkdir osgbuild
mkdir fgbuild
mkdir sgbuild
mkdir install
Note that we tell simgear where to find the newly constructed OpenSceneGraph. If you also loaded the fedora distribution of OpenSceneGraph to support building 2024.1 above, there is no conflict as we explictly tell simgear where to look.
cd $HOME/fg2024.2/osgbuild
cmake ../openscenegraph -DCMAKE_INSTALL_PREFIX=$HOME/fg2024.2/install -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)
make install
cd $HOME/fg2024.2/sgbuild
cmake ../simgear -D OSG_INCLUDE_DIR=$HOME/fg2024/install/include -DCMAKE_INSTALL_PREFIX=$HOME/fg2024.2/install -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)
make install
cd $HOME/fg2024.2/fgbuild
cmake ../flightgear -DCMAKE_INSTALL_PREFIX=$HOME/fg2024.2/install -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)
make install

export PATH=$HOME/fg2024.2/install/bin:$PATH

== Various tools ==
The examples above use low level tools such as tar and make to build the system. Higher level tools can also be used depending on user preference.

=== cmake ===
''cmake --build'' can be used in place of ''make''. The effect and level of effort are similar. If the developer is familiar with cmake and wishes to use the level of command there is no problem replacing make with cmake for this development.

=== Download_and_compile.sh ===
As mentioned above, the download_and_compile.sh command is used by developers on apt-based Linux systems to automate parts of the development process.

The single script merges all aspects of the devlelopment given above. In particular, the script has lists of system package dependencies that are automatically checked, loaded, or updated as needed. However this behaviour is closely linked to details of the ''apt'' command suite. Users on ''dnf''-based systems such as Fedora, or redhat cannot use this.

If desired, the script can be used for parts of the development process on Fedora by omitting the system-package checks performed by ''apt''. For example, the script uses git to automatically pull updates for the various parts of Flightgear from the repositories.

To use, load the system packages listed above with ''dnf'' and then do something like this:
mkdir $HOME/fg2024
cd $HOME/fg2024
{{fgmeta clone | post = fgmeta}}
fgmeta/download_and_compile.sh -p n FGFS
The ''-p n'' arg tells the script to NOT use ''apt'' to check, update, or fetch packages. Once the required packages are loaded from the Fedora repositories normal dnf upgrade commands will update the needed packages along with the rest of your system.

A detailed help message is available with
fgmeta/download_and_compile.sh --help
With no additional arguments as in the example above, the script will build 2024.2/next. To build 2024.1:
fgmeta/download_and_compile.sh -s -p n FGFS
Use of the download_and_compile.sh script has pros and cons.

If one is developing on both Fedora and other apt-based systems such as Ubuntu or Raspberry Pi, then using a common tool suite may be an advantage.

On the other hand, the script builds a somewhat complex directory structure and may do additional work not needed at various steps in your particular process. If you prefer a fully automated single tool, then the script may be desirable for you. If you prefer lower-level finer grained control of the process, using the separate commands my be preferred.
[[Category:Building from source]]

Fedora 16 Package List

2026-01-14T22:36:01Z

The FL3dd0x: Very outdated, redirect to current article

#REDIRECT [[Fedora Packages and Compiling]]
[[Category:Building from source]]

Swift

2024-07-04T14:52:08Z

The FL3dd0x: Version compatibility was specified wrong.

{{infobox subsystem
|image = FG swift connection.PNG
|name = swift-connection module
|started = 10/2018
|description = Connection module to swift pilot client which allows connections to FSD servers like VATSIM
|status = Released (FG 2020.1) and actively developed
|maintainers = Lars Toenning
|developers = Lars Toenning
|folders = {{flightgear source | path = src/Network/Swift/ }}
}}

This module allows [[FlightGear]] to connect to an externally running '''''swift''''' client.

''swift'' is an open-source pilot client for multiple flight simulators (FSX, P3D, FS9, XPlane, FG) and operating systems (Windows, MacOS, Linux). It allows connections to FSD servers like VATSIM. Further information about ''swift'' can be [https://datastore.swift-project.org/page/about.php found here].

== swift project status ==
''swift'' is actively developed [https://dev.swift-project.org/ here] and is in public beta status.

== Current features ==
The key features include:

* aircraft interpolation
* voice communication with ATC, support for new VATSIM codec planned
* model matching
* Database support for model mappings, users can contribute
* [[TCAS]] support

== Compatibility ==

<span style="color: red;">'''FlightGear 2019.1.2 and earlier isn't compatible with swift >= 0.11.0.'''</span>

For communication between FlightGear and swift dbus is used. To assure that both sides using the same commands for communication the FGSWIFTBUS_API_VERSION must match each other. Otherwise connection is not possible.

For compatibility see the following table:

{| class="wikitable" style="text-align:center; border: none; background: none;"
|-
!{{diagonal split header|swift|FlightGear}}
! scope="col"| <2019.2
! scope="col"| next
|-
! scope="row"| <=0.9.3
| style="background-color:#ff0000;"| -/-
| style="background-color:#00ff00;"| -/-
|-
! scope="row"| develop
| style="background-color:#ff0000;"| 1/-
| style="background-color:#ff0000;"| 1/-
|}

== Install/Setup ==
For an setup guide for FG see: https://swift-project.org/home/install/configure_fg/

Alot of good videos for the swift gui are on youtube: https://www.youtube.com/playlist?list=PLREsotdYQdGmeasv1x8vsNhiZGhankLoP

=== Linux specifics ===

==== Hotkeys support ====
https://swift-project.org/troubleshooting/linux_hotkeys/

On Linux, the swift client needs read access to the device nodes <code>/dev/input/event*</code>. In case your linux user does not have read access to this nodes, the swift client cannot grab keyboard events, and thus the PTT assigned keybind will not work.

To fix, for example in Debian 12, you just need to add a udev rule from the link above and reboot.

== Aircraft mapping (swift mapping tool) ==
For correct aircraft loading and parsing into swift you need to add FG's model directories.
The supported folders are:
* <tt>[[$FG_ROOT]]/AI/Aircraft</tt>
* Any other folder which contains user-flyable airplanes (in separate folders).

=== Note for Windows users ===
Starting with swift 0.9.1, swift automatically adds the sim and model paths if FlightGear was installed through the installer.

== WIP video ==
{{#ev:youtube|l5O3tRobYPY}}

[[Category:Software]]

Using TerraGear

2021-05-12T18:11:23Z

The FL3dd0x: Fixed the Windows build and SRTM-3 links

{{Out of date}}

[[File:Terragearprocesschart.png|thumb|TerraGear Process Flow Chart]]
The [[TerraGear]] software project supports [[FlightGear]] by creating the files used by FlightGear to represent the elevation and texture of the earth, including airports, cities, fields, forests, rivers, roads and so on. The TerraGear software reads data files containing ground elevation, airport locations and layouts, geographical land-cover data, and more, and produces the scenery files used by FlightGear to represent the terrain of the world.

For simplicity and convenience, most FlightGear users simply download the plug-and-play scenery files from the FlightGear scenery server, or use [[TerraSync]] to automatically download scenery as needed. But there is a variety of reasons you might want to use TerraGear to produce your own terrain files, rather than downloading the standard FlightGear scenery.

For instance, if you use [[WorldEditor]] to modify/improve information about an [[:Category:Airports|airport]]'s taxiway/apron layout, you might wish to see how that modified airport would look in the scenery before deciding you're happy with the results. Maybe the official scenery is too detailed for your slow machine, and you'd like to build terrain using a digital elevation model (DEM) with poorer resolution, to decrease the number of polygons and thus improve your framerates. Or maybe you've got a fantastically fast machine, and you want to build your own terrain using higher-resolution vector data (vmap1, Tiger, osm) to get better roads/streams. For all these reasons, learning how to use TerraGear is a good idea.

== Obtaining TerraGear ==
You can either build TerraGear yourself, or download a pre-compiled binary. The latter is the easiest and advised for starters.

* '''Option 1a - Download TerraGear pre-compiled (recommended for beginners) on Windows'''
*# Download the latest TerraGear (TerraGearGUI included) build from: http://www.mediafire.com/file/ul2xy2ykgig2mct/160605_Sucessfull_Terragear_Win_Built.7z. This is by BecOzlacan, it's very stable and works well.
*# Create or choose a directory to hold the TerraGear tools.
*# Unzip the package.

* '''Option 1b - Download ppa packages for Ubuntu Linux'''

https://launchpad.net/~saiarcot895/+archive/ubuntu/flightgear-edge/+index?batch=75&memo=75&start=75

* '''Option 1c - Use the TerraGear Docker instance'''

[[Howto:Docker_scenery_toolchain]]

* '''Option 2 - Compile TerraGear from source code''' as explained in [[Building TerraGear|this article]].

{{note|1=You might need <code>default_priorities.txt</code> from the {{terragear source|path=src/BuildTiles/Main/default_priorities.txt|text=git repository}} or from the archive downloaded from the build server (in the <code>archive/install/msvc100/TerraGear/share</code> subdirectory). See [http://forum.flightgear.org/viewtopic.php?f=5&p=77950 this forum thread] for details.}}

=== GUI tool ===
A [[TerraGear GUI]] is available for those that would like to use TerraGear without knowing/using the command line options.

== Using TerraGear ==
First, choose the boundaries for the area of scenery you want to build, in terms of latitude and longitude. The smaller the area of scenery you generate, the smaller the amount of data you will need, and the less CPU time it will take. For example, if you are just interested in generating a new airport layout at 12.3W 34.4N, then simply generating the scenery between 12W 34N and 13W 35N would be sufficient.

Write down the bounding box (minimum and maximum longitude and latitude) for the scenery you want to generate. Remember that West and South are negative - in essence 4W 10S would be -4, -10. Try not to get mixed up, otherwise you'll end up generating scenery or airports on the other side of the planet!

You'll be dealing with multiple different types of data in various formats. Create a new directory for your scenery work. Within that directory, create the following sub-directories:

; <code>data/</code>: For raw and pre-processed data (eg elevation files)
; <code>output/</code>: For the scenery files you will create
; <code>work/</code>: For data that has been processed (eg by shape-decode) and is ready to be munged into scenery

=== Obtaining and processing data ===
TerraGear uses three different kinds of information to generate scenery:

# The elevation of the land (provided by SRTM)
# The location and layout of airports (provided by apt.dat or a custom .dat)
# Whether a given lat/lon is sea, land, city, forest, town, road, railway (provided by VMAP0, [[CORINE]] etc. or custom shapefiles)

This article describes how obtain and process each of these types of data in order, and bring it together for use by FlightGear. The order of these steps is important. For example, the airport data step needs the elevation data to determine the elevation of the airports and thus you should start with preparing elevation data.

{{caution|For inclusion in the official FlightGear scenery, all data '''must''' come from [[GNU GPL]] compatible sources!}}

==== Elevation data ====
The best worldwide elevation data currently available is from the Shuttle Radar Topography Mission (SRTM). There are two types of SRTM data:
* Highly accurate 1-arcsecond resolution data, known as SRTM-1, for the USA
* Less accurate 3-arcsecond resolution data, known as SRTM-3, for the rest of the world.
From now on, we'll assume you are using SRTM-3 data. Unless otherwise noted, the process for SRTM-1 is identical.

You can download the appropriate data from http://viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm. You want all .hgt.zip files covering your region of interest. Depending on the size of your scenery, there may be quite a few. Download them to <code>data/SRTM-3/</code> (or SRTM-1/SRTM-30 depending on the type you downloaded) in your base directory. (Genapts looks for a few known, hardcoded elevation data directories in its working directory. SRTM-30 is one of them and this is the least confusing in that list. Note: W.E.F. 31st July 2010, the genapts tool now also looks for SRTM-1/SRTM-3 directories. If you are using an older version, please supply the directories using --dem-path).

Now we've got the data, we need to convert it into something of use to TerraGear. First, you need to unzip each of the .hgt files. After that, open the commandline (Windows: Start > Run > <code>cmd.exe</code>) and change into the base directory (<code>cd .../.../TerraGear</code>).

{{note|According to [[TerraGear_Documentation]], hgtchop is superseded by gdalchop.}}
{{note|For SRTM-1 data, replace the <code>3</code> by a <code>1</code> in the first argument to hgtchop}}
{{tip|If you want to create a batch-file, replace <code>%f</code> with <code>%%f</code>, see [http://technet.microsoft.com/en-us/library/bb490909.aspx]}}

For Windows:
for %f in (.\data\SRTM-3\*.hgt) do .\Terragear\hgtchop.exe 3 %f .\work\SRTM-3
or
for %f in (.\data\SRTM-3\*.hgt) do .\Terragear\hgtchop.exe 3 .\data\SRTM-3\%f .\work\SRTM-3

For Linux:
for f in ${PWD}/data/SRTM-3/*.hgt; do ./Terragear/hgtchop 3 "${f}" "${PWD}/work/SRTM-3"; done

Now you will get a lot of .arr.gz files in your work/SRTM-3/ directory. We need to convert these to the .fit.gz format. Run the commandline again with

{{note|The space and dot at the and are important!}}

For Windows:
.\Terragear\terrafit.exe work\SRTM-3

For Linux:
./Terragear/terrafit work/SRTM-3

==== Airport data ====
Now we've got elevation data, we can generate our airports. First, create a <code>data/airports/</code> directory and copy in your apt.dat file. This may be direct from your FlightGear data package (though you'll need to unzip it), or it may be one that you've modified with [[WorldEditor]].

The command to create airports is "genapts850". Run it without any arguments to see the various command-line options.

If it is simply run with a specified apt.dat and work directory, it will generate airport layouts for every airport in the file, which can take a long time. Make sure the input is not the apt.dat.gz, but an uncompressed file. Otherwise genapts850 will block and not produce any output.

If you are just creating a single airport and you know the ICAO ID (for example [[San Francisco International Airport|KSFO]], EGPH or EG32), use it as follows from your root scenery directory (in essence the directory above your data, work and output directories). If you use an apt.dat file with one single airport in it you should omit the <code>--airport</code> parameter.

genapts850 --input=data/airports/apt.dat --work=./work --airport=<AIRPORT_ID>

or, if you have elevation data available:

genapts850 --input=data/airports/apt.dat --work=./work --dem-path=SRTM-3

If you are generating a larger set of scenery, then you can specify the minimum and maximum longitude and latitude.

Genapts will create two sub-directories in your work directory:

* <code>AirportArea/</code>
* <code>AirportObj/</code>

These contain the definitions of the airport layout and any objects present (e.g. windsocks and beacons).

==== Landuse data ====

{{note|The text in this section refers to using data from the MapServer, which has been discontinued. Land use data (shapefiles) should be acquired from another source for now.}}

The final piece of data we need to generate is the landuse data. In general, this is taken from the VMAP0 dataset as shapefiles from the scenery database mapserver, but other sources can also be used.

The landuse data can be split into a number of different types:

; Landmass: Separates the land from the sea. It can be used as a mask for all other data. The most commonly used is the VMAP0 Landmass, but GSHHS can also be used. When running tg-construct with <code>--ignore-landmass</code>, all input shapefiles will be taken into consideration, so no landmass mask is required then.
; Land use data: Defines whether a piece of land is forest, urban, sand, lava, glacier etc. These are usually VMAP0 data, defined as polygons.
; Line data: Includes railroads, streams, roads. Typically VMAP0, but also OpenStreetMap for roads.
; Point data: Is currently only used for defining towns.

By far the easiest way to get this data is to download shapefiles from the wonderful [http://mapserver.flightgear.org MapServer]. The MapServer lets you download the shapefiles for any selected scenery area. Click on the "Download Shapefiles" link (or go direct: http://mapserver.flightgear.org/download.psp). Enter in the bounding box of the scenery you want to generate, select the type of shapefile data you want, and click download.

==== Layers ====

; <code>v0</code>: Global coverage, low detail. This is "the last resort", but unfortunately it is the only layer that covers the entire world.
; <code>cs</code>: It is v0 with some contributions someone did in the past. Get this instead of v0.
; <code>v1</code>: Only parts of some countries available, higher detail than v0.
; <code>clc06</code>: European '''only'''. Very high detail, this is the preferred choice for an European country.
; <code>osm</code>: Global coverage, high resolution but very low detail.
: This means: if you are interested in an area out of Europe and forests are defined in OpenStreetMaps for your area, this is going to be the best data source. If forests are not defined, you will get a dull, neverending DEFAULT landclass. OSM provides the best coastline and I encourage you to use this coastline even in Europe. [http://forum.flightgear.org/viewtopic.php?f=5&t=25549&sid=d501cb651ef9e34ca9dc8fae429d51ab&p=234002#p234002]

{{caution|Make sure each shape file is in its own directory whether you download shape files or create your own otherwise the ogrDecode step will fail.}}
Download each shapefile into a seperate (!) <code>data/shapefiles/...</code> directory. So, for v0_landmass, you would end up with <code>data/shapefiles/v0_landmass/v0_landmass.shp</code> etc.

You can load these shapefiles into a GIS editor such as [[QGIS]] or GRASS to view and edit. This is a good idea to verify you have the correct files! Later on, you can experiment with replacing various shapefiles with other versions (GSHHS for coastline, OSM for roads etc.).

The next step is to decode the shape-files into TerraGear format using the '''ogr-decode''' command (renamed to '''poly-decode''' in recent versions of TerraGear).

There are three important command-line arguments for ogr-decode:
* the destination directory for the decoded data
* the location of the shapefile's directory
* the material type

Each shape-file corresponds with one of the material types defined in the materials.xml files. The mapping is pretty obvious. For example, <code>v0_mixedcroppasturecover</code> maps to <code>MixedCropPastureCover</code>. Note that the material types are case-sensitive, so it is a good idea to refer to the <code>[[$FG_ROOT]]/Materials/default/materials.xml</code> file (<code>[[$FG ROOT]]/materials.xml</code> in FlightGear 2.6.0 and older) to hand so you can check. The exception is landmass, which - when used - MUST be mapped onto the type Default.

Additionally, there are a number of optional arguments, to indicate the width of line data (for roads, streams, railways), how large to make point data (for towns) and how long the longest straight line is allowed to be.

For example, to decode the <code>v0_landmass</code> shapefile, you use the following command:

ogr-decode --max-segment 500 --area-type Default work/Default data/shapefiles/v0_landmass

To create streams of width 10 metres

ogr-decode --max-segment 500 --line-width 10 --area-type Stream work/Stream data/shapefiles/v0_stream

To generate some towns about 1km across

ogr-decode --point-width 500 --area-type Town work/Town data/shapefiles/v0_town

Run this command for each shapefile in the set.

== Generating scenery ==
You will now have a work directory, with subdirectories like:
{|
|
: AirportArea
: AirportObj
: Bog
: Default
: DryCropPastureCover
: EvergreenBroadCover
: GrassCover
: IrrCropPastureCover
: Lake
: Marsh
: MixedCropPastureCover
| valign="top" |
: MixedForestCover
: Railroad
: Road
: Sand
: ScrubCover
: Shared
: SRTM-3
: Stream
: Town
: Urban
|}

Now we can actually generate the scenery. This is done by the tg-construct command. Run the command with <code>--help</code> to get usage information.

We need to define:
* The work (<code>--work-dir</code>) and output (<code>--output-dir</code>) directories.
* The center of the scenery we want to generate (<code>--lat</code> and <code>--lon</code>).
* The radius (<code>--xdist</code> and <code>--ydist</code>) from which to generate.
* All the work directories to include in the scenery.

{{note|The output directory must point to a <code>Terrain/</code> directory, else recent FlightGear versions will be unable to load the terrain.}}

For example:
{{Pre2|<nowiki>tg-construct --work-dir=./work --output-dir=./output/Terrain --min-lon=55 --max-lon=57 --min-lat=60 --max-lat=62 AirportArea SRTM-3 AirportObj Default Stream Bog IrrCropPastureCover Town Lake Urban Railroad DryCropPastureCover Road EvergreenBroadCover Marsh Sand MixedCropPastureCover ScrubCover GrassCover MixedForestCover</nowiki> }}

When this finishes, the output directory will contain a scenery sub-tree. Point to it by setting either [[$FG_SCENERY]] or by using the <code>--fg-scenery</code> command-line option to fgfs, and give your new scenery a try!

== Troubleshooting ==
Below is a list of common problems and solutions. If in doubt - Google it. Many problems (particularly when compiling TerraGear) have been hit before:

* Crashes in genapts. Sometimes genapts will crash when dealing with a particular airport. In that case, try running it again with the <code>--start-id</code> argument to start at the airport it failed on, and the <code>--nudge</code> argument which tries to nudge the calculations in the right direction.
* tg-construct killed. The tg-construct process may kill itself if it is using too many system resources. Increasing the values for <code>setrlimit</code> in <code>src/BuildTiles/Main/main.cxx</code> is the best solution.
* tg-construct silently stops immediately without an error and nothing goes to the "output" directory: make sure that lon/lat values correspond to tiles boundaries. See [[Tile Index Scheme]]
* tg-construct says it is building the tiles requested, but at the end, nothing has been built: even if the requested tiles are covered by the elevation file (.hgt), tg-construct needs at least a default shapefile covering any terrain, or else it skips the tile with no output.
* Airports appear in the bottom of holes, or there are spaces between the airports and the scenery. This typically happens when genapts is unable to find the correct elevation data, or the elevation data changed between running genapts and shape-decode. Try generating a single airport in your scenery area using genapts, and look at the output. In particular, make sure there is a work/SRTM-3 directory.
* Only the airports appear in the scenery. There are three typical causes for this:
** You didn't download the correct shapefiles for the area.
** You haven't run shape-decode on the <code>v0_landmass</code> shapefile as Default
** You didn't include the correct directories in tg-construct.
* Generate scenery includes data removed from the shapefiles. If you are editing shapefiles, you need to delete the appropriate work subdirectory before running shape-decode. Otherwise your changes will be in addition to those already present.
* All the scenery is flat and at sea-level. Typically this is because you didn't include any elevation data in your tg-construct command. Make sure there's a STRM-3 directory included in the command-line.
* All terrain copies the material of a certain shapefile. You have probably forgotten to put each of the downloaded shapefiles in a seperate directory inside the Data/shapefiles directory.
* genapts850 never passes the stage "Adding airport <ICAO> to parse list": did you unzip <code>apt.dat.gz</code>?

== General comments from forum discussion ==
{{cquote|f-ojac, you are right, the parameters used in scenery 2.0 were "-e 5 -x 20000" according to the wiki. I don't know why I had the impression these parameters were not public. In any case, it does not matter because using the same parameters will create closer results, but they are not guaranteed to be the same.

The parameters used to create scenery 2,0 seem to be:

-m ??: the minimum number of vertices in a tile. In FG, any number bellow 100 (and probably, any number below 1000) will do. I don't think there is any surface on the world perfectly flat for several kilometers. The default value is 50 and I'm sure is ok for any normal use.
-e 5: the max allowed error for elevation, in meters. That is: if terrafit calculates a simplification of the terrain where all points are at most this distance from the real elevation, no more vertices are created. The default value is 40 meters: a point may have an elevation error up to 40m (~100ft) High values for this parameter create less detailed mountains and smaller (in disk size) and more efficient (in FPS) terrain.
-x 20000: the max number of vertices in a tile. If this number of vertices is reached, terrafit stop regardless the max error of the vertices. The default value is 1000

Keep in mind you can set values that do not make sense:

* "-e 1 -x 100" does not make sense because it is going to be impossible to calculate errors less than 1 meters using only 100 vertices. The max number of vertices will be reached always and the max error will be probably ignored.
* "-e 300 -x 20000" does not make sense, tiles are going to use for sure much less vertices than 20,000 because you are allowing huge elevation errors.

If you want an efficient scenery (less vertices), use the default values "-e 40 -x 1000". If you want more accurate elevation at the cost of disk space and FPS, use values similar to scenery 2.0 ("-e 5 -x 20000") Anything in the middle will produce performance and disk use in the middle.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=5&t=24681#p225363
|title=Re: Terrasync Help (surprinsingly!) :)
|author=ludomotico |date= Mon Nov 24, 2014 4:28 am}}</ref>|ludomotico}}

<references/>

== Related content ==
* [[Howto:Create custom terrain]], editing/making terrain data.
* [[TerraGear CORINE]], building terrain from CORINE data.
* [[TerraGear Documentation]], using TerraGear details.

{{Terra}}

[[Category:Scenery enhancement|TerraGear, Using]]

[[fr:Utiliser TerraGear]]
[[zh:Using TerraGear]]

Howto talk:Start core development

2021-05-09T13:15:39Z

The FL3dd0x: /* YouTube playlist link not working */

= Open questions =
* merge requests (post follow-up to mailing list and file review via issue tracker)

= Planned improvements =
* navigating the source trees (FG + SG)
* FG entry point (bootstrap.cxx)
* the FG main loop
* FG subsystems
* adding new fgcommands
* adding new network protocols
* adding new telnet/props commands
* adding new startup options (options.cxx)
* adding new subsystems
* networking
* scripting
* GUI code
* instruments
* list of FG related projects (URLs, type of software)
* list of FG related websites
* list of FG related people (i.e. developers)
* gdb, valgrind, gprof, gcov

== Use of "repo" links in wiki pages. ==

I'm not sure there's much advantage to using the "repo" link system. It's an abstraction that protects us against something that happens extremely rarely (changing of the main git repositories) at the cost of an obscure macro-like thing in the wiki text. Personally i'm with the Python philosophy of "Explicit is better than implicit" in this case. Apart from anything else, the most likely change to repositories is not a simple move to different location, but a merging of flightgear and simgear into a single repository, for which the repo macro is useless. [[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 10:34, 22 November 2020 (EST)

: It was agreed on by the people involved in updating the wiki after the last migration, and given that another migration is currently being discussed, it might not be such a bad idea. I do think that the existing macros could be adapted to reflect a merged repository (if the need arises). If in doubt, Johan and bugman were primarily involved in establishing these "link templates", but it seemed other wiki admins were also convinced it's a good idea, here's the original context: http://wiki.flightgear.org/index.php?title=FlightGear_wiki:Village_pump&oldid=87148#Repository_link_templates --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:09, 22 November 2020 (EST)

:: I manually did the large part of that migration myself. The pain is insane! The changes could not be scripted - my attempts ended in a large proportion of dead links. There is too much variability and redundancy in the PHP query strings. I dealt with something like 5000 dead gitorious links manually, one by one. It took me weeks, and innumerable hours of work. If there is another infrastructure change, now with the {{tl|repo link}} family of templates I can migrate all of those 5000 links within seconds. Or if SourceForge, GitHub, GitLab, or the Gitorious archive change their URLs or PHP query string interface, I can fix all links within a single location. In 20 years we will still have the wiki and we would probably have gone through one or two infrastructure migrations, just as we have been through 3 different infrastructures in the previous 20 years (Curt's CVS server, Gitorious, and SourceForge). So there is a very big advantage for the long term viability of the wiki.

:: A merged repository is also no problem for these templates. Just as I experimented with creating that merged repository, I also looked into what is required for the templates, and this is trivial (either for a merged repository, a submodule, or a subtree).

:: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 16:32, 22 November 2020 (EST)

::: Agreed, I am entirely with bugman on this ...wiki admins (and hosting providers) come and go, but we don't really have many people interested in doing such tedious work. In fact, I wish there were more people with the privileges that Simon and Gijs have, so this mediawiki installation itself could be better maintained here. For instance, these template are enormously helpful, but obviously it could really go a long way if such helper templates were properly integrated in the WYSIWYG editor/interface - this, and many similar requests have been made over the years, but were rarely implemented by our server admins. Thus, templates like these are a compromise obviously, but I'd rather use these than have no option at all. So, thank you bugman for all your work here !! (to be fair, {{Usr|Red Leader}} did have an instrumental role in the development of the original idea. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:40, 22 November 2020 (EST)

:::: To be fair, you'd need to have seen it or looked at the {{tl|repo link}} history to know that I did some major work on that template. From its history it is clear that {{usr|Red Leader}} started these templates. I only extended the family and the dealt with the direct and dead link Gitorious mess.

:::: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 16:55, 22 November 2020 (EST)

Ok, fair enough, thanks everyone for explaining things.

Is there more information about the repository links system somewhere? I couldn't see anything in [[Special:SpecialPages]] for example?

[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 05:22, 23 November 2020 (EST)

: Everything is reachable from [[:Category:Repository_link_templates]], and each template is documented. Maybe the table in {{tl|Repo link/doc related}} could be better documented?

: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 05:27, 23 November 2020 (EST)

= YouTube playlist link not working =

Hi, I just found out that the link to the YouTube tutorial playlist doesn't work any more, as YouTube changed their playlist links and ID's: http://www.youtube.com/view_play_list?p=1D6727247CA35794. I also wasn't able to find the playlist on YouTube.
[[User:The FL3dd0x|The FL3dd0x]] ([[User talk:The FL3dd0x|talk]]) 13:12, 9 May 2021 (UTC)

Howto talk:Start core development

2021-05-09T13:14:55Z

The FL3dd0x: /* YouTube playlist pink not working */

= Open questions =
* merge requests (post follow-up to mailing list and file review via issue tracker)

= Planned improvements =
* navigating the source trees (FG + SG)
* FG entry point (bootstrap.cxx)
* the FG main loop
* FG subsystems
* adding new fgcommands
* adding new network protocols
* adding new telnet/props commands
* adding new startup options (options.cxx)
* adding new subsystems
* networking
* scripting
* GUI code
* instruments
* list of FG related projects (URLs, type of software)
* list of FG related websites
* list of FG related people (i.e. developers)
* gdb, valgrind, gprof, gcov

== Use of "repo" links in wiki pages. ==

I'm not sure there's much advantage to using the "repo" link system. It's an abstraction that protects us against something that happens extremely rarely (changing of the main git repositories) at the cost of an obscure macro-like thing in the wiki text. Personally i'm with the Python philosophy of "Explicit is better than implicit" in this case. Apart from anything else, the most likely change to repositories is not a simple move to different location, but a merging of flightgear and simgear into a single repository, for which the repo macro is useless. [[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 10:34, 22 November 2020 (EST)

: It was agreed on by the people involved in updating the wiki after the last migration, and given that another migration is currently being discussed, it might not be such a bad idea. I do think that the existing macros could be adapted to reflect a merged repository (if the need arises). If in doubt, Johan and bugman were primarily involved in establishing these "link templates", but it seemed other wiki admins were also convinced it's a good idea, here's the original context: http://wiki.flightgear.org/index.php?title=FlightGear_wiki:Village_pump&oldid=87148#Repository_link_templates --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:09, 22 November 2020 (EST)

:: I manually did the large part of that migration myself. The pain is insane! The changes could not be scripted - my attempts ended in a large proportion of dead links. There is too much variability and redundancy in the PHP query strings. I dealt with something like 5000 dead gitorious links manually, one by one. It took me weeks, and innumerable hours of work. If there is another infrastructure change, now with the {{tl|repo link}} family of templates I can migrate all of those 5000 links within seconds. Or if SourceForge, GitHub, GitLab, or the Gitorious archive change their URLs or PHP query string interface, I can fix all links within a single location. In 20 years we will still have the wiki and we would probably have gone through one or two infrastructure migrations, just as we have been through 3 different infrastructures in the previous 20 years (Curt's CVS server, Gitorious, and SourceForge). So there is a very big advantage for the long term viability of the wiki.

:: A merged repository is also no problem for these templates. Just as I experimented with creating that merged repository, I also looked into what is required for the templates, and this is trivial (either for a merged repository, a submodule, or a subtree).

:: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 16:32, 22 November 2020 (EST)

::: Agreed, I am entirely with bugman on this ...wiki admins (and hosting providers) come and go, but we don't really have many people interested in doing such tedious work. In fact, I wish there were more people with the privileges that Simon and Gijs have, so this mediawiki installation itself could be better maintained here. For instance, these template are enormously helpful, but obviously it could really go a long way if such helper templates were properly integrated in the WYSIWYG editor/interface - this, and many similar requests have been made over the years, but were rarely implemented by our server admins. Thus, templates like these are a compromise obviously, but I'd rather use these than have no option at all. So, thank you bugman for all your work here !! (to be fair, {{Usr|Red Leader}} did have an instrumental role in the development of the original idea. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:40, 22 November 2020 (EST)

:::: To be fair, you'd need to have seen it or looked at the {{tl|repo link}} history to know that I did some major work on that template. From its history it is clear that {{usr|Red Leader}} started these templates. I only extended the family and the dealt with the direct and dead link Gitorious mess.

:::: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 16:55, 22 November 2020 (EST)

Ok, fair enough, thanks everyone for explaining things.

Is there more information about the repository links system somewhere? I couldn't see anything in [[Special:SpecialPages]] for example?

[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 05:22, 23 November 2020 (EST)

: Everything is reachable from [[:Category:Repository_link_templates]], and each template is documented. Maybe the table in {{tl|Repo link/doc related}} could be better documented?

: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 05:27, 23 November 2020 (EST)

= YouTube playlist link not working =

Hi, I just found out that the link to the YouTube tutorial Playlist doesn't work any more, as YouTube changed their playlist links and ID's: http://www.youtube.com/view_play_list?p=1D6727247CA35794. I also wasn't able to find the playlist on YouTube.
[[User:The FL3dd0x|The FL3dd0x]] ([[User talk:The FL3dd0x|talk]]) 13:12, 9 May 2021 (UTC)

Howto talk:Start core development

2021-05-09T13:14:37Z

The FL3dd0x:

= Open questions =
* merge requests (post follow-up to mailing list and file review via issue tracker)

= Planned improvements =
* navigating the source trees (FG + SG)
* FG entry point (bootstrap.cxx)
* the FG main loop
* FG subsystems
* adding new fgcommands
* adding new network protocols
* adding new telnet/props commands
* adding new startup options (options.cxx)
* adding new subsystems
* networking
* scripting
* GUI code
* instruments
* list of FG related projects (URLs, type of software)
* list of FG related websites
* list of FG related people (i.e. developers)
* gdb, valgrind, gprof, gcov

== Use of "repo" links in wiki pages. ==

I'm not sure there's much advantage to using the "repo" link system. It's an abstraction that protects us against something that happens extremely rarely (changing of the main git repositories) at the cost of an obscure macro-like thing in the wiki text. Personally i'm with the Python philosophy of "Explicit is better than implicit" in this case. Apart from anything else, the most likely change to repositories is not a simple move to different location, but a merging of flightgear and simgear into a single repository, for which the repo macro is useless. [[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 10:34, 22 November 2020 (EST)

: It was agreed on by the people involved in updating the wiki after the last migration, and given that another migration is currently being discussed, it might not be such a bad idea. I do think that the existing macros could be adapted to reflect a merged repository (if the need arises). If in doubt, Johan and bugman were primarily involved in establishing these "link templates", but it seemed other wiki admins were also convinced it's a good idea, here's the original context: http://wiki.flightgear.org/index.php?title=FlightGear_wiki:Village_pump&oldid=87148#Repository_link_templates --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:09, 22 November 2020 (EST)

:: I manually did the large part of that migration myself. The pain is insane! The changes could not be scripted - my attempts ended in a large proportion of dead links. There is too much variability and redundancy in the PHP query strings. I dealt with something like 5000 dead gitorious links manually, one by one. It took me weeks, and innumerable hours of work. If there is another infrastructure change, now with the {{tl|repo link}} family of templates I can migrate all of those 5000 links within seconds. Or if SourceForge, GitHub, GitLab, or the Gitorious archive change their URLs or PHP query string interface, I can fix all links within a single location. In 20 years we will still have the wiki and we would probably have gone through one or two infrastructure migrations, just as we have been through 3 different infrastructures in the previous 20 years (Curt's CVS server, Gitorious, and SourceForge). So there is a very big advantage for the long term viability of the wiki.

:: A merged repository is also no problem for these templates. Just as I experimented with creating that merged repository, I also looked into what is required for the templates, and this is trivial (either for a merged repository, a submodule, or a subtree).

:: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 16:32, 22 November 2020 (EST)

::: Agreed, I am entirely with bugman on this ...wiki admins (and hosting providers) come and go, but we don't really have many people interested in doing such tedious work. In fact, I wish there were more people with the privileges that Simon and Gijs have, so this mediawiki installation itself could be better maintained here. For instance, these template are enormously helpful, but obviously it could really go a long way if such helper templates were properly integrated in the WYSIWYG editor/interface - this, and many similar requests have been made over the years, but were rarely implemented by our server admins. Thus, templates like these are a compromise obviously, but I'd rather use these than have no option at all. So, thank you bugman for all your work here !! (to be fair, {{Usr|Red Leader}} did have an instrumental role in the development of the original idea. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:40, 22 November 2020 (EST)

:::: To be fair, you'd need to have seen it or looked at the {{tl|repo link}} history to know that I did some major work on that template. From its history it is clear that {{usr|Red Leader}} started these templates. I only extended the family and the dealt with the direct and dead link Gitorious mess.

:::: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 16:55, 22 November 2020 (EST)

Ok, fair enough, thanks everyone for explaining things.

Is there more information about the repository links system somewhere? I couldn't see anything in [[Special:SpecialPages]] for example?

[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 05:22, 23 November 2020 (EST)

: Everything is reachable from [[:Category:Repository_link_templates]], and each template is documented. Maybe the table in {{tl|Repo link/doc related}} could be better documented?

: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 05:27, 23 November 2020 (EST)

= YouTube playlist pink not working =

Hi, I just found out that the link to the YouTube tutorial Playlist doesn't work any more, as YouTube changed their playlist links and ID's: http://www.youtube.com/view_play_list?p=1D6727247CA35794. I also wasn't able to find the playlist on YouTube.
[[User:The FL3dd0x|The FL3dd0x]] ([[User talk:The FL3dd0x|talk]]) 13:12, 9 May 2021 (UTC)

Howto talk:Start core development

2021-05-09T13:12:07Z

The FL3dd0x: /* YouTube playlist pink not working */ new section

= Open questions =
* merge requests (post follow-up to mailing list and file review via issue tracker)

= Planned improvements =
* navigating the source trees (FG + SG)
* FG entry point (bootstrap.cxx)
* the FG main loop
* FG subsystems
* adding new fgcommands
* adding new network protocols
* adding new telnet/props commands
* adding new startup options (options.cxx)
* adding new subsystems
* networking
* scripting
* GUI code
* instruments
* list of FG related projects (URLs, type of software)
* list of FG related websites
* list of FG related people (i.e. developers)
* gdb, valgrind, gprof, gcov

== Use of "repo" links in wiki pages. ==

I'm not sure there's much advantage to using the "repo" link system. It's an abstraction that protects us against something that happens extremely rarely (changing of the main git repositories) at the cost of an obscure macro-like thing in the wiki text. Personally i'm with the Python philosophy of "Explicit is better than implicit" in this case. Apart from anything else, the most likely change to repositories is not a simple move to different location, but a merging of flightgear and simgear into a single repository, for which the repo macro is useless. [[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 10:34, 22 November 2020 (EST)

: It was agreed on by the people involved in updating the wiki after the last migration, and given that another migration is currently being discussed, it might not be such a bad idea. I do think that the existing macros could be adapted to reflect a merged repository (if the need arises). If in doubt, Johan and bugman were primarily involved in establishing these "link templates", but it seemed other wiki admins were also convinced it's a good idea, here's the original context: http://wiki.flightgear.org/index.php?title=FlightGear_wiki:Village_pump&oldid=87148#Repository_link_templates --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:09, 22 November 2020 (EST)

:: I manually did the large part of that migration myself. The pain is insane! The changes could not be scripted - my attempts ended in a large proportion of dead links. There is too much variability and redundancy in the PHP query strings. I dealt with something like 5000 dead gitorious links manually, one by one. It took me weeks, and innumerable hours of work. If there is another infrastructure change, now with the {{tl|repo link}} family of templates I can migrate all of those 5000 links within seconds. Or if SourceForge, GitHub, GitLab, or the Gitorious archive change their URLs or PHP query string interface, I can fix all links within a single location. In 20 years we will still have the wiki and we would probably have gone through one or two infrastructure migrations, just as we have been through 3 different infrastructures in the previous 20 years (Curt's CVS server, Gitorious, and SourceForge). So there is a very big advantage for the long term viability of the wiki.

:: A merged repository is also no problem for these templates. Just as I experimented with creating that merged repository, I also looked into what is required for the templates, and this is trivial (either for a merged repository, a submodule, or a subtree).

:: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 16:32, 22 November 2020 (EST)

::: Agreed, I am entirely with bugman on this ...wiki admins (and hosting providers) come and go, but we don't really have many people interested in doing such tedious work. In fact, I wish there were more people with the privileges that Simon and Gijs have, so this mediawiki installation itself could be better maintained here. For instance, these template are enormously helpful, but obviously it could really go a long way if such helper templates were properly integrated in the WYSIWYG editor/interface - this, and many similar requests have been made over the years, but were rarely implemented by our server admins. Thus, templates like these are a compromise obviously, but I'd rather use these than have no option at all. So, thank you bugman for all your work here !! (to be fair, {{Usr|Red Leader}} did have an instrumental role in the development of the original idea. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:40, 22 November 2020 (EST)

:::: To be fair, you'd need to have seen it or looked at the {{tl|repo link}} history to know that I did some major work on that template. From its history it is clear that {{usr|Red Leader}} started these templates. I only extended the family and the dealt with the direct and dead link Gitorious mess.

:::: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 16:55, 22 November 2020 (EST)

Ok, fair enough, thanks everyone for explaining things.

Is there more information about the repository links system somewhere? I couldn't see anything in [[Special:SpecialPages]] for example?

[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 05:22, 23 November 2020 (EST)

: Everything is reachable from [[:Category:Repository_link_templates]], and each template is documented. Maybe the table in {{tl|Repo link/doc related}} could be better documented?

: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 05:27, 23 November 2020 (EST)

== YouTube playlist pink not working ==

Hi, I just found out that the link to the YouTube tutorial Playlist doesn't work any more, as YouTube changed their playlist links and ID's: http://www.youtube.com/view_play_list?p=1D6727247CA35794. I also wasn't able to find the playlist on YouTube.
[[User:The FL3dd0x|The FL3dd0x]] ([[User talk:The FL3dd0x|talk]]) 13:12, 9 May 2021 (UTC)