--- Mathew McBride <[EMAIL PROTECTED]> wrote:
> On Tuesday 14 January 2003 23:14, ace project wrote:
> <snip>
> > A squakbox add-on would be a great, Matthew.
>
> There's a problem there, I've ended up considering
> either:
> 1) Reverse engineering the Simclients protocol (used
> by SB and Procontroller).
> Simclients won't give me information on the protocol
> without signing a NDA.
> 2) Developing a open protocol. This can be a better
> option, but at some times,
> a bit of a gamble. It would have to be LGPL'ed, but
> on the plus side, anyone
> wanting to create a ATC client for any sim can do
> so.
>
The network modules works outside the ATC at this
time.
The protocols I use are documented a little bit, which
can be found at
htp://people.zeelandnet.nl/liono/ace/mpe/mpe.htm
A stand alone client will not be continued further at
this time because this client would not to the
scenery, but there is code in place to fascilitate
this later.
If the standalone client should be maintained say it
now, so I will do it (will only introduce more
#defines).
> Developing a ATC client for FGFS is a good solution
> both Short and Long term
> (saying that no one with a copy of FS2002 uses it
> these days because of it's
> interactive ATC)
> <snip>
> * The aircraft type. Can someone suggest a default
> aircraft type if FlightGear
> doesn't have a suitable matching aircraft (aircraft
> info is sent as a ICAO
> 4-character code. I don't want to redefine every
> FGFS FDM so aircraft can
> identify their ICAO code on request, keeping in mind
> FS suffers from the same
> problem).
I don't know what the ICAO format is, can I retrieve
this value from the FG property-tree ? If so, it will
implemented at once. At this moment I use the name of
the short name of the aircraft.
>
> * What aircraft is the airport departing from. I
> don't need to feed this, but
> it will speed FGFS up when a new aircraft joins in
> so if someone incorrectly
> defines the positition of a runway/terminal/taxiway
> etc. (unlikely in most
> cases), it won't look like it's taking off grass.
Not my responsebility at this time, without more
collision detection with the scenery its undoable to
handle this kind of subtle errors.
>
> * (could be useless) Aircraft vectors. FS2002
> clients mainly use GPS, so this
> may not be needed. But, if FlightGear ever gets
> interactive ATC, if the ATC
> knows in advance where the particular aircraft is
> (supposedly) going, that
> would help to avoid crashes.
FG itself does not maintain vectors, how could we
implement this in this module ?
(maintaining static position, extrapolating them and
sending the resulting vector might work ???)
> Some other things:
> The network module must either not tolerate multiple
> connections from the same
> client (and if my (proposed) add-on is on the same
> machine as FGFS, which it
> will likley be, it would have to open multiple) or
> be able to listen on
> multiple ports (these would have to be user space
> ones). Unless it would have
> no problem with me using one connection, and just
> putting the callsign as the
> first parameter of every message between the client
> and FGFS. (which I don't
> think is a good gamble)
A client computer can open as much connection as it
wants, but there should be only 1 for each Flight Gear
Client. The server can distinguis clients on different
computers by the UDP-port they are using (its unique
per sockets, when we're not cheating)
The UDP-ports the client uses gets assigned by the OS
and is unique for the client and the IP-address.
> My client has to be able to somehow plot a direct
> line as a flight path if
> another user's connection says nothing for more than
> a acceptable amount of
> time (didn't Leon say he was seaching for a way to
> do this, after all, we
> coukd just act like the plane is on Heading hold),
> Simclients (I think) kills
> the connection when a message is send to the client,
> but times out.
At the moment the plane would just stands still in mid
air for 10 second before the connection gets killed.
This is because I don't have a extrapolation formule
put is yet.
> If it (the user) drops out, we could do something
> more than making it
> disappear ,e.g, making it descend as if it's
> landing, but without the landing
> gear activated, or making some fun over the radio
> ("XXX001 Heavy at 35,000
> ft, declaring emergency, decending fast", "XXX001
> Heavy, rgr, descend to
> 10,000 feet", "[some tower] rgr [explosion]")
Not my idea, because in a development env this would
mean about 10 crashing planes at once when the server
drops out or the client looses his connection to it.
> >
> > =====
> > My Flight Gear Multiplayer Stuff
> (work-in-progress):
> >
>
http://www.kbs.twi.tudelft.nl/People/Students/L.Otte/
>
>
> --
> Mathew McBride
> [EMAIL PROTECTED]
> http://mcbridematt.dhs.org
> Jabber: mcbridematt on the jabber.org server
>
> _______________________________________________
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
>
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
=====
My Flight Gear Multiplayer Stuff (work-in-progress):
http://www.kbs.twi.tudelft.nl/People/Students/L.Otte/
OK, I admit it: My girlfriend's just an object to me.
Unfortunately, there is some information hiding, but
thankfully, she's fairly encapsulated, nicely modular, and
has a very well defined interface!
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
