I wrote: > > ThorstenB wrote: > > ... snip ... > > > > 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_). > > > ... snip ... > > Getting back to the original purpose ... it's worse than I thought. Using > Hudson Build #331 (the latest AFAIKS), Target Directory seems to stick, > but > I have made it run just once. I will file a proper bug report. >
I have now been working with Terrasync/Built in scenery download for over a week now. I though I might share with you some observations using Win XP and MSVC9 The bug which was stopping the built-in download running here was trivial - once we found it: a space in a directory name. Replaced with an underscore and it worked right out of the tin. Not quite - only the external mode was available. That turned out to be caused by a non-updated config.h file. Thanks to Fred for his help and guidance to solve that one. In doing this I noticed that both the built in and external variants seem to be functionally similar. I can't even work out how or why the external variant works - but it does. FG finds, starts, and stops the external SVN program. Either ThostenB has been very clever, or it's just serendipity here. I hope it's the former. I decided to revert my local build to external only, and then compare Terrasync started from FGRun with the internal (using Hudson's nightly build) and external variants (using my build). Using the Spitfire4b at Gatwick I discovered: 1. With no download the framerate was 42 with the local build and 33 with the Hudson build. I suspect that is caused by different compiler options. 2. With scenery download running each option costs about 10 fps. 3. The Terrasync/FGRun scenery pre-fetch option works well, and is useful. 4. It is handy to be able to switch off/on scenery download at runtime, but here you only get about 5 of the 10 fps back. I see that once started the svn program remains loaded: this might be the cause. 5. The automatic refresh works well. There is an occasional grey-out. Disconcerting at first, but actually not a problem. This is a major advantage over Terrasync 5. To use the built-in option requires 2 additional and quite large dependencies which will need updating etc from time to time. For those of us that build FG this is a bit of a pain. 6. Both the internal and external variants seem to be using the external svn.exe. Each variant relies on a different build. Both builds are using all 4 cores here while the download is running (FG normally uses only 1 and a bit) I _think_ that's good to see. Do we require Windows users to have installed svn? I have - and that seems to be what is being used. 7. The external variant would seem to meet Csaba's design ideal, without any apparent drawback. Except from the fact that, AFAIKS, apart from the menu item, both the external and internal variants are the same. Perhaps that's not the case for Linux builds. Or perhaps I'm wrong in my assessment. If the 2 builds are in fact different perhaps the build variant internal/external could be made conditional. Summary. We seem to have ended up with 3 overlapping systems, all with advantages and disadvantages. Would it be possible to combine them? It certainly would not seem sensible to maintain all 3. Vivian ------------------------------------------------------------------------------ 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
