Re: [Flightgear-devel] More ideas on dogfighting

[Stuart Buchanan]

--- "Ampere K. Hardraade" wrote:
> On Monday 14 May 2007 04:38, Stuart Buchanan wrote:
> > If what you are suggesting is that to use MP, we will have to run the
> FDM
> > on a server and accept a much lower refresh rate on the client, then I
> > don't think that is acceptable as it will make the civil MP experience
> > much worse.
> 
> This isn't as big a deal as many have advocated.  There's no requirement
> that 
> the FDM server has to be run at a central location.  The server can be
> run on 
> the client machine as well, serving FDM functions to the client only,
> and 
> latency wouldn't be an issue at all.

Sure, but as I understand the current proposal, running the FDM on the
client will only be done for non-MP use. For any MP environment (civil or
military), the FDM will reside on the server. 

I apologize if I have mis-understood the proposal.

> From what I can see, a FDM server brings in tremendous potentials to 
> Flightgear, whereas enhancement to the present architecture would offer 
> little.  For example, to enable multiple users to fly a single aircraft,
> 
> there must be some sort of server to recieve inputs from multiple
> locations 
> and to multicasts FDM outputs.  There's no reason why one would want to
> hack 
> a client to make it do the jobs of a server when this can be very easily
> implemented if a dedicate FDM server is present.

This is getting somewhat off-topic, but I think the current MP protocol
could be enhanced to provide this function fairly easily. The first step
would be to (re-add) function to export arbitary properties. Then define
the FDM properties to be exported from the master computer (running the
FDM), and define control inputs to be passed the other way from the slave
(running null FDM). Write a bit of Nasal to mix the ai tree with the
normal tree and you're done.

There are obviously some issues regarding shared controls, but I think
those are going to be present no-matter how you split the FDM.

> > My conclusion is that the dog-fighting MP protocol (using a server
> FDM) is
> > going to have to be completely separate from the civil MP protocol
> (usign
> > a client FDM).
> >
> > -Stuart
> 
> That's an absolutely awful idea.  You will end up with two development 
> branches to keep track of, and inevitibly the more "popular" protocol
> would 
> end up being much more advanced than the less "popular" one.

Yes, it is awful. However, requiring a remote server FDM for civil MP is
worse.

-Stuart




___ 
Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. 
http://uk.docs.yahoo.com/nowyoucan.html

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Ampere K. Hardraade]

On Monday 14 May 2007 04:38, Stuart Buchanan wrote:
> If what you are suggesting is that to use MP, we will have to run the FDM
> on a server and accept a much lower refresh rate on the client, then I
> don't think that is acceptable as it will make the civil MP experience
> much worse.

This isn't as big a deal as many have advocated.  There's no requirement that 
the FDM server has to be run at a central location.  The server can be run on 
the client machine as well, serving FDM functions to the client only, and 
latency wouldn't be an issue at all.

>From what I can see, a FDM server brings in tremendous potentials to 
Flightgear, whereas enhancement to the present architecture would offer 
little.  For example, to enable multiple users to fly a single aircraft, 
there must be some sort of server to recieve inputs from multiple locations 
and to multicasts FDM outputs.  There's no reason why one would want to hack 
a client to make it do the jobs of a server when this can be very easily 
implemented if a dedicate FDM server is present.

> My conclusion is that the dog-fighting MP protocol (using a server FDM) is
> going to have to be completely separate from the civil MP protocol (usign
> a client FDM).
>
> -Stuart

That's an absolutely awful idea.  You will end up with two development 
branches to keep track of, and inevitibly the more "popular" protocol would 
end up being much more advanced than the less "popular" one.



Ampere

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Mathias Fröhlich]

On Sunday 13 May 2007, Jonathan Wagner wrote:
> Maik,
>
> These are not "dogfight-only" problems.  These are multiplayer problems
> which currently are not addressed well in the current multiplayer
> implementation.  On the public servers with high latency, multiplayer
> flight can be choppy as a plane in your view "magically" disappears from
> your right view and reappears in your left view.  Also, syncing
> positions across the entire network allows proper collision detection.
> I know it is fun to fly the Rascal or some small plane inside another
> player's Boeing 737, but it is not realistic which seems to be the focus
> of zeal in this project.
>
> Having proper collision detection would allow realistic damage and
> system failures.  In the example above, if the Rascal were to fly into
> an aileron on the left wing it is likely that the Rascal would be
> destroyed, but the 737 would only lose operation of the left aileron.
> The 737 would not be in a desirable situation, but with sufficient
> piloting skills would be able to land safely anyway.

I do not like syncing positions across the network. Because you do usually not 
have any latency you can rely on.

The current implementation tries to make the best of that information that is 
available from an other multiplayer.
Collision detection can happen at a relatively low rate I think.
But objects like the carrier where a tight coupling between the aircraft and 
the FDM(s) must be done can be a huge problem in high latency environments.

In low latency environments this will all work well ...

   Greetings

  Mathias

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Mathias Fröhlich]

On Sunday 13 May 2007, Ampere K. Hardraade wrote:
> On Sunday 13 May 2007 13:18, Harald JOHNSEN wrote:
> > If the server does the fdm 100 times per second and send the data 10
> > times per second it's like if the client was running the fdm at 10 hz.
> > That's why I said it's not needed to run the fdm at more than 10 hz
> > (those numbers are just examples).
>
> Essentially, your scenario is the same with we currently have: I/O are made
> at the same frequency as framerate while the FDM runs at 120Hz.
>
> I think you should view the scenario this way.  Consider yourself being in
> a plane that is stationary on the ground.  If you close your eyes and not
> make any adjustment to the controls of the plane, your plane would still be
> interacting with its environment.  The FDM simulates that interaction, thus
> it should continue to run at the highest rate possible regardless of the
> frequency of I/O made by the client.
As it would be good to have network packets in that rate in a LAN. You will 
easily saturate your DSL connection with that high rate ...

   Good luck

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Mathias Fröhlich]

On Sunday 13 May 2007, Bill Galbraith wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> > Behalf Of Stefan Seifert
> > Sent: Saturday, May 12, 2007 10:38 PM
> > To: FlightGear developers discussions
> > Subject: Re: [Flightgear-devel] More ideas on dogfighting
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > James Palmer wrote:
> > > In your experience, Harald, what has been the approximate
> >
> > ratio of FDM
> >
> > > vs Graphics vs remainder code on CPU time?  Has anyone done work on
> > > clocking the various subroutines in FG to determine this?
> >
> > (Perhaps I
> >
> > > underestimate the CPU time required of the FDM?)
> >
> > You could simply run stand-alone JSBSim
> > (http://www.jsbsim.org) to see, how much CPU a FDM needs. I'd
> > guess that Yasim lies in the same range.
> >
> > Nine
>
> I think that was investigated a few months ago. JSBSim FDM took only a
> couple percent of the CPU, or course depending on your hardware and what
> you were drawing. I don't think it's anything that you need to worry about.

The FDM part is very cheap.
What takes time is the intersection tests.
I have a half ready bv tree implementation here that will speed that up.
The most important thing here is to get movements right - that is to move 
correctly on the carrier for example ...
Having a better collision detection will enable many ten aircraft simulated on 
an average current cpu.

 Greetings

   Mathias

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Mathias Fröhlich]

On Friday 11 May 2007, Gene Buckle wrote:
> The problem is one of network latency.  This has been a major hurdle for
> games like Aces High, Air Warrior and WWII Online.  The server should
> handle the collision to avoid situations where the shooter client sees a
> hit and the shootee client doesn't.
Sure. I do not see a good chance to have that kind of stuff reliable over high 
network latency connections like we usually have at home.
But what could be done well is such things on a local area network with small 
latencies ...

Greetings

  Mathias


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Mathias Fröhlich]

Hi,

On Friday 11 May 2007, Martin Spott wrote:
> "Vivian Meazza" wrote:
> > Well, as the Irish would say, if you want to get there, you don't want to
> > start here. Good luck. And if you want to see how much work would be
> > involved, compare that task with the cutover to osg - now 6 months old
> > and nowhere near completion.
>
> Indeed, implementing the structure that James has in mind will
> certainly take a long time and require much work. Yet, this comparison
> with the move to OSG - heh, you really like banging on that one  :-)  -
> doesn't really match because the move to OSG was delayed by reasons
> that reside outside the FlightGear project,

Ok, there is a simpler and almost done version of that.
Sure, it would be good to have the IG's seperated from the physics engine. But 
that is a relatively huge task. At least what that proposal shows. Not sure 
if all of that is good ...

But what is very near is that we can do the phsyics in parallel with the cull 
and draw stage on a different cpu. That will utilize multi core machines in 
this current generation very well. Also osg allows us to feed multiple views 
from within one single application where each view runs its cull and draw on 
its own cpu. Osg provides much more here, but for the first cut this 
describes it well enough.

Given that in the near future only the update step does communication between 
the physics part and the IG part we have many places where the physics 
pipeline stage feeds the IG pipeline stage identified, I can see a good 
chance to do that update step with data feed over a network interface.

I can see an incremental way do go somewhere there ...

  Greetings

  Mathias

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Mathias Fröhlich]

Hi,

On Saturday 12 May 2007, Ampere K. Hardraade wrote:
> While development over the past few years might give the preception that
> Flightgear is a game, Flightgear is actually meant to be a serious flight
> simulator.  Things that go boom are cool in games, but they are also
> useless; more so in a simulator.
>
> Part of the reason why I'm against combat elements in Flightgear is that as
> more military stuffs get added, the more Flightgear appears like a game. 
> If people still want Flightgear to be treated as a serious flight
> simulator, then the less combat capabilities the better.
Ack.
My opinion is basically the same!

   Greetings

Mathias


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Lorne McIntosh]

You guys might want to give this a read. I found it helpful as an
introduction when I was looking at this multiplayer stuff a few years ago:
http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html

Because of their "fast-paced" competitive nature, First Person Shooters have
extremely tight tolerances for lag and hit-detection etc. which really makes
them perfect for the study of multiplayer architectures.

I'm tempted to say that the tolerances for a flight-sim could be a lot less,
but with aircraft doing Mach 2, firing missiles at however-many-hundred m/s,
they might just be higher :P

Lorne


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Martin Spott]

Hi James,

"James Palmer" wrote:

> If it is overly burdensome on framerate due to latency, I see no reason why
> a server cannont support both architectures (single and split).
[...]
> -As I investigate this proposed architecture, I plan to avoid splitting the
> FG world.  I do plan to allow easy avoidance between fighters and
> non-fighters (at various levels), but I think the FG community as a whole
> benefits from a single set of servers.
[...]
> The new architecture we are proposing will not be useful if it does not meet
> or exceed the performance of the current architecture.  We are well aware of
> this.

Trying to get to "the point" (TM), I'd present the now following
conclusion. This is my favourite in discussions like this one: Cutting
a mixture of different topics into respective pieces  :-)

1.) In order to run every FDM on one single server (or a cluster of
servers, if you like), you'd need to design and implement an
network protocol which is smart enough to send all control input !! 
to the server _plus_ the result of the FDM back to the client
without user-noticeable delay. You're relying on a two-way
communcation (loop) here which involves four transitions between
simulator and network (which, BTW, adds to the latency).
2.) Simply doing the job of collision detection on a centralized server
does not necessarily require to have a local FDM, you 'just' have
to make sure the position, velocity and acceleration data of the
aircraft is available just in time (TM  ;-)  - no matter how it
gets there.
3.) In case you manage to design and implement a network protocol that
meets the conditions of 1.) then it doesn't matter where the FDM is
actually running - because per your own definition you have a
network infrastructure whose latency is soo low that the pilot
wouldn't notice.
4.) If the network loop is faster than your pilot's cognition it makes
absolutely no difference if the collision detection, which is
supposed to take place on the MP server, is done at the beginning
or in the middle of the loop - per definition the pilot won't see
the difference anyway. Additionally, the visual outcome of your
enemies' action in a dogfight is always the same because this
_always_ goes:

  enemies client -> MP-server -> your client
 ^^ step 1^^ step 2

If your're running a central FDM sever, then step 1 includes all
the pilot's controls and step 2 contains FDM output. If everybody
is running their local FDM, then step 1 contains FDM output as
well, instead of pilot controls - which would not make significant
difference to the latency.

Thus I don't see the point in running the FDM on the server. In
contrast:

1.) If the network latency is really sooo low that the pilot doesn't
recognize, then you're done by implementing collision detection on
the server and leaving the FDM on the client.
2.) If network latency is too large, then the collision detection will
get delayed _plus_ the pilot will feel seriously annoyed because
his own aurcraft is being rendered 'unflyable'. The outcome of this
is that you're buying mediocre collision detection for the risk of
annoying 'your' users.

Of course FlightGear would profit from every type of improvement, which
certainly includes the network protocol as well - even though I think
what we currently have in CVS is already pretty smart ! Yet I heavily
doubt that a centralized FDM server is the solution.

BTW: What are you going to do if the server has a short (or even a
bigger) outage, maybe just 10 seconds. This might affect one local
client connection, a peer connection between different carriers or
maybe the server itself. Such thing actually _does_ happen in real
network life and you have to take this into account.

If people are running their local FDM, then they will see other
aircraft freeze during this period, but they'll continue to fly along
their path. If you're running every FDM on a central server, then
_every_ pilot will see his aircraft freeze at the current location.
What a fun 

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Curtis Olson]

On 5/14/07, Bill Galbraith wrote:


If I remember correctly, the human eye can detect something less than
about
15-20 fps.



The number that comes to my mind is about 22?  Movies that you'd see in a
theater run at 24 fps I believe.

One aditional element though that is *critical* is that this has to be an
absolutely rock solid rate for it to look smooth.  The human eye is really
good at picking out changes in frame rate even above this threashold.  If
you are running at 60fps and drop just one frame (so you run at 30fps for
one cycle), your eye can pick out the discontinuity in motion.

This is a why I'm a huge advocate of turning on the sync to vblank feature
on the video card.  It generally makes FlightGear run so much smoother
because it forces the frame rates to be more consistant.

