1) The AIStorm sets the properties:
/environment/turbulence/magnitude-norm
/environment/turbulence/rate-hz
The actual turbulence effects are handled by the FDM.
If the effects are deemed unrealistic, then that will
have to be fixed in the FDM(s).
2) The zone of turbulence is cylindrical, and is centered
at the AIStorm's lat/lon. The diameter is set with
<diameter-ft>, the top with <height-msl>, the bottom is
assumed to be at <altitude> minus 1000 feet.
3) Note that the zone of turbulence may not match well with
the visual model of the storm. In this case I had to
x-offset the storm model by 4700 meters to match the zone
of turbulence. (i.e. the storm model is 4700m off center).
4) While I was in there I also increased the speed of the
lightning flashes to look more realistic.
I have done a patch to eliminate the jitter of 3D-objects near the viewpoint
(for example 3D cockpit objects).
The problem is the roundoff accuracy of the float values used in the
scenegraph together with the transforms of the eyepoint relative to the
scenery center.
The solution will be to move the scenery center near the view point.
This way floats relative accuracy is enough to show a stable picture.
To get that right I have introduced a transform node for the scenegraph which
is responsible for that shift and uses double values as long as possible.
The scenery subsystem now has a list of all those transforms required to place
objects in the world and will tell all those transforms that the scenery
center has changed when the set_scenery_center() of the scenery subsystem is
called.
The problem was not solvable by SGModelPlacement and SGLocation, since not all
objects, especially the scenery, are placed using these classes.
The first approach was to have the scenery center exactly at the eyepoint.
This works well for the cockpit.
But then the ground jitters a bit below the aircraft. With our default views
you can't see that, but that F-18 has a camera view below the left engine
intake with the nose gear and the ground in its field of view, here I could
see that.
Having the scenery center constant will still have this roundoff problems, but
like it is now too, the roundoff error here is exactly the same in each
frame, so you will not notice any jitter.
The real solution is now to keep the scenery center constant as long as it is
in a ball of 30m radius around the view point. If the scenery center is
outside this ball, just put it at the view point.
As a sideeffect of now beeing able to switch the scenery center in the whole
scenegraph with one function call, I was able to remove a one half of a
problem when switching views, where the scenery center was far off for one or
two frames past switching from one view to the next. Also included is a fix
to the other half of this problem, where the view position was not yet copied
into a view when it is switched (at least under glut). This was responsible
for the 'Error: ...' messages of the cloud subsystem when views were
switched.
I'm looking through the AI code, trying to find the bug that's killing the
thermals. The following things don't look right:
1) AIManager::101 , the Traffic Manager pointer is searched for by name at
every dt. I'll leave this for you to look at.
2) AIManager::295 , the thermal height is not being set. We need to
restore the line: ai_thermal->setHeight(entity->height_msl);
This fixes the thermal problem.
3) AIManager::328 , I changed the fetching of the user state to occur every
sim cycle, and changed the fetching function from by-name lookup to a lookup
by node pointer. It should be faster now, and more accurate too. This helps
the air-refueling.
- don't treat *every* child in the xml as submodel, especially not a "param"
block
- do not only *enable* the contrail flag above some altitude, but also
disable it below
I have done some cleanup where I moved some values out of classes where they
do not belong and such stuff.
Also the fols offsets are now named in the carrier xml file with a more
verbose name (flols-pos/offset-*) than before (only offset-*).
There is a little preparation for definitions of parking positions on the
carrier which should later be used for starting flightgear directly on the
carrier.
I attach the long-promised improved version of the USS Nimitz.
It includes an improved version of the FLOLS, which requires the attached
diff to be applied to AICarrier.cxx and AICArrier.hxx.
I've made lots of eye-candy in the form or the flightdeck crew.
Unfortunately, it about doubles the size of the tarball. I'll send it to you
later; when I've figured out some way of only loading on request (any advice
would be very welcome).
I could provide a \u2018bare\u2019 version to cut down on the vertex count for
less capable systems however, the count isn\u2019t huge in the first place.
I've cut the textures down as far as I can without losing definition.
I just heard from John Wojnaroski that you and he are going to work on getting
a flightgear demo machine up for the linux expo thursday and Friday. John
indicated that he would very much like to get a CVS version with the new
traffic code up and running before the expo.
We should now be able to find
wires or catapults when the ac3d model is loaded without the crease patch
(caused by the much more unstructured scene graph emitted by the old loader).
It should also emit more warnings if the carrier hardware configuration
includes conflicting definitions.
That code is the most intrusive one, it should not be used until you configure
an aircraft carrier as a aimodel. So I think it should be save to apply that
before the release too.
a single apt.dat.gz file which is in the native X-Plane format.
To do this I wrote a front end loader than builds the airport and runway
list. Some of the changes I needed to make had a cascading effect, so there
are minor naming changes scattered throughout the code.
I have a small update which fixes the algorythm used for marking solid
surfaces for some cases where some branch nodes carry the object names I had
expected in the leaf nodes.
That will also introduce the possibility to mark whole subtrees from the
scenegraph solid.
This is a sub-system which can be added to any carrier.
These files add a functioning Fresnel Lens Optical Landing System (FLOLS).
The orange/red 'source' lights are illuminated according to the position of
the pilot's eye above/below the 3.5 deg glide slope. The apparent position
of the source light relative to the fixed green datum lights allow the pilot
to 'fly the meatball'. The green 'cut' lights flash when the pilot's eye is
below the coverage of the lowest (red) source light.
TODO - add rules for the operation of the wave-off lights.
Okay, here's the latest update to the tarffic manager/AI Manager. AITraffic
can now fly multiple routes and be initialized while sitting statically at
airports.
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.
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.
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.
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 think I found the problem in props.hxx. I have an exception when copying properties. An alias to a property that has no value trigger this exception. The code that generate that is in AIManager.cxx :
void FGAIAircraft::bind() {
FGAIBase::bind();
props->tie("controls/gear/gear-down",
SGRawValueMethods<FGAIAircraft,bool>(*this,
&FGAIAircraft::_getGearDown));
props->getNode("controls/lighting/landing-lights", true)
->alias("controls/gear/gear-down");
}
controls/gear/gear-down has no value ( _type == NONE ) and controls/lighting/landing-lights is copied somewhere.
Erik:
Frederic's fix was to change props.hxx but he has expressed his doubts.
For now I've commented out the line that causes the problem so we have more
time to look deeper into the problem.
cvs -z4 -q diff -u props.hxx (in directory I:\FlightGear\cvs\SimGear\simgear\props\)
Index: props.hxx
===================================================================
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/props/props.hxx,v
retrieving revision 1.4
diff -u -r1.4 props.hxx
--- props.hxx 19 Sep 2004 09:08:12 -0000 1.4
+++ props.hxx 21 Oct 2004 07:10:54 -0000
@@ -622,7 +622,7 @@
/**
* Test whether this node contains a primitive leaf value.
*/
- bool hasValue () const { return (_type != NONE); }
+ bool hasValue () const { return (_type != ALIAS && _type != NONE) || (_type == ALIAS && _value.alias->_type != NONE); }
/**
I've finished the variation of Cd with Mach number.
The calculations are only applicable to ballistic
objects, and then strictly one shape: non boat-tailed bullets/shells, so
I've put them in AIBallistic rather than AIBAase. For all inputs, Cd
should be the sub-sonic value, so bullets will need changing.
I've just posted a graphical analysis here:
http://myweb.tiscali.co.uk/vmeazza/FlightGear/cd_mach.pdf
The calculation of submodel mass from weight has been moved from AIBallistic
to Submodel so that it is calculated only once, rather than on every
iteration as a present. The parameter <contents> has been added, primarily
so that droptanks will have the proper mass. It is the path to an
appropriate property containing a weight in lbs.
Care has to be taken with the use of <contents> because after a reset there
appears to be a delay in submodel instantiation (dt not properly reset???)
and the weight property is not always picked up before it is set to zero in
the key bindings. Slightly hard to explain. It works fine if FGFS has not
been reset though. There is a partial solution which involves the rejigging
of the fuel and gui nasal scripts, but there is still the visible delay in
instantiation to be resolved. I've nearly done the nasal fixes, which will
form part of an update to the Hunter only. I'll probably complete those
later today.
The value of rho (air density) varies with height. (Including the upper
stratosphere, ust in case someone wants to model ICBMs.) The standard
atmosphere is used (based on a sea-level temperature of 15 deg C.).
Erik Hofman:
I moved this code over the AIBase::update() so all AIModels can make
use of rho, temperature, pressure, etc.
I have added <Cd> and <weight> to the input parameters in the submodels.xml
script. Raw data may be used, thus avoiding the need to guestimate <eda>.
Eda remains, but should now be used to enter the proper cross-sectional
area.
I had to reverse a number of signs to get it right. I took the opportunity
to add roll to the submodel so that droptanks will come off with the right
orientation. I have neither added the rotational speed to the submodel, nor
yaw, so if you release droptanks with significant roll rate or yaw angle on
the aircraft the submodel will not be quite right. Straight and level, or
nearly so, is fine.
The maths, so far, is now correct. Roll and pitch are now both in the
correct sense. The aircraft velocity is added correctly to the
submodel velocity, and the submodel is now visible when instantiated.
However, the velocity is measured at the aircraft centre. To be totally
correct we ought to take into account the aircraft's rotational
velocity. We have pitch rate and roll rate available, but not yaw rate
(small anyway).
I've added another parameter to the submodel - wind.
It's activated by the entry <wind>true</wind> in the ../submodel.xml file.
If true, the submodel is affected by the local wind, otherwise not. The
parameter defaults to false. This is useful for exhausts and smoke, and
possibly all objects.
Attached are the modified files to add buoyancy as a parameter for a
ballistic object. It may be set by adding
<buoyancy>x</buoyancy> to the submodel .xml file, where x is the appropriate
value (ft per sec2):
32 neutral buoyancy - contrails
>32 positive buoyancy - exhaust plumes
(0 non-op - default value)
If <buoyancy>x</buoyancy> is not used, then there is no effect on the
current ballistic model
Silly me. I was starting the timer at zero, so the first tracer didn't fly
until 0.25 seconds after pulling the trigger. Now the timer starts at the
same value as "delay", so the first round comes out immediately.
Also, I've added an optional configuration attribute that allows you to change
the ballistics of the submodel. This allows parachutes, or anything else
that has ballistics different from a bullet. The attribute is called "eda",
which is the equivalent drag area. Default value is 0.007, which gives the
same ballistics as the current tracers. Increasing this value gives more
drag. A value of 2.0 looks good for a parachute.
math stuff
########################################################################
The deceleration of the ballictic object is now given by:
[ (rho) (Cd) ] / [ (1/2) (m) ] * A * (V * V)
where rho is sea-level air density, and Cd and m are fixed, bullet-like
values. So the calculation is:
0.0116918 * A * (V * V)
The value "A" is what I'm calling the "eda" (equivalent drag area).
########################################################################
A parachute model will have to be built so that the parachutist's feet
are in the forward x-direction.
Here is the submodel.xml config I use for "parachutes":
<submodel>
<name>flares</name>
<model>Models/Geometry/flare.ac</model>
<trigger>systems/submodels/submodel[0]/trigger</trigger>
<speed>0.0</speed>
<repeat>true</repeat>
<delay>0.85</delay>
<count>4</count>
<x-offset>0.0</x-offset>
<y-offset>0.0</y-offset>
<z-offset>-4.0</z-offset>
<yaw-offset>0.0</yaw-offset>
<pitch-offset>0.0</pitch-offset>
<eda>2.0</eda>
</submodel>
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 additions to AI that allow refueling from an AI tanker (the actual
onload of fuel must be handled by the user's FDM of course, this just lets
the FDM know that the user is in position to refuel).
I've added a new class of AIAircraft called "tanker". It uses the same
performance struct as a jet transport. An AI tanker is just like an AI jet
transport, except it uses the already-existing radar data to control the
boolean property systems/refuel/contact. The code change was minimal.
An AI tanker can be created like this:
<entry>
<callsign>Esso 1</callsign>
<type>aircraft</type>
<class>tanker</class>
<model>Aircraft/737/Models/boeing733.xml</model>
<latitude>37.61633</latitude>
<longitude>-122.38334</longitude>
<altitude>3000</altitude>
<heading>020</heading>
<speed>280</speed>
<roll>-15</roll>
</entry>
This puts a tanker over KSFO at 3000 feet, in a left-hand orbit. When the
user gets within refueling range (contact position) then the property
systems/refuel/contact will be true. Otherwise it is false.
The dimensions of the refueling envelope are pretty rough right now, but still
usable. The user must be behind the tanker (ie. radar y_offset > 0). The
user must be at or below the tanker's altitude (ie. radar elevation > 0).
The user's lat/lon must be within 250 feet of the tanker's lat/lon (ie. radar
range_ft < 250). This last requirement is loose because the radar data is
only updated every 100 ms, which is accurate enough for radar use, but
which is sloppy for air refueling. This could be tightened up by increasing
the radar update rate to once every sim cycle.
I'm going to add a light to the T-38 instrument panel that will monitor the
property systems/refuel/contact. This will make it easier to explore the
boundaries of the refueling envelope.
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.
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.
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>.
I added some things to the AI stuff to improve the AIThermal processing.
Before, all the thermals were processed in order, and the last one overwrote
the prior one. Now, only the data from the nearest thermal is kept. This
way a tile can be populated with many thermals, and (as long as they have the
same diameter) the one nearest the airplane correctly takes effect. This
will make us ready for the next step, "auto-thermaling", where FlightGear's
tile manager can cover a tile with thermals, and set the thermal strength
based on land-use type.
I moved the enumerated object_type to the base class. When an AI object is
created it now sets the _otype variable in the base class. This lets the AI
manager find out what kind of AI object it is dealing with, using the base
pointer. I also added a function isa() to the base class, so the manager can
process objects differently based on their type.
The AI manager now sends AIThermal processing to a different function, where
only the data from the nearest thermal is kept. After the manager processes
all the AI objects, then the results from the nearest thermal are applied to
wind-from-down.
Here's a new batch of AI code which includes a working radar instrument.
I put the radar calculations into the existing AIAircraft class. It was
easier that way, and it can always be migrated out later if we have to.
Every tenth sim cycle the AIManager makes a copy of the current user state
information. When the AIAircraft updates it uses this information to
calculate the radar numbers. It calculates:
1) bearing from user to target
2) range to target in nautical miles
3) "horizontal offset" to target. This is the angle from the nose to the
target, in degrees, from -180 to 180. This will be useful later for a HUD.
4) elevation, in degrees (vertical angle from user's position to target
position)
5) vertical offset, in degrees (this is elevation corrected for user's pitch)
6) rdot (range rate in knots, note: not working yet, so I commented it out)
and three items used by the radar instrument to place the "blip"
7) y_shift, in nautical miles
8) x_shift, in nautical miles
9) rotation, in degrees
The radar instrument uses the above three items, and applies a scale factor to
the x-shift and y-shift in order to match the instrument's scale. Changing
the display scale can be done entirely in the XML code for the instrument.
Right now it's set up only to display a 40 mile scale.
The radar is an AWACS view, which is not very realistic, but it is useful and
demonstrates the technology. With just a little more work I can get a HUD
marker. All I need to do there is make a bank angle adjustment to the
current values.
I went through the AI code to put the "bank" node back into the config file,
so the models can fly circles. While I was in there I made some other
changes.
*) Moved the initialization of roll, tgt-roll, pitch ... etc, from init()
into the constructor, so it wouldn't over-write the config settings.
*) Changed the altitude getter to remove the meters-to-feet conversion. The
altitude is kept internally in feet. Only the scenery code needs meters.
*) Added "bank" item for config file (for type=aircraft). Left bank is
negative.
*) Added "rudder" item for config file (for type=ship). Left rudder is
negative. Internally this is stored in the "roll" variable, but the ship
model doesn't roll. It uses the "roll" variable for turning though.
The following puts a tanker at 3000 feet, 6 nm northwest of KSFO. On takeoff,
the tanker is visible over the hanger building at one-o'clock.
<entry>
<type>aircraft</type>
<class>jet_transport</class>
<path>Aircraft/737/Models/boeing733.xml</path>
<speed-KTAS type="double">320.0</speed-KTAS>
<altitude-ft type="double">3000.0</altitude-ft>
<longitude type="double">-122.455</longitude>
<latitude type="double">37.69667</latitude>
<heading type="double">200.0</heading>
<bank type="double">-15.0</bank>
</entry>
