Virtual ATC Discussion

Work in progress This article or section will be worked on in the upcoming hours or days. See history for the latest developments.

VATO FlightGear

Virtual Air Traffic Organization also known as vATO is a virtual organization in FlightGear Flight Simulator that promotes realism in event based operations currently within Europe and North America. vATO is a complete overhaul and re-brand of Air H5. Air H5 was an organization in FlightGear which consisted of two main event-based virtual airlines, Eurfly which operates in Europe and Fremont which operates in North America. Air H5 was originally founded by Rick Ace in July 2010 and its activity had to end after a few months of success. Air H5 was then reorganized in May 2012 but due to the low standards and lack of pilots and ATCs, it ended its operations in January 2013. vATO's new goal is to increase the standards even more and create the best and most realistic multiplayer event experience FlightGear has to offer. <iframe width="420" height="315" src="http://www.youtube.com/embed/auj_eA-dTTs" frameborder="0" allowfullscreen=""></iframe> — Omega (Mon Mar 18). Virtual Air Traffic Organization (vATO). (powered by Instant-Cquotes)

OATCONS

With recent concern regarding a more formalized way to track flights, plan routes and communicate, I have thought of a brief and rough layout for a FlightGear version (or FG + other open source projects) of the VATSIM network. VATSIM, or Virtual Air Traffic SIMulation, is a network to communicate between pilots on Microsoft Flight Simulator. However, due to its patented programming, is basically blocked to the mainstream flight sim. This means other projects such as YSsim and our own FlightGear cannot join. With that said, and a possible demand from the new Atlas Virtual Airlines and FlightGear Aerial Display Team, I have decided to propose this concept. "OATCONS" (Opensource Air Traffic COntrol Network for Nonproprietory Simulators). Please tell me if this seems good or if it needs improvement. — kyokoyama (Thu Feb 18). FlightGear's VATSIM: The OATCONS Concept. (powered by Instant-Cquotes)

Development

I think you may be concentrating on creating completely new applications for this, while we have all the pieces already. We just need a fairly small set of enhancements to FGCom and FGTracker. That is a lot less effort than starting from scratch and re-inventing the wheel. Plus, you're much more likely to get the developers of existing applications who already have the required skills to make enhancements than find completely new developers. — stuart (Thu Feb 18). Re: FlightGear's VATSIM: The OATCONS Concept. (powered by Instant-Cquotes)

Document the things that are missing and determine how the existing tools and infrastructure would need to be modified in order to achieve that goal (for example by creating a new wiki page). And then think in terms of milestones (tiny steps) to make things tangible. Similarly, prioritize your ideas in the sense of "MUST have" ... "NICE" ... "OPTIONAL". Starting completely from scratch is unlikely to succeed at all. Just take a careful look: many things that would be needed, exist already in one form or another (fgms, atlas, fgcom, atc aircraft, mpmap etc) Some of these would only need minor modifications to be used for other tasks. And when you start asking people for features, never forget that only a minority of these will actually be required, most of them will be optional for a prototype implementation. You only have to take a look at the mailing list archives: just doing a quick search, there were probably like 12 different attempts at integrating IVAO/VATSIM or creating a similar environment for FG during the last couple of years. And just a couple of hours ago, someone posted to the original VATSIM thread introducing his own new project of integrating FG and VATSIM. — Hooray (Wed Feb 24). Re: FlightGear's VATSIM: The OATCONS Concept. (powered by Instant-Cquotes)

there are apparently now like 5-8 different people working on improving the ATC support in FlightGear (core developers not counted, just forum users). If these people were working together to concentrate on common goals, they might actually be able to accomplish something and really improve the situation. But as long as everybody is inclined to start his/her own project from scratch, this really isn't going anywhere. — Hooray (Wed Mar 17). Re: FlightGear's VATSIM: The OATCONS Concept. (powered by Instant-Cquotes)