Curt.
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/  http://www.humanfirst.umn.edu/
http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Bill Galbraith]

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Ralf Gerlich
> Sent: Monday, May 14, 2007 10:23 AM
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] More ideas on dogfighting
> 
> Hi,
> 
> Gene Buckle wrote:
> >>> Martin, the 300ms figure is really only applicable to a Level A 
> >>> simulator which is basically equivalent to a cockpit procedures 
> >>> trainer with no visuals.
> >> Ok - that one makes sense. On the other hand, any type of 'tricky' 
> >> VFR flight with 300 ms delay, I'd expect even with 150 ms 
> would ruin 
> >> every pilot's nerves   :-)
> >>
> > 150ms is the maximum allowed for a Level D certification.  I don't 
> > know of any that were that slow.  Even the 
> Conductron-Missouri 737-200 
> > simulator I
> 
> Hm, this sounds to me as if these _maximum_ numbers are 
> already unreasonably high and therefore obviously not a good 
> reference for discussing response times _acceptable to 
> users_, are they?
> 
> Currently, due to problems which might be related to an OSG 
> update, FlightGear is running on my system with 10fps in some 
> areas, where I used to get 25fps and more, and I would say 
> that this is essentially unbearable. So I'd be saying that we 
> should be talking about a maximum delay which is well below 100ms.
> 
> I won't enter this discussion, but just let me state for the 
> record that I'm clearly in favor of keeping the FDM with the client.
> 


If I remember correctly, the human eye can detect something less than about
15-20 fps.

Bill


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Ralf Gerlich]

Hi,

Gene Buckle wrote:
>>> Martin, the 300ms figure is really only applicable to a Level A simulator
>>> which is basically equivalent to a cockpit procedures trainer with no
>>> visuals.
>> Ok - that one makes sense. On the other hand, any type of 'tricky' VFR
>> flight with 300 ms delay, I'd expect even with 150 ms would ruin every
>> pilot's nerves   :-)
>>
> 150ms is the maximum allowed for a Level D certification.  I don't know of
> any that were that slow.  Even the Conductron-Missouri 737-200 simulator I

Hm, this sounds to me as if these _maximum_ numbers are already
unreasonably high and therefore obviously not a good reference for
discussing response times _acceptable to users_, are they?

Currently, due to problems which might be related to an OSG update,
FlightGear is running on my system with 10fps in some areas, where I
used to get 25fps and more, and I would say that this is essentially
unbearable. So I'd be saying that we should be talking about a maximum
delay which is well below 100ms.

I won't enter this discussion, but just let me state for the record that
I'm clearly in favor of keeping the FDM with the client.

Cheers,
Ralf

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Gene Buckle]

> > Martin, the 300ms figure is really only applicable to a Level A simulator
> > which is basically equivalent to a cockpit procedures trainer with no
> > visuals.
>
> Ok - that one makes sense. On the other hand, any type of 'tricky' VFR
> flight with 300 ms delay, I'd expect even with 150 ms would ruin every
> pilot's nerves   :-)
>
150ms is the maximum allowed for a Level D certification.  I don't know of
any that were that slow.  Even the Conductron-Missouri 737-200 simulator I
used to work on had better response times (overall) than that.  It was
built in 1967.  I do know that for the purposes of recertification it was
grandfathered in on some of the FAA cert. requirements.  It was only a
three axis sim (roll, pitch and heave) and used a Vital II visual system
(roughly 320x200 - the moon had corners :) )

g.

-- 
"I'm not crazy, I'm plausibly off-nominal!"

Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[James Palmer]

Stuart wrote:
I think our current MP architecture is superb for the following reasons:
- Setting it up is straightforward
- it is light-weight. The load on the client and server is low -
personally I have it switched on permanently - so people are encouraged to
use it for general flying, even if they are not flying specific MP
missions
- The environment is global - there is a single virtual airspace, no
matter which server you connect to (except for CVS vs. release ports)
.
My conclusion is that the dog-fighting MP protocol (using a server FDM) is
going to have to be completely separate from the civil MP protocol (usign
a client FDM).

End Quote.

I think we can still achieve these goals in the proposed architecture.
-Easy set up can be achieved not a problem.
-Over the next several weeks, I plan to do some benchmarking to determine
how "heavy" the FDM really is.
If it is overly burdensome on framerate due to latency, I see no reason why
a server cannont support both architectures (single and split).  It could
simply pass UDP packets as it does now, but also support clients requesting
FDM services.  If a user is too distance (latency wise) from a server to
find the serverside FDM useful, then they can switch to the system as it is,
run the FDM locally and probably suffer from MP "jumpiness".  However, if
the latency is not a framerate killer then they will benefit from better MP
sync  not a problem.
-As I investigate this proposed architecture, I plan to avoid splitting the
FG world.  I do plan to allow easy avoidance between fighters and
non-fighters (at various levels), but I think the FG community as a whole
benefits from a single set of servers.  There are problems associated with
distributing the FDM of several craft over servers geographically spaced
out, but I am confident enough that it can be overcome to warrant more
research.

Jonathan and I have a fair amount of hardware at our disposal.  When we have
a test architecture (don't have a time estimate yet) we plan to test client
and server on single, dual, quad and eight core machines.  We have a high
speed connection into our NOC (read high speed fiber) and will likely host a
server here.
The new architecture we are proposing will not be useful if it does not meet
or exceed the performance of the current architecture.  We are well aware of
this.
If the new version fails to outperform the current implementation in
benchmark testing we will not proceed further.  We may go back to the
drawing board, or we may focus our effort elsewhere.

I may be wrong, but I think alot of people here are getting wound up over
the fact that dogfighting may be implemented, without seeing the inherent
improvements that it offers FG.
The technical problems associated with DF could foreseeably offer:
-improved response to future hardware parallelism
-better sync for formation flying
-real world consequenses for hitting your formation partner (air-air
collision)
-real world modeling for aircraft damage (how bad was that air-air collision
during formation flying?)
-improved interaction between AI and users (SAR could be implemented coast
guard style)

Regards,
James


On 5/14/07, Martin Spott <[EMAIL PROTECTED]> wrote:


Gene Buckle wrote:

> > Personally I'd go crazy in the real Cessna if it would take me one
> > third of a second until the beast starts !! responding to a control
> > movement - this would turn almost every landing at gusty crosswind
into
> > a really difficult situation 
>
> Martin, the 300ms figure is really only applicable to a Level A
simulator
> which is basically equivalent to a cockpit procedures trainer with no
> visuals.

Ok - that one makes sense. On the other hand, any type of 'tricky' VFR
flight with 300 ms delay, I'd expect even with 150 ms would ruin every
pilot's nerves   :-)

> BTW, sorry for being such a jerk.  You were able to (likely
> unintentionally) wind me up like a clock-spring connected to a gas
> turbine. :)

  ;-)
You're welcome, it's ok,

Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel





--
James Palmer
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/__

Re: [Flightgear-devel] More ideas on dogfighting

[Martin Spott]

Gene Buckle wrote:

> > Personally I'd go crazy in the real Cessna if it would take me one
> > third of a second until the beast starts !! responding to a control
> > movement - this would turn almost every landing at gusty crosswind into
> > a really difficult situation 
> 
> Martin, the 300ms figure is really only applicable to a Level A simulator
> which is basically equivalent to a cockpit procedures trainer with no
> visuals.

Ok - that one makes sense. On the other hand, any type of 'tricky' VFR
flight with 300 ms delay, I'd expect even with 150 ms would ruin every
pilot's nerves   :-)

> BTW, sorry for being such a jerk.  You were able to (likely
> unintentionally) wind me up like a clock-spring connected to a gas
> turbine. :)

  ;-)
You're welcome, it's ok,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Stuart Buchanan]

--- Jonathan Wagner wrote:
> These are not "dogfight-only" problems.  These are multiplayer problems 
> which currently are not addressed well in the current multiplayer 
> implementation.  On the public servers with high latency, multiplayer 
> flight can be choppy as a plane in your view "magically" disappears from
> your right view and reappears in your left view.  

But critically, this only affects other aircraft in the current MP
environment - your own aircraft FDM is unaffected by network lag, or the
number of aircraft in the session. I don't really care if other aircraft
are a bit choppy as long as my aircraft is responding  immediately to my
inputs. I should only be limited by _my_ hardware, not someone elses!

If what you are suggesting is that to use MP, we will have to run the FDM
on a server and accept a much lower refresh rate on the client, then I
don't think that is acceptable as it will make the civil MP experience
much worse.

I think our current MP architecture is superb for the following reasons:
- Setting it up is straightforward
- it is light-weight. The load on the client and server is low -
personally I have it switched on permanently - so people are encouraged to
use it for general flying, even if they are not flying specific MP
missions
- The environment is global - there is a single virtual airspace, no
matter which server you connect to (except for CVS vs. release ports)

All of these things mean that MP is a "no-brainer" for users, and help
populate the virtual skies.

If a new MP system lacks these qualities, it will not be as useful or as
popular. I cannot see a server-run FDM being able to meet these
requirements, as all aircraft in a geographical area will need to be on
the same FDM server, which may be on the other side of the planet from the
client. Additionally, the number of aircraft a server will be able to
support is going to be is going to be less.

My conclusion is that the dog-fighting MP protocol (using a server FDM) is
going to have to be completely separate from the civil MP protocol (usign
a client FDM).

-Stuart



___ 
The all-new Yahoo! Mail goes wherever you go - free your email address from 
your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Gene Buckle]

> > coupled closely to provide integrated sensory
> > cues 6 These systems shall respond to abrupt
> > pitch, roll and yaw inputs at the pilot's position
> > within 150/300 milliseconds of the time, but not
> > before the time, when the airplane would respond
> > under the same conditions. [...]"
>
> Uh, 300 ms response time looks pretty bad to me at a first glance. They
> already include the time which the 'real' aircraft would need to
> respond aerodynamically - right ?
>
> Personally I'd go crazy in the real Cessna if it would take me one
> third of a second until the beast starts !! responding to a control
> movement - this would turn almost every landing at gusty crosswind into
> a really difficult situation 
>

Martin, the 300ms figure is really only applicable to a Level A simulator
which is basically equivalent to a cockpit procedures trainer with no
visuals.

BTW, sorry for being such a jerk.  You were able to (likely
unintentionally) wind me up like a clock-spring connected to a gas
turbine. :)

g.
 -- "I'm not crazy, I'm plausibly off-nominal!"

Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Bill Galbraith]

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Martin Spott
> Sent: Sunday, May 13, 2007 5:01 PM
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] More ideas on dogfighting
> 
> Hi Bill,
> 
> "Bill Galbraith" wrote:
> 
> > "Relative responses of the motion system, visual system, 
> and cockpit 
> > instruments shall be coupled closely to provide integrated sensory 
> > cues 6 These systems shall respond to abrupt pitch, roll and yaw 
> > inputs at the pilot's position within 150/300 milliseconds of the 
> > time, but not before the time, when the airplane would 
> respond under 
> > the same conditions. [...]"
> 
> Uh, 300 ms response time looks pretty bad to me at a first 
> glance. They already include the time which the 'real' 
> aircraft would need to respond aerodynamically - right ?
> 
> Personally I'd go crazy in the real Cessna if it would take 
> me one third of a second until the beast starts !! responding 
> to a control movement - this would turn almost every landing 
> at gusty crosswind into a really difficult situation 
> 

Sorry. I wasn't specific enough (and figured SOMEONE would question what I
wrote). That delay is not counting the aircraft aerodynamic delay. In the
simulation world, we set up special code for this testing, so that it takes
the same path through normal code, it just bypasses the aerodynamic effects
and recognizes the step control input, and generates a step output on the
three output systems (instruments, visual, motion).

Typically, one would also do a throughput analysis, if you have separate
computers for various functions (you do on real sims). You look at the
control input happened at t=0, but ooo, it just missed a data transfer from
the control loading computer to the host, so you have to wait for the next
one to come along. The host recognizes the input and generates the output,
and sends the signal out to the I/O, visual, and motion computers. Those
transfers are usually initiated by the host at the end of a frame, but if
they aren't you have to play the game of ooo, I just missed that data
transfer, I have to wait for the next one to happen, all the time adding up
the delays. If the theorical delay is too great, you don't have a good
architecure for something (data transfer, host execution, whatever) and may
have to make some changes. Your theorical value should be less than the 150
or 300 msec, since this is the worst that it's allowed to be. You won't
always hit the theorical number that you calculate, but hopefully you are
less some of the time.

Bill


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Jonathan Wagner]

Maik,

These are not "dogfight-only" problems.  These are multiplayer problems 
which currently are not addressed well in the current multiplayer 
implementation.  On the public servers with high latency, multiplayer 
flight can be choppy as a plane in your view "magically" disappears from 
your right view and reappears in your left view.  Also, syncing 
positions across the entire network allows proper collision detection.  
I know it is fun to fly the Rascal or some small plane inside another 
player's Boeing 737, but it is not realistic which seems to be the focus 
of zeal in this project. 

Having proper collision detection would allow realistic damage and 
system failures.  In the example above, if the Rascal were to fly into 
an aileron on the left wing it is likely that the Rascal would be 
destroyed, but the 737 would only lose operation of the left aileron.  
The 737 would not be in a desirable situation, but with sufficient 
piloting skills would be able to land safely anyway.

Just some thoughts,

Jonathan Wagner


Maik Justus wrote:
> Hi Ampere,
>
> yes,
>
> but solving this dogfight-only problem by bringing in a general problem 
> for every flightgear user is much worse.
>
> Maik
>
>
> Ampere K. Hardraade schrieb am 13.05.2007 21:25:
>   
>> On Sunday 13 May 2007 15:05, Maik Justus wrote:
>>   
>> 
>>> Maybe it is easier, that the clients run their own fdm and the
>>> combat-server makes a test of the actual performance of the client
>>> against stored values, which could be generated by a script (maximum
>>> acceleration, turn rate, speed for several sets of orientation/speed).
>>>
>>> Maik
>>> 
>>>   
>> That wouldn't solve the problem of syncing clients' positions across the 
>> entire network.
>>
>>
>>
>> Ampere
>>   
>> 
>
>
> -
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>   


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Jonathan Wagner]

