Only handle PackageRef by reference in the header file, so we don’t
create calls to the copy constructor and/or destructor. If this doesn’t
work will need to create a stub implementation file.
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,
where I is the illuminance of the moon outside the atmosphere and min_loglux and
max_loglux are hardcoded to -0.504030345621 and -4.39964634562 respectively.
Although the value should never be outside of [0, 1], for safety it is clipped
to be between these values. For more background, see
http://forum.flightgear.org/viewtopic.php?f=47&t=28201&start=60#p270516 .
This is the base 10 log of equation 20, converted from foot-candles to lux,
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).
To obtain the sun's true longitude, the Star::getlonEcl() function has been
created. The moon's age is then calculated as the difference between the moon's
and sun's true longitudes. The phase is then simply half of one minus the
cosine of the age. Hence these calculations are very cheap compared to the rest
of the moon position calculations. The algorithm is from:
Duffett-Smith, Peter. Practical Astronomy With Your Calculator. 3rd ed.
Cambridge: Cambridge University Press, 1981. ISBN 0-521-28411-2.
The code can replicate the example in the book of Feb 26, 1979 at 16h UT, with
an age of -0.4767 degrees a phase of 0.0:
$ fgfs --aircraft=UFO --start-date-gmt=1979:02:26:16:00:00 --airport=EGLL \
--altitude=50000 --enable-hud
The calculated phase is 1.459e-5 and the age is -6.2908 (which is -0.43628
degrees). For a recent full moon:
$ fgfs --aircraft=UFO --start-date-gmt=2015:11:25:22:44:00 --airport=EGLL \
--altitude=50000 --enable-hud
The calculated age is -3.1413 and the phase is 0.9999999778.
By storing repetitive intermediate calculations, the number of mathematical
operations for a single call to CelestialBody::updatePosition() has decreased by
12. This matches the changes to MoonPos::updatePosition().
The following functions have been added: MoonPos::getM(), MoonPos::getw(),
MoonPos::getxg(), MoonPos::getyg(), MoonPos::getye(), MoonPos::getze(),
MoonPos::getDistance(). These are copied from and match the Star class
functions (but with xs and ys replaced by xg and yg).
By storing repetitive intermediate calculations, the number of mathematical
operations for a single call to MoonPos::updatePosition() has decreased by 32.
Commit 8277857827 relies on zlib's
gzoffset() function (not just offset(): that was a typo in the commit
message, sorry). This function appeared in zlib 1.2.4 (which dates from
2010). Enforce this requirement with CMake.
This way, one can easily use the OS-dependent separarator for path lists in
other places to build and split path lists in an optimal way (e.g., not
sacrificing ';' on Unix, since the path list separator is ':' on this
platform).
Erik Hofman