FlightGear Newsletter October 2016: Difference between revisions

Jump to navigation Jump to search
Cleanup cont.
(Start cleanup)
(Cleanup cont.)
Line 8: Line 8:
[[#Next default airport|Next default airport]]<br>
[[#Next default airport|Next default airport]]<br>
[[#Git multimail script updated|Git multimail script updated]]<br>
[[#Git multimail script updated|Git multimail script updated]]<br>
[[#Local apt.dat versions support|Local apt.dat versions support]]<br>
{{Newsletter-cover-header|In the hangar}}<br>
{{Newsletter-cover-header|In the hangar}}<br>
  | valign="top" width="33%" |
  | valign="top" width="33%" |
Line 41: Line 42:


=== Local apt.dat versions support ===
=== Local apt.dat versions support ===
{{WIP}}
Thanks to work by Florent Rougon, multiple apt.dat files (which contain airport data) can now be loaded, rather than the single <tt>''[[$FG_ROOT]]/Airports/apt.dat.gz''</tt>.<ref>{{cite web
Thanks to work by Florent Rougon, multiple apt.dat files can now be loaded.
|url    = https://forum.flightgear.org/viewtopic.php?p=296919#p296919
apt.dat now supports local versions:
|title  = apt.dat - local version(s)
 
|author = Alant
Local NavData directory support was added very recently, it wasn't included in 2016.3.1. But even when you do have a more recent version, you still need to use TerraGear to actually generate the visible terrain. NavData is only used for maps, startup locations etc., while the physical layout including runways and taxiways has to be generated in advance with TerraGear.<ref>{{cite web
|date  = Oct 18th, 2016
  |url    =  https://forum.flightgear.org/viewtopic.php?p=297382#p297382
|added  = Oct 18th, 2016
  |title  =  <nowiki> Re:  </nowiki>
|script_version = 0.40
  |author =  <nowiki> Gijs </nowiki>
}}</ref> These files (either <tt>*.dat</tt> or <tt>*.dat.gz</tt>) can be loaded from <tt>'''''Scenery path'''/NavData/apt/''</tt>, where '''Scenery path''' is any path specified by the <code>--fg-scenery</code> command line option. These will take precedence over the default one (<tt>''[[$FG_ROOT]]/Airports/apt.dat.gz''</tt>). Note that any change to apt.dat files should continue to be submitted to the [https://gateway.x-plane.com/ X-Plane gateway] so that they will eventually be included in the main distribution.
  |date  =  Oct 25th, 2016
  |added  =  Oct 25th, 2016
  |script_version = 0.40
  }}</ref>
 
the NavData/apt/*.dat[.gz] files will allow you to see airports on the map, but to see actual 3D terrain different from what is already in TerraSync, running TerraGear and using its output(*) will be necessary.
 
<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=297391#p297391
  |title  =  <nowiki> Re:  </nowiki>  
  |author =  <nowiki> rominet </nowiki>
  |date  =  Oct 25th, 2016
  |added  =  Oct 25th, 2016
  |script_version = 0.40
  }}</ref>
 
 
It is now possible to have one or more local apt.dat files each containing data for one or more airfields.  The airfields in the local apt.dat files take precedence over the contents of the apt.dat.g file that is distributed as part of fgdata. - in much the same way as local custom scenery takes preference over terragear scenery.
If you are using WED, the apt.dat output by that program is suitable.
To use it add a folder NavData/apt in your fg-scenery and place your private files in that folder. <ref>{{cite web
  |url    = https://forum.flightgear.org/viewtopic.php?p=296919#p296919  
  |title  = <nowiki> apt.dat - local version(s) </nowiki>
  |author = <nowiki> Alant </nowiki>
  |date  = Oct 18th, 2016  
  |added  = Oct 18th, 2016  
  |script_version = 0.40  
  }}</ref>
Of course, your apt.dat changes should continue to be submitted to the Xplane gateway so that they will eventually be included in the main distribution.<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=296919#p296919
  |title  =  <nowiki> apt.dat - local version(s) </nowiki>  
  |author =  <nowiki> Alant </nowiki>
  |date  =  Oct 18th, 2016
  |added  =  Oct 18th, 2016
  |script_version = 0.40
  }}</ref>
 
 
No need for any command-line option. As I wrote in <https://sourceforge.net/p/flightgear/mailman/message/35424973/>;, you have to put your apt.dat files (any name ending with .dat or .dat.g is OK) in a structure like the following:
<pre>
Scenery path
├── NavData
│  ├── apt
|  |  ├── vrmg.dat
|  |  ├── vrmh.dat
|  |  ├── vrmk.dat
        ├── vrmm.dat
        ├── vrmo.dat.gz
        └── vrmt.dat
</pre>
 
where "Scenery path" can be any of you scenery paths (e.g., any component of --fg-scenery/$FG_SCENERY; the path given to --terrasync-dir is also one). The files read are all NavData/apt/*.dat[.gz] files inside each scenery path, followed by the default $FG_ROOT/Airports/apt.dat.gz (last in precedence order, thus allowing your custom sceneries to override airports already present in $FG_ROOT/Airports/apt.dat.gz). In the typical case, just put your apt.dat files(*) in the NavData/apt subdirectory of your custom scenery and they will be picked up automatically. In each of these files, you may include as many airport definitions as you want. (*) Actually, any name ending with .dat or .dat.gz---but the syntax inside, of course, must be valid "apt.dat syntax". And if the file name ends in .gz, of course the contents must be gzipped-compressed. <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35432391/
  |title  =  <nowiki> Re: [Flightgear-devel] apt.dat - add local version ? </nowiki>
  |author =  <nowiki> Florent Rougon </nowiki>
  |date  =  Oct 17th, 2016
  |added  =  Oct 17th, 2016
  |script_version = 0.40
  }}</ref>
 
The rule is that your file(s) must end in .dat (or .dat.g if gzip-compressed), there is no requirement to use the airport code in the file name, although of course it is clearer this way if you have one apt.dat file per airport. But it is also possible to have many airports in one big apt.dat or apt.dat.gz file like the $FG_ROOT/Airports/apt.dat.gz that comes with FG.<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=297374#p297374
  |title  =  <nowiki> Re:  </nowiki>
  |author =  <nowiki> rominet </nowiki>
  |date  =  Oct 25th, 2016
  |added  =  Oct 25th, 2016
  |script_version = 0.40
  }}</ref>
you shouldn't add things yourself to the TerraSync folder or even, in this case, to K:\Program Files (x86)\FlightGear 2016.3.1\data created by the FG installation. You should just create a '''new''' folder for your custom scenery (k:\myflightgear\myscenery was an example, choose whatever you want) and declare it as a scenery path to FG. The Airports, Objects and Terrain subfolders are standard folders inside custom sceneries, so in the end if your custom scenery is non-empty, you'll have at least Objects or Terrain.<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=297374#p297374
  |title  =  <nowiki> Re:  </nowiki>
  |author =  <nowiki> rominet </nowiki>
  |date  =  Oct 25th, 2016
  |added  =  Oct 25th, 2016
  |script_version = 0.40
  }}</ref>
As for the startup locations, it is definitely good for the future to include them in these files, but current FG only takes them from groundnet.xml files AFAIK, not apt.dat files (however, I've seen people post links about conversion tools from apt.dat format to groundnet.xml format, so probably the best way currently is to use apt.dat/WED as your primary data source even for startup locations/parkings and generate the groundnet.xml files from that). FFGo does read startup locations from $FG_ROOT/Airports/apt.dat.g, not yet from NavData/apt/*.dat[.gz] files inside scenery paths, but this is coming...<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=297391#p297391
  |title  =  <nowiki> Re:  </nowiki>
  |author =  <nowiki> rominet </nowiki>
  |date  =  Oct 25th, 2016
  |added  =  Oct 25th, 2016
  |script_version = 0.40
  }}</ref>


=== A standalone Canvas NavDisplay Dialog ===  
=== A standalone Canvas NavDisplay Dialog ===  

Navigation menu