ehofman [Sat, 29 May 2004 11:39:10 +0000 (11:39 +0000)]
David Culp:
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>
curt [Fri, 28 May 2004 16:24:43 +0000 (16:24 +0000)]
Curt Olson:
These change add some code that at initialization time will snap all
localizers into perfect alignment with their runways. It's my experience
that the DAFIF/FAA data reports runway and localizer headings to a level
of precision that is great for making charts, or adjusting your OBS, etc.
But the level of precision of this data can be far enough off to make you
visibly *un*aligned with the runway when the CDI needle is centered.
There are probably cases where the localizer isn't really perfectly
aligned with the runway, or intentionally misaligned to avoid obstacles
or terrain. So I have made this configurable for those that trust the
data more than I do. Just set "/sim/navdb/auto-align-localizers" to
true/false in the preferences file to turn this feature on or off in the
code.
curt [Fri, 28 May 2004 05:24:54 +0000 (05:24 +0000)]
This set of changes impliments the following:
- FG now directly supports Robin's native nav database file format.
- His latest data now separates out dme, gs, loc, and marker beacon
transmitters rather than lumping them all into a single "ILS" record.
- These new data structure changes prompted me to do some code restructuring
so that internally these different types of navaids are all kept as
separate lists and searched and handled separately.
- This structural change had a cascading affect on any code that
references or uses the nav databases. I've gone and "touched" a lot of
nav related code in a lot of places.
- As an added bonus, the new data (and code) adds DME bias so these will
all now read as they do in real life.
- Added Navaids/navdb.cxx and Navaids/navdb.hxx which provide a front
end loaders for the nav data.
- Added Navaids/navrecord.hxx which is a new "generic" nav data record.
- Removed Navaids/ils.hxx, Navaids/ilslist.cxx, Navaids/ilslist.hxx,
Navaids/mkrbeacons.cxx, and Navaids/mkrbeacons.hxx which are all now
depricated.
ehofman [Fri, 21 May 2004 16:50:19 +0000 (16:50 +0000)]
David Culp:
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.
One problem. WARNING **** There is a bug in the way the property system
works, which causes a segfault, but I don't know if the problem is in the
property code, or in how I'm using it. After an AI object terminates, if you
access the property tree through the property browser the sim will segfault.
andy [Tue, 18 May 2004 01:46:36 +0000 (01:46 +0000)]
Fix a bug with propeller gearing. The torque computations weren't
properly correcting for the gear ratio. This is the source of the
problems Vivian and Jim were having with the Spitfire and Mustang.
ehofman [Mon, 17 May 2004 08:45:33 +0000 (08:45 +0000)]
David Culp:
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.
ehofman [Sat, 15 May 2004 09:07:55 +0000 (09:07 +0000)]
David Culp:
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>.
andy [Fri, 14 May 2004 17:16:35 +0000 (17:16 +0000)]
Fix the slider to request a non-zero length, and make its width a
little larger.
The text widget can now be meaningfully associated with a property; in
PUI, it's "value" isn't the same thing as its label, but we can hack
things to treat them symmetrically.
Commit an experimental "live" property that can be set on widgets to
cause them to update their values every frame. This works great for
text widgets, as above. Note that this synchronization is input-only:
no support is provided (or needed -- the GUI only changes when the
user does something) for writing those properties out every frame.
curt [Fri, 14 May 2004 15:49:10 +0000 (15:49 +0000)]
Code at this level shouldn't care if the sound manager is paused or not.
Just forge ahead as if sound is playing, let the sound manger worry about
the details.
andy [Wed, 12 May 2004 15:36:07 +0000 (15:36 +0000)]
GUI layout management and a few visual/eye-candy modifications. See
DOCS/README.layout in the base package for details, along with the
modified dialog files.
andy [Thu, 6 May 2004 16:28:08 +0000 (16:28 +0000)]
Fix from Melchior: It replaces the ridiculous 5 seconds by
the 30 seconds that Maik had originally intended, according to the comment.
This is important for the pending sound and rotor disc changes (and of course
for realism).
andy [Mon, 3 May 2004 00:40:50 +0000 (00:40 +0000)]
GUI windows are now draggable. This missing feature has annoyed me
for a while, it turned out to be pretty easy to implement. Also, the
property picker is now non-modal, I presume the modality wasn't an
intentional feature.
ehofman [Sat, 1 May 2004 09:40:09 +0000 (09:40 +0000)]
Roy Vegard Ovesen:
I've added a vertical navigation capability to the GPS module. One can input
two waypoints, wp[0] and wp[1], with altitude. If the altitudes differ, then
the altitude deviation from a "straigth" line from wp[0] to wp[1] is
calculated. The true course and course deviation from wp[0] to wp[1] is also
calculated. All this can be found in the wp subdir where one also finds the
wp[0] and wp[1] subdirs.
All this has to be done through the property browser. Maybe I should make a
gui window for the GPS!
andy [Sat, 1 May 2004 00:26:33 +0000 (00:26 +0000)]
Initial checkin of a TurbineEngine implementation. This hasn't been
tested at all yet, but it doesn't seem to have broken anything so it
should be safe. See the README in the base package for docs.
andy [Sat, 1 May 2004 00:25:56 +0000 (00:25 +0000)]
Attempt at a fix for the propeller torque problems in the
"slow/windmilling propeller" regime. I'm happy with the foundations
of the solution, but this hasn't been complete tested yet. The
solution behavior seems fine on the planes I tried.
andy [Fri, 30 Apr 2004 19:06:29 +0000 (19:06 +0000)]
Refactoring in preparation to add a turbine engine to YASim. The
PistonEngine class has grown an "Engine" superclass. Some other stuff
moved around too, and I cleaned up some property naming while I was in
there. This hasn't been tested very thorougly, hopefully I didn't
break anything.
andy [Fri, 30 Apr 2004 00:52:11 +0000 (00:52 +0000)]
Changes to get FlightGear (well, the src directory at least) to
configure and compile out-of-the-box on a MinGW target:
Use -lSDL instead of -lglut32 on windows builds when --enable-sdl
is set.
Link against alut.dll in addition to openal32.dll.
Replace BSD bcopy() with ANSI C memmove() in a few places. This is
simpler than trying to abstract it out as a platform dependency in a
header file; bcopy() has never been standard.
The ENABLE_THREADS handling has changed to be set to 0 when threads
are not in use. This breaks expressions like #ifdef ENABLE_THREADS.
Replace with a slightly more complicated expression. It might have
been better to fix the configure.ac script, but I didn't know how and
this whole setting is likely to go away soon anyway.
The MinGW C runtime actually does include snprintf, so only MSVC
builds (and not all WIN32 ones) need _snprintf in JSBSim/FGState.cpp
Building on a platform with no glut at all exposed some spots where
plib/pu.h was being included without a toolkit setting (it defaults to
glut). Include fg_os.hxx first.
And when still using glut, glut.h has a bizarre dependency on a
_WCHAR_T_DEFINED symbol. It it's not defined, it tries to redefine
(!!) wchar_t to disasterous effect.
Replace axe by axis. Make sure the right number of joystick buttons is used. The number of defined buttons does not always equal the maximum number of allowed buttons.
Revert the previous patch. The <target-platform> tag is not supported
anymore. Instead Frederic Bouvier suggests to add a <number> tag to
the axis definition which accepts values for <windows> and <unix>
for now but which can be extended later on:
1. The listener is always positioned at the origin.
2. All sounds eminate from the aircraft's model position.
3. Sound positions are relative to the listener location.
Make it possible to define a <target-platform> tag in the joystick configuration file. This would make it possible to have different configuration files for Windows. Possible values are: Windows, UNIX or All. Not specifying the tag equals to 'All'.
I've added a tracking bug to the gps. This is of course very similar to a
heading bug for a DG. I don't know if this is the common name, but I feel
that for a gps the name tracking bug is more accurate than heading bug. A
true bug error and a magnetic bug error is calculated and shifted into the
-180 to 180 range so that they can be used by autopilots.
I've also fixed a property name that crept in when I had to change back to
indicated-***. Back then I accidentally changed the desired course name to
"indicated-course". The property that is supposed to be the input for the
desired course should naturally be named something like "desired-course", and
definitely _not_ "indicated-course". If this name change breaks anything it
should be fixed in the other end.
I've also commented out a lot of #includes that I don't think is needed. I'm
on Suse 9.0 now, and it builds fine here, but this might be a problem for
different platforms I guess we have to cross our fingers.
Fix a seg fault that could be caused if all no AI models were in existance. Ssg could then free the memory pointed to by our pointer behind our back, causing it to crash when next approaching a controlled airport requiring an AI model. Fix is to hold one ref to each model in the AIMgr at all times.
andy [Tue, 6 Apr 2004 04:06:11 +0000 (04:06 +0000)]
Added mouse cursor definitions stolen from the X11 cursor font (via a
pointer from Melchior to a font editor that could read .pcf and
generate image files)
andy [Tue, 6 Apr 2004 03:51:11 +0000 (03:51 +0000)]
Oops. A change to an upstream header seems to have remove glu.h, which
these files require. Dunno why my build didn't pick up the transitive
dependency.