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 

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 

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.


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.
Flightgear-devel mailing list

Reply via email to