[Flightgear-devel] Re: multiplayer status and idea

[Michael Matkovic]

Hi Adam,

I'm in the process of having a networked system of 5 computers for purposes of running 
flightgear-based
experiments. One of the main things I was looking for is exactly what you're working 
on! :-D
I'd be happy to try the server code on our machines (once they're up and running).
Where's the code? in CVS?
thanks
Michael.
/
I only have one machine that can run flightgear here, so
testing involves running flightgear twice on the same machine.  Needless
to say, I've barely tested it with 3 planes. :)  (It seemed to work
though.)  If anyone else has more resources and would like to try it
out, please let me know./


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

Re: [Flightgear-devel] Re: multiplayer status and idea

[Adam Boggs]

Duncan McCreanor <[EMAIL PROTECTED]> wrote:

> Adam Boggs wrote:
> > Date: Wed, 04 Feb 2004 16:42:26 -0700
> > From: Adam Boggs <[EMAIL PROTECTED]>
> > Subject: [Flightgear-devel] multiplayer status and idea (Long)
> > To: [EMAIL PROTECTED]
> > Message-ID: <[EMAIL PROTECTED]>
> 
> >
> > So my thought was since that code is mostly there and does practically
> > all of the things that we would want to do on the server (with some
> > slight differences), why not reuse as much of that code as possible?
> > ...
> >
> > Thanks,
> > -Adam
> 
> Adam,
> 
> The multiplayer server you have created is what we had in mind when we
> wrote the multiplayer code. So I think you're on the right track.

Great!  I could tell from the comments that it had been thought ahead.

Unfortunately I ran into problems trying to link an external program
straight with libMultiPlayer.  The "globals" require linking with
libMain and suddenly there are a huge set of library dependencies.  I
included a couple of the header files and stripped down a private copy
of mpplayer.cxx so it should be easy to move that direction.  I'm not
really a flightgear developer yet so wanted to avoid touching the main
code as much as possible.  To get a server any further than the basic
functionality will probably require some changes though.

> Some things that I think should be taken into consideration when
> creating a multiplayer server based on the current code are:
> 
>  - the multiplayer code limited the number of players to ten. This was
> done because the frame rate drops as the number of multiplayer
> aircraft being rendered increases. It is highly likely that ten
> is too many.

Good point.  I only have one machine that can run flightgear here, so
testing involves running flightgear twice on the same machine.  Needless
to say, I've barely tested it with 3 planes. :)  (It seemed to work
though.)  If anyone else has more resources and would like to try it
out, please let me know.

>  - the number of aircraft rendered could be minimised by comparing the
> position of each player and only sending player data to/from other
> players within a player's visible range or some fixed radius.

That's a great idea.  I'm still a little unsure about the contents of
the sgMat4 that is sent in the position message, so I haven't done any
interpretation of it beyond printing it out.  Is it just a transformation
matrix with position, rotation, etc?  Right now I just pass it on opaquely.

>  - the rate the data is sent to a player should be based on the rate
> the data is received from that player by the server. The rate that a
> player sends and processes received position updates is specified on
> the command line, but limited by the frame rate. There is not much
> point in sending updates more frequently than the player is able to
> process them. Basically, when the server receives a packet from a
> player, it should reply with the cached positions of other players.

So it becomes more of a "pull" model...  Right now when host A sends out
an update it immediately gets forwarded to B, C, and D.  But this puts
host D, who might be suffering on slow hardware, in the drinking-from-a-
firehose situation ("push" model).  So instead we can rate limit it by
making it so when A sends out an update, A immediately receives the
(cached) positions of BC&D, and BCD don't get A's update until they
send their next position update.  I'll give that a try, should be easy
to change.  Would be nice to be able to include multiple position
messages in a single packet too.

> I had one day hoped to develop a Flightgear multiplayer server along
> the lines that you're experimenting with, but couldn't find the time.
> So it would be good to see someone doing this.
> 
> Regards,
> Duncan.

Well, if you're interested in working/playing with this at all you're
welcome to.  :)  Thanks for the great ideas above.

-Adam


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

Re: [Flightgear-devel] Re: multiplayer status and idea

[Christian Brunschen]

