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.

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)