John Wojnaroski wrote:

Will FlightGear provide a pilot entity, controller entity, or both?

This is what I would PERSONALLY consider reasonable:

        1) make FG export the necessary data from its property tree

        2) interface FG with the network(s) - so that the flights show
           up on *normal* (already available) VATSIM/IVAO clients

        3) incorporate a cross-platform VoIP tool, this would not need
           to be compiled by default, but should rather be optional

        => so far this is step #1

At this point we would already be able to use FlightGear with
(one of) the major network(s)

        4) think about implementing a cross-platform ATC client,
           possibly based on 'xatc'

At this point one would also have the possibility to attract
users of other platforms to the whole ATC thing


And then there's of course still the possibility, to

        5) think about ways to add TTS/ARS capabilities

These would not need to be directly linked to any of the
networks, but it would certainly be interesting to be
able to:

        6) mix virtual 'real' controllers and AI controllers.

But, I think it's still quite a task ...


The
needs are driven in large part by the scope of operations the individual
wishes to perform -- from a few circuits around the local airfield, a short
flight with the family to visit the grandparents, an IFR cross-county, a
commercial 737 from KLAX to KDEN, a 747 flight from KJFK to EGLL...

As you already mentioned, it would indeed be quite attractive to have an AI available, that can deal with the 'pilots' as they wish ... so, no need to really have people available who really do the controlling part in realtime.


That way we can also determine what's acceptable and what's not.

As soon as these things are clear, we'll see their *real* ;-)
attitude.


By all means, keep the dialogue open...


Sure, this morning I received the following short reply from the
author of squawkbox 3:

8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<

        My protocol code is already cross-platform ready.  SquawkBox 3
        is a Microsoft Flight Simulator plug-in though so it's really
        tied to that. Otherwise there is no particular reason why it
        needs to be Windows.

        X-Plane runs on Mac, as does MacRadarScope, a Mac ATC client.
        The server software runs on Linux.  So the protocol is in no way
        particularly tied to Windows.

8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<

This was in response to my question whether his protocol/implementation
would be specific to windows, or how feasible it would be to slowly
migrate the protocol, so that it can be used on non-windows platforms.


As to the three points:

1) the protocol has to be open. Security should not be an issue, if it is
then there is something wrong with the design and/or implementation

this is actually exactly what I replied to the IVAO folks, who seem to be following that route ...

2) the protocol should be platform neutral (although there might be some
issues with # of bytes for data type and big endian/little endian).

right, so the VATSIM reply seems really rather encouraging

3) probably need both "live voice" and an ASR/TTS capability to handle a mix
of live and AI controllers.

personally, I think this is mainly about an INTEGRATION issue, not so much about adapting the current implementation - ultimately 'our AI' ;-) could probably be simply linked to a running ATC client that connects to (one of) the two network(s).

That way, the whole approach would be kept modular, and if it should
really happen that this is going to be possibly anytime soon, one
could still decide whether to run the AI directly on the same hosts
as FG - for local purposes, or link the AI part to the ATC network
itself ...

Even though, I have some doubts regarding the speech recognition
part in such a scenario,because the ASR would then have to deal
with many people, whose voice profiles aren't available ....

Hence, it would probably be a better idea, to run the TTS/ASR
locally on most FG machines, and simply transmit the actual
ATC instructions to the AI part ?

If we ever get to the point that the AI
controllers can pass the Turing test maybe we can "shoot" the live
controllers ;-) or at least provide a more robust expanded controller
population

it's not happening that soon - so, if there is is a simple chance to get any of the major networks to support FG, this would already be quite a success - one can still think about the AI part, I certainly will play around with the ideas that were mentioned so far - even if it's just for the fun of it ...


 This almost begs to be a separate project under the FlightGear umbrella
(aka JSBSim). It would not be all that hard to write a network module to
output FG parameters -- there is a plethora of protocols defined in
../src/Networks adding one more won't cost that much.

what I know so far: the VATSIM protocol *seems* to be based on some simple telnet-like protocol, so one might very well be able to to get this going by making only minimal adjustments to the sources, and simply use the existing possibility to define protocols within XML.

One might need to do some basic calulations within the XML defintions,
though ...


The AI/ATC module is another bigger question, and we need to hear from the
author.

David ?

it would also be interesting to hear how the virtual ATC community
feels about the idea of mixing AI and live controllers. This would also
complicate the protocol to some degree....

this is of course right, BUT actually SOMETHING like this is already done on some networks - software like squawkbox goes even one step further and provides logical implementations of aircraft systems such as 'TCAS' that work with the 'real' traffic as well as the AI traffic.

So, if it should be really possible at some point, to integrate
one system into the other, it's probably going to happen anyway ;-)



---------
Boris

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

Reply via email to