Harald JOHNSEN wrote:
> Vivian Meazza wrote:
>
>   
>> Harald
>>
>>  
>>
>> 
>>> Sent: 13 May 2007 18:19
>>> To: FlightGear developers discussions
>>> Subject: Re: [Flightgear-devel] More ideas on dogfighting
>>>
>>>
>>> Ampere K. Hardraade wrote:
>>>
>>>
>>>
>>>   
>>>>  
>>>>
>>>> 
>>> If the server does the fdm 100 times per second and send the data 10 
>>> times per second it's like if the client was running the fdm 
>>> at 10 hz. 
>>> That's why I said it's not needed to run the fdm at more than 10 hz 
>>> (those numbers are just examples).
>>>
>>>
>>>
>>>   
>>>> Since the FDM takes so little CPU power, the amount clients 
>>>>  
>>>>
>>>> 
>>> that can be 
>>>
>>>
>>>   
>>>> served
>>>> should be dependent on the bandwidth.
>>>>
>>>>  
>>>>
>>>> 
>> I suppose that we run the fdm at 120Hz for a good reason: why could we
>> suddenly accept 10Hz?
>>
>> Vivian
>>
>>  
>>
>> 
> That was in the situation where the MP server does the fdm computation 
> for the client. The 10 hz comes from a ping of 100 ms between the client 
> and the server.
>
> Harald.
>
>   
Don't forget that since the current and proposed systems use UDP as the 
packet protocol which has no acknowledge packet.  Theoretically the 
server could push out FDM calculated info at 120 Hz with a 50 ms lag 
(1/2 the roundtrip ping).  Just a thought.

BTW, I'm the jwagner James referred to in an earlier post.

Jonathan Wagner

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Martin Spott]

Hi Bill,

"Bill Galbraith" wrote:

> "Relative responses of the motion system,
> visual system, and cockpit instruments shall be
> coupled closely to provide integrated sensory
> cues 6 These systems shall respond to abrupt
> pitch, roll and yaw inputs at the pilot's position
> within 150/300 milliseconds of the time, but not
> before the time, when the airplane would respond
> under the same conditions. [...]"

Uh, 300 ms response time looks pretty bad to me at a first glance. They
already include the time which the 'real' aircraft would need to
respond aerodynamically - right ?

Personally I'd go crazy in the real Cessna if it would take me one
third of a second until the beast starts !! responding to a control
movement - this would turn almost every landing at gusty crosswind into
a really difficult situation 

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Bill Galbraith]

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Martin Spott
> Sent: Sunday, May 13, 2007 4:17 PM
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] More ideas on dogfighting
> 
> Maik Justus wrote:
> 
> > Does anyone know, which latency between control input and visible 
> > reaction is acceptable (== unnoticeable)?
> 
> I'm unable to cite a qualified source from the top of my 
> head. Yet I remember different people talking and/or writing 
> about not to exceed a delay of approx. 50 ms. As a rough 
> guess think of which FlightGear frame rate you consider as 
> 'flyable' - I'd say 20 fps is the absolute minimum of what 
> people call 'smooth',
> 

Measuring between a control input and the first response to instruments,
visual, or motion base.

FAA Advisory Circular AC 120-40B, for Aiplane Simulator Qualification says:

"Relative responses of the motion system,
visual system, and cockpit instruments shall be
coupled closely to provide integrated sensory
cues 6 These systems shall respond to abrupt
pitch, roll and yaw inputs at the pilot's position
within 150/300 milliseconds of the time, but not
before the time, when the airplane would respond
under the same conditions. Visual scene changes
from steady state disturbance shall occur within
the system dynamic response limit of
150/300 milliseconds but not before the resultant
motion onset. 

[Note: 300 msec for Level A and B, 150 msec for level C and D]

FAA AC 120-45A, for Flight Training Devices, requires 150 msec for level 7,
and 300 for levels 1 through 6.

Military standards are usually 150 msec, sometimes lowered to 100 msec.

There is also a requirement that the three outputs be within 50 msecs of
each other, and visual can't respond before the motion. 

Bill


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Maik Justus]

Hi Ampere,

yes,

but solving this dogfight-only problem by bringing in a general problem 
for every flightgear user is much worse.

Maik


Ampere K. Hardraade schrieb am 13.05.2007 21:25:
> On Sunday 13 May 2007 15:05, Maik Justus wrote:
>   
>> Maybe it is easier, that the clients run their own fdm and the
>> combat-server makes a test of the actual performance of the client
>> against stored values, which could be generated by a script (maximum
>> acceleration, turn rate, speed for several sets of orientation/speed).
>>
>> Maik
>> 
>
> That wouldn't solve the problem of syncing clients' positions across the 
> entire network.
>
>
>
> Ampere
>   


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Martin Spott]

Maik Justus wrote:

> Does anyone know, which latency between control input and visible 
> reaction is acceptable (== unnoticeable)?

I'm unable to cite a qualified source from the top of my head. Yet I
remember different people talking and/or writing about not to exceed a
delay of approx. 50 ms. As a rough guess think of which FlightGear
frame rate you consider as 'flyable' - I'd say 20 fps is the absolute
minimum of what people call 'smooth',

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Ampere K. Hardraade]

On Sunday 13 May 2007 15:05, Maik Justus wrote:
> Maybe it is easier, that the clients run their own fdm and the
> combat-server makes a test of the actual performance of the client
> against stored values, which could be generated by a script (maximum
> acceleration, turn rate, speed for several sets of orientation/speed).
>
> Maik

That wouldn't solve the problem of syncing clients' positions across the 
entire network.



Ampere

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Maik Justus]

Hi,
James Palmer schrieb am 13.05.2007 03:14:
> Harald,
>
> You are correct, solution #1 does require the server to run all of the 
> FDM for all players in multiplayer mode.
Does anyone know, which latency between control input and visible 
reaction is acceptable (== unnoticeable)? The worst case of the latency 
with the FDM running on the server is the sum of
a) max. time between control input and next packet send (1/rate, e.g. 
100ms at 10Hz)
b) time for the packet from the client to the server (1/2 ping time, 
e.g. 50ms)
c) max. time for the server to do the fdm calculation and sending of the 
next packet (the fdm calculation seem to be negligible compared to the 
other latencies, therefore we get 1/rate, e.g. 100ms at 10Hz)
d) time for the packet from the server to the client (1/2 ping time, 
e.g. 50ms)
e) time for drawing of the picture at the client (1/framerate, 
eg.1s/20=50ms)

The sum of the example is 100+50+100+50+50=350ms.


The same calculation for the fdm running at the client (like it is today):
a) 0ms
b) 0ms
c) 1/framerate, eg.1s/20=50ms
d) 0ms
e) 1/framerate, eg.1s/20=50ms
results in 100ms.

I think you can feel the 350ms latency, but I am not total sure. Maybe 
some could write a tool, which add some delay to any control input and 
check out, which latency can be felt?

And think of force-feedback input devices (ok, not supported now), but 
there the maximum allowed latency is much smaller.


Maybe it is easier, that the clients run their own fdm and the 
combat-server makes a test of the actual performance of the client 
against stored values, which could be generated by a script (maximum 
acceleration, turn rate, speed for several sets of orientation/speed).

Maik

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Ampere K. Hardraade]

On Sunday 13 May 2007 13:18, Harald JOHNSEN wrote:
> If the server does the fdm 100 times per second and send the data 10
> times per second it's like if the client was running the fdm at 10 hz.
> That's why I said it's not needed to run the fdm at more than 10 hz
> (those numbers are just examples).

Essentially, your scenario is the same with we currently have: I/O are made at 
the same frequency as framerate while the FDM runs at 120Hz.

I think you should view the scenario this way.  Consider yourself being in a 
plane that is stationary on the ground.  If you close your eyes and not make 
any adjustment to the controls of the plane, your plane would still be 
interacting with its environment.  The FDM simulates that interaction, thus 
it should continue to run at the highest rate possible regardless of the 
frequency of I/O made by the client.


Ampere

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Stefan Seifert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Harald JOHNSEN wrote:
>
> That was in the situation where the MP server does the fdm computation 
> for the client. The 10 hz comes from a ping of 100 ms between the client 
> and the server.

I think FDM caculations have to be at a certain rate, independent of how
fast the calculated values are consumed because each iteration is based
on it's predecessor and the Hz determines the minimum length of any "event".

For example if an aircraft flies through an air hole for 1/100 of a
second, the impact is far less than when the smallest quantity of time
is 1/10 of a second.

But I don't really know anything about FDMs on the other hand :)

Nine
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGR1h+1QuEJQQMVrgRCOg3AJ0eFpfybrtgaJupCKmxl6mfT0GXuQCdE0th
7u0/8ZH/sp59MOHcBsROyJQ=
=BDaI
-END PGP SIGNATURE-

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Harald JOHNSEN]

Vivian Meazza wrote:

>Harald
>
>  
>
>>Sent: 13 May 2007 18:19
>>To: FlightGear developers discussions
>>Subject: Re: [Flightgear-devel] More ideas on dogfighting
>>
>>
>>Ampere K. Hardraade wrote:
>>
>>
>>
>>>  
>>>
>>If the server does the fdm 100 times per second and send the data 10 
>>times per second it's like if the client was running the fdm 
>>at 10 hz. 
>>That's why I said it's not needed to run the fdm at more than 10 hz 
>>(those numbers are just examples).
>>
>>
>>
>>>Since the FDM takes so little CPU power, the amount clients 
>>>  
>>>
>>that can be 
>>
>>
>>>served
>>>should be dependent on the bandwidth.
>>>
>>>  
>>>
>
>I suppose that we run the fdm at 120Hz for a good reason: why could we
>suddenly accept 10Hz?
>
>Vivian
>
>  
>
That was in the situation where the MP server does the fdm computation 
for the client. The 10 hz comes from a ping of 100 ms between the client 
and the server.

Harald.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Vivian Meazza]

Harald

> Sent: 13 May 2007 18:19
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] More ideas on dogfighting
> 
> 
> Ampere K. Hardraade wrote:
> 
> >On Sunday 13 May 2007 03:52, Harald JOHNSEN wrote:
> >  
> >
> >>Now if the server is doing the
> >>FDM computation it's obvious that there is no need to do that 120 
> >>times per second because the data can not be send at that rate. How 
> >>many loops does the mp server need to do per second ? 10 ? 20 ? At 
> >>that frequency you could handle 100 clients with no problems.
> >>
> >>Harald.
> >>
> >>
> >
> >As far as I know, the FDM frequency controls the fidelity of the 
> >simulation.
> >It has no relationship with the I/O frequency.
> >  
> >
> If the server does the fdm 100 times per second and send the data 10 
> times per second it's like if the client was running the fdm 
> at 10 hz. 
> That's why I said it's not needed to run the fdm at more than 10 hz 
> (those numbers are just examples).
> 
> >Since the FDM takes so little CPU power, the amount clients 
> that can be 
> >served
> >should be dependent on the bandwidth.
> >

I suppose that we run the fdm at 120Hz for a good reason: why could we
suddenly accept 10Hz?

Vivian


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Harald JOHNSEN]

Ampere K. Hardraade wrote:

>On Sunday 13 May 2007 03:52, Harald JOHNSEN wrote:
>  
>
>>Now if the server is doing the
>>FDM computation it's obvious that there is no need to do that 120 times
>>per second because the data can not be send at that rate.
>>How many loops does the mp server need to do per second ? 10 ? 20 ? At
>>that frequency you could handle 100 clients with no problems.
>>
>>Harald.
>>
>>
>
>As far as I know, the FDM frequency controls the fidelity of the simulation.  
>It has no relationship with the I/O frequency.
>  
>
If the server does the fdm 100 times per second and send the data 10 
times per second it's like if the client was running the fdm at 10 hz. 
That's why I said it's not needed to run the fdm at more than 10 hz 
(those numbers are just examples).

>Since the FDM takes so little CPU power, the amount clients that can be served 
>should be dependent on the bandwidth.
>
>Ampere
>
>  
>


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Ampere K. Hardraade]

On Sunday 13 May 2007 03:52, Harald JOHNSEN wrote:
> Now if the server is doing the
> FDM computation it's obvious that there is no need to do that 120 times
> per second because the data can not be send at that rate.
> How many loops does the mp server need to do per second ? 10 ? 20 ? At
> that frequency you could handle 100 clients with no problems.
>
> Harald.

As far as I know, the FDM frequency controls the fidelity of the simulation.  
It has no relationship with the I/O frequency.

Since the FDM takes so little CPU power, the amount clients that can be served 
should be dependent on the bandwidth.

Ampere

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Jon S. Berndt]

> I think that was investigated a few months ago. JSBSim FDM took only a
> couple percent of the CPU, or course depending on your hardware
> and what you were drawing.
>
> BIll

I didn't see that one. In any case, I just made a 200 second scripted test
run, which took 42 seconds on my 2 GHz clunker. The execution time took
about 2% of the actual corresponding real time. Also, I ran JSBSim
standalone in realtime mode, and it took about 2% of the CPU. Or, so I
thought. I watched the CPU usage when I wasn't running JSBSim, and it was no
different: still 2% of the CPU was being used. :-)

Jon


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Harald JOHNSEN]

Bill Galbraith wrote:

