Implementing new features for FlightGear: Difference between revisions

Jump to navigation Jump to search

Implementing new features for FlightGear (view source)

Revision as of 18:29, 2 June 2014

11,934 bytes added ,  2 June 2014
→‎Release early, document your efforts
(→‎Some (unpleasant) truths up front: +example from the forum)
Line 182: Line 182:


If you made it to this point, you may perhaps appreciate much better why the devel community is how it is!
If you made it to this point, you may perhaps appreciate much better why the devel community is how it is!
== Collaboration and Consistency ==
{{cquote
  |<nowiki>the thing is that consistency is a b*tch to get "right" 
There are obvious areas like backward compatibility where consistency would help us a great deal.
But being consistent takes a great deal of work, not just in your own working areas, but especially in other areas that you have never touched.
Being consistent takes a lot of time, dedication, discipline and skill and a ton of networking. And it really isn't fun at all 
We have an infinite number of examples for this being the case in FlightGear. It's not just our lack of standardized XML processing.
The whole MP/MMO debate is basically about the same thing - competing/conflicting features that never got updated and integrated, so that they end up crippling each other.
And we end up having a dozen way to "skin a cat" semi-properly 
Being consistent means that "coding" (or even 3D modeling or developing FDMs) is suddenly no longer "just" about your own work, but looking at all the other places and potential use-cases in FlightGear that may benefit from it, including stuff that you never used, and never intend to use yourself.
</nowiki>
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209465#p209465
    |title=<nowiki>Re: scaling instruments in xml</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Wed May 14</nowiki>
  }}
}}
{{cquote
  |<nowiki>To see for yourself, just ask yourself if any of your recent work (textures, 3D models, livery packs, FDMs, FDM components, autopilots, scripts, instruments or aircraft) can be easily used outside the context/scope that you designed them for originally ?
For instance, how easily can your aircraft:
support being used by the AI traffic system ?
support different liveries, liveries over MP ?
dual-pilot use across multiplayer ?
the weight& balance dialog ?
the replay/flight recorder subsystem ?
checklists ?
autopilot dialog ?
the bombable addon ?
...
These are all features in existence today that could be supported by aircraft developers - but most contributors only really scratch their own itch understandably 
And that's really just the non-coding side of things - for programmers, pulling off consistent designs is often even more difficult.</nowiki>
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209465#p209465
    |title=<nowiki>Re: scaling instruments in xml</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Wed May 14</nowiki>
  }}
}}
{{cquote
  |<nowiki>As a coder, you permanently need to re-evaluate your own design and look at other/similar features, and see how those affect each other potentially - and be willing to modernize and re-implement certain stuff.
There's stuff like our networking stack, and the I/O system, along with its generic protocol system - and a httpd/telnet system, and of course the multiplayer system. All of this came into existence at different times - so are hardly integrated, even though they're sharing almost identical requirements, and could be re-implemented on top of 3-5 building blocks probably.</nowiki>
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209465#p209465
    |title=<nowiki>Re: scaling instruments in xml</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Wed May 14</nowiki>
  }}
}}
{{cquote
  |<nowiki>The thing about consistency is that it needs to be future-proof, too - i.e. in case someone leaves the project for a while, or even completely abandons a project.
And that's when becoming a "visionary" is almost as important as being a "designer" of some new project or feature.
Which also means that solutions must not be "lock-in" solutions, but need to be sufficiently well-understood and documented to either allow others to review/maintain them over time, or let them completely revamp/replace them if needed.
We always tend to see the problems in solutions that others come up with, but refer to our own contributions as "hacks", "workarounds", or more eloquently, "prototypes", even though they typically have the same issues and effects on projects and features developed by others
Yet, those very "prototypes" often end up being around for several years until someone comes up with something better or some major improvement.
At the end of the day, we're all just that: lazy human beings - and volunteers at that, too - i.e. we are really only motivated by stuff that's not a chore, but it must be fun.
So you end up with a huge herd of cats that don't want to be organized at all ...</nowiki>
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209490#p209490
    |title=<nowiki>Re: scaling instruments in xml</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Wed May 14</nowiki>
  }}
}}
{{cquote
  |<nowiki>Then again, there are a few people doing the unpopular "grunt" work here, i.e. constantly refactoring things, and permanently looking at the bigger picture to generalize stuff over time.
However, their work is usually not at all "visible" or even compelling to non-developers, often not even to developers.
We're really here to scratch our own itch and not contribute to some "global cause" that we may never benefit from at all.
Asking for better and more consistency is however exactly doing that: asking people to drop the "interesting & fun" stuff in favor of improving things for the long-term, without them necessarily benefiting from such work (or without it being obvious to them). Understandably, that's kinda frustrating - not just for the people asked to do the work, but also for those asking for it </nowiki>
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209490#p209490
    |title=<nowiki>Re: scaling instruments in xml</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Wed May 14</nowiki>
  }}
}}
{{cquote
  |<nowiki>magine for a second you had spent 18 months working on a new project/aircraft/feature, and everybody is proud of your product, but suddenly someone comes around and says something along the lines of this is all great, but it's not future-proof, what you should really be doing is neuter the whole thing, split it up into a dozen modules, generalize each component to make it accessible to other users, and please don't complain about regressions - there certainly will be many, and we won't have much time to help you, but it's basically the right thing to do, and it needs to be done ASAP
This is pretty much what's happening to many developers who come up with useful, but non-generic, stuff - especially in a healthy software development environment, where people are constantly reviewing their own code. We've had many such discussions here in the past, i.e. when the random buildings system got first introduced, Thorsten and I were the ones discussing potential scripting hooks to make it less random and expose it to scripting space, so that placement heuristics could be based on other data (i.e. OSM). Back then, that was not a popular thing to ask for, the response was "this only has theoretical merits..." - 3+ years later, this is what people are looking into now 
So being consistent really is a painful thing unfortunately, because it means more work, less time for interesting stuff, much more networking - and the outcome may still be uncertain, and it may cause frustration among contributors, too.</nowiki>
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209490#p209490
    |title=<nowiki>Re: scaling instruments in xml</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Wed May 14</nowiki>
  }}
}}
{{cquote
  |<nowiki>For instance, when one aircraft developer came up with the new NavDisplay code, we had been talking with Zakalawe about doing kinda that as part of the map dialog - and I was pretty frustrated seeing code that was more complete than mine, but on the other hand much less generic (not as re-usable), i.e. it being aircraft-specific, single instance, single style, too slow etc
And raising my concerns, the 747 developer was the one saying "not a high priority for me" and next: "but, ok be my guest" (which is very common around here!).
So that's how the whole shebang got split up into ~20 different modules, introducing a plethora of regressions/bugs (that he gratefully ignored!), slowing down his progress and overall development by at least 6 months in the process, and introducing a degree of complexity, so that the original developer no longer felt responsible for the modified code, or even refused to work with it afterwards 
As you can imagine, this sort of thing ...case.
So, all the while we'd been trying to be more consistent, and then that - and looking at the extra500 commit history, we're apparently having a hard time inviting them to be more consistent by adopting our framework now.
And that's what kinda everybody is going through here - Thorsten also mentioned various times that it would be so much easier to just code his own stuff than having to maintain compatibility with other/similar or even conflicting features (e.g. basic weather/rembrandt).
It really is hard to understand why we should accept such issues without being also paid for all the frustration resulting from all this
Honestly, consider this a freakin' petri-dish in which software evolution simply takes place and you'll have a much better time</nowiki>
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209490#p209490
    |title=<nowiki>Re: scaling instruments in xml</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Wed May 14</nowiki>
  }}
}}
{{cquote
  |<nowiki>The Canvas/MapStructure work is another example for this: for over a decade, we've had various hard-coded instruments, a hard-coded GUI library, and certain 2D rendering code that could only be used within a fixed context, like 1) cockpit, 2) GUI, 3) scenery. It's only recently -thanks to canvas- that this is being unified and re-implemented, to hopefully get rid of a plethora of legacy features and modernize them through canvas and scripting space wrappers.
Previously, people could not render an instrument/HUD in a dialog, or vice versa - yet, this is a key feature, because supporting recursion means that even features like interactive map editors can share the same back-end code. </nowiki>
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209465#p209465
    |title=<nowiki>Re: scaling instruments in xml</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Wed May 14</nowiki>
  }}
}}
{{cquote
  |<nowiki>Today, just the MapStructure framework is under 1k lines of code, and is making roughly 9k-15k lines of C++ code obsolete in FlightGear (agradar,groundradar,wxradar,map dialog), unifying the whole shebang in the process, which also ensures that more modern OSG/OpenGL can be used, i.e. better performance in the long-term.
This all has taken place in under 24 months actually (MapStructure just being 6 months old now actually) - whereas hard-coded instruments (wxradar, agradar, navdisplay,kln89 etc) are usually 5+ years old, and things like the Map dialog even older - in comparison, these were all "easier" to come up with in the first place, but obviously don't scale as well as a Canvas-based solution. Gijs NavDisplay framework is already better accessible and more feature-rich than the original ND code.
But this kind of work isn't exactly fun, it comprises lots of refactoring and is more about talking and coordinating things than actually coding stuff - because the implementation may very well just be a fraction the size of all the manifestations that are hopefully replaced over time.</nowiki>
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209465#p209465
    |title=<nowiki>Re: scaling instruments in xml</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Wed May 14</nowiki>
  }}
}}


== Some context on different perceptions ==
== Some context on different perceptions ==
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/72260"

Navigation menu