Re: [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic

[Durk T. <dur...@gm...>]

> There is one slightly fundamental choice here, about where the AI logic
> resides.
>

My preference would be to have the intelligence reside on the Traffic
generator side. If we decouple it from FlightGear, there's no fundamental
limit at how smart wek can make these aircraft.


>
> My preferred approach would be to extend the MP protocol into an ‘AI’
> protocol, and have the option to run all current AI types (carriers,
> tankers, scenarios, MP, traffic) via that protocol. With the same
> prediction in the client (current flightgear side) but nothing else really.
>

Agreed. I just finished checking my test setup, which consists of a local
multiplayer server running on my linux box, one instance of FlightGear
running on the same machine, and a second instance of FlightGear running on
my laptop. From here, I intend to replace the FlightGear instance on my
laptop with something the generates traffic, and feeds that to the local
multiplayer server.


>
> Then we run the ‘server’ side which runs scenarios / traffic / carriers as
> a separate thread or process. Ideally we allow a given FG client to show
> ‘AI objects’ from multiple sources for testing. When you connect to an ‘MP’
> server you’re really joining a consistent simulation environment, whether
> that be a local server, local thread or an Internet server.
>

Agreed. One thought just struck me, which is that we could incorporate a
copy of the detailed weather  subsystem server side, so that we could
generate consistent weather across sessions, without the need to had that
generated from within FlightGear.

Having said that, it's probably good to take this one step at the time...
:-)

Cheers,
Durk