> 
>
>  
>
>>-Original Message-
>>From: [EMAIL PROTECTED] 
>>[mailto:[EMAIL PROTECTED] On 
>>Behalf Of Stefan Seifert
>>Sent: Saturday, May 12, 2007 10:38 PM
>>To: FlightGear developers discussions
>>Subject: Re: [Flightgear-devel] More ideas on dogfighting
>>
>>-BEGIN PGP SIGNED MESSAGE-
>>Hash: SHA1
>>
>>James Palmer wrote:
>>
>>
>>
>>>In your experience, Harald, what has been the approximate 
>>>  
>>>
>>ratio of FDM 
>>
>>
>>>vs Graphics vs remainder code on CPU time?  Has anyone done work on 
>>>clocking the various subroutines in FG to determine this?  
>>>  
>>>
>>(Perhaps I 
>>
>>
>>>underestimate the CPU time required of the FDM?)
>>>  
>>>
>>You could simply run stand-alone JSBSim 
>>(http://www.jsbsim.org) to see, how much CPU a FDM needs. I'd 
>>guess that Yasim lies in the same range.
>>
>>Nine
>>
>>
>
>
>I think that was investigated a few months ago. JSBSim FDM took only a
>couple percent of the CPU, or course depending on your hardware and what you
>were drawing. I don't think it's anything that you need to worry about.
>
>BIll
>
>  
>
I don't have fresh number but the time of a standalone JSBSim takes has 
nothing to do with the time the FDM takes in FG. First it depends on how 
many times you run it per second (in FG the default is 120 Hz). Second 
in addition to the fdm itself we are computing some ground intersection. 
And since the world geometry is very badly organized in FG this can take 
some non negligeable time (but we should see a great improvment in the 
intersection code with the osg branch). Now if the server is doing the 
FDM computation it's obvious that there is no need to do that 120 times 
per second because the data can not be send at that rate.
How many loops does the mp server need to do per second ? 10 ? 20 ? At 
that frequency you could handle 100 clients with no problems.

Harald.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Ron Jensen]

On Sat, 2007-05-12 at 20:14 -0500, James Palmer wrote:
> Harald, 
> 
> You are correct, solution #1 does require the server to run all of the
> FDM for all players in multiplayer mode.
> However, I think you are incorrect about additions or adjustments to
> the FDM.  When using FG in single player mode, the player has both the
> client and server on the same machine.  The difference is that the UDP
> traffic never leaves the machine, and the local machine only has one
> instance of the FDM (therefore single player).  Feel free to add or
> tweak the FDM as you please.  If it is a sound change, I'm sure
> whoever is maintaining the multiplayer server will have a
> method/schedule to grab changes from the CVS if they so choose.

I believe you missed the point.  Many aircraft are not in the CVS for a
variety of reasons(1)(2)(3), and much developement work has been done on
aircraft while flying on the current multiplayer servers.

I personnaly loathe the concept that someone has to vet and install
every change I want to make to an aircraft I'm developing if I want to
fly it with/against other people. 

I'm also concerned this seems to be a move away from everyone being on
one (or two) large multi-player networks (which makes syncing FDMs even
harder).   So no more watching others fly on mpmap software...


(1) http://www.jentronics.com/fgfs/
(2) http://home.comcast.net/~davidculp2/hangar/hangar.html
(3) http://perso.orange.fr/GRTux/tux/index-en.html


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Jon S. Berndt]

> I think that was investigated a few months ago. JSBSim FDM took only a
> couple percent of the CPU, or course depending on your hardware
> and what you were drawing.
>
> BIll

I didn't see that one. In any case, I just made a 200 second scripted test
run, which took 42 seconds on my 2 GHz clunker. The execution time took
about 2% of the actual corresponding real time. Also, I ran JSBSim
standalone in realtime mode, and it took about 2% of the CPU. Or, so I
thought. I watched the CPU usage when I wasn't running JSBSim, and it was no
different: still 2% of the CPU was being used. :-)

Jon


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Bill Galbraith]

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Stefan Seifert
> Sent: Saturday, May 12, 2007 10:38 PM
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] More ideas on dogfighting
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> James Palmer wrote:
> 
> > In your experience, Harald, what has been the approximate 
> ratio of FDM 
> > vs Graphics vs remainder code on CPU time?  Has anyone done work on 
> > clocking the various subroutines in FG to determine this?  
> (Perhaps I 
> > underestimate the CPU time required of the FDM?)
> 
> You could simply run stand-alone JSBSim 
> (http://www.jsbsim.org) to see, how much CPU a FDM needs. I'd 
> guess that Yasim lies in the same range.
> 
> Nine


I think that was investigated a few months ago. JSBSim FDM took only a
couple percent of the CPU, or course depending on your hardware and what you
were drawing. I don't think it's anything that you need to worry about.

BIll


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Stefan Seifert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

James Palmer wrote:

> In your experience, Harald, what has been the approximate ratio of FDM vs
> Graphics vs remainder code on CPU time?  Has anyone done work on clocking
> the various subroutines in FG to determine this?  (Perhaps I underestimate
> the CPU time required of the FDM?)

You could simply run stand-alone JSBSim (http://www.jsbsim.org) to see,
how much CPU a FDM needs. I'd guess that Yasim lies in the same range.

Nine
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGRnoG1QuEJQQMVrgRAvskAJwO+nEGGYgwEDjmjTSgeQUnn1oYMgCffZuL
wA0Q57BtKtfX0itJE4YgJlI=
=9OAG
-END PGP SIGNATURE-

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[James Palmer]

Harald,

You are correct, solution #1 does require the server to run all of the FDM
for all players in multiplayer mode.
However, I think you are incorrect about additions or adjustments to the
FDM.  When using FG in single player mode, the player has both the client
and server on the same machine.  The difference is that the UDP traffic
never leaves the machine, and the local machine only has one instance of the
FDM (therefore single player).  Feel free to add or tweak the FDM as you
please.  If it is a sound change, I'm sure whoever is maintaining the
multiplayer server will have a method/schedule to grab changes from the CVS
if they so choose.

I still have some research to do on scalability of the proposal.  On first
glance, I think (don't know) it will scale just fine.  The server is just a
mega FDM crunchin' machine.  It won't have any graphics information to
handle, just the FDM(s).  My original intent was a system capable of up to
30+ planes with full submodel capability running at once.  We'll see what I
run into as I continue to read through the core material of FG.

I agree with you that server lag is a major concern.  But I think on single
player mode (with no server to lag) it will not be an issue, and on a
multiplayer server it would yield better results than the current
multiplayer structure.

In your experience, Harald, what has been the approximate ratio of FDM vs
Graphics vs remainder code on CPU time?  Has anyone done work on clocking
the various subroutines in FG to determine this?  (Perhaps I underestimate
the CPU time required of the FDM?)

Regards,
James


On 5/12/07, Ron Jensen <[EMAIL PROTECTED]> wrote:


On Sat, 2007-05-12 at 11:06 -0500, James Palmer wrote:
> Thanks for the input Harald.
>
> -I'm going more away from Solution #2 and more toward Solution #1.

James,

Correct me if I'm wrong, but doesn't Solution #1 require the server to
run the FDM therefor preventing anyone but the server owner from
adjusting the FDM at all?  Also if the server owner doesn't / won't add
new FDMs we're stuck with using whatever FDMs they feel like adding?

While this may be a good thing from a gaming perspective I believe it
would be a very bad thing from an overall open source/flightgear
perspective. There are several interesting military aircraft available
for FGFS that either aren't GPL-able or not part of the base package for
other reasons.

How will this scale when we have 20+ aircraft flying around each
spawning multiple sub-models/AI aircraft the server is also responsible
for tracking?

The number one rule for any pilot (fighter or otherwise) is:
FLY THE AIRPLANE
If you don't (can't) do that nothing else matters.  Offloading the FDM
to another computer subject to server lag is not a good idea.

Thanks,

Ron



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel





--
James Palmer
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Ron Jensen]

On Sat, 2007-05-12 at 11:06 -0500, James Palmer wrote:
> Thanks for the input Harald.
> 
> -I'm going more away from Solution #2 and more toward Solution #1.

James,

Correct me if I'm wrong, but doesn't Solution #1 require the server to
run the FDM therefor preventing anyone but the server owner from
adjusting the FDM at all?  Also if the server owner doesn't / won't add
new FDMs we're stuck with using whatever FDMs they feel like adding?  

While this may be a good thing from a gaming perspective I believe it
would be a very bad thing from an overall open source/flightgear
perspective. There are several interesting military aircraft available
for FGFS that either aren't GPL-able or not part of the base package for
other reasons.

How will this scale when we have 20+ aircraft flying around each
spawning multiple sub-models/AI aircraft the server is also responsible
for tracking?

The number one rule for any pilot (fighter or otherwise) is:
FLY THE AIRPLANE
If you don't (can't) do that nothing else matters.  Offloading the FDM
to another computer subject to server lag is not a good idea.

Thanks,

Ron



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[James Palmer]

Thanks for the input Harald.

-I'm going more away from Solution #2 and more toward Solution #1.

-Yes I'm aware that I need to be aware of the ground.  I haven't given it
detailed thought yet, so the details here are still a bit fuzzy.  I plan to
consider this more when I write the proposal.  I'm not sure whether the
client or the FDM server should keep track of the ground.  If the client
keeps track of it (for himself only), then the FDM server could just keep
track of sea level for AI objects. (yes I know there are points below sea
level).
Like I said.. I haven't had time to think about it yet.

-I'm not sure about the hz that each will run at.  At first glance though, I
think your numbers may be a bit slow.  I'm hoping for better than that, but
we'll see.

-You are correct on adding all AI objects to the network.  I plan on
implementing that.

-I'm moving more away from that model, so I don't know yet how I plan to
solve that problem.

James

On 5/12/07, Harald JOHNSEN <[EMAIL PROTECTED]> wrote:


James Palmer wrote:

> Server Coordination:
> Some discussion on how to coordinate AI-Ballistic and AI-missile (yet
> to be created) with players was had yesterday.
> Basic Problem: Jet A is travelling at mach 2 and he has a slow
> Internet connection (200ms latency).  Jet B is approaching him from a
> direct right angle (i.e. Jet A will exactly cross Jet B's gun sight
> very shortly)  When Jet A's pilot realizes that he is about to be
> toast, he makes a hard turn, but at mach 2 he will travel
> approximately 450 feet before his slow packet reaches the server.
> This is a very simplified example, but it gets the point across.  I
> need to figure out the best way to minimize the effects of Jet A's
> latency and determine the best method of position coordination between
> players.
>
> Suggested Solution #1 - DFMP is server driven and server coordinated:
> The dogfighting MP (DFMP) should be server driven (thanks to Lethe for
> the insight into this direction) and server coordinated.  Clients
> should send user input information to the server and let the server
> calculate where the player is on the earth and inform the player of
> it.  The server would also be responsible for determining whether a
> collision has occured.  This is the approach taken by many of todays
> MP Internet games.

Note that in those games there is no client side to compute position,
etc, and in mono player mode the server is run on the client computer.
Since it's allways the server that do the computations the games react
the same wether you are in mono or multi player.

> Changes for this approach include :
> 1-an overhaul of the MP protocol.  Currently users send a UDP message
> on their position to the server which then updates the other players
> AI-Aircraft models (I think I understand this correctly,.. if not
> someone please chime in).  Clients would now have to send user input
> information to the server.  The server would have to model the FDM of
> the craft they are using, determine its new position and then update
> the client and other DFMP players on the clients new location.  These
> calculations and updates would happen for every DFMP there is on the
> server.
> 2 - a change in the client side of MP protocol to send only user
> input, and to accept new positions from the server that is driving.
> 3 - the server would need additional collision detection ("hit-box"
> relative to the size of the craft flown)

You realize that you need to compute intersections with the terrain too
(for the fdm and other objects that you launch).

>
>
> Suggested Solution #2 - DFMP is client driven and server coordinated:
> The DFMP should be client driven and server coordinated.  Clients
> would be responsible for calculating their own FDM and position on the
> earth.  Each client would send its position information to the server,
> which would maintain a list of aircraft and AI positions.  The server
> would only be responsible for passing position information to all
> players and determining whether a collision has occurred.  To further
> reduce the effects of latency, vector extrapolation may be used to
> determine a player's position when no new information packet has
arrived.

Extrapolation is done in the two scenario because knowing the real
position of things is a special case (your sims run at 50 hz and the
server send packet at 5 hz for example).

> Changes for this approach include :
> 1- Adding AI objects to the MP protocol so that gun and missile
> information can be transferred.

*Every* AI objects must be sent on the network ; aircrafts and missiles
are just one of them. On a mp server the world must be synced, a carrier
must be at the same position on all client. If I open a hangar door on
my client it must be opened on all client computer.

> 2 - the server would need additional collision detection ("hit-box"
> relative to the size of the craft flown)

If the server computes all collisions then you need the terrain too. Or
t

Re: [Flightgear-devel] More ideas on dogfighting

[Harald JOHNSEN]

James Palmer wrote:

> Server Coordination:
> Some discussion on how to coordinate AI-Ballistic and AI-missile (yet 
> to be created) with players was had yesterday. 
> Basic Problem: Jet A is travelling at mach 2 and he has a slow 
> Internet connection (200ms latency).  Jet B is approaching him from a 
> direct right angle (i.e. Jet A will exactly cross Jet B's gun sight 
> very shortly)  When Jet A's pilot realizes that he is about to be 
> toast, he makes a hard turn, but at mach 2 he will travel 
> approximately 450 feet before his slow packet reaches the server.  
> This is a very simplified example, but it gets the point across.  I 
> need to figure out the best way to minimize the effects of Jet A's 
> latency and determine the best method of position coordination between 
> players.
>
> Suggested Solution #1 - DFMP is server driven and server coordinated:
> The dogfighting MP (DFMP) should be server driven (thanks to Lethe for 
> the insight into this direction) and server coordinated.  Clients 
> should send user input information to the server and let the server 
> calculate where the player is on the earth and inform the player of 
> it.  The server would also be responsible for determining whether a 
> collision has occured.  This is the approach taken by many of todays 
> MP Internet games. 

Note that in those games there is no client side to compute position, 
etc, and in mono player mode the server is run on the client computer. 
Since it's allways the server that do the computations the games react 
the same wether you are in mono or multi player.

> Changes for this approach include :
> 1-an overhaul of the MP protocol.  Currently users send a UDP message 
> on their position to the server which then updates the other players 
> AI-Aircraft models (I think I understand this correctly,.. if not 
> someone please chime in).  Clients would now have to send user input 
> information to the server.  The server would have to model the FDM of 
> the craft they are using, determine its new position and then update 
> the client and other DFMP players on the clients new location.  These 
> calculations and updates would happen for every DFMP there is on the 
> server.
> 2 - a change in the client side of MP protocol to send only user 
> input, and to accept new positions from the server that is driving.
> 3 - the server would need additional collision detection ("hit-box" 
> relative to the size of the craft flown)

You realize that you need to compute intersections with the terrain too 
(for the fdm and other objects that you launch).

