First, preferences.xml will define the scenario filename.
For now, the other way of defining ai objects still works, so the sailboat
stays in preferences.xml. Later, I'll move the sailboat into the demo
scenario. If no scenario filename is given, then no scenario will be
processed.
I changed the demo scenario to create two 737's, one takes off on runway 01L,
and the other takes off on runway 01R. This will make a good demo for the ai
system. One problem, if you takeoff on 28L/R right away, you might run into
the taking-off 737's, or be scared.
Here's the newest AI stuff.
The AIManager at init() creates a new scenario. Right now the
default_scenario is hard coded in, but eventually the AIManager should get
the scenario filename from preferences.xml.
The scenario defines which AI objects will be created. Right now it only
creates AIAircraft, but this is easily extended. The scenario also defines
which flightplan will be assigned to the airplane. Scenario config files go
in data/Data/AI.
The Airplane gets a pointer to a FlightPlan object. Each airplane should get
its own flightplan object, even if two airplanes have the same flight plan.
This is because the flightplan maintains the iterator pointing to the
current waypoint, and two airplanes might be at different locations (for
instance if they were created at different times). The flight plan files go
in data/Data/AI/FlightPlans.
When the airplane gets to the waypoint named "END" it vanishes. The
AIAircraft destructor deletes its flight plan (if it has one).
The last waypoint is a place holder only. I called mine
<WPT><NAME>"EOF"</NAME></WPT>.
the root problem was a C++ bug. Remove the no-op hbox around the mute
button, and make it "live" when clicked. Tried to make the slider
live, but discovered that bindings don't work on them; gotta fix
that. Change some of the wording to be more in line with standard
conventions; hopefully Curt's OK with that. :)
x/y/width/height values went into the calculation for the next popup,
and things got iteratively worse due to padding issues). But the
good news is that this whole subsystem is vastly simpler when
implemented with the new interface.
"engines die when any tank is empty" behavior. Otherwise, just
deselect the empty tank. This matches the "both" behavior many
lightplane fuel selectors have.
Here is the KAP140 Two Axis Autopilot update.
I think it's fairly complete now, all the modes are working. I tested the
localizer and glideslope hold and it was pretty stable all the way down to
the middle marker.
In the pilot guide for backcourse hold (REV) mode it says to reset the heading
bug to the _front course_. I haven't figured out how to implement this so for
the time beeing one should reset the heading bug to the _backcourse_. Apart
from this the panel should operate identical to the way the pilot guide
describes.
Here is the KAP140 Two Axis Autopilot.
Aircraft/Instruments/KAP140TwoAxis.xml
Is of course the instrument config file.
Aircraft/Instruments/Textures/KAP140.rgb
The texture.
Nasal/kap140.nas
Most of the work is done here. Without Nasal I don't see how I could implement
the NAV-ARM modes and the flashing annunciators.
Aircraft/c172p/Systems/KAP140.xml
The autopilot PID controllers configuration file. Maybe this file should be in
a more accessible directory and not hidden deep inside c172p!?
I've also attached the changes to the default C172 to include this autopilot
in the 3d-cockpit panel and the 2d vfr panel. Or at least I hope that I've
managed to include all that is needed.
