Re: [Flightgear-devel] Heads up: scenery download /built-interrasync
On 25.06.2011 01:31, Vivian Meazza wrote: But isn't this a function of libsvn and we are talking about external svn and libsvn not present? I'm currently testing another fix without libsvn functions. Thanks, Torsten - well done. This is true. But using Fred's MSVC9 solution files as provided it is not possible to switch off the libsvn stuff AFAIKS. That's not good, of course. libsvn should be optional, but no idea how we do such options for MSVC9. But it's certainly optional for any other build system - and it's good that it is. As I said way back - we seem to have at least 3 overlapping scenery download methods. I'm not entirely clear on the relative merits of the internal and external svn options. D'oh. I'm giving up... Tired of repeating. I think we also need svn_path_uri_encode() in the internal path to allow download directories paths to have spaces. Usually, white-spaces are a particular issue when calling external command-lines utilities. The entire command-line is constructed as single string - and then needs to be parsed by the command-line processor into separate parmeters. That's where things go wrong with white-spaces in paths - since such paths get split into several parameters (rather than one parameter with a white-space). No one has reported any issues with white-spaces with libsvn. I remember reports that white-spaces were even working with internal SVN on Windows (it certainly does for the other OS). cheers, Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ 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-interrasync
- ThorstenB a écrit : This is true. But using Fred's MSVC9 solution files as provided it is not possible to switch off the libsvn stuff AFAIKS. That's not good, of course. libsvn should be optional, but no idea how we do such options for MSVC9. But it's certainly optional for any other build system - and it's good that it is. Simple, build your win32 binaries yourself. This is the only thing possible as long as it is a build option Regards, -Fred -- Frédéric Bouvier http://www.youtube.com/user/fgfred64 Videos -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ 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-interrasync
Torsten Am 24.06.11 23:59, schrieb Torsten Dreyer: Is this built-in function: svn_path_uri_encode() any help? Yup, does the trick - no need for fancy formatting. I'll see if I can do a damned merge request this side of Monday. Vivian But isn't this a function of libsvn and we are talking about external svn and libsvn not present? I'm currently testing another fix without libsvn functions. Torsten Here you go: simgear commit d36170879c9394064b37fc9acb3d12d451f2be82 makes whitespaces in the command _and_ the target directory work for me. Tested on Linux, MacOS and WinXP/VS2008. Please pull simgear and rebuild simgear+flightgear and test if it works for you. All options work exactly as they should: Internal and External, with / or \ and with or without white spaces. I would never have guessed that double double quotes would do the trick, but they clearly do. svn_path_uri_encode() also does the trick, but this is a more robust solution. Thanks for all your effort in clearing this bug. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ 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-interrasync
Torsten wrote, I also know that quoting white-space paths works well in command.com Windows shells. But apparently it didn't work when terrasync called the system function to call svn. Unfortunately I have no means to test any of this on Windows. The following patch seem to do the trick for me, it allow whitespace in the command and in the local path name. It simply wraps the entire system() command in and uses backslash instead of forward slash for the path separator in the local path. Please check, if it works for you. Nope. I added a few extra alerts, and got this: svn: 'D:/terrasync' does not appear to be a URL Failed to synchronize directory ext'Objects/w130n30/w122n37', error code= 1 sync command ext 'svn checkout -q http://terrascenery.googlecode.com/svn/trunk/ data/Scenery/Terrain/w130n30/w122n37 D:/terrasync test\Terrain/w130n30/w122n37' Looks to me as if the command has to include no white space, and that's it. Perhaps we should accept it, make sure the user is aware of it, and leave it at that. It's a pooh trap because all sorts of directories with spaces are created automatically by Windows - Program Files is only one such. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ 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-interrasync
Am 24.06.11 11:09, schrieb Vivian Meazza: Looks to me as if the command has to include no white space, and that's it. No, it may contain white space. It's just that we mix backslash and forward slash in the local path. This: D:/terrasync test\Terrain/w130n30/w122n37 Is a complete mess (from Windows point of view). I'll work on a solution later, probably today. Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ 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-interrasync
Torsten wrote Am 24.06.11 11:09, schrieb Vivian Meazza: Looks to me as if the command has to include no white space, and that's it. No, it may contain white space. It's just that we mix backslash and forward slash in the local path. This: D:/terrasync test\Terrain/w130n30/w122n37 Is a complete mess (from Windows point of view). I'll work on a solution later, probably today. Is this built-in function: svn_path_uri_encode() any help? -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ 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-interrasync
I wrote: -Original Message- From: Vivian Meazza [mailto:vivian.mea...@lineone.net] Sent: 24 June 2011 18:45 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Heads up: scenery download /built- interrasync Torsten wrote Am 24.06.11 11:09, schrieb Vivian Meazza: Looks to me as if the command has to include no white space, and that's it. No, it may contain white space. It's just that we mix backslash and forward slash in the local path. This: D:/terrasync test\Terrain/w130n30/w122n37 Is a complete mess (from Windows point of view). I'll work on a solution later, probably today. Is this built-in function: svn_path_uri_encode() any help? Yup, does the trick - no need for fancy formatting. I'll see if I can do a damned merge request this side of Monday. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ 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-interrasync
Is this built-in function: svn_path_uri_encode() any help? Yup, does the trick - no need for fancy formatting. I'll see if I can do a damned merge request this side of Monday. Vivian But isn't this a function of libsvn and we are talking about external svn and libsvn not present? I'm currently testing another fix without libsvn functions. Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ 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-interrasync
Am 24.06.11 23:59, schrieb Torsten Dreyer: Is this built-in function: svn_path_uri_encode() any help? Yup, does the trick - no need for fancy formatting. I'll see if I can do a damned merge request this side of Monday. Vivian But isn't this a function of libsvn and we are talking about external svn and libsvn not present? I'm currently testing another fix without libsvn functions. Torsten Here you go: simgear commit d36170879c9394064b37fc9acb3d12d451f2be82 makes whitespaces in the command _and_ the target directory work for me. Tested on Linux, MacOS and WinXP/VS2008. Please pull simgear and rebuild simgear+flightgear and test if it works for you. Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ 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-interrasync
Torsten Is this built-in function: svn_path_uri_encode() any help? Yup, does the trick - no need for fancy formatting. I'll see if I can do a damned merge request this side of Monday. Vivian But isn't this a function of libsvn and we are talking about external svn and libsvn not present? I'm currently testing another fix without libsvn functions. This is true. But using Fred's MSVC9 solution files as provided it is not possible to switch off the libsvn stuff AFAIKS. As I said way back - we seem to have at least 3 overlapping scenery download methods. I'm not entirely clear on the relative merits of the internal and external svn options. I think we also need svn_path_uri_encode() in the internal path to allow download directories paths to have spaces. A space in the directory path is almost bound to happen, because the default terrasync directory is C:/Program Files/FlightGear/terrasyncdir. Nevertheless, a non-libsvn solution must be good. If it can be done in svn_path_uri_encode(), it must be doable locally. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ 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-interrasync
-- From: Vivian Meazza vivian.mea...@lineone.net Sent: Wednesday, June 22, 2011 11:32 PM To: 'FlightGear developers discussions' flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Heads up: scenery download /built-interrasync ThorstenB wrote: You need to provide a target directory for the scenery. This message means the target directory is completely empty (or contains white-spaces only). See directory configured in the scenery download GUI. Stuart's suggestion to use a default target may be a good idea. Today, with the new GIT the Flightgear program crashes. Here is a stack trace: Thanks, a string boundary problem - should be fixed right now. The new check to avoid svn from crashing on trailing / was missing a pair of parenthesis. With the latest Jenkins or Local builds I get this: Starting automatic scenery download/synchronization. Using external SVN utility 'C:/Program Files/Subversion/bin/svn'. Directory: 'D:/Git_New/terrasync'. 'C:/Program' is not recognized as an internal or external command, operable program or batch file. Looks like a white space issue to me. When svn.exe is in the path I get: Starting automatic scenery download/synchronization. Using external SVN utility 'svn'. Directory: 'D:/Git_New/terrasync'. The filename, directory name, or volume label syntax is incorrect. Missing something? I'm probably doing something wrong. Any guidance? The Built-in download works correctly. Vivian I have this on my MSVC10 machine and have put it down to cmake not finding the SVN libraries. ( Note. I have given cmake the path to the SVN includes.) If you look into the simgear\CMakeModules\FindSvnClient.cmake the SVN search paths are all unix style ones such /usr/local, but I have not looked any further into the problem. All is OK on MSVC9, which is not encumbered with cmake. Alan Alan -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ 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-interrasync
Alan wrote -- From: Vivian Meazza vivian.mea...@lineone.net Sent: Wednesday, June 22, 2011 11:32 PM To: 'FlightGear developers discussions' flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Heads up: scenery download /built-interrasync ThorstenB wrote: You need to provide a target directory for the scenery. This message means the target directory is completely empty (or contains white- spaces only). See directory configured in the scenery download GUI. Stuart's suggestion to use a default target may be a good idea. Today, with the new GIT the Flightgear program crashes. Here is a stack trace: Thanks, a string boundary problem - should be fixed right now. The new check to avoid svn from crashing on trailing / was missing a pair of parenthesis. With the latest Jenkins or Local builds I get this: Starting automatic scenery download/synchronization. Using external SVN utility 'C:/Program Files/Subversion/bin/svn'. Directory: 'D:/Git_New/terrasync'. 'C:/Program' is not recognized as an internal or external command, operable program or batch file. Looks like a white space issue to me. When svn.exe is in the path I get: Starting automatic scenery download/synchronization. Using external SVN utility 'svn'. Directory: 'D:/Git_New/terrasync'. The filename, directory name, or volume label syntax is incorrect. Missing something? I'm probably doing something wrong. Any guidance? The Built-in download works correctly. Vivian I have this on my MSVC10 machine and have put it down to cmake not finding the SVN libraries. ( Note. I have given cmake the path to the SVN includes.) If you look into the simgear\CMakeModules\FindSvnClient.cmake the SVN search paths are all unix style ones such /usr/local, but I have not looked any further into the problem. All is OK on MSVC9, which is not encumbered with cmake. I'm getting this problem on the latest Jenkins build #345, which I understand uses MSVC9, as well as my local MSVC9 build. Interesting to know that you aren't getting it with your local MSVC9 build. I'll look into it some more. Vivian -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ 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-interrasync
-- From: Vivian Meazza vivian.mea...@lineone.net Sent: Thursday, June 23, 2011 8:44 AM To: 'FlightGear developers discussions' flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Heads up: scenery download /built-interrasync Alan wrote -- From: Vivian Meazza vivian.mea...@lineone.net Sent: Wednesday, June 22, 2011 11:32 PM To: 'FlightGear developers discussions' flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Heads up: scenery download /built-interrasync ThorstenB wrote: You need to provide a target directory for the scenery. This message means the target directory is completely empty (or contains white- spaces only). See directory configured in the scenery download GUI. Stuart's suggestion to use a default target may be a good idea. Today, with the new GIT the Flightgear program crashes. Here is a stack trace: Thanks, a string boundary problem - should be fixed right now. The new check to avoid svn from crashing on trailing / was missing a pair of parenthesis. With the latest Jenkins or Local builds I get this: Starting automatic scenery download/synchronization. Using external SVN utility 'C:/Program Files/Subversion/bin/svn'. Directory: 'D:/Git_New/terrasync'. 'C:/Program' is not recognized as an internal or external command, operable program or batch file. Looks like a white space issue to me. When svn.exe is in the path I get: Starting automatic scenery download/synchronization. Using external SVN utility 'svn'. Directory: 'D:/Git_New/terrasync'. The filename, directory name, or volume label syntax is incorrect. Missing something? I'm probably doing something wrong. Any guidance? The Built-in download works correctly. Vivian I have this on my MSVC10 machine and have put it down to cmake not finding the SVN libraries. ( Note. I have given cmake the path to the SVN includes.) If you look into the simgear\CMakeModules\FindSvnClient.cmake the SVN search paths are all unix style ones such /usr/local, but I have not looked any further into the problem. All is OK on MSVC9, which is not encumbered with cmake. I'm getting this problem on the latest Jenkins build #345, which I understand uses MSVC9, as well as my local MSVC9 build. Interesting to know that you aren't getting it with your local MSVC9 build. I'll look into it some more. Vivian Are you linking these libraries which are the ones that cmake can't find for me? libsvn_client-1.lib,libsvn_subr-1.lib,libsvn_ra-1.lib They are in the very latest 3rd party from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/fgfs-win32-VS90-3rdParty+OSG-20110618.zip. Alan -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ 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-interrasync
On 23.06.2011 00:32, Vivian Meazza wrote: Looks like a white space issue to me. When svn.exe is in the path I get: Starting automatic scenery download/synchronization. Using external SVN utility 'svn'. Directory: 'D:/Git_New/terrasync'. The filename, directory name, or volume label syntax is incorrect. Enclosing all paths in quotes, i.e. calling c:\Program Files\foo\svn.exe checkout d:\white space instead of c:\Program Files\foo\svn.exe checkout d:\white space usually fixes white-space issues when building command-lines. It does so for Linux (and pretty sure Mac). But as you report, apparently it doesn't help with Windows. Such paths never worked for original terrasync(.exe) with external svn support. I've disabled the use of white spaces for Windows now, when using the external utility. Doesn't fix the issue, but at least people get a meaningful error message and are told to use a different directory. Anyone running Windows and able to investigate the issue, is welcome to look at why calling a Windows command-line utility doesn't accept quoted paths (with white-spaces). cheers, Thorsten -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ 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-interrasync
On Thu, 23 Jun 2011, ThorstenB wrote: On 23.06.2011 00:32, Vivian Meazza wrote: Looks like a white space issue to me. When svn.exe is in the path I get: Starting automatic scenery download/synchronization. Using external SVN utility 'svn'. Directory: 'D:/Git_New/terrasync'. The filename, directory name, or volume label syntax is incorrect. Enclosing all paths in quotes, i.e. calling c:\Program Files\foo\svn.exe checkout d:\white space instead of c:\Program Files\foo\svn.exe checkout d:\white space usually fixes white-space issues when building command-lines. It does so for Linux (and pretty sure Mac). But as you report, apparently it doesn't help with Windows. Have you tried quoting the entire command line to see if that helps? 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. -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ 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-interrasync
ThorstenB wrote On 23.06.2011 00:32, Vivian Meazza wrote: Looks like a white space issue to me. When svn.exe is in the path I get: Starting automatic scenery download/synchronization. Using external SVN utility 'svn'. Directory: 'D:/Git_New/terrasync'. The filename, directory name, or volume label syntax is incorrect. Enclosing all paths in quotes, i.e. calling c:\Program Files\foo\svn.exe checkout d:\white space instead of c:\Program Files\foo\svn.exe checkout d:\white space usually fixes white-space issues when building command-lines. It does so for Linux (and pretty sure Mac). But as you report, apparently it doesn't help with Windows. Such paths never worked for original terrasync(.exe) with external svn support. I've disabled the use of white spaces for Windows now, when using the external utility. Doesn't fix the issue, but at least people get a meaningful error message and are told to use a different directory. Anyone running Windows and able to investigate the issue, is welcome to look at why calling a Windows command-line utility doesn't accept quoted paths (with white-spaces). This works: D:\New Gitsvn info C:/Program Files/FlightGear/terrasync/Models Path: C:\Program Files\FlightGear\terrasync\Models URL: http://terrascenery.googlecode.com/svn/trunk/data/Scenery/Models Repository Root: http://terrascenery.googlecode.com/svn Repository UUID: 383cc0dc-9303-11dd-9049-4d0e41e9b215 Revision: 16328 Node Kind: directory Schedule: normal Last Changed Author: goo...@mgras.net Last Changed Rev: 16305 Last Changed Date: 2011-06-20 12:47:41 +0100 (Mon, 20 Jun 2011) Notice that there are white spaces everywhere. C:/Program Files/FlightGear/terrasync/Models also works. This does not work: D:\New Gitsvn info C:/Program Files/FlightGear/terrasync svn: 'C:\Program Files\FlightGear\terrasync' is not a working copy. In fact, none of the other directories under terrasync are recognized by svn. I don't have a clue how it ever worked, except to say it did actually work before the last update. Of course, that might have indeed been pure chance. Is this any help? Vivian -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ 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-interrasync
On 23.06.2011 19:16, Vivian Meazza wrote: This works: D:\New Gitsvn info C:/Program Files/FlightGear/terrasync/Models This does not work: D:\New Gitsvn info C:/Program Files/FlightGear/terrasync Is this any help? Unfortunately this differnece is unrelated. Terrasync creates separate SVN repositories for the Models folder, for each airport directory letter (A-Z directories) and for each scenery leaf directory. All those directories contain separate SVN repositories. All other directories, including the terrasync root directory, are normal system directories and are completely unknown to SVN. Hence, svn info (or svn checkout etc) only works with specific directories. terrasync always calls svn checkout with specific directories - never with the root directory, i.e. we never pull the complete world scenery with a single svn command. I also know that quoting white-space paths works well in command.com Windows shells. But apparently it didn't work when terrasync called the system function to call svn. Unfortunately I have no means to test any of this on Windows. cheers, Thorsten -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ 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-interrasync
I also know that quoting white-space paths works well in command.com
Windows shells. But apparently it didn't work when terrasync called the
system function to call svn. Unfortunately I have no means to test
any of this on Windows.
The following patch seem to do the trick for me, it allow whitespace in
the command and in the local path name.
It simply wraps the entire system() command in and uses backslash
instead of forward slash for the path
separator in the local path.
Please check, if it works for you.
Greetings, Torsten
diff --git a/simgear/scene/tsync/terrasync.cxx
b/simgear/scene/tsync/terrasync.cxx
index 1d9bf8e..48e9ede 100644
--- a/simgear/scene/tsync/terrasync.cxx
+++ b/simgear/scene/tsync/terrasync.cxx
@@ -315,6 +315,7 @@ bool SGTerraSync::SvnThread::start()
#ifdef SG_WINDOWS
if ((_use_svn)(!use_int_svn))
{
+#if 0
// external SVN support is used
if (hasWhitespace(_local_dir))
{
@@ -338,6 +339,7 @@ bool SGTerraSync::SvnThread::start()
_stalled = true;
return false;
}
+#endif
}
#endif
@@ -494,7 +496,7 @@ bool SGTerraSync::SvnThread::syncTreeExternal(const char*
dir)
#ifdef SG_WINDOWS
// no support for white-space paths
snprintf( command, 512,
-%s %s %s/%s %s/%s, _svn_command.c_str(), svn_options,
+\%s %s %s/%s %s\\%s\, _svn_command.c_str(), svn_options,
_svn_server.c_str(), dir,
_local_dir.c_str(), dir );
#else
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
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-interrasync
On 21.06.2011 23:00, Alan Teeder wrote: Yesterday in the command window I got Cannot start scenery download. No local cache directory defined. The new SVN system did not work You need to provide a target directory for the scenery. This message means the target directory is completely empty (or contains white-spaces only). See directory configured in the scenery download GUI. Stuart's suggestion to use a default target may be a good idea. Today, with the new GIT the Flightgear program crashes. Here is a stack trace: Thanks, a string boundary problem - should be fixed right now. The new check to avoid svn from crashing on trailing / was missing a pair of parenthesis. cheers, Thorsten -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ 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-interrasync
Thanks for the help. The built in SVN is now available and working. There is a BUT of course. ;-( There are repeated errors:- Failed to synchronize directory ´Airports/Q', Server sent unexpected return value (502 Bad Gateway) in response to PROPFIND for 'svn/!svn/bln/16328/trunck/data/Scenery/Airports/R' (code 175002) SVN repository cleanup successful for 'Airports/Q' and Failed to synchronize directory ´Airports/R', Server sent unexpected return value (502 Bad Gateway) in response to PROPFIND for 'svn/!svn/bc/16328 (code 175002) SVN repository cleanup successful for 'Airports/R' After a few of these Stalled changes from true to false and a message sayng that there have been too many errors appears on the main screen. Alan -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ 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-interrasync
If occasional 50x responses occur in batches, but not for most simulation runs where you synchronize scenery, don't worry about it and certainly don't blame the FGFS codebase. If 50x's occur routinely for several hours, feel free to let me know. Just in case the shared backend is misbehaving. Aside: I don't think terrasync (and thus probably the integrated library) reschedules failed requests for a few minutes later; maybe it should do so? On Wed, Jun 22, 2011 at 7:28 AM, Alan Teeder ajtee...@v-twin.org.uk wrote: Thanks for the help. The built in SVN is now available and working. Failed to synchronize directory ´Airports/Q', Server sent unexpected return value (502 Bad Gateway) in response to PROPFIND for 'svn/!svn/bln/16328/trunck/data/Scenery/Airports/R' (code 175002) SVN repository cleanup successful for 'Airports/Q' -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ 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-interrasync
-- From: Alex Perry alex.pe...@ieee.org Sent: Wednesday, June 22, 2011 3:48 PM To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Heads up: scenery download /built-interrasync If occasional 50x responses occur in batches, but not for most simulation runs where you synchronize scenery, don't worry about it and certainly don't blame the FGFS codebase. If 50x's occur routinely for several hours, feel free to let me know. Just in case the shared backend is misbehaving. Aside: I don't think terrasync (and thus probably the integrated library) reschedules failed requests for a few minutes later; maybe it should do so? The problem went away, so I guess the server was sulking (or overloaded) for a while. Thanks Alan -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ 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-interrasync
On 22.06.2011 16:48, Alex Perry wrote: If occasional 50x responses occur in batches, but not for most simulation runs where you synchronize scenery, don't worry about it and certainly don't blame the FGFS codebase. If 50x's occur routinely for several hours, feel free to let me know. Just in case the shared backend is misbehaving. Not sure, but maybe related: I've recently seen lots of ERROR 500 when using the bug tracker at code.google.com. Scenery is hosted on googlecode.com. So maybe google code is having issues (Could _Google_ really have traffic/performance trouble?? Is that possible for them... ;-) ). Aside: I don't think terrasync (and thus probably the integrated library) reschedules failed requests for a few minutes later; maybe it should do so? Good idea. And indeed it doesn't. terrasync doesn't care if an update is successful or not. Directories are always blocked for several hours before another update attempt is allowed (or terrasync is restarted). It'd be trivial to change that, so that a directory only get's blocked for several minutes when the attempt failed, while we'd keep it blocked for hours if the update was successful. That wouldn't actively reschedule anything, but it would allow another attempt if the user again crossed (or circled in) the same area. That would improve things - and maybe that's even good enough. cheers, Thorsten -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ 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-interrasync
Still more problems from Alan. MS- VC90 on my laptop now works fine - thanks. MS- VC10 uses cmake, which does not know how to find the SVN libraries with windows. The SVN includes (in the 3rdparty include directory) are fine. Alan -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ 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-interrasync
ThorstenB wrote: You need to provide a target directory for the scenery. This message means the target directory is completely empty (or contains white-spaces only). See directory configured in the scenery download GUI. Stuart's suggestion to use a default target may be a good idea. Today, with the new GIT the Flightgear program crashes. Here is a stack trace: Thanks, a string boundary problem - should be fixed right now. The new check to avoid svn from crashing on trailing / was missing a pair of parenthesis. With the latest Jenkins or Local builds I get this: Starting automatic scenery download/synchronization. Using external SVN utility 'C:/Program Files/Subversion/bin/svn'. Directory: 'D:/Git_New/terrasync'. 'C:/Program' is not recognized as an internal or external command, operable program or batch file. Looks like a white space issue to me. When svn.exe is in the path I get: Starting automatic scenery download/synchronization. Using external SVN utility 'svn'. Directory: 'D:/Git_New/terrasync'. The filename, directory name, or volume label syntax is incorrect. Missing something? I'm probably doing something wrong. Any guidance? The Built-in download works correctly. Vivian -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ 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. Do we require Windows users to have
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-interrasync
With Yesterday in the command window I got Cannot start scenery download. No local cache directory defined. The new SVN system did not work Today, with the new GIT the Flightgear program crashes. Here is a stack trace: msvcr90.dll!_crt_debugger_hook(int _Reserved=0) Line 65C msvcr90.dll!_invoke_watson(const wchar_t * pszExpression=0x, const wchar_t * pszFunction=0x, const wchar_t * pszFile=0x, unsigned int nLine=0, unsigned int pReserved=0) Line 230 + 0x7 bytes C++ msvcr90.dll!_invalid_parameter_noinfo() Line 125 + 0xc bytes C++ msvcp90.dll!std::basic_stringchar,std::char_traitschar,std::allocatorchar::operator[](unsigned int _Off=4294967295) Line 1583C++ fgfs.exe!stripPath(std::basic_stringchar,std::char_traitschar,std::allocatorchar path=) Line 107 + 0x2e bytes C++ fgfs.exe!simgear::SGTerraSync::SvnThread::setLocalDir(std::basic_stringchar,std::char_traitschar,std::allocatorchar dir=) Line 147 + 0x4dbytesC++ fgfs.exe!simgear::SGTerraSync::reinit() Line 665 C++ fgfs.exe!simgear::SGTerraSync::init() Line 647 C++ fgfs.exe!SGSubsystemGroup::init() Line 152 + 0x46 bytesC++ fgfs.exe!SGSubsystemMgr::init() Line 458 + 0x1b bytes C++ fgfs.exe!fgInitSubsystems() Line 1518 C++ fgfs.exe!fgIdleFunction() Line 501 + 0x5 bytes C++ fgfs.exe!fgOSMainLoop() Line 285 C++ fgfs.exe!fgMainInit(int argc=1, char * * argv=0x02734d28) Line 663 + 0x5bytes C++ fgfs.exe!main(int argc=1, char * * argv=0x02734d28) Line 243 + 0xd bytesC++fgfs.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C kernel32.dll!7688d0e9() [Frames below may be incorrect and/or missing, no symbols loaded forkernel32.dll] ntdll.dll!76e816c3() ntdll.dll!76e81696()fgfs.exe!fgOptTraceRead(const char * arg=0xffc88b04) Line 889 + 0xb7bytes C++ c48300bf()Unfortunately FG will not link in Debug mode so I can't go any further.I am using the new 3rd party stuff fromftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/fgfs-win32-VS90-3rdParty+OSG-20110618.zipAlan -- 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 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
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 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
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
- 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: 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
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-dev2dev
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
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
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
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, 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: ... 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
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 ... 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 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
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
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
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
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
On Mon, Jun 13, 2011 at 9:50 PM, ThorstenB bre...@gmail.com 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
On Wed, 15 Jun 2011, Csaba Halász wrote: On Mon, Jun 13, 2011 at 9:50 PM, ThorstenB bre...@gmail.com 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
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 Wednesday 15 June 2011 07:36:51 Csaba Halász wrote: On Mon, Jun 13, 2011 at 9:50 PM, ThorstenB bre...@gmail.com 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
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 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 bre...@gmail.com 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
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
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
On Wed, Jun 15, 2011 at 7:35 PM, Martin Spott martin.sp...@mgras.net 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
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
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
On Wed, Jun 15, 2011 at 10:57 PM, Martin Spott martin.sp...@mgras.net 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
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, 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
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
Csaba Halász wrote: On Wed, Jun 15, 2011 at 10:57 PM, Martin Spott martin.sp...@mgras.net 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
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
On 15.06.2011 22:57, Martin Spott wrote: By having a closer look at Thorsten's patches you'd realize that his primary work was to turn the standalone program with hard-coded host- and pathnames into a neatly configurable library. The interface between this lib and FlightGear is pretty slim, it doesn't add much overhead and you're free not to use it. Thanks Martin. Another thing to add here: what I actually did was dividing existing terrasync sources into two parts: the library which holds all the actual SVN code, and another part that parses command-line arguments, processes UDP messages and runs as a stand-alone utility. I actually tested the new library using the (remains) of terrasync(.exe) stand-alone utility - but decided not to push any changes to terrasync itself. Not now at least. And I'm pretty aware of the HLA approaches - we've discussed that for long at LinuxTag (surprise, Mathias was there). I'm absolutely in favour of splitting things up - Mathias and Martin know this from LT. Yet, I did not see any contradiction with integrating terrasync. I would like more subsystems being converted into separate libraries and being capable of running them outside FlightGear (which, I agree, is great for any advanced user - especially those with CAE-like setups), but still have the option to also run the same subsystems all inside a single FG (which does have advantages for other kinds of users). With a proper and flexible interface (HLA could be the solution here) both is possible. When we have that standard interface installed, we can use the new library with it (while the left-over bits of terrasync(.exe)'s command-line/UDP code might die and be replaced by some generic loader). On 15.06.2011 23:30, Vivian Meazza wrote: And less clever users, which is most of the people out there, won't. I include myself in that category, since I have failed to make it work so far. I sometimes wonder if we really expect the average user to poke around in preferences.xml? But then, we have FGRun that does most of that for us. There should be no need to edit anything in preferences.xml. You should be able to enter the directory in the GUI (yes, I know, no directory dialog). Or you could also provide it via a new command-line option (--terrasync-dir). And it's preserved across sessions. So you only need to provide/edit it once. I had responded to your email yesterday in private, hinting that you probably somehow managed an incomplete fgdata pull (which you later confirmed). Maybe something is still broken - maybe with my code or still on your system. Or maybe I forgot to push something. So, I am really sorry, Vivian, that you were still unable to make the system work for you - on day 2 (though it seems people only started trying to use it _today_). But this and other posts today show our general FG mailing list tendency: being negative. It's the almost natural response to any change. Oh crap! Doesn't work! Don't like it... I've spent _loads_ of time into FG in recent months. I have worked the bug tracker almost daily. I have fixed countless bugs other people have introduced - _some_ even hidden in absolutely crappy code (so much on the design issue). I have searched and fixed memory leaks and investigated performance issues. I've fixed loads of issues affecting systems that I personally never use. So, if anything wasn't working with my _own_ addition now - only in GIT for two days, remember - I think it should've been more than obvious that I'd be absolutely willing to explain/test/resolve things - and help anyone who was really interested. And to make it work as expected: to provide an easier solution in accessing scenery (read the forums, if you want to know how users do get along with existing terrasync). But that's not how FG works. It's normal that any slight malfunction is immediately criticized as hell. No attempts in being positive, trying to encourage / motivate other people in improving their work - and to keep them working on FG. When something isn't working, start complaining and being negative. Just look at this list's recent history. So, you're all hoping for a better FG. A large redesign, so we can make use of multi-core systems, can even distribute parts across multiple machines. Can separate the GUI. Get Nasal outside the main simulation loop. Well, so do I. But I'm becoming more and more convinced, that this indeed is _not_ going to happen. No, not because of that new library and such tendencies (while in fact that library is much better prepared to be driven by HLA or something similar than most other parts). No, we're very likely to not get any of this since we're absolutely unable to motivate - or at least keep people motivated on working on our project. That's a major issue we have. Everyone who spends time is welcomed by negative comments - and surprisingly many leave. And I'm sorry to say, after reading emails like
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 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 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
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
Excellent! On Mon, Jun 13, 2011 at 12:50 PM, ThorstenB bre...@gmail.com 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
