I've included the latest fixes to the Traffic Manager/AI flightplan generation
code. Most of the code changes are in AIFllightplan.cxx. This is the code
that runs without depending on predefined FlightPlans in
#FG_ROOT/Data/AI/Flightplans.i
As suggested by Dave, I've also added a new property in
preferences.xml: /sim/traffic-manager/enabled, which is used to control
whether or not the traffic manager is active.
I'm still working on a few more 737 traffic patterns, those are going to take
a little longer, so I didn't want to wait sending in this code.
Finally, I haven't put much effort into ensuring "aeronautical correctness" in
this version yet. The code works on my system, but what the AI plane do may
actaully be quite rediculous. But I'd like to leave that for the next
version.
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>
Don't know if this was intentional, but since revision 1.128
(2003/10/01 21:15:55; david; "Add some whitespace, and initialize
the new ADF subsystem.") the ADF isn't initialized with useful
frequencies any more. It should be something in the bay area.
379 is for BRIJJ again (in the glide slope of KSFO) and 341 is
for RORAY (KOAK). Don't know what the standby frequency was before.
controls in the cockpit vs. which wheels they apply to. FlightGear now
sets /controls/gear/brake-left, /controls/gear/brake-right, and
/controls/gear/brake-parking. It should be up to the FDM to sort out
which wheels under which circumstances are affected by these controls
and ultimately what happens to the physical motion of the aircraft.
These patches add a clock instrument, which allows to model failure ("serviceable") and to adjust the time independently of the system time (defaults to GMT). The main incentive is to make the p51d clock work and adjustable via the knob.
o Offers a time string ("12:03:15") for the LCD or for LED
clocks, or an empty string in case of failure/power off. The
instrument assumes that digital clocks are battery buffered,
so they will be updated even if there's nothing on the display.
o Offers the number of seconds since midnight for analog
clocks, like in the p51d. This number is not increased
if !serviceable. So the clock will stand still and continue
where it stopped when it's serviceable again.
I did not consider voltage yet, because the Mustang's clock will need a lot more current than the LCD clock. The instrument is updated 4 times per second but returns immediately if neither time nor offset changed. The function getGMTString() in fg_props.cxx could be removed after applying these patches.
There are a number of little changes. Tested with current cvs as of 20:30EST
04Feb. Actually been running since the beginning of January with these
patches. All changes work without crashing with the current base package cvs,
but there are some visual problems with the views (other than pilot view)
without changes to the base package.
As soon as you can build test and commit I can add in those base package
updates that will make it all work nicely. I will also go through all the 3D
Aircraft configs to make sure the change in the "pitch-offset" for cockpit
views (see below) are made to maintain current behavior.
Here are the files (changes listed below):
http://www.spiderbark.com/fgfs/viewerupdate.diffs.gzhttp://www.spiderbark.com/fgfs/viewerupdate.tar.gz
there was only the addition of the 5th view discussed, and a developer noted
that the Lookfrom Tower view was useful for multi-aircraft development. So
this patch preserves the new 5th view, returns the Lookfrom Tower and removes
the second Lookat Tower. One is enough for now IMHO, but still open for
discussion of course.
-- Jim
but the view position is near the aircraft.
Adding in a new 5th view that looks in a fixed direction at the
external airplane. In this new view the yaw does not cause the view
to swing back and forth along the horizon as it does w/ the first
view.
MSS
implement them for the C172P 3D model. Look near the top of
preferences.xml for an example. The recognized properties are as
follow, with vanilla defaults in parentheses:
/sim/view/config/default-field-of-view-deg (30)
/sim/view/config/default-pitch-deg (0)
/sim/view/config/front-direction-deg (0)
/sim/view/config/front-left-direction-deg (45)
/sim/view/config/left-direction-deg (90)
/sim/view/config/back-left-direction-deg (135)
/sim/view/config/back-direction-deg (180)
/sim/view/config/back-right-direction-deg (225)
/sim/view/config/right-direction-deg (270)
/sim/view/config/front-right-direction-deg (315)
These are particularly useful for the view from inside a 3D aircraft
model.
This adds supports for a language specific font, defined in locale.xml
I've also moved the fgInitLocale() routine from main.cxx to fg_init.cxx
to prevent an ungly extern definition in options.cxx.
These are the updates for the View manager properties. Removed the last of
items (within the viewer/viewmgr) hard coded to view number. Added support
for per view configuration of ground level nearplane value. Tower views look
very nice with little or no z-buffer problem in the models. Pilot offset
dialog can be used to move eye in all views.
lot, since otherwise a property that is never set or tied by
FlightGear itself will always be kept as a string and converted on
each access. That's why fgGetBool and friends could take up a lot of
processor time sometimes.
position, and for engaging the starter. Here's how it works:
1. To select an engine, use '!' (shift-1) for engine 1, '@' (shift-2)
for engine 2, '#' (shift-3) for engine 3, '$' (shift-4) for engine
4, or '~' to select all engines. These bindings set the bool
properties /sim/input/selected/engine[0],
/sim/input/selected/engine[1], etc.
2. To decrease the magneto for the selected engine(s), use '{'.
3. To increase the magneto for the selected engine(s), use '}'.
4. To engage the starter for the selected engine(s), use SPACE.
Eventually, I'll extend this so that the throttle uses the selected
engine as well, and will perhaps even support engine selection in the
joystick bindings. Right now, only engine 1 (engines[0]) is selected
by default.
preferences.xml, and added <sim>...</sim> tags back into the *-set.xml
files. You need the newest FlightGear CVS changes to use together
with these changes.
- new external file for joystick configuration
- designed for a basic three-axis, three-button joystick; others will
require some work
** keyboard.xml
- changed back to using index ('n' attribute) to represent key code
- switched to nesting for modifiers, so that they can all appear in
the same declaration
- bound 'b' to brake, but modified so that the brake is released
as soon as the button is
** preferences.xml
- start mixture at 1.0 (full rich), which is most appropriate for
take-off and landing
- commented out old joystick bindings
- added reference to external joysticks.xml file
