Use a suggested exit method as described in the SDL_Quit man page. (fgOSExit() is still uncalled in both fg_os.cxx (glut) and fg_os_sdl.cxx, which makes these functions kind-of useless.) The other changes are fixes for gcc 3.3.4 warnings.
directory and over to the Instrumentation directory and make them modular
in the sense of being able to pick and choose what you include with any
particular aircraft.
Aaron says:
I just got the virtual runway hud projection working on all views and
2D & 3D HUDs. It is working awesome(see below). I have attached every
file that was modified (hud.hxx, hud.cxx, and the default.xml for the hud)
and every file that was added (hud_rwy.cxx and runwayinstr.xml).
Just a quick overview of how the instrument works.
The virtual runway is projected by getting the "cockpit view" of the
runway in 3D and projecting the points on to the 2D HUD. Therefore, the
virtual runway will be displayed the same in every view. For example,
you can land an aircraft from the "Tower View" by flying the HUD. Also
if you're in "Cockpit View" and it is centered then the virtual runway
lines will perfectly outline the actual runway. I am getting the active
runway via the wind like done in the ATC classes, which may need changed.
Also, I made the assumption the view 0, in view manager, is always the
cockpit view, which may need changed as well.
The runway configuration file will allow you to specify a center offset
(x,y) and a bounding box (width,height). You can also configure the line
stipple pattern for the outside and the center line. For instance, if
you wanted a 0xFAFA pattern, then specify 64250 as the value. If you
want a solid line, you can specify -1 or 65535 (0xFFFF) and zero will
turn the line off. It also draws a runway indication arrow when the
runway is not in the HUD or it can be drawn all the time if arrow_always
is true. The arrow will point in the direction of the runway (2D) by
rotating around the center at a radius of arrow_radius. If you wish to
turn the arrow off, you must set the arrow_scale <=0. The arrow really
should be 3D arrow that points to the runway (or points in the direction
of the aircraft-to-runway vector).
Add some controls required for carrier operations:
/controls/gear/launchbar
should be 1.0 if the launchbar is lowered, that means the aircraft should now
be arrested at the catapult.
/controls/gear/catapult-launch-cmd
Should be set to 1.0 when the aircraft should be launched from tha catapult.
The moving ai models will jump around realtive to the moving aircraft model.
I can see that with the carrier but others have noticed that too with ai
aircraft before.
The reason is that all SGSystems are called with a dt value which is not
necessarily a multiple of 1/hz.
In contrast, most FDM's use the _calc_multiloop function from FGInterface
which forces the time update to be a multiple of 1/hz for the FDM aircraft.
As a result, in the worst case, the FDM aircraft has moved nearly 1/hz seconds
further than the rest of flightgear (1/120sec*300kts that is about 1.3m).
That patch forces the time update to be a multiple of 1/hz.
systems. Fix a couple bugs/oversights.
- atc610x.cxx: Much code has moved into the configurable input mapper
(ATC-Inputs.cxx) and the remaining input massaging code has moved into
the atcsim.nas module.
We have decided that hardcoded initialization of instruments and systems is
bad. So we remove them.
Hardcoded initialization is bad because it can't be overridden from config
files or from the command line. We prefer to do it through config files that
should be, eventually, aircraft specific (*-set.xml), not global
(preferences.xml).
I attach the latest version of Nimitz. The textures have been improved. A glide-path has been added, it is on by default, but can be switched off by means of the properties browser: /ai/models/ship/controls/glide-path. The origin has been adjusted to the turning pivot and approximate roll center.
Modified AiShip files are also attached. These allow the radius of the turning circle of a ship to be input. The turning circle is adjusted for speed and rudder angle. Roll has been corrected so that a ship leans out of a turn, not inwards like an aircraft. The roll angle is adjusted for speed and rudder angle (yes, application of more rudder reduces roll angle - rudders act as stabilizers).
TODO
Add a relative wind calculation so that a carrier can be turned to the appropriate launch and recovery courses.
Add a 'flight plan' so that the carrier can carry out a racetrack for flight ops.
Add a projector landing sight.
Add auto-land facilities.
The caption should already be set when the window is opened. This is
important for some window managers. (KDE's kwin, for example, can store
special settings for certain windows, such as "no border" and "always
on top". KDE uses the window title to determine if a special rule is
to be applied. KDE will be made more tolerant, too.)
Here are files to get automated contrails working. I've set up contrails for
the 737, using my simple, untextured contrail model. Vivian has made another
contrail model, but I'm still trying to get his to work. I'm hoping others
will try to make contrail models also.
Here's some code that defines a top to thermals. When the top of a thermal is
reached the strength is phased-out linearly over the next 100 feet of
altitude. At first I tried just capping the thermal at the top, but the
change in thermal strength was too fast for the FDM to handle well.
Included is a new version of the thermal scenario that includes a top
(height-msl) to the thermal. The default value is 5000 feet.
on the ground) -- this is based on some wild guesses, but it seems
reasonable for now.
The next step will be to give the compass some angular momentum so
that it does not snap instantly to a heading, and so that it can
overshoot a heading and oscillate.
After applying the attached patches (based on latest CVS) you should
have a new option available within your version that should also
show up using fgfs --help, the syntax is:
fgfs --min-status={level} --show-aircraft
whereas "level" can be anything between
"alpha","beta","early-production" and "production"
Of course running something like
fgfs --min-status=alpha --show-aircraft
should not return any aircraft right now, as none of the
current aircraft definition files in your base-package is using the
required
<status></status>
tag - but you can easily give it a try by adding something like
<status>alpha</status>
The tag should be placed as a sub-tag within <sim> - so directly behind
the <description> tag would be just fine and straight-forward.
As a result of recent requests, I've implemented the ability to switch off
aerodynamic stabilisation:
This has to be added to the submodel.xml files:
<aero-stabilised>false</aero-stabilised>
When false the submodel retains the pitch given at instantiation.
It defaults to true.
I've made an encoder and a transponder. The transponder gets C-Mode altitude
information from the encoder. These two might not be very usefull right now,
but I think they might come in handy when the ATC network gets going.
input.cxx allocates memory for js->getNumAxes() axes and for jsCaps.wNumButtons
or MAX_JOYSTICK_BUTTONS buttons per joystick. But it doesn't check if some
xml config defines bindings for more axes/buttons, in which case it writes
to unallocated memory and causes crashes. This is a real world example:
sidewinder-force-feed-pro.xml defines 7 axes, but only newer versions of
this js do actually have that many. Older ones (-> gameport) don't. The patch
drops unused and unusable bindings.
I've added two new debug log types for the instrumentation and systems. They
used to use the autopilot debug log, because I couldn't figure out how to
make new log types. Well, now I have figured it out. ;-)
This will modify menubar.cxx/hxx so that it exports the
entire menubar (from menubar.xml) to the property tree, so that it can
now be changed dynamically using Nasal's setprop() instruction and
afterwards running a newly added fgcommand to update the menubar
based on those changes using the appropriate menubar path within
the property tree.
By default the menubar from menubar.xml will be stored within:
/sim/menubar/default
Erik:
I have moved the loading of menubar.xml into preferences.xml and
made sure that the menubar is destroyed every time a new menubar
is created.
