1
0
Fork 0
Commit graph

10 commits

Author SHA1 Message Date
ehofman
cfc05f5f0d David Culp:
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>
2004-08-26 16:25:54 +00:00
ehofman
72b201d96c David Culp:
The AIBase code was updated to fix an uninitialized pointer, and the
AIBallistic code has an improved FDM.
2004-08-21 12:24:54 +00:00
ehofman
c43e514e87 No need to do he calculations twice. FGAIBAse::update() handles them already. 2004-06-12 11:34:05 +00:00
ehofman
24820e6d5a Move the radar update code to the AIBase class. There seems to be a problem where all targets disappear whenever one of them disappears, but that was present in the previous update also. 2004-06-11 13:49:07 +00:00
ehofman
6a08c79fcc David Culp:
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.
2004-03-07 12:08:46 +00:00
ehofman
85a1e5cc98 David Culp:
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.
2004-02-27 10:20:17 +00:00
ehofman
2d7a6e475d Split up model[] into ship[], aircraft[], ballistic[] and model[] (for unspecified models). 2003-12-22 12:30:35 +00:00
ehofman
298f53edef Tidy up the code a bit more, move /ai/model[] to /ai/models/model[] and make sure there can be more than one model subtree. 2003-12-22 10:24:15 +00:00
ehofman
9bc2517417 Make the AI model export it's internal state to the property tree under /ai/model[] using the same naming convention as used for the regular FDM. Also make sure the model animations are relative the the /ai/model[] node. 2003-12-21 20:12:55 +00:00
ehofman
cd0c447b43 Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code. 2003-11-28 15:48:05 +00:00