There have been LOTS of discussions in the past about improving the AI/ATC system in FG. So it's probably worth spending some time looking into what people have previously suggested. For starters: index.php/Stand_Alone_ATC_Control_Development index.php/An_Integrated_AI_Traffic_System index.php/Decoupling_the_AI_Traffic_System The first link is specific to ATC stuff, the other two links are specific to improving the AI system in FG. We created the ATC page a while ago to help coordinate all things related to ATC (VATSIM, IVAO etc) In the meanwhile it has turned into a pretty huge collection of random ideas more or less related to ATC. — Hooray (Sat Mar 05). Re: [Masterproject AI] First Draft Specification. (powered by Instant-Cquotes)

VATSIM/IVAO Support

there are typically a handful of VATSIM/IVAO related "efforts" (discussions) per year. Most of these take up weeks discussing things, with very little (usually nothing at all) materializing ultimately. Usually, people are either no experts in VATSIM/IVAO or simply not familiar with FG internals. There are some very real restrictions on the FG side of things, especially related to our MP infrastructure (fgms/MP protocol) but also licensing. None of this is impossible to solve, but it takes time for very little gain - if we suddenly had VATSIM/IVAO support, our MP system would become more popular, which it is not designed for. Personally, I consider it much more likely/worthwhile to support VATSIM et al once HLA is fully supported and used to modernize/re-implement our MP system. — Hooray (Sat May 03). Re: Flightgear and vatsim. (powered by Instant-Cquotes)

There are a lot of people here who have a ton of ideas on MP, without really understanding how it works, and why extending it in its current form would not be a good idea - our MP system is one of those components that will greatly benefit from being re-implemented sooner or later. Discussing this with non-developers is kinda pointless however. HLA is the right technology here, as it also handles multi-instance state synchronization/replication, i.e. for distributed setups, or even just professional multi-machine setups. Mostly, FlightGear is an extremely inconsistent piece of software with many features being either partially re-invented in other places, or even completely incompatible. Things like the MP protocol or the native/controls protocols, but also the generic protocols system, are basically solving the same underlying problem but were never unified, so have some great ideas and concepts that are usually incompatible still. Anybody looking at implementing VATSIM/IVAO support should be aware of such restrictions in the first place, and be aware of who they're talking to, because we have an increasing number of users trying to contribute to development discussions that are way beyond their expertise, which is adding to the confusion obviously. Stilll, they're the ones responding to certain threads and providing feedback, which is misrepresenting that state of support from fellow developers. — Hooray (Sat May 03). Re: Flightgear and vatsim. (powered by Instant-Cquotes)

There's areas in FG development where it doesn't make much sense TECHNICALLY to build on existing stuff any longer, i.e. stuff that needs to be yanked sooner or later, and that is even already in the process of being yanked by some of the most experienced core developers, the multiplayer system certainly qualifies as such a component, and all developers who are aware of this, are extremely hesitant to extend, or even just maintain, such components. Thus, unlike suggested elsewhere , this is not primarily a matter of someone coming along with the right "skills" to "fix MP", it's mainly a matter of consistently addressing our requirements in a generic fashion, not just MP centric. We used to have roughly 2-3 discussions per year about ripping out the FlightGear GUI (PUI), but since the adoption of Canvas that discussion has stopped completely, for a good reason. There's only so much that can be accomplished by extending mediocre technology, such as PUI, without causing lots of work, but also a ton of incompatibilites - preparing FG to get rid of PUI was the right decision, still it's taken many years, and we're still not quite there yet. We went through the same thing when PLIB SG was replaced with OSG, which ended up causing frustration, because certain features (shadows) would no longer work properly - still, it was the right decision. So waiting is not such a bad thing overall. — Hooray (Sat May 03). Re: Flightgear and vatsim. (powered by Instant-Cquotes)

Efforts

