I'd like to suggest that the spoiler settings are set in the same way as the
flaps are now done i.e. via Nasal, so that specific spoiler settings can also
be defined in the aircraft set file.
It was only when I was about to change the keyboard bindings for the slats
control that I remembered that there wasn't already a mapping for them in
keyboard.xml. I've _not_ added a mapping for slats as this is a bit of a hot
topic atm but as I had already added a Nasal func for the slats in
controls.nas I've left that in there. It's a trivial bit of code but I don't
know if leaving it in there is a good idea as it's code that shouldn't ever
be called until there's a corresponding keyboard mapping.
Here's some new AI stuff.
1) AI objects must now be defined in a scenario file, not in preferences.xml
or a *-set file. (Of course this doesn't prevent objects from being created
dynamically, as with Durk's traffic manager).
2) A new demo_scenario file is attached. It creates 3 aircraft, a sailboat,
and a thunderstorm.
3) Objects without flightplans live forever.
4) FGAIShip::ProcessFlightplan() is not yet implemented.
5) preferences.xml should now define only <enabled> and <scenario>
1. Removed aircraft roll on ground.
2. Decreased descent pitch angle.
3. Updated flightplans to include <on-ground>
4. Fixed property indexing, so all AI aircraft have their own property branch
The default value of <on-ground> is false, so you only need to specify it when
on the ground. For takeoff you need to specify <on-ground>true</on-ground>
for the first waypoint, and for the acceleration waypoint. For landing you
need to specify it for the touchdown point and any taxi points.
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.
