> It's a dead end time when someone who had asked for changes leaves > before that changes comes because it not comes too long and that makes > some issue area related development impossible. (...) > If that dead end will come seventy years after now then for sure I had > missed the point. If not then not and some quick reaction is needed > immediately right now before it will get too far. (...) > I had said what on my deepest thoughts current chaos in Flight Gear > project will lead everybody to problems what I had experienced with > Vostok project pretty soon. (...) > Occasional dropouts and slowing to 1fps and things as that. More and > more bugs with every change what's harder and harder to eliminate, not > linearly, squarely harder. Dramatical lowering of common development > rate, coming to "very outdated" state and loosing of new developers and > users inflow, then final stopping. That's what, I suppose, awaits > everybody on current FG path.
If I understand you correctly, the reason you are leaving is that you worry that the future state of the project will be such that it can't be fixed, because the time to fix errors grows quadratically (in what? lines of code?time?), and you want to leave before that happens. I remember when discussing a terrain rendering engine capable of spaceflight in the forum, a user named vitos wrote the following: "Boris Elyseyevitch Chertok, who had and have essential role in real Russian Space Program, and particularly in Vostok program, had said many times: 'If today someone would put before us Vostok and ask us for permission to let it fly then no one of us would vote for that. That day we all had vote for it without a doubt.' We would never get somewhere in case we would though about distant future problems. Those problems does not matter because it unexisted until we not solve current." It strikes me that worrying about things like what happens if 500+ users go on a multiplayer server of if the time to fix a bug grows to several months is very much worrying about distant future problems. What happened to that user named vitos - did he change his views? But the whole argument is misleading when based on Vostok-1 - with Vostok-1, you are observing issues which are not bugs in the current system to be addressed or issues to be fixed - you are using an existing system outside its design specification. Flightgear makes a lot of assumptions which are entirely reasonable for aircraft (i.e. you move with a finite speed, at altitudes below 120.000 ft, the gravitational field of the moon doesn't matter,...) - e.g. the loading of terrain (or of weather in my case) assumes that you move with the speed of an aircraft - at arbitrary velocities, you can outrun both systems (as easily tested with the ufo). There is nothing to 'fix' here to use Vostok as you intend - you have to scrap and redesign systems, and that takes way longer than to fix an existing system while leaving its structure largely intact (I have been saying that all along in the forum) - even provided you find the volunteers to do it here. There's no evidence to me that other aircraft will ever create similar problematic issues, while other spacecraft will always create them. Vostok is a special case, because it demands things from the system which no aircraft will ever even in principle demand - for that reason it's not a reasonable litmus test. A singularly complex problem doesn't reflect the general state of affairs. As for growing complexity - it's generically true that the time to fix an issue grows non-linear with the number of code lines. But as Microsoft is all too happy to demonstrate, that doesn't really correlate with the structure of project management. On the other hand, the code seems pretty modular. I observe in debugging my 10.000 lines of Local Weather that there are large parts which are simply stable - they have been checked to the degree that they work free of bugs, so the actual amount of lines I have to consider to address an issue is usually much smaller than 10.000. At least that project does not seem to run into longer and longer debugging times. I think it's grossly unfair to mix these issues: Spaceflight requires to essentially write a space simulator. One of my first statements in the forum was: "Orbital flights opens a whole new can of worms besides the need for different rendering - completely different physics, completely different numerical stability issues,... basically you want to write a new orbital simulator, because the amount of stuff you can really use from a flight simulator is pretty small." I still think that is a correct statement (up to the part that JSBSim seems adequately equipped to get ascent and descent right, although we don't know about long-term orbital stability - which wasn't clear to me when I wrote it)- so from where I am standing, you are claiming that Flightgear development is failing based on the observation that people could not write a spaceflight simulation in 6 months or tell you how to do that. As a positive final note, I think contrary to your statements, judging by current GIT pulls 2.4 will have a lot less bugs than 2.0. At least for me it's a lot more stable. Just my two cents. * Thorsten ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
