- if no <impact-reports> node is defined for a particular submodel, then
write the path to /ai/models/model-impact instead
- don't tie() properties that are only ever set a single time, if at all!
- better variable names
a report node in the submodels config:
<impact-reports>/sim/model/cow/impact</impact-reports>
When an impact happens, then the path of the submodel will be written to
this node. An attached listener function can evaluate the impact properties.
"""
"Flight plans" which can start at a given time (gmt)
WAITUNTIL tokens which pause the flight plans until a given time (gmt)
Submodels can now be attached to any AI objects (except submodels - it can
be done, but in my experimental code it's too expensive in frame rate atm)
"No-roll" attribute added to Ballistic objects - useful for wakes and the
like
"Random" attribute added to Ballistic objects (adds =- 5% to the Cd) -
useful for smoke, exhausts
If the <trigger> tag is not specified the Ballistic object/s will be
released at start-up (cannot be stopped)
Submodels are not released from AI Objects if the AI Object is more than 15
miles away.
"""
mf: minor code and formatting fixes; submodels.?xx were FUBAR and are thus
astyle formatted;
NOTE that <name> tags END, EOF, WAIT, WAITUNTIL are *depreciated*.
Don't get too used to them. This will have to be moved from the "name"
to regular engries.
and tgt_altitude -> tgt_altitude_ft. Also fix a comment in AIBase.hxx
indicating that the altitude is in meters, even though the usage throughout the
code was most definitely feet.
- In AIMultiplayer.cxx, update the altitude_ft variable so that the altitude
is reported correctly in the entity's property subtree.
- In AIMultiplayer.cxx, compute a velocity value in kts to fill in the speed
entry in the entity's property subtree. Note, this is not an earth centered
reference speed, not an indicated speed and not a speed relative to the local
airmass (that would be much harder to do.)
This patch removes some useless indirection when creating AIModels. It
obsolets AIScenario*.
AIEntities are just an intermediate copy of an other intermediate copy of an
xml file on the way from the ai scenario configuration file to the AIModels.
As such the AImodels can now be created directly from the property tree read
from the scenario file.
This reduces the amount of work needed to add an other AIModel and reduces the
amount of copy operations done during initialization.
It also moves internal knowledge of special AI models into these special AI
models class instead of spreading that into the whole AIModel subdirectory
which in turn enables to use carrier internal data structures for carrier
internal data ...
Also some unused variables are removed from the AIModel classes.
I believe that there are still more of them, but that is what I stumbled
accross ...
Tested, like the other splitouts these days in a seperate tree and using the
autopilot for some time, and in this case with a carrier start ...
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'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 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.
