On 15.06.2011 22:57, Martin Spott wrote: > By having a closer look at Thorsten's patches you'd realize that his > primary work was to turn the standalone program with hard-coded host- > and pathnames into a neatly configurable library. The interface > between this lib and FlightGear is pretty slim, it doesn't add much > overhead and you're free not to use it.
Thanks Martin. Another thing to add here: what I actually did was dividing existing terrasync sources into two parts: the library which holds all the actual SVN code, and another part that parses command-line arguments, processes UDP messages and runs as a stand-alone utility. I actually tested the new library using the (remains) of terrasync(.exe) stand-alone utility - but decided not to push any changes to terrasync itself. Not now at least. And I'm pretty aware of the HLA approaches - we've discussed that for long at LinuxTag (surprise, Mathias was there). I'm absolutely in favour of splitting things up - Mathias and Martin know this from LT. Yet, I did not see any contradiction with integrating terrasync. I would like more subsystems being converted into separate libraries and being capable of running them outside FlightGear (which, I agree, is great for any advanced user - especially those with CAE-like setups), but still have the option to also run the same subsystems all inside a single FG (which does have advantages for other kinds of users). With a proper and flexible interface (HLA could be the solution here) both is possible. When we have that standard interface installed, we can use the new library with it (while the left-over bits of terrasync(.exe)'s command-line/UDP code might die and be replaced by some generic loader). On 15.06.2011 23:30, Vivian Meazza wrote: > And less clever users, which is most of the people out there, won't. I > include myself in that category, since I have failed to make it work > so far. > I sometimes wonder if we really expect the average user to poke > around in preferences.xml? But then, we have FGRun that does most of > that for us. There should be no need to edit anything in preferences.xml. You should be able to enter the directory in the GUI (yes, I know, no directory dialog). Or you could also provide it via a new command-line option (--terrasync-dir). And it's preserved across sessions. So you only need to provide/edit it once. I had responded to your email yesterday in private, hinting that you probably somehow managed an incomplete fgdata pull (which you later confirmed). Maybe something is still broken - maybe with my code or still on your system. Or maybe I forgot to push something. So, I am really sorry, Vivian, that you were still unable to make the system work for you - on day 2 (though it seems people only started trying to use it _today_). But this and other posts today show our general FG mailing list tendency: being negative. It's the almost natural response to any change. Oh crap! Doesn't work! Don't like it... I've spent _loads_ of time into FG in recent months. I have worked the bug tracker almost daily. I have fixed countless bugs other people have introduced - _some_ even hidden in absolutely crappy code (so much on the "design" issue). I have searched and fixed memory leaks and investigated performance issues. I've fixed loads of issues affecting systems that I personally never use. So, if anything wasn't working with my _own_ addition now - only in GIT for two days, remember - I think it should've been more than obvious that I'd be absolutely willing to explain/test/resolve things - and help anyone who was really interested. And to make it work as expected: to provide an easier solution in accessing scenery (read the forums, if you want to know how users do get along with existing terrasync). But that's not how FG works. It's "normal" that any slight malfunction is immediately criticized as hell. No attempts in being positive, trying to encourage / motivate other people in improving their work - and to keep them working on FG. When something isn't working, start complaining and being negative. Just look at this list's recent history. So, you're all hoping for a better FG. A large redesign, so we can make use of multi-core systems, can even distribute parts across multiple machines. Can separate the GUI. Get Nasal outside the main simulation loop. Well, so do I. But I'm becoming more and more convinced, that this indeed is _not_ going to happen. No, not because of that "new" library and "such tendencies" (while in fact that library is much better prepared to be driven by HLA or something similar than most other parts). No, we're very likely to not get any of this since we're absolutely unable to motivate - or at least keep people motivated on working on our project. That's a major issue we have. Everyone who spends time is "welcomed" by negative comments - and surprisingly many leave. And I'm sorry to say, after reading emails like the above, I do have difficulties in keeping myself motivated. On 15.06.2011 23:59, Gene Buckle wrote: > I have the option of being able to just punt and keep using FSX. :D I have options, too. cheers, Thorsten ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
