Re: [Flightgear-devel] Heads up: scenery download / built-in
On Tue, 21 Jun 2011 21:00:39 +0200, ThorstenB wrote in message <4e00ea57.7060...@gmail.com>: > On 21.06.2011 00:39, Vivian Meazza wrote: > > 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. > The white-space issue is fixed for the new library now. It only > applied to external svn. ...and to this message. ;o) Please add a wee bit of vertical white-space in between your inline responses to e.g. Vivian above here, to help improve the readability of your own message. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
On Mon, Jun 13, 2011 at 8:50 PM, ThorstenB wrote: > Hi, > > the final GUI bits for a new feature are now in fgdata - the last > feature addition for the 2.4 release from my part... You can > download/update scenery directly from FlightGear now (main menu: > Environment => Scenery). Credit for the idea goes to James - bugs are > mine ;-). Great work guys. I really, really, like this feature. >From a completely new user perspective, this is almost perfect. The problem is that /sim/terrasync/scenery-dir isn't set by default, so a new user has to A) Set FG_SCENERY to something "sensible", in the correct order B) Find some way to set up /sim/terrasync/scenery-dir C) Use the fine GUI we've just created. Of course, A and B can be well handled by launchers, but it would be fantastic if there was no dependency. I _think_ we default $FG_SCENERY to $FG_HOME/Scenery. Could we default it to $FG_HOME/TerraSync:$FG_HOME/Scenery, and then set /sim/terrasync/scenery-dir=$FG_HOME/TerraSync? (Note that this would mean scenery-dir supporting $FG_HOME) That way a completely new user without any launcher would be able to use this fine feature straight out of the box. It would also allow me to vastly simplify the instructions for downloading scenery in the manual. -Stuart -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
On 21.06.2011 00:39, Vivian Meazza wrote: > 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. The white-space issue is fixed for the new library now. It only applied to external svn. The same problem persists for original terrasync(.exe) - it'll be fixed there once the utility is adapted to use the library (after the release). Same is true for the "trailing '/' issue". Fixed for the library now, persisting for terrasync(.exe) for now. > 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. Indeed, thanks to Fred. It did work nicely for automake. I'm sorry that there were issues with the MSVC9 project (or cmake). But I'm depending on others helping me out here. And I truly hope we can have a common build system only one day - cmake maybe. > 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. The code relies on finding "svn" on the system path. Same as terrasync(.exe) did - remember it's (almost) the same code. The latest update (yesterday) has an option to configure a full path to svn(.exe), which resolves the issue with systems where svn(.exe) isn't on the system path. Again, that's not available yet for the terrasyn(.exe) utility - it will be later (see above). And of course, the svn-library/svn-command-line options are functionally similar. > 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. I don't see "svn" processes sticking. If a "svn" process is still present, then subversion is still active. The call to external svn is blocking - it's impossible that a svn process sticks when you've successfully disabled svn support (see status in GUI). You'll notice that hitting "Apply"/"OK" buttons briefly block the GUI when you disable terrasync: they block since the code waits for the final (blocking) svn operation to return/abort. And I can guarantee that there is no thread or anything running once terrasync is disabled. So, if you see any fps difference and terrasync is disabled, then that difference isn't caused by terrasync/svn. > 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 Yesterday, I have limited that feature for the current release to only affect cases where ocean tiles (missing scenery) are replaced by actual scenery. It removes the distracting effect for normal tiles, until we can handle the refresh smoothly (like when they are out of sight). It remains an advantage when missing scenery is replaced by actual data: better to have a brief gray-out and then see the tile with the destination airport, than to keep seeing a patch of ocean/missing scenery. > 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. It's absolutely the same dependency that terrasync(.exe) has. If you haven't used/weren't interested in terrasync(.exe) so far - don't bother about the new feature. If you have used it, then FG can now be built with the same dependencies like terrasync(.exe) was. Again, nothing really changes. cmake/automake will make sure that the svn-library dependency is automatically disabled when the library isn't present (again, sorry, if you're using a fixed MSVC9 project - hopefully cmake will help you soon). Those running pre-built Windows/Mac binaries will be happy about using the svn-library (no separate "svn" utility to worry about) - especially since a "svn" command-line utility isn't common for most normal Win/Mac users/systems. I guess most Linux distros have a "svn" utility pre-installed by default. And those building FG themselves (again, many Linux users I guess) have the option to use external svn. > 6. Both the internal and external variants seem to be using the external > svn.exe. No way. Built-in svn uses the library and doesn't depend on any external svn(.exe). If you saw svn(.exe) being called, then built-in support was disabled (either since the feature wasn't compiled into FG or since the "use-built-in-svn" property was "false"). To make such things more obvious, there's a new status message when svn starts now: it'll tell whether internal or external support is selected/used. Pull yesterday's simgear. >
Re: [Flightgear-devel] Heads up: scenery download / built-in
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
Re: [Flightgear-devel] Heads up: scenery download / built-in
Frederic Bouvier wrote: > No scenery dir (top most) is editable. The google url isn't. Ah, ok, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
- "Martin Spott" a écrit : > Frederic Bouvier wrote: > > > embedded terrasync was not working for me because the scenery-dir > > entered in the dialog was not copied in the property. It should be > > fixed in fgdata now (dialog definition lacking a global > dialog-apply). > > Isn't the scenery-dir in the terrasync dialogue meant to be > non-writeable anyway ? As far as I understand you're supposed to > supply the scenery-dir on program start. > Maybe we're just talking about different dialogues !? No scenery dir (top most) is editable. The google url isn't. Regards, -Fred -- Frédéric Bouvier http://www.youtube.com/user/fgfred64 Videos -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
Frederic Bouvier wrote: > embedded terrasync was not working for me because the scenery-dir > entered in the dialog was not copied in the property. It should be > fixed in fgdata now (dialog definition lacking a global dialog-apply). Isn't the scenery-dir in the terrasync dialogue meant to be non-writeable anyway ? As far as I understand you're supposed to supply the scenery-dir on program start. Maybe we're just talking about different dialogues !? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
Vivian, embedded terrasync was not working for me because the scenery-dir entered in the dialog was not copied in the property. It should be fixed in fgdata now (dialog definition lacking a global dialog-apply). I don't know if it is related to the issue you are seeing, but fgfs nightly downloaded today seems to work for me now. Regards, -Fred -- Frédéric Bouvier http://www.youtube.com/user/fgfred64 Videos -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
Am 13.06.11 21:50, schrieb ThorstenB: > Hi, > > the final GUI bits for a new feature are now in fgdata - the last > feature addition for the 2.4 release from my part... You can > download/update scenery directly from FlightGear now (main menu: > Environment => Scenery). Credit for the idea goes to James - bugs are > mine ;-). > > It provides built-in terrasync support - with some advantages: Hi Thorsten Thank you (and others) for this . I have some question about the new feature: > > * Configuration requires a scenery target directory only (your > "terrasync" directory) and a checkbox to enable. For now, you'll also > need to provide the terrasync directory as part of your --fg-scenery > paths (otherwise you won't see downloaded scenery). What is about separating default scenery path and synced scenery path to different path command line options ? Something like fg-scenery=/Scenery and custom-scenery=/terrasyncdir ? I think it is much easier and almost self-explaining for some users to set paths only once and that there are less possibilites to set paths wrong. You set custom-scenery and you can be sure that a) order of paths is correct for scenery "fallback" and b) built-in or external terrasync takes the same path and there is only one place to set paths. Or do I miss something here? Another small problem on OSX remains with terrasync for me. Default path (i.e. when you do not set a path at all, but starting terrasync) a terrasyncdir data directory is created in the MacOS binaries folder in the bundle, because this is root here now. This is a "hidden" place for OSX users, only more or less experienced OSX people know how to "open" a bundle, or how to find it (i.e. you can not find it with common search tools on OSX). Most OSX users do not know how to set paths to a data folder in a bundle. Setting paths wrong (or left blank) for terrasync on OSX will end up with "filling" the application bundle with tons of data, in the "wrong" directory anyway. Maybe default terrayncdir, at least for OSX, should be created somewhere else, where users can find it (for the FGx bundle I put it here by default "/Documents/TerrasyncScenery", far from saying this is the only right location). Cheers, Yves -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
thorsten.i.r...@jyu.fi wrote: > Flightgear has a lot less trouble finding consensus, because the numbers > are much smaller than in the ATLAS collaboration. And here's the point: A 'significant' number (in the statistical meaning) of FlightGear developers is, to put it mildly, not very well trained in the competence of developing consensus. Exactly this is the topic I'd expect a "project management" in the OpenSource/volunteer arena to take serious care of. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
Erik > > On Fri, 2011-06-17 at 10:55 +0300, thorsten.i.r...@jyu.fi wrote: > > At this point, it made a lot of sense to code in Nasal, if only for the > > simple reason that I couldn't know if it would ever included into the > base > > package or not. > > As an addition it also helped to develop good insight in efficient Nasal > programming which might prove to be very useful in the future. > I'm not sure that 'efficient Nasal' isn't an oxymoron :-) I would never claim to have written efficient, or even good or clever Nasal, but here are some simple heuristics: Avoid for and while loops - if you must have them, keep the number of iterations low, otherwise you will kill the frame rate. It is better to do a little work every frame rather than a lot of work in intermittent frames, otherwise you will introduce jitter. Avoid writing too many lines, otherwise the evil god Garbage Collector will bite you. Avoid writing Nasal. Now we are compiling snapshots of the source code nightly, where code is generally applicable it should, if at all possible, be written in c++. Here is the long version: http://wiki.flightgear.org/index.php/Nasal_scripting_language Perhaps Melchior will provide better advice. 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
On Fri, 2011-06-17 at 10:55 +0300, thorsten.i.r...@jyu.fi wrote: > At this point, it made a lot of sense to code in Nasal, if only for the > simple reason that I couldn't know if it would ever included into the base > package or not. As an addition it also helped to develop good insight in efficient Nasal programming which might prove to be very useful in the future. Erik -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
> BTW, while I'm very much in favour of having FlightGear's various > subsystems split into distinct parts, I think the "bad design" claim > coming from you is pretty weak. Where was your voice when the Local > Weather subsystem was added ? Gentlemen, it's so nice to be mentioned so often if an example for bad design is needed :-) I don't really understand what you'd see as 'good design' in this instance, but I can tell you why it is the way it is, and maybe there's a useful lesson for the future in there. Local Weather started out of my experiments with how to render various cloud types, initially using the AI system, which was a problem I found quite interesting in itself. At some point, Hooray in the forum pointed out that what Flightgear could use was an integrated weather system. I thought about that problem over night, had the impression that I could do it and designed a system. The first thing I did was setting up a wiki page sketching the project. The second thing was asking for comments, ideas and help. I'm pretty sure at this point most people thought 'That's never going to be finished anyway.', smiled and turned away (can't really blame anyone). So most of the time I discussed with Hooray (and a few glider enthusiasts), that's why most of the structure that isn't my design is based on his ideas how things should be (and he's a Nasal enthusiast). At this point, it made a lot of sense to code in Nasal, if only for the simple reason that I couldn't know if it would ever included into the base package or not. A Nasal-coded addon you can distribute with reasonable effort - a C++ patch which people have to recompile reaches a far smaller target audience. Serious contact with core developers (a big thanks to a lot of people here who worked with me on various aspects of the system at this point!) didn't happen until much later when the structure of 'Local Weather' as an optional addon which is off by default was largely fixed. What could have changed this is not project management - if someone would have told me 'You must code this in this structure, and we need it like that' I'd have said 'Can't do it - don't understand the requirement.' and wouldn't have done anything. The thing that could have made a difference is a kind of tutoring system - someone working with me, explaining to me what design works in what way and helping me code what I can't code (I come from scientific computing - which means I usually write codes for a single user (me) with zero requirements on integrating into bigger systems, GUI,... and largely performance and accuracy being the goals - so I can work out what methematical function describes cloud distributions easily, but I can't know what design is superior to what other design). > FlightGear is a huge, complex project and has no kind of real project > management at all. Doesn't mean it's bound to be a failure though... Consider the ATLAS particle detector at CERN, one of the most amazing pieces of technology on this planet. The ATLAS collaboration involves several thousand physicists, and it has a spokesperson (not a leader), because (freedom of research, the collaboration members bring their own funding) nobody is really in the position to command another sufficiently senior person. For the juniors, there are dual hierarchies, collaboration and local institution, so a single PhD student can have two superiors telling him to do two different things. The collaboration is run my a messy exercise of finding any sort of consensus - people have to talk to each other to arrange things and convince others of their view, if they fail to do so, several groups may be working on the same analysis at the same time. For instance, muon chambers are built with some set of specifications - but are all different in details, so dependent on which institution built them, the readout software needs several different option just to accomodate what kind of chamber this is precisely. I bet no company would ever consider this messy, anarchic process of common consensus-finding and pulling into different directions as a form of sane project management - and yet, it works! The anarchic club of ingenious trouble-making physicists has built a machine which no company could hope to develop. Flightgear has a lot less trouble finding consensus, because the numbers are much smaller than in the ATLAS collaboration. I think just talking, tossing ideas around, exploring detours, merge things in later can be a very efficient approach. It may lack the elegance of managed projects - but it can produce things which are out of reach of managed projects. Just my two cents. * 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-dev2de
Re: [Flightgear-devel] Heads up: scenery download / built-in
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. 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
I think Thorsten has been doing a marvelous job. I see the changes flow by in the commitlogs emails, and it probably goes unsaid too often, but it's clear who has been putting in the effort to deal with user bug reports, tricky bits of code, and a whole host of other issues. There are always a few negative voices in any forum and they often project too loudly and too often. Sometimes saying things once and then letting it be is a better strategy. Thoughts and ideas take time to sink in, and bashing people over the head repeatedly does not usually accelerate the process. There are a few developers who are very smart, have a good knowledge of FlightGear, and are well intentioned, but have trouble unwrapping a negative tinge from many of their messages. I think they find that this style is an "effective" way to communicate their concerns, and probably feel that it will motivate others to take their words more seriously. But I'm serious in saying that for each one of these, there are 50 or maybe 100 others out there who do see the effort and who do appreciate it, but hesitate to contribute to the discussion for any number of reasons. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
ThorstenB wrote: ... snip ... > > 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. Yes - _I_ know that your code does not require anything done to preferences.xml by the user. And, as I said, the average user should not be required to do so. > 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_). I'm reasonably sure it's something here. But the latest Hudson build #331 doesn't work here either, with the same error messages as my local build. The trouble is, I have no idea how to fix it. > 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. Yes, you have done very well for FG, and I'm sure everyone is very grateful, even if they don't say it. I know I am. But, if you suddenly thrust something into FG which hasn't been announced or trailed in any way, for which no clear need has been established, and which apparently doesn't work, at least for some (or possibly only me), you will get a majority of seemingly negative comments. That's just inevitable - for those who are happy won't say anything and those that are unhappy will be vociferous. At the end of the day, they are just other peoples' opinions: you can either accept them or ignore them. FWIW - on the few occasions in the past when I made major contributions to FG I ensured that they were tested on both Linux and Windows by others before they the ever saw the light of day. I'm always ready to test stuff for you or anyone else. This is actually what I was trying to do on this occasion. > 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 That was a dig at me - Gene and I were just joshing one another. Finally - I have this hanging in my study: http://www.kipling.org.uk/poems_if.htm Vivian
Re: [Flightgear-devel] Heads up: scenery download / built-in
On Thu, 2011-06-16 at 07:35 +, Martin Spott wrote: > ThorstenB wrote: > > But this and other posts today show [...] > > This is by far the best characterization of The FlightGear Projects > age-old disease I've ever read, As I see it there are two sides to the story, users who criticize too quickly but also developers who don't seem to handle criticism particularly well (not that I'm accusing Thorsten here). Add to that that non native English speakers might sound a bit short cut to native English speakers and that non native English speakers might find comments from other non native speakers insulting because of these misunderstandings while there's actually no intention to do so and there's a problem. Personally I like the idea of being able to fetch new scenery from within FlightGear itself. Working a bit more towards what users expect and appreciate isn't a bad thing, it could even attract new developers who might just want to work on the areas you think FlightGear is lacking (scenery, selecting a new aircraft at runtime). That's how it has always worked so far. The first 3d models weren't particularly attractive but showed that it works and that attracted new developers. Because of that the 3d models created these days are just about the best you can get. Erik -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
ThorstenB wrote: > But this and other posts today show [...] This is by far the best characterization of The FlightGear Projects age-old disease I've ever read, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
On Thu, 16 Jun 2011, ThorstenB wrote: > 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. > That's completely understandable. The bickering does get a bit old and I'm just as guilty as others in my participation in it. :( FlightGear has been around as a going project since 1997. I've hung around the edges of the project this whole time, some times more active than others. I've not contributed a lot of code, but I've tried to push in the right spots periodically. I suspect if I get within arms' reach of Curt, I'm a cooked geek. :) FlightGear has some of the best systems simulation interfaces I've seen. It's easy to use and frankly, on par with what FSX/ESP/Prepar3d offers in terms of ability. The flight modeling is right up there as well - JSBSim has a great tendency to wipe the floor with the blood-encrusted remains of what FSX calls a "flight model". One thing that really lacks is the scene generator. I'm not really interested in why it's like that, but it is something that should be addressed. I'm absolutely not going to point fingers - frankly, I'm not qualified and it wouldn't really solve anything. What needs to happen is a post mortem of it. Outstanding issues need to be identified, they need to be triaged and they need to be addressed. These things need to be committed to paper (e or otherwise) before any code is written in order to prevent any ugly surprises down the road. FlightGear is a huge, complex project and has no kind of real project management at all. If that is not addressed, the mad rush in generally the same direction will eventually lead to the end of FlightGear. Be it a fork or just developer apathy, it's going to end. I'll put my hat in the ring to take over this duty - I figure I've annoyed just about every developer on the list, which everyone knows is the hallmark of a good manager. :) However, if it's not me, it MUST be someone. We need to be organized and we need it badly. The best way to get this herd of cats moving is to stuff 'em all in a long narrow hallway with a really angry dog on the end you don't want them moving towards. :) Woof. :) It's your call guys. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
Interesting ideas , i personally like the fact that terrasync can be enabled from the menu since i always run it from a separate terminal anyway but did i hear the words 'add it to a launcher ??? 'shudder' ok , iv'e been a linux user too long ;) -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
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 re
Re: [Flightgear-devel] Heads up: scenery download / built-in
On Wed, 15 Jun 2011, Vivian Meazza wrote: >> The one wrench in the works is aircraft (and their systems) that add >> entries to the GUI menu items... >> > > If you can generate a better way, or even an alternate way - I'll look at > it. Until then you're stuck with it. > I have the option of being able to just punt and keep using FSX. :D g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
Csaba Halász wrote: > On Wed, Jun 15, 2011 at 10:57 PM, Martin Spott wrote: >> Csaba Halász wrote: >> >>> Finally, there could be other programs that need scenery data, would >>> you embed terrasync in each one? I view this as bad design. >> >> 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. > > I am not arguing to remove this, I am just saying I don't like the > general tendency. That's ok with me. Nevertheless declaring Thorsten's approach as "bad design" sounds extremely onesided to me. First of all, Thorsten put the hard-wired TerraSync code into a configurable, pretty versatile library. I wonder how you'd declare this particular step as "bad design". Secondly he interfaced this lib into FlightGear, which is probably not the incarnation of "good design" (I definitely agree with you on this one), but it a) doesn't do much harm, b) defaults to "off" c) is easy to remove when the time has come, d) adds noticeable convenience for guesstimated 90 % of the userbase and e) see blow. > Implementation difficulties don't really concern theoretical design, > but of course certain tradeoffs might have to be made in practice. Since the history of FlightGear development is plastered with tradeoffs in order to serve this projects unique flavour of 'pragmatism', I think that Thorsten's move is also e) pretty much conformant with "the FlightGear project's traditional way of doing things" :-)) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
Gene > > On Wed, 15 Jun 2011, Vivian Meazza wrote: > > >> > > > > "This" is indeed more or less consistent with those opinions. Csaba > says: > > "For example, all the GUI stuff should be thrown out and left to a > > launcher/control console application." Gene says: "All the functionality > in > > the GUI could be provided in a stand-alone tool that talked to the > > simulator." Ron says that he supports Csaba. I said: "I'm > > happy to set this all up, and more, in a separate GUI." How is my view > > inconsistent? > > > > The one wrench in the works is aircraft (and their systems) that add > entries to the GUI menu items... > If you can generate a better way, or even an alternate way - I'll look at it. Until then you're stuck with it. 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
On Wed, 15 Jun 2011, Vivian Meazza wrote: >> > > "This" is indeed more or less consistent with those opinions. Csaba says: > "For example, all the GUI stuff should be thrown out and left to a > launcher/control console application." Gene says: "All the functionality in > the GUI could be provided in a stand-alone tool that talked to the > simulator." Ron says that he supports Csaba. I said: "I'm > happy to set this all up, and more, in a separate GUI." How is my view > inconsistent? > The one wrench in the works is aircraft (and their systems) that add entries to the GUI menu items... g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
Martin Spott wrote > -Original Message- > From: [mailto:martin.sp...@mgras.net] > Sent: 15 June 2011 18:36 > To: flightgear-devel@lists.sourceforge.net > Subject: Re: [Flightgear-devel] Heads up: scenery download / built-in > > "Vivian Meazza" wrote: > > > This was NOT a good time to introduce a whole new idea, just before a > > release. > > http://wiki.flightgear.org/Release_Plan#Detailed_Time_Schedule > > June 17th is declared as being the feature freeze day. Thus, as long as > they don't commit a pile of crap to the repository, why should people > refrain from adding new features during the regular development cycle ? > > > [...] And I can't see any real advantage over Fred's implementation in > > FGRun, which I have used for years. > > Some people _do_ see a real advantage. And all I said was that I don't. Let others speak for themselves. > > [...] In any case, you have to decide a priori > > to use Terrasync - you need to specify the terrasync scenery directory > > Indeed. I suspect that clever users of this feature are going to > hardwire the TerraSync scenery directory via some command line alias, > preferences file, ~/.fgfsrc or whatever, like they do for other custom > preferences. It's up to you to do the same. 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. > > This is more or less consistent with Gene's, Csaba's and Ron's view - > I'm > > happy to set this all up, and more, in a separate GUI. > > "This" is not consistent with Gene's, Csaba's and Ron's view. If you > read carefully, then you'll realize that these three guys have > primarily expressed their opinion on wether to have the GUI inside the > visual system or not. > "This" is indeed more or less consistent with those opinions. Csaba says: "For example, all the GUI stuff should be thrown out and left to a launcher/control console application." Gene says: "All the functionality in the GUI could be provided in a stand-alone tool that talked to the simulator." Ron says that he supports Csaba. I said: "I'm happy to set this all up, and more, in a separate GUI." How is my view inconsistent? 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
On Wed, Jun 15, 2011 at 10:57 PM, Martin Spott wrote: > Csaba Halász wrote: > >> Finally, there could be other programs that need scenery data, would >> you embed terrasync in each one? I view this as bad design. > > 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. I am not arguing to remove this, I am just saying I don't like the general tendency. Obviously removing stuff that has already been coded (and is at least marginally useful) is an entirely different thing than deciding to not do something in advance. I must have missed the mail thread where this modification was proposed and discussed. > BTW, while I'm very much in favour of having FlightGear's various > subsystems split into distinct parts, I think the "bad design" claim > coming from you is pretty weak. Where was your voice when the Local > Weather subsystem was added ? There could be other programs that need > the same local weather, let's say multiple viewer instances on the same > FlightGear scenario. That was a new system that happened to be born in FG, not an already well established standalone program that we suddenly integrated. In any case, missing one opportunity to spot trouble doesn't mean I have to give up my voice forever (and also doesn't invalidate any arguments). > Adding another 'wrapper' around libsgtsync, let's say a configurable > HLA interface, and removing the current one from FlightGear is > extremely cheap compared to making local weather multi-viewer > compatible. Just a random example, think about it Implementation difficulties don't really concern theoretical design, but of course certain tradeoffs might have to be made in practice. -- Csaba/Jester -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
Csaba Halász wrote: > Finally, there could be other programs that need scenery data, would > you embed terrasync in each one? I view this as bad design. 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. BTW, while I'm very much in favour of having FlightGear's various subsystems split into distinct parts, I think the "bad design" claim coming from you is pretty weak. Where was your voice when the Local Weather subsystem was added ? There could be other programs that need the same local weather, let's say multiple viewer instances on the same FlightGear scenario. Adding another 'wrapper' around libsgtsync, let's say a configurable HLA interface, and removing the current one from FlightGear is extremely cheap compared to making local weather multi-viewer compatible. Just a random example, think about it Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
Csaba Halász wrote: > For example, if you have 2 separate scenery "consumers" it would make > sense if they both sent requests to the same terrasync instance. If > both included their own terrasync copy, who knows what confusion might > result (double download, svn lock, etc.). Nobody forces you to run TerraSync from within FlightGear. But now you're having the choice to do the one _or_ the other, whichever meets your needs. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
On Wed, Jun 15, 2011 at 7:35 PM, Martin Spott wrote: > "Vivian Meazza" wrote: > >> [...] And I can't see any real advantage over Fred's implementation in >> FGRun, which I have used for years. > > Some people _do_ see a real advantage. > >> This is more or less consistent with Gene's, Csaba's and Ron's view - I'm >> happy to set this all up, and more, in a separate GUI. > > "This" is not consistent with Gene's, Csaba's and Ron's view. If you > read carefully, then you'll realize that these three guys have > primarily expressed their opinion on wether to have the GUI inside the > visual system or not. It is pretty consistent with mine, actually. For example, if you have 2 separate scenery "consumers" it would make sense if they both sent requests to the same terrasync instance. If both included their own terrasync copy, who knows what confusion might result (double download, svn lock, etc.). Another scenario could be if the scenery data resided on a separate machine - it would make sense to run a terrasync daemon there and not embedded in FG. My setup is an example for both cases, because I have my scenery data on an NFS share that my laptop and my desktop use. Finally, there could be other programs that need scenery data, would you embed terrasync in each one? I view this as bad design. -- Csaba/Jester -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
On Wed, 15 Jun 2011, Martin Spott wrote: > "This" is not consistent with Gene's, Csaba's and Ron's view. If you > read carefully, then you'll realize that these three guys have > primarily expressed their opinion on wether to have the GUI inside the > visual system or not. > Precisely. I was offering my support for folding _all_ the GUI features into a completely stand-alone application. This is actually an area that I'd be happy to contribute to as long as people don't mind my excrible C++ code. (you could make me a happy man if I could write it in Lazarus. :D ) There's no reason the management application couldn't run on the same computer as the simulator itself. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in
"Vivian Meazza" wrote: > This was NOT a good time to introduce a whole new idea, just before a > release. http://wiki.flightgear.org/Release_Plan#Detailed_Time_Schedule June 17th is declared as being the feature freeze day. Thus, as long as they don't commit a pile of crap to the repository, why should people refrain from adding new features during the regular development cycle ? > [...] And I can't see any real advantage over Fred's implementation in > FGRun, which I have used for years. Some people _do_ see a real advantage. > [...] In any case, you have to decide a priori > to use Terrasync - you need to specify the terrasync scenery directory Indeed. I suspect that clever users of this feature are going to hardwire the TerraSync scenery directory via some command line alias, preferences file, ~/.fgfsrc or whatever, like they do for other custom preferences. It's up to you to do the same. > This is more or less consistent with Gene's, Csaba's and Ron's view - I'm > happy to set this all up, and more, in a separate GUI. "This" is not consistent with Gene's, Csaba's and Ron's view. If you read carefully, then you'll realize that these three guys have primarily expressed their opinion on wether to have the GUI inside the visual system or not. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
On Wed, 15 Jun 2011 08:07:21 -0600, Ron wrote in message <201106150807.21230.w...@jentronics.com>: > On Wednesday 15 June 2011 07:36:51 Csaba Halász wrote: > > On Mon, Jun 13, 2011 at 9:50 PM, ThorstenB wrote: > > > the final GUI bits for a new feature are now in fgdata - the last > > > feature addition for the 2.4 release from my part... You can > > > download/update scenery directly from FlightGear now (main menu: > > > Environment => Scenery). Credit for the idea goes to James - bugs > > > are mine ;-). > > > > For the record, I don't think we are going in the right direction > > with this. I personally think more modules should be split out > > rather than integrated. For example, all the GUI stuff should be > > thrown out and left to a > > launcher/control console application. We could then get rid of plib > > and avoid the "what gui toolkit to use" controversy (at least for > > the core FG). FDM and visualization should also be split, obviously > > with multiple instances allowed of either. > > For the record, and for what its worth, I totally agree with Csaba > here. > > Thanks, > Ron ..splitting the eye candy from the FDMs, screen shot server, networking etc so each item can run in its own thread, yeah, my vote too for whatever it's worth, Linus blamed his 3.0.0 kernel numbering on his own desire to play alpha male. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
Fred > -Original Message- > > It was not a reproach. I just committed fixes at the time I sent those > messages > > -Fred > > - "Vivian Meazza" a écrit : > > > Fred wrote > > Fred wrote > > > > > > > > Please pull latest SimGear > > > > > > And Flightgear too > > > > > > > Well, I thought I had - otherwise I wouldn't have re-compiled and run > > it, > > would I? And it does compile and run - even provides error messages. > Hmmm - pulled, compiles and built. But when it I try to use it I get the following errors: http://pastebin.com/3c6J4D4r I'm probably missing something obvious - any clues? This was NOT a good time to introduce a whole new idea, just before a release. And I can't see any real advantage over Fred's implementation in FGRun, which I have used for years. In any case, you have to decide a priori to use Terrasync - you need to specify the terrasync scenery directory This is more or less consistent with Gene's, Csaba's and Ron's view - I'm happy to set this all up, and more, in a separate GUI. 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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
On Wednesday 15 June 2011 07:36:51 Csaba Halász wrote: > On Mon, Jun 13, 2011 at 9:50 PM, ThorstenB wrote: > > the final GUI bits for a new feature are now in fgdata - the last > > feature addition for the 2.4 release from my part... You can > > download/update scenery directly from FlightGear now (main menu: > > Environment => Scenery). Credit for the idea goes to James - bugs are > > mine ;-). > > For the record, I don't think we are going in the right direction with > this. I personally think more modules should be split out rather than > integrated. For example, all the GUI stuff should be thrown out and left to > a > launcher/control console application. We could then get rid of plib > and avoid the "what gui toolkit to use" controversy (at least for the > core FG). FDM and visualization should also be split, obviously with > multiple instances allowed of either. For the record, and for what its worth, I totally agree with Csaba here. Thanks, Ron -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
> talked to the simulator. You could run it on one machine or on a dedicated > machine. > Gah. Brain to fast for fingers! "You could run it on the SAME machine..or on a dedicated machine..." *facepalm* g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
On Wed, 15 Jun 2011, Csaba Halász wrote: On Mon, Jun 13, 2011 at 9:50 PM, ThorstenB wrote: the final GUI bits for a new feature are now in fgdata - the last feature addition for the 2.4 release from my part... You can download/update scenery directly from FlightGear now (main menu: Environment => Scenery). Credit for the idea goes to James - bugs are mine ;-). For the record, I don't think we are going in the right direction with this. I personally think more modules should be split out rather than integrated. For example, all the GUI stuff should be thrown out and left to a launcher/control console application. We could then get rid of plib and avoid the "what gui toolkit to use" controversy (at least for the core FG). FDM and visualization should also be split, obviously with multiple instances allowed of either. I really, really, like this idea. When was the last time CAE shipped a simulator that had a drop down menu appear in the visual system? :) All the functionality in the GUI could be provided in a stand-alone tool that talked to the simulator. You could run it on one machine or on a dedicated machine. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end.-- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
On Mon, Jun 13, 2011 at 9:50 PM, ThorstenB wrote: > > the final GUI bits for a new feature are now in fgdata - the last > feature addition for the 2.4 release from my part... You can > download/update scenery directly from FlightGear now (main menu: > Environment => Scenery). Credit for the idea goes to James - bugs are > mine ;-). For the record, I don't think we are going in the right direction with this. I personally think more modules should be split out rather than integrated. For example, all the GUI stuff should be thrown out and left to a launcher/control console application. We could then get rid of plib and avoid the "what gui toolkit to use" controversy (at least for the core FG). FDM and visualization should also be split, obviously with multiple instances allowed of either. -- Csaba/Jester -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
It was not a reproach. I just committed fixes at the time I sent those messages -Fred - "Vivian Meazza" a écrit : > Fred wrote > Fred wrote > > > > > Please pull latest SimGear > > > > And Flightgear too > > > > Well, I thought I had - otherwise I wouldn't have re-compiled and run > it, > would I? And it does compile and run - even provides error messages. -- Frédéric Bouvier http://www.youtube.com/user/fgfred64 Videos -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
ThorstenB wrote:
> The feature reuses the terrasync sources and relies on a subversion
> client. Either using built-in subversion (when "libsvn" is installed,
> which is recommended). Otherwise, fgfs tries calling an external utility
> ("svn") for downloads.
I'm observing one minor issue: The SVN client lib is available, it's
being found by CMake in SimGear:
-- Looking for svn_client_checkout in svn_client-1
-- Looking for svn_client_checkout in svn_client-1 - found
-- Looking for svn_cmdline_init in svn_subr-1
-- Looking for svn_cmdline_init in svn_subr-1 - found
-- Looking for svn_ra_initialize in svn_ra-1
-- Looking for svn_ra_initialize in svn_ra-1 - found
-- Found LIBSVN: 1
-- libsvn found, enabling in SimGear
It's being found by Automake in FlightGear:
checking svn_client.h usability... yes
checking svn_client.h presence... yes
checking for svn_client.h... yes
Using built-in subversion (libsvn) for scenery downloads.
checking for library containing svn_client_checkout... -lsvn_client-1
checking for library containing svn_cmdline_init... none required
checking for library containing svn_ra_initialize... none required
It's linked into FlightGear:
jive: 12:29:42 ~> which fgfs
/opt/FlightGear/bin/fgfs
jive: 12:29:45 ~> ldd `which fgfs`| grep svn
libsvn_client-1.so.1 => /usr/lib/libsvn_client-1.so.1
(0x7f2d82c4e000)
libsvn_wc-1.so.1 => /usr/lib/libsvn_wc-1.so.1 (0x7f2d7dee7000)
libsvn_ra-1.so.1 => /usr/lib/libsvn_ra-1.so.1 (0x7f2d7dcdd000)
libsvn_delta-1.so.1 => /usr/lib/libsvn_delta-1.so.1 (0x7f2d7dad2000)
libsvn_diff-1.so.1 => /usr/lib/libsvn_diff-1.so.1 (0x7f2d7d8c6000)
libsvn_subr-1.so.1 => /usr/lib/libsvn_subr-1.so.1 (0x7f2d7d675000)
libsvn_ra_local-1.so.1 => /usr/lib/libsvn_ra_local-1.so.1
(0x7f2d7c586000)
libsvn_repos-1.so.1 => /usr/lib/libsvn_repos-1.so.1 (0x7f2d7c35b000)
libsvn_fs-1.so.1 => /usr/lib/libsvn_fs-1.so.1 (0x7f2d7c154000)
libsvn_ra_svn-1.so.1 => /usr/lib/libsvn_ra_svn-1.so.1
(0x7f2d7bf3d000)
libsvn_ra_neon-1.so.1 => /usr/lib/libsvn_ra_neon-1.so.1
(0x7f2d7bd18000)
libsvn_ra_serf-1.so.1 => /usr/lib/libsvn_ra_serf-1.so.1
(0x7f2d7baf3000)
libsvn_fs_fs-1.so.1 => /usr/lib/libsvn_fs_fs-1.so.1 (0x7f2d7af6)
libsvn_fs_base-1.so.1 => /usr/lib/libsvn_fs_base-1.so.1
(0x7f2d7ad3)
libsvn_fs_util-1.so.1 => /usr/lib/libsvn_fs_util-1.so.1
(0x7f2d7ab2e000)
But the dialogue box "Automatic Scenery Download" says:
"Built-in SVN available: false"
Anyhow, the "scenery-dir" property is set correctly (because I did) and
FG is properly calling the external 'svn' command :-)
SimGear, FlightGear, Base Package from GIT as of this morning (10:00
UTC), SimGear was configured via CMake with "-D ENABLE_LIBSVN=ON",
FlightGear was configured via Autoconf with "--with-libsvn".
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
Fred wrote Fred wrote > > Please pull latest SimGear > > And Flightgear too > Well, I thought I had - otherwise I wouldn't have re-compiled and run it, would I? And it does compile and run - even provides error messages. 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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
> Please pull latest SimGear And Flightgear too -Fred -- Frédéric Bouvier http://www.youtube.com/user/fgfred64 Videos -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
Hi Vivian, > Fred - should this work with MSVC9? Only if the required symbols are defined. > It compiles and runs, but I get this error: > > "Cannot start scenery download. Rsync scenery server is undefined." > > The server input in the menu item is blank, and does not accept any > input Please pull latest SimGear Regards, -Fred -- Frédéric Bouvier http://www.youtube.com/user/fgfred64 Videos -- 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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
Excellent!
On Mon, Jun 13, 2011 at 12:50 PM, ThorstenB wrote:
> Hi,
>
> the final GUI bits for a new feature are now in fgdata - the last
> feature addition for the 2.4 release from my part... You can
> download/update scenery directly from FlightGear now (main menu:
> Environment => Scenery). Credit for the idea goes to James - bugs are
> mine ;-).
>
> It provides built-in terrasync support - with some advantages:
>
> * Configuration requires a scenery target directory only (your
> "terrasync" directory) and a checkbox to enable. For now, you'll also
> need to provide the terrasync directory as part of your --fg-scenery
> paths (otherwise you won't see downloaded scenery). Maybe we can add the
> directory to the search path internally some time, simplifying things
> even more. Should help anyway (especially new users) in obtaining world
> scenery. Not quite as simple as loading scenery with Google Earth yet -
> but closer...
> Before someone asks: the scenery server address is displayed in the GUI,
> but editing is disabled. Is there any reason (right now), why users
> would want to change? (You could still change using preferences.xml /
> property browser though).
>
> * You can enable/disable scenery download any time using the menu. When
> you notice mid-flight that scenery is missing, just enable the download
> checkbox and wait a bit (depending on your connection speed ;-) ).
>
> * There is also a (still experimental) option to refresh scenery tiles
> once their update is complete. You could "warp" into a new region,
> initially see ocean only (default replacement for missing scenery) and
> eventually see the ocean tiles being replaced by actual scenery. That's
> still experimental though, the update logic requires improvement. Looks
> weird when scenery tiles are removed when the a/c is just parked/rolling
> on them (old scenery disappears for a second before the "fresh" one
> reappears). Also bad on final approach... And the a/c position and
> altitude of clouds may need to be adapted when scenery altitude has
> changed - which is a problem when ocean (sea level) is replaced by
> actual scenery (mountains...). Usually ok to enable the feature
> mid-flight. Otherwise, there is also a manual "refresh" button, so you
> could choose yourself at what time to replace ocean/missing scenery.
>
> The feature reuses the terrasync sources and relies on a subversion
> client. Either using built-in subversion (when "libsvn" is installed,
> which is recommended). Otherwise, fgfs tries calling an external utility
> ("svn") for downloads. All the same as with original terrasync.
> The built-in svn support is enabled for automake right now (use
> "--with_libsvn=no" to disable). It's off by default for cmake builds (we
> could change that, use "ENABLE_LIBSVN" to enable for now). The cmake
> build isn't really well tested yet - except that Hudson seems happy for
> all targets. And as mentioned, I'd need help with cmake if it wasn't
> working properly. And it'd also be good to get Hudson to build the
> Windows/Mac binaries with built-in svn support (seems to do that for
> Linux/automake already).
>
> As usual, report any (new) issues. If you don't like the feature, keep
> the checkbox disabled and the whole thing shouldn't bother you. You can
> keep using manual downloads or the separate terrasync utility as before
> (which lives on), of course.
>
> cheers,
> Thorsten
>
> PS: Yes, a complete update (sg+fg+fgdata) is required for things to
> work.
>
>
>
> --
> 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
>
--
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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
ThorstenBv wrote
>
> Hi,
>
> the final GUI bits for a new feature are now in fgdata - the last
> feature addition for the 2.4 release from my part... You can
> download/update scenery directly from FlightGear now (main menu:
> Environment => Scenery). Credit for the idea goes to James - bugs are
> mine ;-).
>
> It provides built-in terrasync support - with some advantages:
>
> * Configuration requires a scenery target directory only (your
> "terrasync" directory) and a checkbox to enable. For now, you'll also
> need to provide the terrasync directory as part of your --fg-scenery
> paths (otherwise you won't see downloaded scenery). Maybe we can add the
> directory to the search path internally some time, simplifying things
> even more. Should help anyway (especially new users) in obtaining world
> scenery. Not quite as simple as loading scenery with Google Earth yet -
> but closer...
> Before someone asks: the scenery server address is displayed in the GUI,
> but editing is disabled. Is there any reason (right now), why users
> would want to change? (You could still change using preferences.xml /
> property browser though).
>
> * You can enable/disable scenery download any time using the menu. When
> you notice mid-flight that scenery is missing, just enable the download
> checkbox and wait a bit (depending on your connection speed ;-) ).
>
> * There is also a (still experimental) option to refresh scenery tiles
> once their update is complete. You could "warp" into a new region,
> initially see ocean only (default replacement for missing scenery) and
> eventually see the ocean tiles being replaced by actual scenery. That's
> still experimental though, the update logic requires improvement. Looks
> weird when scenery tiles are removed when the a/c is just parked/rolling
> on them (old scenery disappears for a second before the "fresh" one
> reappears). Also bad on final approach... And the a/c position and
> altitude of clouds may need to be adapted when scenery altitude has
> changed - which is a problem when ocean (sea level) is replaced by
> actual scenery (mountains...). Usually ok to enable the feature
> mid-flight. Otherwise, there is also a manual "refresh" button, so you
> could choose yourself at what time to replace ocean/missing scenery.
>
> The feature reuses the terrasync sources and relies on a subversion
> client. Either using built-in subversion (when "libsvn" is installed,
> which is recommended). Otherwise, fgfs tries calling an external utility
> ("svn") for downloads. All the same as with original terrasync.
> The built-in svn support is enabled for automake right now (use
> "--with_libsvn=no" to disable). It's off by default for cmake builds (we
> could change that, use "ENABLE_LIBSVN" to enable for now). The cmake
> build isn't really well tested yet - except that Hudson seems happy for
> all targets. And as mentioned, I'd need help with cmake if it wasn't
> working properly. And it'd also be good to get Hudson to build the
> Windows/Mac binaries with built-in svn support (seems to do that for
> Linux/automake already).
>
> As usual, report any (new) issues. If you don't like the feature, keep
> the checkbox disabled and the whole thing shouldn't bother you. You can
> keep using manual downloads or the separate terrasync utility as before
> (which lives on), of course.
>
> cheers,
> Thorsten
>
> PS: Yes, a complete update (sg+fg+fgdata) is required for things to
> work.
Fred - should this work with MSVC9? It compiles and runs, but I get this
error:
"Cannot start scenery download. Rsync scenery server is undefined."
The server input in the menu item is blank, and does not accept any input
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
[Flightgear-devel] Heads up: scenery download / built-in terrasync
Hi,
the final GUI bits for a new feature are now in fgdata - the last
feature addition for the 2.4 release from my part... You can
download/update scenery directly from FlightGear now (main menu:
Environment => Scenery). Credit for the idea goes to James - bugs are
mine ;-).
It provides built-in terrasync support - with some advantages:
* Configuration requires a scenery target directory only (your
"terrasync" directory) and a checkbox to enable. For now, you'll also
need to provide the terrasync directory as part of your --fg-scenery
paths (otherwise you won't see downloaded scenery). Maybe we can add the
directory to the search path internally some time, simplifying things
even more. Should help anyway (especially new users) in obtaining world
scenery. Not quite as simple as loading scenery with Google Earth yet -
but closer...
Before someone asks: the scenery server address is displayed in the GUI,
but editing is disabled. Is there any reason (right now), why users
would want to change? (You could still change using preferences.xml /
property browser though).
* You can enable/disable scenery download any time using the menu. When
you notice mid-flight that scenery is missing, just enable the download
checkbox and wait a bit (depending on your connection speed ;-) ).
* There is also a (still experimental) option to refresh scenery tiles
once their update is complete. You could "warp" into a new region,
initially see ocean only (default replacement for missing scenery) and
eventually see the ocean tiles being replaced by actual scenery. That's
still experimental though, the update logic requires improvement. Looks
weird when scenery tiles are removed when the a/c is just parked/rolling
on them (old scenery disappears for a second before the "fresh" one
reappears). Also bad on final approach... And the a/c position and
altitude of clouds may need to be adapted when scenery altitude has
changed - which is a problem when ocean (sea level) is replaced by
actual scenery (mountains...). Usually ok to enable the feature
mid-flight. Otherwise, there is also a manual "refresh" button, so you
could choose yourself at what time to replace ocean/missing scenery.
The feature reuses the terrasync sources and relies on a subversion
client. Either using built-in subversion (when "libsvn" is installed,
which is recommended). Otherwise, fgfs tries calling an external utility
("svn") for downloads. All the same as with original terrasync.
The built-in svn support is enabled for automake right now (use
"--with_libsvn=no" to disable). It's off by default for cmake builds (we
could change that, use "ENABLE_LIBSVN" to enable for now). The cmake
build isn't really well tested yet - except that Hudson seems happy for
all targets. And as mentioned, I'd need help with cmake if it wasn't
working properly. And it'd also be good to get Hudson to build the
Windows/Mac binaries with built-in svn support (seems to do that for
Linux/automake already).
As usual, report any (new) issues. If you don't like the feature, keep
the checkbox disabled and the whole thing shouldn't bother you. You can
keep using manual downloads or the separate terrasync utility as before
(which lives on), of course.
cheers,
Thorsten
PS: Yes, a complete update (sg+fg+fgdata) is required for things to
work.
--
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
