On Fri, Feb 6, 2009 at 4:01 PM, Tim Krajcar wrote:
> Hi there,
> I'm sure you've all seen the news recently of Microsoft closing the ACES
> Studio and throwing doubt on the future of the Flight Simulator franchise.
> I'm a member of VATSIM's Board of Governors; my official position is VP of
> Web Services but I work pretty closely with our VP of Development, Ross
> Carlson, who I chatted with before sending this message.
> The news about ACES has drummed up renewed interest in VATSIM for
> alternative pilot client solutions; as you're probably aware we have a quite
> successful implementation with X-Plane. There are some limitations due to
> our network protocol (FSD)'s lackings (of which a newer version has been
> under development for awhile now) but on the whole it really functions quite
> I know there have been many concerns raised in the past in the FG community
> about working with a closed-source, NDA-requiring entity. I'd like to throw
> a little fuel on the fire, if I may, and also put forth a couple ideas I had
> of how we can work together.
> First, you should know that neither Ross or I nor most of VATSIM view our
> current closed-source/NDA arrangement as ideal, and we are working our way
> (albeit quite slowly) to a future version that will be fully open.
> Second, you should know that while VATSIM does at the moment require
> developer NDA to gain access to the FSD specifications, I did have a couple
> thoughts on how FG & VATSIM could potentially coexist.
> One model that has been proposed before is the proxy server model; that
> would certainly be a possibility.
> Another model that occurred to me is by creating a stand-alone application
> that is closed-source and serves as the FlightGear/VATSIM client. By
> remaining closed-source it would fulfill VATSIM's requirements. How, then,
> would it communicate with FG? This you guys will know better than I as I'm
> not familiar with all the interprocess communication options you have
> available, but one thought is that you could open a TCP/IP socket and pass
> messages back and forth with the standalone client.
> Certainly I understand that you as developers of FG will work on features
> that you find interesting first (VATSIM, as an all-volunteer organization,
> is much the same way), and for some the mere concept of signing a NDA and/or
> working on a closed-source project is unacceptable. That's fine; we have no
> problems with that viewpoint and I don't need reminding of why you feel that
> way. I am an active open-source developer myself on several projects and
> completely understand the reasonings of those who might feel this way.
> However, if there are developers within the FG community who would be
> interested in working on a project like this, we at VATSIM would be quite
> keen to participate and I think that you would see a greatly increased
> visibility for your project as we would be able to heavily promote
> FlightGear within VATSIM. Participating in VATSIM is always completely free
> of charge, and indeed it is possible to act as a controller without anything
> except a computer and internet connection, but as a pilot you must purchase
> a commercial flightsim. If a client was created for FlightGear, we (and you)
> could and would promote it as the completely no-cost way to enjoy online
> flying with real people providing air traffic control via real world
> I'd be happy to answer any questions or concerns you might have, on- or
> off-list, as best as I can.
Sorry to quote your whole message ... chalk it up to laziness. :-)
As I read through your message a few thoughts occurred to me.
First, there is a large variety of opinions represented here on our
developers list, and we have a few really die hard open-source folks ...
"give me open-source or give me death ..." But I think the overwhelming
majority of FlightGear developers and users are pretty pragmatic. We
certainly honor, value, promote, and vigorously protect the GPL nature of
FlightGear, but we realize that there are multiple ways to get through
life. There's a certain art (probably which none of us have really
mastered) :-) of filtering through the list noise and focusing in on the
important responses, ignoring the flame bait, and giving people a little
slack if they respond with too much haste, or misunderstand the original
One idea came to me, and I haven't fully thought through all it's
implications, but let me present it here for discussion.
What if we (meaning a vatsim developer with protocol access and flightgear
developers as consultants) develop a utility that to FlightGear looks like a
standard flightgear multiplayer server. This would run on a user's local
machine, and their local copy of FlightGear would connect to it like any
other multiplayer server. This utility would be closed source, and it would
know how to speak the vatsim protocol. So like you say, it would be a
bridge between the local copy of FlightGear and the vatsim network.
I like this because we wouldn't necessarily need to change anything within
the FlightGear source code, and we would automatically support current and
past versions of FlightGear.
There would need to be some dancing in terms of the FlightGear mutiplayer
protocol. Certainly you could reimpliment a functional interface, but it
might save you time if you could borrow some code from the FlightGear
multiplayer server. That could only happen with express permission of the
authors of that particular code. Some here may argue vigorously against
this, but I think a lot of people would be pretty pragmatic about this ...
assuming you had full support from the multiplayer server author(s) and it
would be their decision to make. Otherwise you'd have to look at the
protocol specification and rewrite your own FlightGear compatible interface
which probably isn't horribly difficult, so maybe that would be the way to
go and you wouldn't risk offending anyone. But if you do that you need to
be pretty careful not to look at our multiplayer server code lest it be too
tempting to copy from it.
I do think it's worth pushing towards vatsim compatibility and I appreciate
your persistence as we try to find a way through that satisfies all the
Curtis Olson: http://baron.flightgear.org/~curt/
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
Flightgear-devel mailing list