>
>
> Suggested Solution #2 - DFMP is client driven and server coordinated:
> The DFMP should be client driven and server coordinated.  Clients 
> would be responsible for calculating their own FDM and position on the 
> earth.  Each client would send its position information to the server, 
> which would maintain a list of aircraft and AI positions.  The server 
> would only be responsible for passing position information to all 
> players and determining whether a collision has occurred.  To further 
> reduce the effects of latency, vector extrapolation may be used to 
> determine a player's position when no new information packet has arrived.

Extrapolation is done in the two scenario because knowing the real 
position of things is a special case (your sims run at 50 hz and the 
server send packet at 5 hz for example).

> Changes for this approach include :
> 1- Adding AI objects to the MP protocol so that gun and missile 
> information can be transferred.

*Every* AI objects must be sent on the network ; aircrafts and missiles 
are just one of them. On a mp server the world must be synced, a carrier 
must be at the same position on all client. If I open a hangar door on 
my client it must be opened on all client computer.

> 2 - the server would need additional collision detection ("hit-box" 
> relative to the size of the craft flown)

If the server computes all collisions then you need the terrain too. Or 
the server computes what he can and the clients compute the ground 
collision and give confirmation of objects collisions between them.

>
> Cutting down the information needed for DFMP
> I've been trying to think of some methods to cut down the network 
> traffic required, by allowing the client to do some of the heavy 
> lifting.  Here are some ideas I have.
> ...
> Problems with this approach: Since the protocol is UDP, if the BO 
> initiation packet is lost, then either the server or Jet B may never 
> know of the object.  (depending on which packet is lost)
> Switching to TCP  would solve this, but that opens up a can of worms 
> I'd rather not deal with.  (anyone want to help out on this?)

Jet B will see the object the next time the object position is updated 
by the server so it should not be a real problem. And if we are in the 
second scenario then the client A is updating the position so the server 
will see the object soon enought.

>
> -- 
> Ja

Re: [Flightgear-devel] More ideas on dogfighting

[James Palmer]

Stuart wrote:
What you are suggesting is very, very, ambitious. As I understand it, you
intend to

1) Completely re-architect FG
2) Completely re-write the MP protocol
3) Add collision detection
4) Improve sub-models for munitions.

Off the top of my head, I'd say that represents something in the region of
6 man-months of full-time work, plus about the same again in bug fixing
(remember, this has to work on almost every platform known to mankind). Do
you really have an entire year to work on this for 7 hours every weekday?

End quote:

Yes.. I am aware that Rome wasn't built in a day and that you eat an
elephant one byte (little nerd humor) at a time.
I also have an advantage that I am not alone.  I will be working on this
development with my coworker jwagner.
I am currently in the process of a more detailed proposal, and I'd
appreciate your critique (and everyone else's) when I have it complete.
I do have quite the learning curve ahead, but challenges are what keeps
skills sharp.  I think your time estimates are probably close to what it
would take.  Fortunately, we do have quite a bit of time to spend on this.
I don't want to wait for nearly a year before having anything to show, so
I'm planning to implement the change in phases.  I haven't defined the
phases in hard terms yet, you'll have to wait for the more detailed
proposal.

Again thanks to all who responded.
The dialog is much appreciated.
Regards,
Jamesw

On 5/12/07, Stuart Buchanan <[EMAIL PROTECTED]> wrote:


--- James Palmer wrote:
> I have a better idea on what is involved now for adding dogfighting to
> FG.
> Thanks to all who have given me input,.. Keep it coming.



Hi James,

It is wonderful that you are so enthusiastic about contributing to the
project, and commendable that you are really thinking about what you are
doing, and discussing it on the list. However, I think it is time to add a
bit of pragmatism here that others have touched on but not really
emphasized nearly enough IMHO.

What you are suggesting is very, very, ambitious. As I understand it, you
intend to

1) Completely re-architect FG
2) Completely re-write the MP protocol
3) Add collision detection
4) Improve sub-models for munitions.

Off the top of my head, I'd say that represents something in the region of
6 man-months of full-time work, plus about the same again in bug fixing
(remember, this has to work on almost every platform known to mankind). Do
you really have an entire year to work on this for 7 hours every weekday?

The architecture document you refer to has been around for a while, and
while it offers an improved architecture for a flight simulator, it isn't
at all clear how we can separate the existing monolithic core of FG into
the different components. More to the point, as far as I know, no-one has
actually attempted to implement it, even though there are contributers
here who put many hours into FG each week.

There is also the minor issue that you aren't very familiar with the code,
having not (as far as I am aware) made any contribution to the project
before. Inevitably this means you will have a learning curve ahead of you,
both to really understand the code, and The Way Things Are Done.

I really don't want to discourage you from contributing - I am sure that
you wouldn't be suggesting this set of enhancements if you didn't have a
lot to offer the project. However, I would humbly suggest that you look
for some smaller features to implement before starting on such a large
project.   Obviously, you will need to find something that appeals to you,
but here's some random suggestions to whet your appetite:-

- Improved weather system. Currently when the METAR updates, the weather
changes instantaneously, causing control problems. A more intelligent
weather system would be of great benefit, and an interesting challenge.
- Ridge-soaring. Implementing orthographic lift and mountain waves would
enhance the gliding features immensly.
- Same aircraft MP. A nice stepping-stone towards dog-fighting would be
implementing a MP capability for two users to share the same cockpit,
allowing pilot/copilot or instructor/student

Once again, you obviously have a lot to offer to project. It would be a
great shame if this was wasted on a huge project that might not complete.

Best regards,

-Stuart


  ___
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up
for
your free account today
http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/

Re: [Flightgear-devel] More ideas on dogfighting

[Stuart Buchanan]

--- James Palmer wrote:
> I have a better idea on what is involved now for adding dogfighting to
> FG.
> Thanks to all who have given me input,.. Keep it coming.



Hi James,

It is wonderful that you are so enthusiastic about contributing to the
project, and commendable that you are really thinking about what you are
doing, and discussing it on the list. However, I think it is time to add a
bit of pragmatism here that others have touched on but not really
emphasized nearly enough IMHO.

What you are suggesting is very, very, ambitious. As I understand it, you
intend to

1) Completely re-architect FG
2) Completely re-write the MP protocol
3) Add collision detection
4) Improve sub-models for munitions.

Off the top of my head, I'd say that represents something in the region of
6 man-months of full-time work, plus about the same again in bug fixing
(remember, this has to work on almost every platform known to mankind). Do
you really have an entire year to work on this for 7 hours every weekday?

The architecture document you refer to has been around for a while, and
while it offers an improved architecture for a flight simulator, it isn't
at all clear how we can separate the existing monolithic core of FG into
the different components. More to the point, as far as I know, no-one has
actually attempted to implement it, even though there are contributers
here who put many hours into FG each week.

There is also the minor issue that you aren't very familiar with the code,
having not (as far as I am aware) made any contribution to the project
before. Inevitably this means you will have a learning curve ahead of you,
both to really understand the code, and The Way Things Are Done.

I really don't want to discourage you from contributing - I am sure that
you wouldn't be suggesting this set of enhancements if you didn't have a
lot to offer the project. However, I would humbly suggest that you look
for some smaller features to implement before starting on such a large
project.   Obviously, you will need to find something that appeals to you,
but here's some random suggestions to whet your appetite:-

- Improved weather system. Currently when the METAR updates, the weather
changes instantaneously, causing control problems. A more intelligent
weather system would be of great benefit, and an interesting challenge.
- Ridge-soaring. Implementing orthographic lift and mountain waves would
enhance the gliding features immensly.
- Same aircraft MP. A nice stepping-stone towards dog-fighting would be
implementing a MP capability for two users to share the same cockpit,
allowing pilot/copilot or instructor/student

Once again, you obviously have a lot to offer to project. It would be a
great shame if this was wasted on a huge project that might not complete.

Best regards,

-Stuart


  ___ 
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today 
http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html 

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Georg Vollnhals]

Stefan Seifert schrieb:
> ...
...
> So the question would be: are these advantages (and a larger user base)
> worth the increased perception of FlightGear being a game?
>
> Nine

Hi,
game or simulation - there is no difference between a civilian and a
military oriented branch.

As an example, we now have nearly 300 registered user of the German
FlightGear forum. Posting the first time, many of them call FlightGear a
game - and are still using FG as a game. They play with the new stuff
for some time as long as it gives some thrill and then throw it away
taking up some new toy.

Therefore a larger user base is nothing worth, neither civilian nor
military. What really counts for me is that there is a guy who seems to
be willing to do a hard job himself, not only asking "it would be nice
if we had ..". If over the time a small group would come together with
this special interest, sweating for it, fine.

Beside the advantages Stefan already showed I would add that we already
have a lot of military craft in the FG world which could profite from
further upgrading and finetuning, flightmodel and 3D-model.

This might or might not be realized over the time, but how can we judge
without giving James (and other interested) the chance to prove that his
suggestions are serious,  that means he is able to translate into deeds
- with some support from the experienced, as always :-)

And no harm for the civilian side of FlightGear, of course, that's the rule.

Georg EDDW

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Stefan Seifert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ampere K. Hardraade wrote:
> 
> While development over the past few years might give the preception that 
> Flightgear is a game, Flightgear is actually meant to be a serious flight 
> simulator.  Things that go boom are cool in games, but they are also useless; 
> more so in a simulator.

Regardless of any ethical or directional questions, getting combat
simulation to work decently, would also bring improvements for "serious"
flight simulation:

* better and more precise multi player
* collission detection, which could make formation flight even more
exciting and realistic (you won't dare to come too close to your wing
man if you can really collide)
* a damage model with which one could train for example one-wing flight
like in the video posted here

Apart from that, the code would surely benefit from adding a different
usage pattern. This usually leads to cleaner code and better
abstraction. And of course if "the document" got implemented as a side
effect of combat simulation, the rest would benefit as well.

So the question would be: are these advantages (and a larger user base)
worth the increased perception of FlightGear being a game?

Nine
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGRZjZ1QuEJQQMVrgRAhbUAJ9Po9Bew/xJ5ijoGDkJ37LhSbFqIACeMqK2
2VRSSJ2bABwIUcuLdLuQ7JI=
=GRKh
-END PGP SIGNATURE-

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Gene Buckle]

On Fri, 11 May 2007, Martin Spott wrote:

> Gene Buckle wrote:
>
> > Horsepucky.  Combat in Flight Gear would _never_ be a "shoot-em game".
> > Virtual != Real.  EVER.  If your little linoleum lizard can't understand
> > that, it's YOUR fault.  Don't nanny-state me because you can't grow a
> > pair.
>
> Hey, thanks for providing such a nice occasion to laugh at you,
>

You're quite welcome.  I'll be here all week.  Please don't forget to tip
your waitress.

g.

-- 
"I'm not crazy, I'm plausibly off-nominal!"

Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Ampere K. Hardraade]

On Friday 11 May 2007 10:28, Gene Buckle wrote:
> Banned?  BANNED?!  Good luck with that.
>
> If this wasn't involving a _simulator_, I might be inclined to agree with
> you.  However, it's a bloody _game_.  Things that go *boom* in games are
> typically pretty cool.

While development over the past few years might give the preception that 
Flightgear is a game, Flightgear is actually meant to be a serious flight 
simulator.  Things that go boom are cool in games, but they are also useless; 
more so in a simulator.

Part of the reason why I'm against combat elements in Flightgear is that as 
more military stuffs get added, the more Flightgear appears like a game.  If 
people still want Flightgear to be treated as a serious flight simulator, 
then the less combat capabilities the better.

> (unless you're against the unfair exploitation and
> destruction of things that don't exist)

Of course I'm not against doing fly pass over your virtual house and dropping 
virtual napalm daily...

> If you don't care for virtual combat, hey that's fine.  You don't have to
> work on combat related systems or use combat aircraft.  However, if you
> climb upon your high horse to ban this or that, don't be too shocked to
> find yourself flat on your back, staring up at the sky while I warm up my
> barbecue to enjoy some recently made horse steaks.

If you want virtual combat so much, there are plenty of combat simulators 
available out there.  But don't expect me to loose any sleep if you choose 
them over Flightgear.

As for banning, regardless of whether virtual combat is implemented or not, 
banning is going to be implemented one way or another -- whether it is 
banning combat completely, banning combat capabilities from civilian servers, 
or banning different generations of aircraft from different servers.  I'm 
really not worried.

Ampere

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[syd & sandy]

On Fri, 11 May 2007 21:58:50 + (UTC)
Martin Spott <[EMAIL PROTECTED]> wrote:

> Gene Buckle wrote:
> 
> > Horsepucky.  Combat in Flight Gear would _never_ be a "shoot-em game".
> > Virtual != Real.  EVER.  If your little linoleum lizard can't understand
> > that, it's YOUR fault.  Don't nanny-state me because you can't grow a
> > pair.
> 
> Hey, thanks for providing such a nice occasion to laugh at you,
> 
>   Martin.

Yes , we need more 'contributors' like this ;)
-- 
syd & sandy <[EMAIL PROTECTED]>

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Martin Spott]

Gene Buckle wrote:

> Horsepucky.  Combat in Flight Gear would _never_ be a "shoot-em game".
> Virtual != Real.  EVER.  If your little linoleum lizard can't understand
> that, it's YOUR fault.  Don't nanny-state me because you can't grow a
> pair.

Hey, thanks for providing such a nice occasion to laugh at you,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Georg Vollnhals]

James Palmer schrieb:
> I'm sorry if I've hit a sore spot with some by bringing up dogfighting
> development.
> I still intend to investigate the possibility more, but I will completely
> make the capability an "opt-in" type.
> I'm thinking along the lines of a 3 command line option set.  (see only
> non-dogfighters, see only dogfighters, and see dogfighters but don't
> participate, with see only non-dogfighters being default)
>
> Regardless of whether or not you agree with the capability the method of
> restructuring (for parallelism) will be a benefit for all (and for future
> development).
> Over the next several weeks or so, I'll be doing alot of reading (and
> asking
> alot questions too).  I plan to come up with a more comprehensive
> proposal
> to discuss with the development community.  I plan to iron out some of
> the
> details of the approach and set out the phases of development.  (At that
> point I expect you all to poke as many holes as you can in it ;-)
>
> Again, thanks to all for the input.  It is greatly appreciated. This
> is what
> drives OSS IMHO.
> Regards,
> James
>
Hi to all,

