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
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.
>
> --
> 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
--
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