For some reason i`had stopped at summer of 2010 my project of IVAO client. I thinked, that IVAO finished they library, but... There is http://www.flightgear.ru/forum/download/file.php?id=628 my alpha project of proxy beetwen IVAO and FG. It`s changed source of squawkgear — Sau (Thu Jan 27).  and FG. (powered by Instant-Cquotes)

I would like to take part in the active development of a radar client. I was a member of the software development team of the IVAO network, and at that time I started building a client application (with C++, wxWidgets, and the IVAO connection library) that read/wrote data between the Flightgear instance and the IVAO servers, using their proprietary protocol (library). The idea was to have FG into the approved IVAO simulators. Unfortunately, I stopped having spare time for professional reasons. Now I have that time again, and I'd rather not continue with that old project, as I think it's way better to develop a radar client specific to FG, and free software, so we don't have to stick to the rules of a proprietary network like IVAO or VATSIM. I also think that this is more efficient and convenient. This will pose the need to change the MP protocol itself, but as we are in the free software world, it can be done. I have been using for years the (excellent) radar client that IVAO guys developed (IvAc), and I have my ideas about how a radar client should work. I also thought about starting a new client in C++, perhaps reusing code from OpenRadar (which I don't know). — pepribal (Tue Nov 30). Re: ATC client for Flightgear. (powered by Instant-Cquotes)

There were several people thinking about vatsim and FlightGear. The problem is, taht there are some licence issues. We need a protocol for using the vatsim-network. Vatsim would offer one - but only when it is "closed" means not under GNU GPL-Licence. That's the problem ... — HHS (Fri Oct 19). . (powered by Instant-Cquotes)

I'm in the process of launching a new online network that provides traffic and ATC for a wide range of simulators, from X-Plane/FS9/FSX users in a home setting, to pilots using mid-range training devices at a flight school, all the way up to Level D full motion simulators at high end sim centers or even airline training departments. Multiplayer networks with ATC are certainly not a new concept. I'm sure everyone knows about VATSIM/IVAO at this point. There are no networks, however, that cater to commercial flight training organizations, or even to student pilots and instrument students. That is the market which this network aims to serve. Additionally, I have strong evidence that there are a reasonable number of sim enthusiasts on various multiplayer networks who would be interested in participating on a subscription-based network with the promise of guaranteed ATC presence, quality, as well as a host of technical features that are simply not found on other networks. We have completed development of the initial client for X-Plane and are nearly finished with the initial FS9/X release. I'm contemplating adding a FG client, but I know so little about the community in terms of the raw numbers of pilots that use it, or the likely level of interest that it will generate. — coma (Fri Jun 03). interest in a client for a commercial MP network?. (powered by Instant-Cquotes)

It's come to my attention that, while SquawkGear is cross-platform, to use SB747, you MUST have Windows. Well, I'd like to fix that. In fact, I may or may not cut out SquawkGear completely. I'd like to create a brand new VATSIM client for FG using Java. So far, anything I've wanted to make in Java for FG has worked, so, I see no reason to NOT try this for a new project. I do realize that the Instructor Station (a program that does little more than connect to FG and display its properties in its own GUI), and FGFSCopilot (a program that connects to FG and manipulates its properties to further automate flying a great deal) will be incomparable to this. However, a few months ago, after some research, I have managed a program (at the time MIA-exclusive, but now too outdated for any practical use) that connects to FG, grabs and stores properties for use with calculations, and then uploads the variables to a website. So, I think I may have already cleared the biggest hurdle for this. My understanding of what a VATSIM client does, in most simple terms, would be the following: Connect to network>gather FG data> broadcast FG data>receive VATSIM data>adjust FG based on VATSIM data (e.g. load up AI aircraft where other VATSIM pilots are located, override FG's real weather with VATSIM's real weather, etc.). Of course, I am leaving out a lot of details, such as allowing the pilot to fill out a FP sheet and file it, look up freqs of nearby ATCs, adjust the transponder, etc. — redneck (Wed Jan 18). Cross-platform . (powered by Instant-Cquotes)