So waiting is not such a bad thing overall. 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. 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 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. 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. 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. There's areas in FG development where it doesn't make much sense TECHNICALLY to build on existing stuff any longer, i.e. Stilll, they're the ones responding to certain threads and providing feedback, which is misrepresenting that state of support from fellow developers. 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.Īnybody 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.
Flightgear vatsim software#
Mostly, FlightGear is an extremely inconsistent piece of software with many features being either partially re-invented in other places, or even completely incompatible.
Flightgear vatsim professional#
for distributed setups, or even just professional multi-machine setups. HLA is the right technology here, as it also handles multi-instance state synchronization/replication, i.e. Discussing this with non-developers is kinda pointless however. 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. 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.Īnd just a couple of hours ago, someone posted to the original VATSIM thread introducing his own new project of integrating FG and VATSIM. Some of these would only need minor modifications to be used for other tasks.Īnd 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. 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)
Starting completely from scratch is unlikely to succeed at all. Similarly, prioritize your ideas in the sense of "MUST have".
Re: FlightGear's VATSIM: The OATCONS Concept.ĭocument 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).Īnd then think in terms of milestones ( tiny steps) to make things tangible.
0 kommentar(er)
