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 23.06.2011 19:16, Vivian Meazza wrote: > This works: > D:\New Git>svn info "C:/Program Files/FlightGear/terrasync/Models" > This does not work: > D:\New Git>svn 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
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 Git>svn 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 Git>svn 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 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
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
[Flightgear-devel] Property Tree - Diagram
Hello all, Which part of the property tree holds the value(node) if i enabled the following in the FGRUN Advanced->Network->proxy and is there a tree diagram image file of the property tree floating some where in the internet domain? Thank you all -- 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] JSBSim new atmosphere
> The way I understand this, the issues are to some degree separate (?).
>
> I believe (correct me if I'm wrong) that what Jon is largely talking about
> is the altitude extrapolation of atmosphere conditions, i.e. given that I
> specify pressure, temperature and dew point at sea level, how will these
> change as a function of altitude. Within some reasonable set of
> assumptions, you can compute these by solving physics equations.
>
> What the weather system does is specify these values *at sea level* as a
> function of (lat, lon) - the altitude interpolation is still done by the
> built-in Flightgear atmosphere model, and as far as I know it'd be no
> problem to use the JSBSim atmosphere for that purpose instead. As far as
> the properties in /environment/ are concerned (I assume they're used by
> the FDM...), one'd probably just switch from one function calculating
> the altitude dependence of pressure from the sea level value to a
different
> one.
> Cheers,
> * Thorsten
Yes, Thorsten understands what I am asking. :-)
In the new JSBSim standard atmosphere model - which is based on the
information and algorithms in the U.S. Standard Atmosphere 1976 ("USSA"
Document: NASA TM-X-74335) the atmospheric properties are "propagated"
upwards to 86 kilometers in altitude based on temperature and pressure
conditions at sea level or at altitude (in the case of temperature). If the
default standard pressure and temperature are assumed, what results is the
U.S. Standard Atmosphere. However, sea level temperature or pressure can be
specified (in one of several units), and then the entire set of key
atmospheric properties is recomputed for the entire altitude range.
Additionally, not only can a simple temperature bias at sea level be
specified, but an additional temperature gradient can be applied, allowing
one to alter the standard lapse rates. This latter feature is an
experimental one.
Another feature I'd like to add at some point is one where some "patchiness"
affects the atmospheric properties, so they are not 100% homogenous at an
altitude and over time - sort of like adding some noise. I'm looking at the
NASA Global Reference Atmosphere Model to gain some insight on how they do
it.
As part of this effort on the JSBSim side, the FGAtmosphere class has been
modified as a standard interface for other atmosphere models which may
follow.
So, currently in JSBSim as it exists in our cvs repository, the temperature,
pressure, density, viscosity, speed of sound, etc. are provided by the
JSBSim atmosphere model. No other sources are used internally for those
parameters, no matter what FlightGear does. The interface between FlightGear
and JSBSim does (or will, when it is finished) modify the sea level
temperature and pressure - although there is some facility for permitting
conditions to be specified at an elevation (or altitude), which JSBSim then
would "transform" into sea level conditions, and propagate properties for
the rest of the altitude profile algorithmically. What is possible, but
highly discouraged, is to permit FlightGear to specify a temperature and
pressure at every timestep. A sea level temperature and pressure should be
specified only at initialization or periodically as one moves geographically
to a new area where weather is changed. Perhaps changing sea level
conditions once every five or ten seconds would be often enough?
Another thing that the new JSBSim standard atmosphere model does is to allow
properties to be queried for a specified altitude, not just the altitude one
is at.
I guessed that on the FlightGear side there was a capability to express sea
level (or ground level) conditions, and that atmospheric properties were
determined from those. It would be good, however, to make sure that
FlightGear and JSBSim are using very similar models. One thing that JSBSim
does not ]yet] do is to model effects of water vapor in the air. According
to the USSA reference document, water vapor plays a relatively minor role in
atmospheric pressure and density calculations. The approach used in the
reference document is to slightly alter the temperature used in calculating
pressure and density, depending on the level of humidity present, IIRC. I'd
be interested to see your calculations for air pressure when humidity is
specified.
Jon
--
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
[Flightgear-devel] ISSUE 295: Re: Shaders: Issue 294 not accepted?
Arghh, yes, I am talking about issue #295 and not #294, sorry for that. -Yves Am 23.06.11 14:17, schrieb HB-GRAL: > Hi all > > For upcoming debugging weeks: Please note that issue #294 and #335 are > still valid here with OSX 10.6, ATI 5750, OSG2.9.7. I still get > > Warning: detected OpenGL error 'invalid operation' at after > RenderBin::draw(..) > > with every plane (i.e. 737-100) where reflect shaders are active. > > I don’t know how to get better debugging information with fgfs, and I > apologize, can someone give me a hint again how I can get "human > readable" error output instead of tousands of this lines above, filling > up my log, pointing to nowhere ? > > Now all what I can say is what my "shader builder" on OSX says for > reflect and reflect-bum-spec: > > --- > Validation Failed: Sampler error: > Samplers of different types use the same texture image unit. > - or - > A sampler's texture unit is out of range (greater than max allowed or > negative). > --- > > Another validation warning with reflect-bump-spec, but this needs only > some small shader clean up I think ;-) > > --- > Program link results: > WARNING: vertex shader writes varying 'Normal' which is not active. > --- > > > NONE of the other shaders have problems with passing an external shader > validation. Please accept the issue #294 for OSX/ATI now and assign it > to shader core developers if he/she is still around. (I will try to help > to fix it of course). > > btw. using 777-200 (see also issue #335) gives me: > > --- > FRAGMENT glCompileShader "" FAILED > FRAGMENT Shader "" infolog: > ERROR: 0:58: '>=' : wrong operand types no operation '>=' exists that > takes a left-hand operand of type 'uniform float' and a right operand of > type 'const int' (or there is no acceptable conversion) > > glLinkProgram "" FAILED > Program "" infolog: > ERROR: One or more attached shaders not successfully compiled > --- > > I will vote for removing all the shaders in aircrafts soon :-) > > Thanks, Yves > -- 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
[Flightgear-devel] Shaders: Issue 294 not accepted?
Hi all For upcoming debugging weeks: Please note that issue #294 and #335 are still valid here with OSX 10.6, ATI 5750, OSG2.9.7. I still get Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..) with every plane (i.e. 737-100) where reflect shaders are active. I don’t know how to get better debugging information with fgfs, and I apologize, can someone give me a hint again how I can get "human readable" error output instead of tousands of this lines above, filling up my log, pointing to nowhere ? Now all what I can say is what my "shader builder" on OSX says for reflect and reflect-bum-spec: --- Validation Failed: Sampler error: Samplers of different types use the same texture image unit. - or - A sampler's texture unit is out of range (greater than max allowed or negative). --- Another validation warning with reflect-bump-spec, but this needs only some small shader clean up I think ;-) --- Program link results: WARNING: vertex shader writes varying 'Normal' which is not active. --- NONE of the other shaders have problems with passing an external shader validation. Please accept the issue #294 for OSX/ATI now and assign it to shader core developers if he/she is still around. (I will try to help to fix it of course). btw. using 777-200 (see also issue #335) gives me: --- FRAGMENT glCompileShader "" FAILED FRAGMENT Shader "" infolog: ERROR: 0:58: '>=' : wrong operand types no operation '>=' exists that takes a left-hand operand of type 'uniform float' and a right operand of type 'const int' (or there is no acceptable conversion) glLinkProgram "" FAILED Program "" infolog: ERROR: One or more attached shaders not successfully compiled --- I will vote for removing all the shaders in aircrafts soon :-) Thanks, Yves -- 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" Sent: Thursday, June 23, 2011 8:44 AM To: "'FlightGear developers discussions'" Subject: Re: [Flightgear-devel] Heads up: scenery download /built-interrasync > Alan wrote > >> -- >> From: "Vivian Meazza" >> Sent: Wednesday, June 22, 2011 11:32 PM >> To: "'FlightGear developers discussions'" >> >> 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
Alan wrote > -- > From: "Vivian Meazza" > Sent: Wednesday, June 22, 2011 11:32 PM > To: "'FlightGear developers discussions'" > > 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" Sent: Wednesday, June 22, 2011 11:32 PM To: "'FlightGear developers discussions'" 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] JSBSim new atmosphere
> Well, FlighGear has its own atmosphere model that is also used by the > other subsystems (e.g. instruments, weather reports, visual system, AI > traffic and whatnot). So far there has been few reasons not use that > model also for the FDM. > > I think the FDM only needs to know the atmospheric properties "here > and now" while a whole simulation system such as FG (idealy) needs more > than that (not that we are there yet, but Thorsten R's work is > interesting > and promising). I'd like to see the wind socks reflect the condition at > their position rather than the conditions where my aircraft is > eventually. The way I understand this, the issues are to some degree separate (?). I believe (correct me if I'm wrong) that what Jon is largely talking about is the altitude extrapolation of atmosphere conditions, i.e. given that I specify pressure, temperature and dew point at sea level, how will these change as a function of altitude. Within some reasonable set of assumptions, you can compute these by solving physics equations. What the weather system does is specify these values *at sea level* as a function of (lat, lon) - the altitude interpolation is still done by the built-in Flightgear atmosphere model, and as far as I know it'd be no problem to use the JSBSim atmosphere for that purpose instead. As far as the properties in /environment/ are concerned (I assume they're used by the FDM...), one'd probably just switch from one function calculating the altitude dependence of pressure from the sea level value to a different one. What is explicitly modelled in the weather system is the altitude dependence of parameters such as visibility which are not the solution of a simple physics equation (you'd need to solve the whole weather system hydrodynamics to know where high-altitude haze layers form...). The temperature dependence of air is somewhere inbetween - there are some simple factors which make it cooler as you go up in altitude, but then airmasses form fronts, and the detailed pattern depends on how these fronts are arranged. I don't think we do this properly as of now, but it's probably not that terribly important. Recently, we also started to model light attenuation in the atmosphere - which is partly due to dust and haze, partly due to clouds - strictly speaking that's also part of the atmosphere model, but in all likelihood not something JSBSim does :-) I don't think an atmosphere model (in the above sense as altitude extrapolation of values specified at sea level) would usually include wind - you can't compute the windfield easily runtime by solving physics, so for all practical purposes it's a vector field which you impose externally. So I'm not quite sure there is a real problem, it just seems to me a semantic issue what parameters are all included in 'atmosphere model'. If you want a windsock which shows conditions at its positions by the way, then just give it some Nasal code which makes it dependent on the results of a function call and I'll supply a function that specifies the wind at that (lat, lon, alt). If you ask for it regularly, you can even drive it in gusty winds... Local Weather has all that info - you just need to ask it nicely - since writing to property nodes is rather slow, I tend to avoid it these days and store most info Nasal-internally. 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