On Thu, 5 Feb 2004, Duncan McCreanor wrote:

> Some things that I think should be taken into consideration when creating a
> multiplayer server based on the current code are:
>
>  - the multiplayer code limited the number of players to ten. This was done
> because the frame rate drops as the number of multiplayer aircraft being
> rendered increases. It is highly likely that ten is too many.
>
>  - the number of aircraft rendered could be minimised by comparing the
> position of each player and only sending player data to/from other players
> within a player's visible range or some fixed radius.
>
>  - the rate the data is sent to a player should be based on the rate the data
> is received from that player by the server. The rate that a player sends and
> processes received position updates is specified on the command line, but
> limited by the frame rate. There is not much point in sending updates more
> frequently than the player is able to process them. Basically, when the
> server receives a packet from a player, it should reply with the cached
> positions of other players.
>
> I had one day hoped to develop a Flightgear multiplayer server along the
> lines that you're experimenting with, but couldn't find the time. So it would
> be good to see someone doing this.

I know I'm not actually involved in FlightGear development, but please
bear with me anyway :)

When it comes to multi-player flight sim, one should keep in mind the
virtual air traffic control networks out there, like
VATSIM , IVAO , and so on.
These all have an existing server infrastructure with existing protocols.

Now, this doesn't in any way invalidate other multiplayer approaches.
But if interoperability with the above-mentioned systems were available,
that would make Flightgear an option for those who want to fly in such a
simulated controlled environment; and also open the door for flying
together with users of other sims.

> Regards,
> Duncan.

Best wishes,

// Christian Brunschen

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

[Flightgear-devel] Re: multiplayer status and idea

[Duncan McCreanor]

Adam Boggs wrote:
> Date: Wed, 04 Feb 2004 16:42:26 -0700
> From: Adam Boggs <[EMAIL PROTECTED]>
> Subject: [Flightgear-devel] multiplayer status and idea (Long)
> To: [EMAIL PROTECTED]
> Message-ID: <[EMAIL PROTECTED]>

>
> So my thought was since that code is mostly there and does practically
> all of the things that we would want to do on the server (with some
> slight differences), why not reuse as much of that code as possible?
>
> In doing this, I came up with a basic server in 500 lines of code that
> simply rebroadcasts in incoming position update to all of the other
> clients connected to the server (and using plib netSockets).  The
> existing MultiPlayer code is somewhat reusable, but the globals hork it
> all up. Grr.
>
> Anyway, the clients still use the --multiplay options, but all specify
> the same out "ip" address/port (to the server) and different "in" ip
> address/ports (for receiving updates).  I pretty much have this written
> and have done some basic testing, but need some help: what's the best
> way to run multiple flightgear instances on a single machine without
> hosing the CPU and memory?  Any suggestions?
>
> NOTE: I'm not necessarily trying to start up a new project here, but am
> more doing this as a prototype/learning experience.  If anyone is
> interested in checking out the code and playing with it once I've got
> some of the kinks worked out, that would be awesome!
>
> Please feel free to educate me on things I might have overlooked, or
> express opinions on the idea/approach.  I still have not fully proved
> the concept yet either.  More testing will tell.
>
>
> Thanks,
> -Adam

Adam,

The multiplayer server you have created is what we had in mind when we wrote 
the multiplayer code. So I think you're on the right track. 

Some things that I think should be taken into consideration when creating a 
multiplayer server based on the current code are:

 - the multiplayer code limited the number of players to ten. This was done 
because the frame rate drops as the number of multiplayer aircraft being 
rendered increases. It is highly likely that ten is too many.

 - the number of aircraft rendered could be minimised by comparing the 
position of each player and only sending player data to/from other players 
within a player's visible range or some fixed radius.

 - the rate the data is sent to a player should be based on the rate the data 
is received from that player by the server. The rate that a player sends and 
processes received position updates is specified on the command line, but 
limited by the frame rate. There is not much point in sending updates more 
frequently than the player is able to process them. Basically, when the 
server receives a packet from a player, it should reply with the cached 
positions of other players.

I had one day hoped to develop a Flightgear multiplayer server along the 
lines that you're experimenting with, but couldn't find the time. So it would 
be good to see someone doing this.

Regards,
Duncan.




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