- add generic text adjustment and
- use it in the ladder: climb -> vert bar on the outside, numbers below line
dive -> vert bar on the inside, numbers above line
work for ground based distance separation of AIAircraft.
Traffic manager initialization related changes:
- Schedules initialize "on the fly", instead of during initialization
- Invalid routes are no longer deleted, but marked as BOGUS and ignored
- Changed loading order from a distance based prioritization to a point-
score based prioritization, resulting in a much faster establisment of
AIAircraft near the user's plane.
Preparatory work for ground-based separation of Aircraft.
- The groundnetwork findShrortestRoute function not only returns a list
of waypoints, but also a list of taxi "segments" (a.k.a. taxiways).
- The taxiway list is stored in the Flightplan, and updated everytime
a new taxi leg is created.
implications.
Fix the ladder so it "moves" around in the hud correctly based on alpha/beta
offset projected onto the horizon line so the horizon is always the horizon.
using Curt's new speed adjustment code. 2) Separated the function
FlightPlanCreateCruise() into a new source file in preparation of a more
elaborate airway following scheme.
calculations. We run the FDM at 120hz and compute how many loops can fit into each FG loop.
Floating point rounding could lead to a situation where we could end up running
1, 3, 1, 3, 1, 3... loops of the FDM when in fact we want to run 2, 2, 2, 2, 2...
If we artificially inflate ml above by a tiny amount to get the
closest integer, then subtract the integer from the original
slightly smaller value, we can get a negative remainder.
Logically this should never happen, and we definitely don't want
to carry a negative remainder over to the next iteration, so
never let the remainder go below zero.
such a box:
_____/\_____
| Booo |
|__________|
likewise with options bottom, left, right. The size can be set via option
<marker-offset> (analogous to <tape> offsets), which describes the distance
from the base to the peak. Default: 8 px
a 8 pt font (set 8 pt in preferences.xml, too)
- fix vertical alignment of digits in label and ladder (temporary
solution -- the whole font handling needs to be reviewd and fixed)
- simplify nadir and zenith (they always want to be horizontally centered
on the ladder lines, no?)
- simplify and abstract label box drawing (no need for stippled side lines)
- align text (more) correctly in label boxes
- move variable declaration near their first use (c++ style rather than c)
- rename (zenith|nadir|hat) to enable-(zenith|nadir|hat) and make them bool
(for consistency reasons)
Generally you want point sprites for performance reasons when enhanced runway
lighting (and smooth points) are activated. Most hardware doesn't
accelerate the rendering of standard smooth points, so without point sprites
you will kill your night time performance if you turn on enhanced runway
lighting.
Note that enhanced runway lighting "breaks" our clever scheme to make the
runway lighting brightness vary with the relative view angle. This means
with enhanced lighting on, all lights are equally bright no matter what
direction you view them from. So perpendicular runways are just as bright
as runways you are directly lined up with (when enhanced runway lighthing
is activated.)
You can revert to the original lighting scheme by turning off enhance runway
lights, turning off distance-attenuation, and turning off point-sprites in
the rendering options menu.
maintainable. The rules are simple (extension functions are called
*with* the lock, which must be dropped before calling naCall(), which
grabs it) but the tracking of when the lock was held was getting a
little confused. Keep a "nasal call depth" count in the subsystem to
figure out whether we are making a sub-call and thus hold the lock.
- Fix a warning about class member initialization order.
- Clear up a problem with the default autopilot behavior on the back side
of an ILS in preparation for adding a real "back course" approach mode.
and "latitude-offset" should not use a precalculated value of warp.
2) Since the values of cur_time and crrGMT are identical in the current
version of the SGTime class, the calculations of the "system", "gmt", and
"latitude" are re-evaluated and updated where necessary.
I attach 2 new files and a diff file for the associated changes to add a
“fluxgate compass” to the instrument inventory. Whist this outputs
essentially the same data as /orientation/heading-magnetic-deg, it has to
be powered, and can be made to fail. I also followed Roy’s suggestion to
generate the error properties for this instrument here rather than in
xmlauto.xml.
When this instrument is included in cvs, I intend to use it in the Hunter,
A4F Seahawk and KC135. After a bit more research, it might be appropriate
for the Spitfire and Hurricane as well. AJ would also like to use it for his
Lightning model.
autopilot with the servos off. In otherwords, the computer goes through the
motions of computing the desired behavior (pitch or roll) but doesn't actually
drive the outputs. This is potentially useful when implimenting a flight
director.
and tgt_altitude -> tgt_altitude_ft. Also fix a comment in AIBase.hxx
indicating that the altitude is in meters, even though the usage throughout the
code was most definitely feet.
- In AIMultiplayer.cxx, update the altitude_ft variable so that the altitude
is reported correctly in the entity's property subtree.
- In AIMultiplayer.cxx, compute a velocity value in kts to fill in the speed
entry in the entity's property subtree. Note, this is not an earth centered
reference speed, not an indicated speed and not a speed relative to the local
airmass (that would be much harder to do.)
the buggy ~fnt(), causing an abort() ... ;-)
(Only loaded texture fonts (*.txf) have a new'ed puFont. The built-in
pixmap fonts don't, and may, thus, not be deleted.)
each frame. However, often these values didn't change leading to bogus data
getting introduced into the computational pipeline.
This patch switches to a much more sane method for ground track computation.
Thanks to tied functions, this is only executed when the node is read. This
will be done by the old & new HUD code, the latter of which won't have a
special lon/lat mode at all. Instead it will be regular labels that point
to these properties for displaying lon/lat.
I would have liked to avoid the duplication of code (lon and lat being
basically the same thing), and to avoid using static buffers and all, but
... if anyone wants to make it prettier, go ahead.
The format is controlled by /sim/lon-lat-format (will be changed if I
find a better place).
AI aircraft are out of range or the piloted aircraft has no radar system.
These computation include range, bearing, and angular offset relative to the
piloted aircraft. This gives some external script the control the behavior
of the AI aircraft relative to the piloted aircraft without requiring a radar
system, and without requiring the AI aircraft to be within radar range.
flightplan. Such aircraft are given some initial conditions that they
fly with. They proceed on in "freeflight" mode indefinitely. For example,
there is a refueling demo where the tanker starts at 3000', 280 kts, and
in a 15 degree bank, and then continues to orbit indefinitely.
For these aircraft with no flightplan, I have added several control nodes in
controls/flight that allow a script or menu or external application to set
heading, altitude, bank angle, and speed. This permits some level of interactive
or scripted control over AI aircraft.
are taken down by the C++ runtime environment. This will later be done
with runlevels. Why would we want to run nasal code in subsystem
destructors? We don't really. But some data structures may use nasal,
which are normally created/destroyed during runtime. And these will
also be destroyed at fgfs exit. In the past things like these didn't
happen, because someone had disabled all subsystem destructors ...
src/AIModel/AIAircraft.cxx src/ATC/AILocalTraffic.cxx
src/FDM/flight.cxx src/FDM/flight.hxx src/FDM/groundcache.cxx
src/FDM/groundcache.hxx src/Main/fg_init.cxx src/Main/main.cxx
src/Scenery/hitlist.cxx src/Scenery/hitlist.hxx
src/Scenery/scenery.cxx src/Scenery/scenery.hxx
Make use of the attached SGMaterial reference userdata on scenegraph
leafs. Make the SGMaterial pointer available to the ground query
routines.
SGPropertyNode to guarded ones. This is also done for JSBSim/JSBSim.hxx,
for which JSB had given explicit permission a while ago. I postponed that
back then, but now is the time.
color group /sim/hud/palette/color[*]/ to the active group /sim/hud/color/
if they really exist. (Parameters like <antialiased> can be set in the
active group and be left alone, or set by each <palette> color group.)
into the <color> group, but that's because on HUD color changes a whole
"color" set from /sim/hud/palette/color[*] is copied to /sim/hud/color/, and
antialiasing needs to be considered with that. (I'm not entirely happy
with the property names yet.)