I just read through all the controverse discussion and as I am always
present here on the list it would be cowardly not to tell my opinion and
hide behind others who already said most of what I think:

First of all, there was already some interest in the FG forum and FG
users list but James is the very first who really wants to do the work
himself!!! I don't know wheather he is aware of the amount of work and
time he has to spend over the next year to get this stuff working, but
give him the chance to realize his ideas. James seems to realize pretty
well that this is only possible if his work does not have any negative
influence on the "civilian side" of the sim, which has to have priority
in all aspects.

If the dogfight ability will be a feature which is deselected by default
and the both usergroups are separated on their own servers then I cannot
see any problem for the "civilian" users.

And - to be honest - although I am a peaceful man, did no harm to
anybody until now and won't do it in the future - it could be real fun
for me trying a dogfight in a Me109 versus a Spit or in a FW190 versus a
P51. But as FG is a simulation, not a game, I doubt to have the least
chance as you really need the skills to control the aircraft *and*
"fight". As already mentioned, this will limit the group using the
feature and exclude "the unwished".

All the best to your project James

Regards
Georg EDDW



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[James Palmer]

I'm sorry if I've hit a sore spot with some by bringing up dogfighting
development.
I still intend to investigate the possibility more, but I will completely
make the capability an "opt-in" type.
I'm thinking along the lines of a 3 command line option set.  (see only
non-dogfighters, see only dogfighters, and see dogfighters but don't
participate, with see only non-dogfighters being default)

Regardless of whether or not you agree with the capability the method of
restructuring (for parallelism) will be a benefit for all (and for future
development).
Over the next several weeks or so, I'll be doing alot of reading (and asking
alot questions too).  I plan to come up with a more comprehensive proposal
to discuss with the development community.  I plan to iron out some of the
details of the approach and set out the phases of development.  (At that
point I expect you all to poke as many holes as you can in it ;-)

Again, thanks to all for the input.  It is greatly appreciated. This is what
drives OSS IMHO.
Regards,
James

On 5/11/07, Gene Buckle <[EMAIL PROTECTED]> wrote:


> > I heavily doubt. The simple fact that already these small kids are so
> > much influenced by depiction of war/crime, that they consider taking
> > the flute for a rifle (even resp. especially if it's just a game) as
> > common practice, should scare us - and certainly this doesn't justify
> > turning serious flight simulation into a shoot-em game !
>
Horsepucky.  Combat in Flight Gear would _never_ be a "shoot-em game".
Virtual != Real.  EVER.  If your little linoleum lizard can't understand
that, it's YOUR fault.  Don't nanny-state me because you can't grow a
pair.

>
> For what it's worth, the R/C modeling community apparently has this same
> basic problem ...
>
> http://www2.towerhobbies.com/cgi-bin/wti0001p?&I=LXJDU1&P=ML
>
> http://www.youtube.com/watch?v=Gh5ekEu9G3o
> http://www.youtube.com/watch?v=e3XHOqgd8hY
>
Now I've seen some irresponsible behavior before, but wow.  That's just
beyond the pale.  Jerks like these give all of us R/C fliers bad names.

> Oh, and I'm surprised that no one has brought up the notion of building
more
> spectacular crashes.  Search youtube for R/C jet crashes and you'll find
> some spectacular ones.  The R/C community is way ahead of us on that
one.
> Also you might want to search youtube for "bill hempel".  Or you might
not
> like youtube and not want to search at all. :-)
>
Hehe.  Mechanically accurate crashes would be great eye-candy for sure.
Bill Hempel is probably the best model pilot I've ever seen.
Here's unassailable proof:

http://www.youtube.com/watch?v=ZaXMrFh3n7M

g.

--
"I'm not crazy, I'm plausibly off-nominal!"

Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel





--
James Palmer
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Gene Buckle]

> > I heavily doubt. The simple fact that already these small kids are so
> > much influenced by depiction of war/crime, that they consider taking
> > the flute for a rifle (even resp. especially if it's just a game) as
> > common practice, should scare us - and certainly this doesn't justify
> > turning serious flight simulation into a shoot-em game !
>
Horsepucky.  Combat in Flight Gear would _never_ be a "shoot-em game".
Virtual != Real.  EVER.  If your little linoleum lizard can't understand
that, it's YOUR fault.  Don't nanny-state me because you can't grow a
pair.

>
> For what it's worth, the R/C modeling community apparently has this same
> basic problem ...
>
> http://www2.towerhobbies.com/cgi-bin/wti0001p?&I=LXJDU1&P=ML
>
> http://www.youtube.com/watch?v=Gh5ekEu9G3o
> http://www.youtube.com/watch?v=e3XHOqgd8hY
>
Now I've seen some irresponsible behavior before, but wow.  That's just
beyond the pale.  Jerks like these give all of us R/C fliers bad names.

> Oh, and I'm surprised that no one has brought up the notion of building more
> spectacular crashes.  Search youtube for R/C jet crashes and you'll find
> some spectacular ones.  The R/C community is way ahead of us on that one.
> Also you might want to search youtube for "bill hempel".  Or you might not
> like youtube and not want to search at all. :-)
>
Hehe.  Mechanically accurate crashes would be great eye-candy for sure.
Bill Hempel is probably the best model pilot I've ever seen.
Here's unassailable proof:

http://www.youtube.com/watch?v=ZaXMrFh3n7M

g.

-- 
"I'm not crazy, I'm plausibly off-nominal!"

Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Curtis Olson]

On 5/11/07, Martin Spott wrote:


As a little add-on we could ask ourselves if associating a flute with
"bang, bang" is really something that relies on our genes 

I heavily doubt. The simple fact that already these small kids are so
much influenced by depiction of war/crime, that they consider taking
the flute for a rifle (even resp. especially if it's just a game) as
common practice, should scare us - and certainly this doesn't justify
turning serious flight simulation into a shoot-em game !



For what it's worth, the R/C modeling community apparently has this same
basic problem ...

http://www2.towerhobbies.com/cgi-bin/wti0001p?&I=LXJDU1&P=ML

http://www.youtube.com/watch?v=Gh5ekEu9G3o
http://www.youtube.com/watch?v=e3XHOqgd8hY

For some reason, right now I can't find the one where the guy accidentally
shoots the camera man on his 4th and last rocket fired from his R/C
helicopter ... that one was great ...

Oh, and I'm surprised that no one has brought up the notion of building more
spectacular crashes.  Search youtube for R/C jet crashes and you'll find
some spectacular ones.  The R/C community is way ahead of us on that one.
Also you might want to search youtube for "bill hempel".  Or you might not
like youtube and not want to search at all. :-)

Curt.
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/  http://www.humanfirst.umn.edu/
http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Martin Spott]

"Vivian Meazza" wrote:

> Well, as the Irish would say, if you want to get there, you don't want to
> start here. Good luck. And if you want to see how much work would be
> involved, compare that task with the cutover to osg - now 6 months old and
> nowhere near completion.

Indeed, implementing the structure that James has in mind will
certainly take a long time and require much work. Yet, this comparison
with the move to OSG - heh, you really like banging on that one  :-)  -
doesn't really match because the move to OSG was delayed by reasons
that reside outside the FlightGear project,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Vivian Meazza]

Well, as the Irish would say, if you want to get there, you don't want to
start here. Good luck. And if you want to see how much work would be
involved, compare that task with the cutover to osg - now 6 months old and
nowhere near completion.
 
Vivian

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James
Palmer
Sent: 11 May 2007 13:06
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] More ideas on dogfighting


Thanks to all for the input... the collaboration of many is what makes FG so
great in my opinion.

I still plan to eventually add some sort of dogfighting capability,
HOWEVER,... I plan to start in the area detailed by this document
<http://wiki.flightgear.org/flightgear_wiki/images/1/1e/New_FG_architecture.
pdf> . (thanks to Lorne McIntosh) I believe the changes detailed in the
architecture will benefit all participants of FG by taking advantage of
multi-core systems and future developments in parallelism.  It also brings
me a bit closer to my own goal of dogfighting by giving me the FDM server/
client separation that I need. 
For those concerned with non-dogfighting, please rest assured that I will
code a "turn off dogfighting" option that will make all weapons invisible
and they will have no effect on the player.  (you would still see the
dogfighting planes circling each other, just nothing else).  This option
would be turned off by default.  If you want to participate in a dogfight,
it will take an action on the part of the user to enable that feature. 

I encourage more discussion on this topic.  I enjoy and benefit from reading
the opinions and information others have to offer.
If anyone in the FG community has begun work on the architecture changes in
the document above (or would like to) please contact me. 

Regards
James


On 5/11/07, Vivian Meazza <[EMAIL PROTECTED]> wrote: 

Detlef Faber

>
>
> Am Donnerstag, den 10.05.2007, 23:55 +0200 schrieb Maik Justus:
> > Hi,
> >
> > what's about using separate server(s) (not connected to the
> > "classical" servers) for the dogfight mode? If you log on a 
> > "classical" server, you would have no dogfight capability.
> >
> > Maik
>
> I'd agree to seperate the "combat ready" flying from the
> "peaceful" flying. There is no reason why both environments 
> should see each other at all.
> Nevertheless it should be a matter of choice which
> environment one wishes to use. This way nobody can get
> offended (If I fly in combat mode I have to be aware someone 
> else could shoot at me).
>
> Adressing the concerns about combat flying, I agree to Curt,
> that FlightGear is an Open Source Project. This means anybody
> is free to work on whatever topic he/she wishes. 
>
> Of course this doesn't mean to ignore the valid concerns of
> the other participants. I think it is very important that
> those who do not wish to use combat functionality can use the
> Multiplayer feature in the known way. 
>
> Flightgear aims to be realistic, so anyone who likes to play
> games will notice, that in Reality combat flying is not as
> easy as those commercially available "sims" pretend.
> Just intercepting an AI Aircraft on a known course is not 
> easy. Most "dubious clientele" will get offended by this.
>
> However my Interest in combat flight is a rather
> technical/historical interest. My aircraft are most WW2
> aircraft, and I've learned a lot by creating them, digging 
> through books and other historic documents.
>
> For a pilot interested in aircraft of that aera the "combat
> mode" is simply a part of the aircraft history, and should be
> possible to explore. That doesn't mean Flightgear will become 
> a "shoot em up game".
>

Hmm - at least for the Brit ac we would need to make the gyro gun sight work
and calculate lead angles. That'll be a challenge! I don't think I'll tackle

that one for a while. Perhaps after I do the RWR with Alexis.

Vivian


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take 
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list 
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
<https://lists.sourceforge.net/lists/listinfo/flightgear-devel> 





-- 
James Palmer 

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Maik Justus]

Hi James,

but how do I explain to my daughters, that suddenly one of the circling 
planes disappears? Periodically!
And from the other point of view:
-A combat-player probably would not like to decide each time, if the 
aircraft on the radar is in the civilian mode or in the dogfight mode.
-Two camel pilots in a dogfight probably would not like to be grounded 
by a homing missile.

 From my point of view combat mode can work only on separate server(s), 
maybe we would need different servers for different periods of time.

Maik

James Palmer schrieb am 11.05.2007 14:06:
> ...For those concerned with non-dogfighting, please rest assured that 
> I will code a "turn off dogfighting" option that will make all weapons 
> invisible and they will have no effect on the player.  (you would 
> still see the dogfighting planes circling each other, just nothing 
> else).  This option would be turned off by default.  If you want to 
> participate in a dogfight, it will take an action on the part of the 
> user to enable that feature. 


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Martin Spott]

"Curtis Olson" wrote:

[... kids saying bang, bang, bang ...]
> So I think we can debate nature vs. nurture all day long, but at some level,
> wanting to make things explode and enjoying it when they do ... is in our,
> uhhh ... genes (sorrry about that Gene) :-) no matter how hard we try to
> deny that.  Of course, having some level of genetic tendency towards
> something doesn't necessarily make it right to act on that tendency ... take
> alcoholism as an example ...

As a little add-on we could ask ourselves if associating a flute with
"bang, bang" is really something that relies on our genes 

I heavily doubt. The simple fact that already these small kids are so
much influenced by depiction of war/crime, that they consider taking
the flute for a rifle (even resp. especially if it's just a game) as
common practice, should scare us - and certainly this doesn't justify
turning serious flight simulation into a shoot-em game !

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Martin Spott]

Gene Buckle wrote:
[... lots of stuff ...]

As I already said in an earlier posting:

"I'm not certain if it's really the kids we have to fear. I guess some
grown-ups that are going wild are much worse  !"

I fear there's not much to add  :-/
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Gene Buckle]

> > Right. Online combat and Chess have two things in common.  First, they're
> > both forms of one on one combat and secondly, nobody ever dies from
> > either.  Actually, online combat would be safer than Chess I think.  You'd
> > never have to worry about playing some nutjob that just might try to bash
> > your skull in with the turn clock if you beat him. :)
>
>
> Your mentioning of chess opens up a window of opportunity for me to post
> this link:
>
> http://www.youtube.com/watch?v=mBT2NUkUbjg
>
> And you are right ... it appears like it can get a bit dangerous ...
>
Well that's not exactly what I had in mind, but it was funny none the
less. :)

g.

-- 
"I'm not crazy, I'm plausibly off-nominal!"

Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Curtis Olson]

On 5/11/07, Gene Buckle wrote:


Right. Online combat and Chess have two things in common.  First, they're
both forms of one on one combat and secondly, nobody ever dies from
either.  Actually, online combat would be safer than Chess I think.  You'd
never have to worry about playing some nutjob that just might try to bash
your skull in with the turn clock if you beat him. :)



Your mentioning of chess opens up a window of opportunity for me to post
this link:

http://www.youtube.com/watch?v=mBT2NUkUbjg

And you are right ... it appears like it can get a bit dangerous ...

Curt.
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/  http://www.humanfirst.umn.edu/
http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Gene Buckle]

