On Monday 10 November 2003 23:47, Andy Ross wrote:
> [Starting a new thread, since the original is getting a little strung
>  out. :)]
> 
> In an attempt to depoliticize the combat flame war as much as
> possible, it's worth pointing out that, irrespective of people's
> opinions on the matter, there are not a lot of "combat" features we
> can really avoid implementing:
> 
> + A missile is just another aircraft with (perhaps) a variant FDM
>   configuration.  Ditto for a bomb.
> 
> + A collision is a collision, be it with a guided missile, a partner
>   in your close formation flight, or the tanker from which you are
>   refueling.
> 
> + Hydraulic/control system failures (or whatever) don't behave
>   differently depending on whether the leak was caused by wear or a
>   shell fragment.  Overstressed civilian aircraft have been known to
>   shed ailerons, wings, or tails on occasion.
> 
> I'm sure others can come up with many more examples.  Here are the
> only three "combat only" features I can actually think of which will
> require code or features we don't already have:
> 
> + Weapon damage code.  The system failures themselves can already be
>   modeles (or will need to be at some point for civilian simulation).
>   But computing "how much failure" results from a given event is
>   something that will need to know about what a "warhead" is and how
>   it differs from a bullet.
> 
> + Gun trajectory modelling.  Even this could *almost* be done with
>   generic collision code by treating each shell as a separte object
>   with its own FDM (do the math -- there aren't that many shells on an
>   airplane, and computers are mind bogglingly fast these days).  But
>   still, the simplest gun implementation is going to be doing
>   gun-specific stuff.
> 
> + Missile homing code.  This could easily be plugged into a generic
>   autopilot framework, of course.  But other than the framework
>   boilerplate, this isn't likely to share code with any civilian
>   autopilot implementations. :)
> 
> Beyond that, all the "combat" stuff I can think of is going to be
> server-side functionality.  Stuff like radar coverage handling,
> battlefield AI, etc...  is all handled more cleanly by a separate,
> shared server application.
> 
> Hopefully this will help to push the flames down until someone
> actually submits code to flame over.  FWIW, I'm a mild, civically
> minded democrat and peacenik.  I still enjoy the occasional dogfight;
> I've even been known to play Quake. :)
> 
> Andy
> 

Identifying some of the specific bits is a good idea - it helps clarify 
things.

The more I think about it, there seems to be more possibilities that match 
with both non-combat and combat environments - bird-strikes and large 
hail-stones were the latest things to occur to me, that might might 
require the same or similar code.

LeeE


_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to