- Don't ignore pushbackRoute="0".
- Stricter parsing with precise log messages when the input is
incorrect.
- Add missing includes in src/Airports/dynamicloader.cxx.
See <https://sourceforge.net/p/flightgear/mailman/message/35788373/> for
the discussion about this change.
Before SimGear commit a962c90b30f36575d01162b64471fa77473237a0,
SGPath::pathListSep was a char in static memory that was not necessarily
followed by '\0'. As a consequence, using &SGPath::pathListSep as a
C-style string could result in a string containing the correct separator
*plus* whatever followed in memory until the first null byte...
SimGear commit a962c90b30 changes this situation by making
SGPath::pathListSep an array of two const chars: the path list separator
followed by a '\0'.
This commit simply adapts FlightGear to this change, which fixes a
couple of bugs where the separator was used, mainly unneeded NavCache
rebuilds due to the "apt.dat", "fix.dat" and "nav.dat" properties in the
SQLite database containing the correct paths separated by a possibly
incorrect separator string (there was no alteration of the cache
contents as far as I can tell, since the db property is only used to
check if the lists of apt.dat, fix.dat and nav.dat files have changed).
Some buggy *.groundnet.xml files (as KSEA currently on TS) define the
pushback hold point for some parking positions as a node on a runway.
In this case, this the pushback hold point for parking
'North_Cargo_Ramp', defined as node 5344 in
Airports/K/S/E/KSEA.groundnet.xml, which is defined twice (second error),
first as:
<node index="5344" lat="N47 27.774559" lon="W122 18.465257" isOnRunway="1" holdPointType="PushBack" />
and then as:
<node index="5344" lat="N47 27.725747" lon="W122 18.159649" isOnRunway="1" holdPointType="PushBack" />
(due to code in flightgear/src/Airports/dynamicloader.cxx, it should be
the second one that wins, which is not on a runway but on apron in the
north cargo area)
As a consequence, when this gate is selected for an AI aircraft, the
pushback route has only one node (since the pushback hold point is then
the closest point to itself supposedly on runway!), and the
corresponding FGTaxiRoute instance has an empty 'routes' member
variable, which FGTaxiRoute::next() doesn't handle gracefully
(segfault).
It may be that an additional check/change could be desirable in
FGTaxiRoute::next() in such a case (one node and obviously no route in
the FGTaxiRoute instance), however I'm not sure how Durk wants this case
to be handled, since FGTaxiRoute::next() seems to iterate on nodes.
This fixes the bug reported at:
https://forum.flightgear.org/viewtopic.php?p=308397#p308397 and
https://sourceforge.net/p/flightgear/mailman/message/35776552/
Thanks to yanfiz and wkitty42 for the report, and to gooneybird for
inspecting the groundnet file.
This is because FGTaxiNode::ident() is generally (always?) an empty
string for FGTaxiNode instances. This concerns the:
unreferenced groundnet node: ...
warning. Also remove one tiny use of boost.
We now show paths in ‘view command line’ and set them through the
standard mechanism. Re-ordering the paths also notifies the rest of
the system correctly.
Code and tests to demonstrate migrating of older auto-save files, with
blacklisting support to exclude properties. Disabled pending agreement
on the required blacklisting values.
Some pieces of code such as fgMainInit() and, by cascading effect,
fgInitHome(), were careful to return a meaningful value indicating
success or error, however the main() function in src/Main/bootstrap.cxx
ignored it royally so far.
main() now returns:
- EXIT_FAILURE if fgMainInit() or fgviewerMain() throws an exception;
- whatever said function returns otherwise.
- Rename fatalMessageBox() to fatalMessageBoxWithoutExit(). This should
prevent the kind of bug that prompted this set of changes: someone
calling fatalMessageBox(), assuming the program would stop at that
point, whereas in reality it did not.
- Add new function fatalMessageBoxThenExit(). This is not vital of
course, but allows one to spare one line here and there and to apply
the DRY principle for such fatal exits.
- Replace every existing call to fatalMessageBox() with one or the other
of the two new functions. Improve formatting along the way. This
fixes a few bugs of the kind explained above.
This reverts commit 9e6a3ebc6b ("Make
fatalMessageBox() end with std::abort() and declare it [[noreturn]]").
After reflexion, it seems better to let fatalMessageBox() return,
because there is existing code that appears to be relying on this aspect
to do some work after having called fatalMessageBox() (cf. main() in
bootstrap.cxx). Also, the way of exiting from fatalMessageBox() after
commit 9e6a3ebc6b (std::abort()) was probably too brutal for a
controlled exit---as opposed to a terminate handler.
Basically, this is because fatalMessageBox() is only safe to call from
the GUI thread, however it seems fg_terminate() can be called from any
thread (according to C++11 semantics). Additionally, fatalMessageBox()
typically requires some work to happen in the GUI thread (event loop) in
order to display something, but we can't realistically expect this while
running a terminate handler just before the program dies.
See messages around
<https://sourceforge.net/p/flightgear/mailman/message/35775803/> for a
discussion of this subject.
+ Minor header cleanup (<locale.h> replaced with <clocale>, etc.)
/sim/multiplay/protocol-version is either 1 or 2 and controls how packets are sent. V2 packets will only have the (motioninfo) basic properties visible to older clients.
New string encoding that is efficient.
Support short int encoding (pack a property and value into 4 bytes).
Allow properties to be transmitted using a different encoding to the property type in the tree.
Support scaled floats; most of the floats we transmit are small and thus can fit into a scaled short.
V2 protocol uses transmit so most properties are either scaled floats or short ints.
Allow the client to request a larger visibility range by setting /sim/multiplay/visibility-range-nm. This will transmit in the repurposed header field ReplyAddress - which has been renamed to RequestedRangeNm. This will require support from fgms to actually do anything.
Extra debugging options. The most useful (for aircraft developers) is the loopback bit, as this allows model multiplay testing without running two instances.
Update property /sim/multiplay/last-xmit-packet-len with the size of the packet transmitted
Debug level bits in property /sim/multiplay/debug-level
bit 1 - loopback (show your own model as an MP model)
bit 2 - dump outgoing packets
bit 3 - dump incoming packets
bit 4 - hexdump outgoing packets
/sim/multiplay/protocol-version is either 1 or 2 and controls how packets are sent. V2 packets will only have the (motioninfo) basic properties visible to older clients.
New string encoding that is efficient.
Support short int encoding (pack a property and value into 4 bytes).
Allow properties to be transmitted using a different encoding to the property type in the tree.
Support scaled floats; most of the floats we transmit are small and thus can fit into a scaled short.
V2 protocol uses transmit so most properties are either scaled floats or short ints.
Allow the client to request a larger visibility range by setting /sim/multiplay/visibility-range-nm. This will transmit in the repurposed header field ReplyAddress - which has been renamed to RequestedRangeNm. This will require support from fgms to actually do anything.
Extra debugging options. The most useful (for aircraft developers) is the loopback bit, as this allows model multiplay testing without running two instances.
Update property /sim/multiplay/last-xmit-packet-len with the size of the packet transmitted
Debug level bits in property /sim/multiplay/debug-level
bit 1 - loopback (show your own model as an MP model)
bit 2 - dump outgoing packets
bit 3 - dump incoming packets
bit 4 - hexdump outgoing packets
We probably need a warning for cross-aircraft paths, but leaving that
for a separate change since I’m worried it will warn on MP aircraft.
Maybe better checked in the Python scripts than in the app?
Compile a useful subset of FG as a shared library, and add two basic
uses of this to exercise some Flightplan / RoutePath / navaid
functions.
The test framework can/will be expanded incrementally from here, this
is just a starting point.
As part of this, add the ability to distinguish default vs explicit
airport selection via a new /sim/presets/airport-requested flag. This
enables us to more cleanly handle different combinations of startup,
especially the case where the user requests an airport but no runway
(wants auto selection), ensuring we don’t look for the default airport’s
runway (from location-presets.xml) in that case.
This renders sgGMTime obsolete, it will go away shortly. Thanks to
Ron H for help tracking this down and Richard Harrison for his
knowledge of Windows APIs in confirming the issue.
Read all values as floating point before applying a factor, then
convert to the target type (int, byte or short). Suggested and
implemented by Oliver Kroth.
As suggested by Chris, these are normalised and account for the logo
size after scaling, so 0.5 will centre, 1.0 is the right/bottom edge.
E.g. (in /sim/startup)
<splash-logo-x-norm>0.5</splash-logo-x-norm>
<splash-logo-y-norm>0.9</splash-logo-y-norm>
Many values will overlap with other text, so use with care!
When adding a scenery path in the built-in launcher, accept folders
containing any of the new directories populated by osm2city. Also try to
improve the message that is displayed when the sanity check conditions
for the added scenery path aren't met (cf. discussion around
<https://sourceforge.net/p/flightgear/mailman/message/35716946/>).
* Propeller required power now accounts for the engine tilt
* Fixed a division by zero in FGLGear::GetSteerNorm for non steerable gears
* Fixed a bug reported by Ron H. and Rebecca N. Palmer on the FG mailing list: the 'length' parameter passed to gethostbyaddr in FGFdmSocket was erroneous.
- Declare 'datTypeStr' and 'defaultDatFile' as public member variables
of NavDataCache ('defaultDatFile' is not *required* for this commit,
it just seems to make sense to treat both members the same way/keep
them together in the source code).
- New keys under "navigation data" in the JSON report: "fix.dat files"
and "nav.dat files".
The frequency field is always an integer, so reading it as a float to
convert it to int doesn't make sense. I've probably been confused by
field indices when I introduced this in commit a2bf424118.
This clarifies things, but shouldn't change the code behavior in any
way (unless with bogus nav.dat files, of course).
This allows using NavXP1100-formatted nav.dat from gateway.x-plane.com.
The skipped field types are:
14 Final approach path alignment point of an SBAS or GBAS approach path
15 GBAS differential ground station of a GLS
16 Landing threshold point or fictitious threshold point of an SBAS/GBAS
approach
We don't have SBAS/GBAS in Flightgear.
This change also includes duplicate detection for multiple nav.dat files
support.
Make a single Cmake value to expose the build type to code, and use
this to default a run-time ‘developer-mode’ property, which can be
over-ridden from the command line.
Use this to drive the different warning levels. Policies subject to
review, especially whether nightly builds should default to
developer mode or not.
Uses TTF fonts, and displays more information textually including
the application version and current aircraft.
Also rename FGRenderer::splashinit to preinit, as was suggested
a long time ago.
On Mac it was visible as random strings displayed in the route manager
dialog for selected SIDs and STARs.
Depends on a SimGear change which introduces SGStringValueMethods.
1. Add support for scaled floats; most of the floats we transmit are small and thus can fit into a scaled short.
2. Change most properties to use scaled floats.
Support for short int encoded values (32 bits with 16 bit for ID and 16 bits for value)
Added extra debugging options
1. Debug level
bit 1 - loopback (show your own model as an MP model)
bit 2 - dump outgoing packets
bit 3 - dump incoming packets
bit 4 - hexdump outgoing packets
2. Update property (/simwith packet
- configurable debug (loopback, packet trace (in,out), packet dump)
- prevent properties from being visible to V1 clients - to ensure reliable compatibility, with just the basic position message being processed. This allows more changes to the V2 protocol whilst giving basic V1 support
- add debug
Based on the comments in the list I think it is better to keep the type that was originally provided as a reference, take the address of it, and store that in a ref_ptr.
Possibly the problem was never compiler related rather OSG related; I'm using 3.5.x and it appears that there are better built in type conversions compared to the target version of 3.2 that we are currently using.
Whilst debugging I had a cannot increment nextIt - because it was at end(). No idea if this could ever happen in flight but it still seems sensible to protect against it.
Use pointers to allow compilation on Linux/Mac until this is fixed properly as OSG elements should always be accessed via the reference counting mechanism.
Change to use pointers rather than osg::ref_ptr<osg::Group> - based on http://andesengineering.com/OSG_ProducerArticles/RefPointers/RefPointers I think that it is not possible that the scenegraph can be modified between the visitor and the modify, provided that the methods are called after each other like this:
ReplaceStaticTextureVisitor visitor(name, new_texture);
branch->accept(visitor);
visitor.modify_groups();
return visitor.getPlacements();
The visitor would modify the scenegraph during the traversal by inserting groups; this is not valid when using vectors, and MSVC2015 debug RTL throws an exception when this happens.
The fix is to simply make a list of the textures that need to be modified and modify once the scenegraph traversal has finished.
This change is the logical counterpart of SimGear's change from commit
79f869a7f32910197be72b21f6489fbbba02c836 that moved the following files
from simgear/misc to simgear/io/iostreams:
gzcontainerfile.cxx
gzcontainerfile.hxx
gzfstream.cxx (formerly zfstream.cxx)
gzfstream.hxx (formerly zfstream.hxx)
sgstream.cxx
sgstream.hxx
sgstream_test.cxx
This is where the ID and the 16 bit value are transitted in the ID field; with no data field. The ID is in the highword - and this is detected by the client and processed as |ID |VALU|
/sim/multiplay/protocol-version is either 1 or 2
The properties defined in multiplaymgr define which version they are related to; however if these are in a more recent protocol than selected they will be transmitted in the selected protocol version.
The id property list now defines a "transmit as" - however this is not yet implemented.
This commit is intended to be a WIP towards changes for 2017.1 that will ensure any future protocol changes are compatible with this version (so this 2017.1 would be able to see a protocl V3 FG if one ever existed), key to this is to stop processing the property list as soon as an unknown ID is encountered.
This moves certain properties into a second part of the buffer that isn't visible to the first with the intention of making a backwards compatible MP protocol that can have more efficient encoding in a second part that is after MsgLen.
Unfortunately this doesn't work because the code ensures that MsgLen in the header matches the received byte count.
Each argument creates another log file, in the directory named. Symbolic
value ‘desktop’ creates logs on the user’s desktop.
Needs corresponding SimGear commit to build
The mirror protocol now sends the position for internal as well as
leaf nodes, and the group uses this data to sort when no explicit
Z-indices exist. This gets the extra-500 much closer to working!
For unknown reasons this seems to alleviate the word-wrap / min-height
bug on Windows. Committing so we can test and verify this is really
the case before the next release.
Requires FGData commit: 0565eaab10a5d466cd485766b17d1870936a0a57
(which actually renames the file).
Also disables the preferences-load command since I don’t believe it
would actually be safe to reload the defaults without doing a simulator
reset (aircraft -set.xml values would be overwritten, for example)
As discussed on the devel list, only require the major+minor versions
of FG+SG+data to match by default. If we encounter a situation on
a release branch where stronger checks are needed, it’s easy to
restore.
Essentially, adapt two places where options.xml was supposed to be found
in $FG_ROOT (in one of these, the comment was already incorrect way
before the recent change moving options.xml out of FGData).
$FG_INSTALL_PREFIX represents the FlightGear installation prefix, such
as /usr, /usr/local or /opt/FlightGear on Unix systems. Copying the
--help output and translated strings there avoids having to write to
$FG_ROOT when 'make install' (or some OS-dependent equivalent) is run
from the FlightGear build directory---that would be ugly when $FG_ROOT
points to the FGData Git repository.
In FGLocale::FGLocale(), Translations/locale.xml is loaded using
readProperties() and fatalMessageBox() (in case an error is
encountered). Note that it couldn't be loaded via fgLoadProps() in the
current state, because this function relies on guiErrorMessage() when an
error is encountered, which calls mkDialog(), which itself does
globals->get_subsystem("gui"). This last call can't be done from
FGGlobals' constructor---where the 'globals' pointer is still
NULL---hence the need for a different mechanism not relying on
FGGlobals.
For consistency, and also because it provides a better user experience[1],
load options.xml using the same method instead of with fgLoadProps().
[1] I.e., in case of an error, the user gets to see a graphical popup
window with an explanatory message before FG exits, assuming he is
either on Windows, or on Mac, or has Qt support built in FG, as
opposed to only an SG_LOG() call [because when options.xml is
loaded, guiErrorMessage() used by fgLoadProps() can't use the 'gui'
subsystem].
- Add an optional argument to flightgear::initApp(): doInitQSettings.
This argument defaults to true, preserving initApp()'s behavior in
this respect. If this argument is set to false, FGGlobals doesn't have
to be initialized.
- New function flightgear::initQSettings(), called by
flightgear::initApp() when its 'doInitQSettings' argument is true.
This allows initializing the QSettings exactly when it is needed.
- New function flightgear::checkKeyboardModifiersForSettingFGRoot().
The code it contains used to be run from initApp(), which is
undesirable because:
1) initApp() is not only called at FG initialization (fgMainInit()),
but also from QtMessageBox(), from QtFileDialog::exec() and twice
from Options::setupRoot(). However, checking the Alt and Shift
modifiers to set 'fg-root' in QSettings to the special value
"!ask" only makes sense in fgMainInit(), not in these other
places.
2) This code relies on the QSettings to be set up, and therefore on
FGGlobals. Thus, freeing initApp() of its dependency on FGGlobals
requires splitting this keyboard modifiers checking code out of
initApp().
This is likely to fix the problem preventing startup on Windows when the
username contains non-ASCII characters (cf.
<https://forum.flightgear.org/viewtopic.php?f=22&t=31320>). Thanks to
Headhunter76 for the useful report and to wkitty42 for doing the liaison
officer. ;-)
I can't actually test this, because I don't have Windows. Windows users
should report whether this works for them.
There is a Flightgear property called /sim/hitches/winch/automatic-release-angle-deg that can be used to simulate a safety feature built into modern gliders. If the cable angle gets too great during a winch launch, the hook will automatically release the cable. This usually happens when the glider gets almost on top of the winch at the top of the launch without releasing the cable.
Unfortunately winch launching has two separate implementations, one in Nasal for JSBSim, and another one in C++ for YASIM. The YASIM one does not implement this property so I wrote a patch to add this.
Previously timer objects defaulted to using wall-clock (real) dt which
does not reflect pause/speed-up. Keep this as the default for
compatibility but make it possible to request simulated time.
Special case handling when recently removed properties are re-added;
when this happens simply send a value change since it's much cheaper
over the wire and for the receiver. Poorly designed Canvas code does
this frequently (eg, every update)
- Handle file I/O and parsing errors. This allows current
<http://gateway.x-plane.com/navaids/LatestNavFix.zip> to be loaded
instead of failing in an endless loop.
Read the fields of a record with std::getline() followed by
simgear::strutils::split(), itself followed by calls to std::stoi(),
std::stof() and std::stod(). Stream extraction (>>) isn't very good
here, because it can read for instance an int *and* a float from the
string "3.14", i.e. extract 3 followed by 0.14 (thus falsifying the
number of fields found...).
Check the number of fields (not 100 % reliable since the last field,
the navaid name, typically contains spaces---but we can detect
some situations where the number of fields is definitely too low).
- Fix line numbering (sgstream.cxx's skipcomment() isn't fit for this
purpose, because it can gobble any number of lines without the line
number being increased).
- Don't use a hardcoded number of lines for the nav.dat loading
percentage indicator; rely on sg_gzifstream::approxOffset() instead.
- Make navDBInit() and loadCarrierNav() throw an sg_io_exception upon
I/O errors (not for parsing errors that only affect a record). They
don't return a bool anymore (which wasn't checked by their only
caller, anyway).
- Use the 'rowCode' variable name instead of 'rawType' for consistency
with the *.dat specs.
- Small change in tests: (elev_ft < 0.01) replaced with (elev_ft <= 0).
Doesn't change the behavior, since 'elev_ft' is an int. Can be
reverted if someone really prefers the float comparison, I don't mind
that much about it.
- Add missing headers and a few comments.
This commit does not change the contents added to the NavCache with
FlightGear's current $FG_ROOT/Navaids/nav.dat.gz, except for 4 bogus
navaids which are not added anymore (at LIBV, OPJA, RCFN and RCYU): see
<https://sourceforge.net/p/flightgear/mailman/message/35526617/>. They
are instead properly reported as coming from invalid nav.dat lines.
Since the Save function can be triggered from Nasal with an arbitrary
path, we must check this path before overwriting the file.
(also add a missing include that is directly needed for this commit)
Use a recursive listener to expose a property tree via a WebSocket.
Currently using a JSON-based encoding, will likely change to binary so
please don’t write code using this interface until the encoding
is stable and documented!
As discussed on the mailing list, make this more consistent with JSBsim.
We could still define common locations for these values as well, but
waiting on positive answer to that discussion on the ML.
Instead of the two vectors we manually composed, used a single unified
vector of structs to store delegate information in the model. This
simplifies the logic for tracking the active variant (and in the future,
thumbnail).
Search for the closest ground-net node near but /not/ on, the requested
runway. This works fairly well, although for some airports the selected
node is surprisingly far from the runway.
The report now looks like:
{
"meta": {
"type": "FlightGear JSON report",
"format major version": 1,
"format minor version": 0
},
...
}
When making compatible changes to the format (e.g., adding members to
JSON objects), only the minor version number should be increased.
Increase the major version number when a change is backward-incompatible
(such as the removal, renaming or semantic change of a member). Of
course, incompatible changes (like this one) should only be considered
as a last recourse.
- New methods Options::printJSONReport() and utility method
Options::OptionsPrivate::createJSONArrayFromPathList().
- Small addition to Options::processOptions(), since the --json-report
option must be processed *after* the TerraSync and download dirs, as
well as aircraft and scenery paths, have been finally set.
Apart from providing a public method giving a path to the autosave file,
the main idea of this commit is to reduce redundancy where
globals->get_fg_home() was so far used in every place where the autosave
file is needed or saved. Use an optional argument for
FGGlobals::loadUserSettings() and FGGlobals::saveUserSettings()[1],
since it should be exceptional to access an autosave file in another
location than $FG_HOME.
Also add comments explaining how to avoid security pitfalls with
saveUserSettings() (cf. discussion around
<https://sourceforge.net/p/flightgear/mailman/message/35461636/>).
[1] Argument *added* to this method, for consistency with
FGGlobals::loadUserSettings().
- The 'DatFilesGroupInfo' struct and 'DatFileType' enum are now public
members of 'NavDataCache'.
- New public method NavDataCache::getDatFilesInfo() returning the
'DatFilesGroupInfo' struct for a given type of dat files. For
instance, this allows one to retrieve the ordered list of apt.dat
files the NavCache would use if it were rebuilt at that time, as well
as their total size.
Similar to the existing FGGlobals::get/set_terrasync_dir(), add
FGGlobals::get_download_dir() and FGGlobals::set_download_dir() methods,
and of course the corresponding FGGlobals::download_dir public member
variable. FGGlobals::set_download_dir() stores the realpath() of the
given directory, including into the /sim/paths/download-dir property,
which is marked as read-only just as /sim/terrasync/scenery-dir already
is.
Handle the setup of the TerraSync and download dirs all in the same
place (Options::processOptions()), since most of the work is already
done there. This allows one to get rid of fgOptTerrasyncDir() and
fgOptDownloadDir(), and to make it easier to see that
globals->set_terrasync_dir() (resp. globals->set_download_dir()) is
called on the correct SGPath, regardless of whether --terrasync-dir
(resp. --download-dir) was passed.
Always create the TerraSync and download dirs when they don't already
exist, regardless of whether --terrasync-dir or --download-dir has been
given on the command line.
Add comments explaining how to avoid security pitfalls with download and
TerraSync dirs (cf. discussion around
<https://sourceforge.net/p/flightgear/mailman/message/35461636/>).
Adjust indentation where it was too broken, hampering readbility.
1) Paths and the FG_SCENERY paths list are now printed like:
FG_ROOT=/home/flo/flightgear/src/fgdata
instead of:
FG_ROOT=Path "/home/flo/flightgear/src/fgdata"
Moreover, FG_SCENERY is now correctly printed (without 'Path ""'
wrapping, without Terrain, Objects and markers instead of the actual
scenery paths) regardless of the position of --version relatively to
--fg-scenery, --terrasync-dir, etc. Of course, the values given to
these options do influence the output of --version.
Simplify printing of FG_SCENERY via SGPath::join() and use the
correct, OS-dependent separator between paths, SGPath::pathListSep.
Write the --version output to stdout, as already done for --help;
then it can be easily piped to $PAGER and doesn't get mixed with the
output of SG_LOG (which is on stderr). This is of course backward
incompatible for programs reading the stderr output of
'fgfs --version', but has been agreed upon on FlightGear-devel (cf.
<https://sourceforge.net/p/flightgear/mailman/message/35461619/>).
2) Don't write explicit values in the OptionResult enum: they don't
matter, but giving them is error-prone in case one does a copy-paste
to add a new member to the enum and forgets to change the value.
For some reason, g++ may see a 'skipws' I/O manipulator from the
standard library (depending on the order of includes...) when compiling
src/Navaids/poidb.cxx. This I/O manipulator is then in competition with
one with the same name defined in simgear/misc/sgstream.cxx. Use std::ws
to remove all ambiguity (std:skipws does something quite different!).
The new FGLight::updateObjects() function is now being passed into the global
events manager as a task rather than FGLight::updateSunPos(). The
updateSunPos() function has been renamed to updateBodyPos() and generalised for
any solar system body and is called twice by updateObjects(), once for the sun
and once for the moon. The local position of the moon is then exposed at
"/ephemeris/moon/local/".
This includes the moon's absolute position, age and phase. For this, the new
simgear MoonPos::get*() functions are tied to the property tree at
"/ephemeris/moon/" using a new tieMoonPos() function.
In addition the moon illumination factor is exposed by tying the simgear
MoonPos::getIlluminanceFactor() function to the /environment/moonlight property.
This is a number ranging between 0 and 1 based on the log of the illuminance of
the moon outside the atmosphere. It is calculated as
factor = (log(I) - max_loglux) / (max_loglux - min_loglux) + 1.0,
The illuminance of the moon outside the atmosphere, I, is from equation 20 from:
Krisciunas K. and Schaefer B.E. (1991). A model of the brightness of
moonlight, Publ. Astron. Soc. Pacif. 103(667), 1033-1039 (DOI:
http://dx.doi.org/10.1086/132921).
For more background, see
http://forum.flightgear.org/viewtopic.php?f=47&t=28201&start=60#p270516 .
The functions fgSunPositionGST() and fgTimeSecondsUntilSunAngle() have been
renamed to fgBodyPositionGST() and fgBodyPositionGST() respectively, and both
require a new char argument specifying the body of interest. This allows the
position of all solar system bodies to be calculated from the aircraft frame of
reference.