> thing a 2 year old boy is going to do the first time he sees some longish
> rigid toy to play with ... of course he's going to pick it up and point it
> an someone and say bang, bang, bang.
>
Give 'em a P90.  They're kid sized. :)  (See Gunslinger Girls)

> So I think we can debate nature vs. nurture all day long, but at some level,
> wanting to make things explode and enjoying it when they do ... is in our,
> uhhh ... genes (sorrry about that Gene) :-) no matter how hard we try to

No problem.  I fully intend to dress up on Halloween this year as a
neandertal.  When asked if I'm a caveman, I'm going to reply, "Nope, I'm
a Recessive Gene". :)

> deny that.  Of course, having some level of genetic tendency towards
> something doesn't necessarily make it right to act on that tendency ... take
> alcoholism as an example ...
>
Right. Online combat and Chess have two things in common.  First, they're
both forms of one on one combat and secondly, nobody ever dies from
either.  Actually, online combat would be safer than Chess I think.  You'd
never have to worry about playing some nutjob that just might try to bash
your skull in with the turn clock if you beat him. :)

> Personally, I really enjoy a TV show called Myth Busters, and they make
> their living off of "busting" or confirming many weapons and explosion
> related myths ... so that show is all about really cool explosions, guns,
> swords, breaking security, torturing plants and animals, hmmm maybe I better
> rethink my favorite TV shows here ... :-)

Hey, the coolest thing ever was when they blew up the cement truck.  That
rocked. :)

g.

-- 
"I'm not crazy, I'm plausibly off-nominal!"

Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Curtis Olson]

On 5/11/07, Gene Buckle wrote:


If this wasn't involving a _simulator_, I might be inclined to agree with
you.  However, it's a bloody _game_.  Things that go *boom* in games are
typically pretty cool.  (unless you're against the unfair exploitation and
destruction of things that don't exist)

The easiest way to solve this is to just have a multi-player server that
caters only to combat ops.  The regular server would just not pass traffic
that involved weaponry.

If you don't care for virtual combat, hey that's fine.  You don't have to
work on combat related systems or use combat aircraft.  However, if you
climb upon your high horse to ban this or that, don't be too shocked to
find yourself flat on your back, staring up at the sky while I warm up my
barbecue to enjoy some recently made horse steaks.



I'm in the camp that isn't spending a lot of my own effort towards enhancing
the combat and weapons feature set of flightgear.  But having said that, I
would like to make one small observation about human nature.  My kids (2
girls) were in a daycare for a while that strictly banned any sort of
weapons playing.  If a kid so much as picked up a flute, pointed it at
something, and said bang, they were thrown in solitary confinement and
tortured for 36 hours.  And then in that environment, guess what the first
thing a 2 year old boy is going to do the first time he sees some longish
rigid toy to play with ... of course he's going to pick it up and point it
an someone and say bang, bang, bang.

So I think we can debate nature vs. nurture all day long, but at some level,
wanting to make things explode and enjoying it when they do ... is in our,
uhhh ... genes (sorrry about that Gene) :-) no matter how hard we try to
deny that.  Of course, having some level of genetic tendency towards
something doesn't necessarily make it right to act on that tendency ... take
alcoholism as an example ...

Personally, I really enjoy a TV show called Myth Busters, and they make
their living off of "busting" or confirming many weapons and explosion
related myths ... so that show is all about really cool explosions, guns,
swords, breaking security, torturing plants and animals, hmmm maybe I better
rethink my favorite TV shows here ... :-)

Curt.
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/  http://www.humanfirst.umn.edu/
http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Gene Buckle]

> > Suggested Solution #1 - DFMP is server driven and server coordinated:
> > The dogfighting MP (DFMP) should be server driven (thanks to Lethe for the
> > insight into this direction) and server coordinated. ?Clients should send
> > user input information to the server and let the server calculate where the
> > player is on the earth and inform the player of it. ?The server would also
> > be responsible for determining whether a collision has occured. ?This is
> > the approach taken by many of todays MP Internet games.
>
> If the server is capable of providing accurate and timely positioning
> information on aircraft, then the clients can do the collision detection.
>

The problem is one of network latency.  This has been a major hurdle for
games like Aces High, Air Warrior and WWII Online.  The server should
handle the collision to avoid situations where the shooter client sees a
hit and the shootee client doesn't.

Multi-player air combat can get pretty complex if you plan to support more
than a few clients at a time.  Network latency can be a huge problem,
especially if there are modem based clients.  You're going to have to come
up with a special protocol to handle it as the "Standard" (milspec)
protocol is far too verbose unless you're on a local LAN or high-capacity
WAN.  A lot of time and effor has gone into this area of online gaming,
but I don't know if the research that has been done is on the net.  I'm
sure there are a few places on the net that explain the ins and outs of
this kind of thing far better than I can.

g.



-- 
"I'm not crazy, I'm plausibly off-nominal!"

Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Gene Buckle]

> I am one of those who are not enthusiastic about adding weapons to
> FlightGear.  However, if combat capability is added, I think we would
> need to limit its scope.
>
The only limit that should be in place would be a client control that
would ignore physical effects and would not display visual effects.  The
default of course should be "off" for the clients.

> In my opinion, putting cannons on to planes is acceptable, but dropping bombs
> on ground is pushing it.  As to missiles and other "smart" weapons, I think
> they should be banned out right.
>
Banned?  BANNED?!  Good luck with that.

If this wasn't involving a _simulator_, I might be inclined to agree with
you.  However, it's a bloody _game_.  Things that go *boom* in games are
typically pretty cool.  (unless you're against the unfair exploitation and
destruction of things that don't exist)

The easiest way to solve this is to just have a multi-player server that
caters only to combat ops.  The regular server would just not pass traffic
that involved weaponry.

If you don't care for virtual combat, hey that's fine.  You don't have to
work on combat related systems or use combat aircraft.  However, if you
climb upon your high horse to ban this or that, don't be too shocked to
find yourself flat on your back, staring up at the sky while I warm up my
barbecue to enjoy some recently made horse steaks.

g.


--
"I'm not crazy, I'm plausibly off-nominal!"

Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Bill Galbraith]

 



  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James
Palmer
Sent: Friday, May 11, 2007 8:06 AM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] More ideas on dogfighting


Thanks to all for the input... the collaboration of many is what makes FG so
great in my opinion.

I still plan to eventually add some sort of dogfighting capability,
HOWEVER,... I plan to start in the area detailed by this document
<http://wiki.flightgear.org/flightgear_wiki/images/1/1e/New_FG_architecture.
pdf> . (thanks to Lorne McIntosh) I believe the changes detailed in the
architecture will benefit all participants of FG by taking advantage of
multi-core systems and future developments in parallelism.  It also brings
me a bit closer to my own goal of dogfighting by giving me the FDM server/
client separation that I need. 
For those concerned with non-dogfighting, please rest assured that I will
code a "turn off dogfighting" option that will make all weapons invisible
and they will have no effect on the player.  (you would still see the
dogfighting planes circling each other, just nothing else).  This option
would be turned off by default.  If you want to participate in a dogfight,
it will take an action on the part of the user to enable that feature. 

I encourage more discussion on this topic.  I enjoy and benefit from reading
the opinions and information others have to offer.
If anyone in the FG community has begun work on the architecture changes in
the document above (or would like to) please contact me. 

Regards
James
 

Okay, I'll be flying the heavily armoured Cessna F-172, so beware   ;-}
 
The Black Ace 
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[James Palmer]

Thanks to all for the input... the collaboration of many is what makes FG so
great in my opinion.

I still plan to eventually add some sort of dogfighting capability,
HOWEVER,... I plan to start in the area detailed by this
document.
(thanks to Lorne McIntosh) I believe the changes detailed in the
architecture will benefit all participants of FG by taking advantage of
multi-core systems and future developments in parallelism.  It also brings
me a bit closer to my own goal of dogfighting by giving me the FDM server/
client separation that I need.
For those concerned with non-dogfighting, please rest assured that I will
code a "turn off dogfighting" option that will make all weapons invisible
and they will have no effect on the player.  (you would still see the
dogfighting planes circling each other, just nothing else).  This option
would be turned off by default.  If you want to participate in a dogfight,
it will take an action on the part of the user to enable that feature.

I encourage more discussion on this topic.  I enjoy and benefit from reading
the opinions and information others have to offer.
If anyone in the FG community has begun work on the architecture changes in
the document above (or would like to) please contact me.

Regards
James

On 5/11/07, Vivian Meazza <[EMAIL PROTECTED]> wrote:


Detlef Faber

>
>
> Am Donnerstag, den 10.05.2007, 23:55 +0200 schrieb Maik Justus:
> > Hi,
> >
> > what's about using separate server(s) (not connected to the
> > "classical" servers) for the dogfight mode? If you log on a
> > "classical" server, you would have no dogfight capability.
> >
> > Maik
>
> I'd agree to seperate the "combat ready" flying from the
> "peaceful" flying. There is no reason why both environments
> should see each other at all.
> Nevertheless it should be a matter of choice which
> environment one wishes to use. This way nobody can get
> offended (If I fly in combat mode I have to be aware someone
> else could shoot at me).
>
> Adressing the concerns about combat flying, I agree to Curt,
> that FlightGear is an Open Source Project. This means anybody
> is free to work on whatever topic he/she wishes.
>
> Of course this doesn't mean to ignore the valid concerns of
> the other participants. I think it is very important that
> those who do not wish to use combat functionality can use the
> Multiplayer feature in the known way.
>
> Flightgear aims to be realistic, so anyone who likes to play
> games will notice, that in Reality combat flying is not as
> easy as those commercially available "sims" pretend.
> Just intercepting an AI Aircraft on a known course is not
> easy. Most "dubious clientele" will get offended by this.
>
> However my Interest in combat flight is a rather
> technical/historical interest. My aircraft are most WW2
> aircraft, and I've learned a lot by creating them, digging
> through books and other historic documents.
>
> For a pilot interested in aircraft of that aera the "combat
> mode" is simply a part of the aircraft history, and should be
> possible to explore. That doesn't mean Flightgear will become
> a "shoot em up game".
>

Hmm - at least for the Brit ac we would need to make the gyro gun sight
work
and calculate lead angles. That'll be a challenge! I don't think I'll
tackle
that one for a while. Perhaps after I do the RWR with Alexis.

Vivian


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel





--
James Palmer
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Vivian Meazza]

Detlef Faber

> 
> 
> Am Donnerstag, den 10.05.2007, 23:55 +0200 schrieb Maik Justus:
> > Hi,
> > 
> > what's about using separate server(s) (not connected to the 
> > "classical" servers) for the dogfight mode? If you log on a 
> > "classical" server, you would have no dogfight capability.
> > 
> > Maik
> 
> I'd agree to seperate the "combat ready" flying from the 
> "peaceful" flying. There is no reason why both environments 
> should see each other at all. 
> Nevertheless it should be a matter of choice which 
> environment one wishes to use. This way nobody can get 
> offended (If I fly in combat mode I have to be aware someone 
> else could shoot at me).
> 
> Adressing the concerns about combat flying, I agree to Curt, 
> that FlightGear is an Open Source Project. This means anybody 
> is free to work on whatever topic he/she wishes.
>  
> Of course this doesn't mean to ignore the valid concerns of 
> the other participants. I think it is very important that 
> those who do not wish to use combat functionality can use the 
> Multiplayer feature in the known way.
> 
> Flightgear aims to be realistic, so anyone who likes to play 
> games will notice, that in Reality combat flying is not as 
> easy as those commercially available "sims" pretend. 
> Just intercepting an AI Aircraft on a known course is not 
> easy. Most "dubious clientele" will get offended by this.
> 
> However my Interest in combat flight is a rather 
> technical/historical interest. My aircraft are most WW2 
> aircraft, and I've learned a lot by creating them, digging 
> through books and other historic documents.
> 
> For a pilot interested in aircraft of that aera the "combat 
> mode" is simply a part of the aircraft history, and should be 
> possible to explore. That doesn't mean Flightgear will become 
> a "shoot em up game".
> 

Hmm - at least for the Brit ac we would need to make the gyro gun sight work
and calculate lead angles. That'll be a challenge! I don't think I'll tackle
that one for a while. Perhaps after I do the RWR with Alexis.

Vivian


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Detlef Faber]

Am Donnerstag, den 10.05.2007, 23:55 +0200 schrieb Maik Justus:
> Hi,
> 
> what's about using separate server(s) (not connected to the
> "classical" servers) for the dogfight mode? If you log on a
> "classical" server, you would have no dogfight capability.
> 
> Maik

I'd agree to seperate the "combat ready" flying from the "peaceful"
flying. There is no reason why both environments should see each other
at all. 
Nevertheless it should be a matter of choice which environment one
wishes to use. This way nobody can get offended (If I fly in combat mode
I have to be aware someone else could shoot at me).

Adressing the concerns about combat flying, I agree to Curt, that
FlightGear is an Open Source Project. This means anybody is free to work
on whatever topic he/she wishes.
 
Of course this doesn't mean to ignore the valid concerns of the other
participants. I think it is very important that those who do not wish to
use combat functionality can use the Multiplayer feature in the known
way.

Flightgear aims to be realistic, so anyone who likes to play games will
notice, that in Reality combat flying is not as easy as those
commercially available "sims" pretend. 
Just intercepting an AI Aircraft on a known course is not easy. Most
"dubious clientele" will get offended by this.

However my Interest in combat flight is a rather technical/historical
interest. My aircraft are most WW2 aircraft, and I've learned a lot by
creating them, digging through books and other historic documents.

For a pilot interested in aircraft of that aera the "combat mode" is
simply a part of the aircraft history, and should be possible to
explore. That doesn't mean Flightgear will become a "shoot em up game".

...off to work,

Greetings

Detlef


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Vivian Meazza]

Holger Wirtz wrote

 
> after reading this thread I also want to drop some words:
> First I thaught dogfight would be nice. Ok, there will ever 
> be cheaters and people who cannot differentiate between 
> simple "fun" playing and the real world. But I think this is 
> not the problem of FlightGear.
> 
> In _my_ opinion (nevertheless if I am a pacifist or not) 
> there are some more important things an the todo-list than 
> dogfight (e.g. the "wall-of-weather-problem"). So why not 
> take the available coding resources for doing things that 
> will be help to gain the realism of the project in a peaceful 
> way? If I really want playing dogfights I can use one of the 
> current available simulators...
> 

Just a few more points:

As Curt said there are benefits in honing piloting skills if a dogfighting
capability were available, but it could be argued that shooting people down
is not necessary to achieve this.

I would be amazed and pleased if the problem of network latency could be
overcome to allow realistic dogfighting with guns, as opposed to combat
simulation with missiles. There could be benefits to the mainstream MP
facility if this were achieved. 

We should remember that realism is the watchword of FGFS (hey - we haven't
said that for a while - bears repeating). We should guard against adding a
facility which is compromises this.

This is an Open Source project, and if someone wants to put in the effort,
then good. As I said at the start of this thread it must be selectable,
preferable at runtime, and when deselected must have no impact on frame
rates c.f. 3D clouds etc. 

I don't think cheating is much of an issue - don't forget that MP uses
_your_ version of the ac. So the addition of a couple of parameters to the
version _you_ hold should preclude the Mach 2 Camel. It's already the case
that you can't fire more rounds than are available locally (unfortunately,
right now, all instances of an ac expend rounds at the same rate).

Vivian 


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Holger Wirtz]

Hello,

after reading this thread I also want to drop some words:
First I thaught dogfight would be nice. Ok, there will ever be cheaters
and people who cannot differentiate between simple "fun" playing and the
real world. But I think this is not the problem of FlightGear.

In _my_ opinion (nevertheless if I am a pacifist or not) there are
some more important things an the todo-list than dogfight (e.g. the
"wall-of-weather-problem"). So why not take the available coding
resources for doing things that will be help to gain the realism of the
project in a peaceful way? If I really want playing dogfights I can use
one of the current available simulators...

Regards, Holger

-- 
#   ##  ##   Holger Wirtz Phone : (+49 30) 884299-40
##  ## ##   ### ##   DFN-Verein   Fax   : (+49 30) 884299-70
##  ##  ##   Stresemannstr. 78E-Mail: [EMAIL PROTECTED]
##  ## ##   ## ###   10963 Berlin
#  ##   ##  ##   GERMANY  WWW   : http://www.dfn.de
GPG-Fingerprint: ABFA 1F51 DD8D 503C 85DC  0C51 E961 79E2 6685 9BCF

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Didier Fabert]

There is a way which satisfied everybody : make an official "add-on" with full 
weapons capabilities (not me, i'm not please to have this in default code, 
just because my children play with it). People who doesn't like weapons, 
doesn't install the add-on.


Le Friday 11 May 2007 07:51:51 Ampere K. Hardraade, vous avez écrit :
> I am one of those who are not enthusiastic about adding weapons to
> FlightGear. However, if combat capability is added, I think we would need
> to limit its scope.
>
> In my opinion, putting cannons on to planes is acceptable, but dropping
> bombs on ground is pushing it.  As to missiles and other "smart" weapons, I
> think they should be banned out right.
>
> Also, with cannons, a player must get into certain range to another for the
> weapons to be useful.  So, the planes of the "naughty" ones can be rigged
> to explode if they are on an intercept course and are too close to an unarm
> aircraft.
>
>
>
> Ampere


-- 
Didier Fabert
[EMAIL PROTECTED]
KFreeFlight project : A FlightGear GUI-Frontend designed for KDE users
http://kfreeflight.sourceforge.net

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Ampere K. Hardraade]

On Thursday 10 May 2007 10:58, James Palmer wrote:
> Suggested Solution #1 - DFMP is server driven and server coordinated:
> The dogfighting MP (DFMP) should be server driven (thanks to Lethe for the
> insight into this direction) and server coordinated.  Clients should send
> user input information to the server and let the server calculate where the
> player is on the earth and inform the player of it.  The server would also
> be responsible for determining whether a collision has occured.  This is
> the approach taken by many of todays MP Internet games.

If the server is capable of providing accurate and timely positioning 
information on aircraft, then the clients can do the collision detection.



Ampere

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Ampere K. Hardraade]

On Thursday 10 May 2007 18:52, Curtis Olson wrote:
> There are some people involved in the FG project that do not enthusiasticly
> embrace weapons and are not excited about combat functionality.
>
> I think the goal here should be to tread cautiously, respect people's views
> and opinions on the matter, and from the other side, remember this is an
> open source project and there is a certain amount of freedom involved here
> that I would like to protect.

I am one of those who are not enthusiastic about adding weapons to FlightGear.  
However, if combat capability is added, I think we would need to limit its 
scope.

In my opinion, putting cannons on to planes is acceptable, but dropping bombs 
on ground is pushing it.  As to missiles and other "smart" weapons, I think 
they should be banned out right.

Also, with cannons, a player must get into certain range to another for the 
weapons to be useful.  So, the planes of the "naughty" ones can be rigged to 
explode if they are on an intercept course and are too close to an unarm 
aircraft.



Ampere

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[syd & sandy]

On Thu, 10 May 2007 22:22:32 + (UTC)
Martin Spott <[EMAIL PROTECTED]> wrote:

> "Bill Galbraith" wrote:
> 
> > Wasn't FlightGear designed with the idea of NOT doing dogfighting?
> 
> Well, I just tried to express my concerns very politely  :-)
> 
>   Martin.
> -- 
>  Unix _IS_ user friendly - it's just selective about who its friends are !

Just to get my two cents worth in , I'm not too thrilled about this becoming a 
Combat Simulator... 
There is this project that might need some help 
http://csp.sourceforge.net/wiki/Main_Page
It uses OSG , too , but I havent tried it ...

syd & sandy <[EMAIL PROTECTED]>

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Curtis Olson]

On 5/10/07, Maik Justus wrote:


what's about using separate server(s) (not connected to the "classical"
servers) for the dogfight mode? If you log on a "classical" server, you
would have no dogfight capability.



Yes, combat, if it is pursued, should be done in a way so that at least the
multiplayer part happens in it's own sandbox.

There are some people involved in the FG project that do not enthusiasticly
embrace weapons and are not excited about combat functionality.

I think the goal here should be to tread cautiously, respect people's views
and opinions on the matter, and from the other side, remember this is an
open source project and there is a certain amount of freedom involved here
that I would like to protect.

Also it is worth pointing out that several current FlightGear aircraft
already have the ability to fire guns, flares, rockets, drop bombs, drop
parachuters, etc.

I would also point out that there are valid flight testing and handling
qualities tests that involve trying to line up your sights on a target
aircraft ... and you need a way to determine if your pipper is calibrated
correctly. :-)

So my point should I discover one in the typing of this message might be
that (a) we've already entered a good distance into the gray area, and (b)
let's respect each other's views on this one, and (c) if we develop any kind
of combat features, we need to be able to turn them off and ignore them so
that they don't consume resources or cpu time for applications that don't
need or want them.

Regards,

Curt.
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/  http://www.humanfirst.umn.edu/
http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Martin Spott]

"Bill Galbraith" wrote:

> Wasn't FlightGear designed with the idea of NOT doing dogfighting?

Well, I just tried to express my concerns very politely  :-)

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Bill Galbraith]

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Martin Spott
> Sent: Thursday, May 10, 2007 6:04 PM
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] More ideas on dogfighting
> 
> James,
> 
> "James Palmer" wrote:
> 
> > Dogfight On/Off Option:  (Thanks to Vivian) -I will include 
> an option 
> > for turning off dogfighting and still allowing multi player.  As 
> > someone pointed out we don't want some kid shooting down 
> everyone over 
> > San Fransisco while everyone else is doing serious flying.
> 
> I'm not certain if it's really the kids we have to fear. I 
> guess some grown-ups that are going wild are much worse  !
> In total I don't think such effort is for the benefit of the 
> FlightGear simulator - well, the regulars on this list will 
> remember that we already had such discussion several times.
> 
> Putting dogfight and shooting/destroying capabilities into 
> FlightGear will attract a dubious clientele that no serious 
> 'pilot' wants to get molested by in their simulated 
> environment. Certainly some of those people will find enough 
> different ways to annoy the serious pilot even if he can 
> block them from shooting him.
> 
> As a consequence I'd propose considering to let this stuff 
> run in an isolated environment, say a 'sandbox', where it 
> can't do harm to the rest of us.
> 
> Regards,
>   Martin.
> --


Wasn't FlightGear designed with the idea of NOT doing dogfighting?  I think
there is someone else out there that does a dogfighting simulation, but the
name escapes me right now. Maybe you could search around looking for them,
as they already have the ability to dogfight over the net.

Bill


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Martin Spott]

James,

"James Palmer" wrote:

> Dogfight On/Off Option:  (Thanks to Vivian)
> -I will include an option for turning off dogfighting and still allowing
> multi player.  As someone pointed out we don't want some kid shooting down
> everyone over San Fransisco while everyone else is doing serious flying.

I'm not certain if it's really the kids we have to fear. I guess some
grown-ups that are going wild are much worse  !
In total I don't think such effort is for the benefit of the FlightGear
simulator - well, the regulars on this list will remember that we
already had such discussion several times.

Putting dogfight and shooting/destroying capabilities into FlightGear
will attract a dubious clientele that no serious 'pilot' wants to get
molested by in their simulated environment. Certainly some of those
people will find enough different ways to annoy the serious pilot even
if he can block them from shooting him.

As a consequence I'd propose considering to let this stuff run in an
isolated environment, say a 'sandbox', where it can't do harm to the
rest of us.

Regards,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Maik Justus]

Hi,

what's about using separate server(s) (not connected to the "classical" 
servers) for the dogfight mode? If you log on a "classical" server, you 
would have no dogfight capability.


Maik


James Palmer schrieb am 10.05.2007 16:58:
I have a better idea on what is involved now for adding dogfighting to 
FG.

Thanks to all who have given me input,.. Keep it coming.

After talking with alot of you, here are the additional and more 
finely tuned ideas that I have.

...Suggested Solution #1 - DFMP is server driven and server coordinated:
...
Suggested Solution #2 - DFMP is client driven and server coordinated:
...


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More ideas on dogfighting

[Lorne McIntosh]

I recall reading a document some time ago about re-structuring FG into a
more robust client / server architecture:

http://wiki.flightgear.org/flightgear_wiki/images/1/1e/New_FG_architecture.p
df

 

You might want to give that a read. it's fairly similar to your "Suggested
Solution #1" I think. That solution would also be the best for
cheating-prevention (not like it means much though when the client
purposefully exposes interfaces for writing UAVs or *cough* aim-bots, haha).
But at least it would preclude a WWI bi-plane from doing Mach 8.

 

Lorne

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James
Palmer
Sent: Thursday, May 10, 2007 7:58 AM
To: flightgear-devel@lists.sourceforge.net
Subject: [Flightgear-devel] More ideas on dogfighting

 

I have a better idea on what is involved now for adding dogfighting to FG. 
Thanks to all who have given me input,.. Keep it coming.

After talking with alot of you, here are the additional and more finely
tuned ideas that I have. 

Dogfight On/Off Option:  (Thanks to Vivian)
-I will include an option for turning off dogfighting and still allowing
multi player.  As someone pointed out we don't want some kid shooting down
everyone over San Fransisco while everyone else is doing serious flying.
The option will not turn off AI-Aircraft, as you still want to see other
players (otherwise you'd play single player on the local machine), it will
just ignore all submodel information from the server ( i.e. guns and
missiles).  This option should probably be turned Off by default.  

Server Coordination:
Some discussion on how to coordinate AI-Ballistic and AI-missile (yet to be
created) with players was had yesterday.  
Basic Problem: Jet A is travelling at mach 2 and he has a slow Internet
connection (200ms latency).  Jet B is approaching him from a direct right
angle (i.e. Jet A will exactly cross Jet B's gun sight very shortly)  When
Jet A's pilot realizes that he is about to be toast, he makes a hard turn,
but at mach 2 he will travel approximately 450 feet before his slow packet
reaches the server.  This is a very simplified example, but it gets the
point across.  I need to figure out the best way to minimize the effects of
Jet A's latency and determine the best method of position coordination
between players. 

Suggested Solution #1 - DFMP is server driven and server coordinated:
The dogfighting MP (DFMP) should be server driven (thanks to Lethe for the
insight into this direction) and server coordinated.  Clients should send
user input information to the server and let the server calculate where the
player is on the earth and inform the player of it.  The server would also
be responsible for determining whether a collision has occured.  This is the
approach taken by many of todays MP Internet games.  
Changes for this approach include :
1-an overhaul of the MP protocol.  Currently users send a UDP message on
their position to the server which then updates the other players
AI-Aircraft models (I think I understand this correctly,.. if not someone
please chime in).  Clients would now have to send user input information to
the server.  The server would have to model the FDM of the craft they are
using, determine its new position and then update the client and other DFMP
players on the clients new location.  These calculations and updates would
happen for every DFMP there is on the server. 
2 - a change in the client side of MP protocol to send only user input, and
to accept new positions from the server that is driving.
3 - the server would need additional collision detection ("hit-box" relative
to the size of the craft flown) 


Suggested Solution #2 - DFMP is client driven and server coordinated: 
The DFMP should be client driven and server coordinated.  Clients would be
responsible for calculating their own FDM and position on the earth.  Each
client would send its position information to the server, which would
maintain a list of aircraft and AI positions.  The server would only be
responsible for passing position information to all players and determining
whether a collision has occurred.  To further reduce the effects of latency,
vector extrapolation may be used to determine a player's position when no
new information packet has arrived. 
Changes for this approach include :
1- Adding AI objects to the MP protocol so that gun and missile information
can be transferred. 
2 - the server would need additional collision detection ("hit-box" relative
to the size of the craft flown)

Cutting down the information needed for DFMP 
I've been trying to think of some methods to cut down the network traffic
required, by allowing the client to do some of the heavy lifting.  Here are
some ideas I have. 
- Ballistic Objects would be initiated but not updated by sender (i.e.
bullet from a gun).  Jet A shoots a bullet at Jet B.  Jet A sends a BO
initiation packet to the server.  It has all of the property information
that is normally associated with it