Re: [Flightgear-devel] Rembrandt performance
It could help you to understand why you are getting that poor performances with your pretty fast beast GTX 670M. Thanks, though I remain mystified. There are few differences I can spot: * you have tree density to 0.7 in the shots, I had it at 2.4 - since there's lots of trees in the scene (it's tropical forest), that would be expected to have an impact * you have cloud density set to 0.4 whereas I have set it to 1, and also in vaguely remember seeing a bit more clouds * you have dds textures used, I have used the regional set - my understanding was that this should affect texture loading times and available resolution, but not really runtime performance, but this needs to be checked - So I have 4 times the number of trees in the scene and 2-3 times the number of cloud sprites. I'm not completely sure how Rembrandt manages trees, but it could be that since they're semi-transparent they're like the clouds taken out of the deferred rendering approach. Multiple cloud sprites in a row are a significant drain on both vertex and fragment shaders as you may need hundreds of texture lookups - so the available performance for Rembrandt-specific tasks isn't quite the same. My gut feeling is that this can't account for a factor 4 in framerate though, especially since there is still the pixel number working the opposite way this time - I will have to test this. In addition there's the question of having two GPUs. I wonder if they're both utilized for the job - if so, maybe one needs such a setup to get above 30 fps with shadows? It would be helpful if a few other Rembrandt users could give some indication of what framerates they usually get and what the main framerate killers are. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] suggest: divide getstart each language
Hi All,
I suggest that we divide getstart each language, reason: More easier
to use Computer-assisted translation tool, e.g. OmegaT
--
now:
getstart/source/*.tex
free.tex
[code]
\iflanguage{english}{
[/code]
--
Kiyohito ,AOKI
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] suggest: divide getstart each language
Hi All,
Sorry, forget before my mail. That's mistake.
I suggest that we divide getstart each language, reason: More easier
to use Computer-assisted translation tool, e.g. OmegaT
--
My suggestion detailed are below. (example from preface.tex)
now:
getstart/source/*.tex
[code]
\iflanguage{english}{Did you ever want to fly a plane yourself,
but lacked the money or ability to do so?...}{}
\iflanguage{french}{N'avez-vous jamais voulu piloter un avion
par vous-m\^{e}me, mais manqu\'{e} d'argent ou de comp\'{e}tences pour
le faire ?...}{}
[/code]
future:
getstart/source/en/*.tex
[code]
Did you ever want to fly a plane yourself, but lacked the money
or ability to do so?...
[/code]
getstart/source/fr/*.tex
[code]
N'avez-vous jamais voulu piloter un avion par vous-m\^{e}me,
mais manqu\'{e} d'argent ou de comp\'{e}tences pour le faire ?...
[/code]
--
Kiyohito, AOKI
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rembrandt performance
* you have tree density to 0.7 in the shots, I had it at 2.4 - since there's lots of trees in the scene (it's tropical forest), that would be expected to have an impact Yes the vegetation has a huge impact, i experienced from 0;7 to 2.5 the fps decrease is 40 %, with or without Rembrandt. The clouds density is right now less sensitive, only the visibility range as an impact ( however, because of the eye candy we are using the maximum ). Two GPU embedded should not be an issue, though our system manager did not noticed any significative improvement with the SLI architecture with FG , but it cant get some comparison since, with it, the display is supposed to be divided (AFS or SFR). It would be interesting to know how these two GPU are working together. Ahmad On 17 June 2013 08:20, Renk Thorsten thorsten.i.r...@jyu.fi wrote: It could help you to understand why you are getting that poor performances with your pretty fast beast GTX 670M. Thanks, though I remain mystified. There are few differences I can spot: * you have tree density to 0.7 in the shots, I had it at 2.4 - since there's lots of trees in the scene (it's tropical forest), that would be expected to have an impact * you have cloud density set to 0.4 whereas I have set it to 1, and also in vaguely remember seeing a bit more clouds * you have dds textures used, I have used the regional set - my understanding was that this should affect texture loading times and available resolution, but not really runtime performance, but this needs to be checked - So I have 4 times the number of trees in the scene and 2-3 times the number of cloud sprites. I'm not completely sure how Rembrandt manages trees, but it could be that since they're semi-transparent they're like the clouds taken out of the deferred rendering approach. Multiple cloud sprites in a row are a significant drain on both vertex and fragment shaders as you may need hundreds of texture lookups - so the available performance for Rembrandt-specific tasks isn't quite the same. My gut feeling is that this can't account for a factor 4 in framerate though, especially since there is still the pixel number working the opposite way this time - I will have to test this. In addition there's the question of having two GPUs. I wonder if they're both utilized for the job - if so, maybe one needs such a setup to get above 30 fps with shadows? It would be helpful if a few other Rembrandt users could give some indication of what framerates they usually get and what the main framerate killers are. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
Hello, Autopilot with Route manager is Longer broken, it is missing /autopilot/settings/gps-driving-true-heading triggered to true and the right /true-heading-deg which goes with it. Since the feature has not been removed from the GUI, i guess it had been broken elsewhere . Your update the GUI GPS box related is right. Thank Ahmad On 16 June 2013 23:23, James Turner zakal...@mac.com wrote: On 16 Jun 2013, at 15:46, grtuxhangar team hohora...@gmail.com wrote: Both same place , same computer.. I've just pushed a fix to FlightGear, which fixes part of this for the Cub. Please test and let me know if things are improved! Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] suggest: divide getstart each language
HI Kiyohito,
Thanks for your interest in the manual.
We made the decision to keep the manual as a single set of source
files with blocks for each language so that the different translations
staying in sync and to make it easy for translators to update a single
section at a time.
Otherwise, it's too easy for the Finnish translation to be out of date
relative to the English version when the latter is updated with the
latest menus.
We didn't consider machine-assisted translation at the time, though
OmegaT looks like a very useful tool.
However, if someone is motivated enough to provide a complete
translation of existing manual in a given language, I'm sure we can
find someone motivated enough to convert it to the existing format if
required.
-Stuart
On Mon, Jun 17, 2013 at 10:38 AM, K.Aoki
athlon64x2.windsor.6000p...@gmail.com wrote:
Hi All,
Sorry, forget before my mail. That's mistake.
I suggest that we divide getstart each language, reason: More easier
to use Computer-assisted translation tool, e.g. OmegaT
--
My suggestion detailed are below. (example from preface.tex)
now:
getstart/source/*.tex
[code]
\iflanguage{english}{Did you ever want to fly a plane yourself,
but lacked the money or ability to do so?...}{}
\iflanguage{french}{N'avez-vous jamais voulu piloter un avion
par vous-m\^{e}me, mais manqu\'{e} d'argent ou de comp\'{e}tences pour
le faire ?...}{}
[/code]
future:
getstart/source/en/*.tex
[code]
Did you ever want to fly a plane yourself, but lacked the money
or ability to do so?...
[/code]
getstart/source/fr/*.tex
[code]
N'avez-vous jamais voulu piloter un avion par vous-m\^{e}me,
mais manqu\'{e} d'argent ou de comp\'{e}tences pour le faire ?...
[/code]
--
Kiyohito, AOKI
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
though not sure
gps.cxx line 774
if (!_config.driveAutopilot() || !_defaultGPSMode) {
_apDrivingFlag-setBoolValue(false);
isn't it that strange ?
_apDrivingFlag is ever set to false
On 17 June 2013 14:22, grtuxhangar team hohora...@gmail.com wrote:
Hello,
Autopilot with Route manager is Longer broken, it is missing
/autopilot/settings/gps-driving-true-heading triggered to true and the
right /true-heading-deg which goes with it.
Since the feature has not been removed from the GUI, i guess it had been
broken elsewhere .
Your update the GUI GPS box related is right.
Thank
Ahmad
On 16 June 2013 23:23, James Turner zakal...@mac.com wrote:
On 16 Jun 2013, at 15:46, grtuxhangar team hohora...@gmail.com wrote:
Both same place , same computer..
I've just pushed a fix to FlightGear, which fixes part of this for the
Cub. Please test and let me know if things are improved!
Regards,
James
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
On 17 Jun 2013, at 14:41, grtuxhangar team hohora...@gmail.com wrote:
though not sure
gps.cxx line 774
if (!_config.driveAutopilot() || !_defaultGPSMode) {
_apDrivingFlag-setBoolValue(false);
isn't it that strange ?
_apDrivingFlag is ever set to false
Yes, the problem is I assumed aircraft with an explicit GPS instrument are
using a fully configured setup, but in fact many (such as yours) are listing an
explicit GPS in instrumentation.xml, but relying on the default configuration.
These problems are because long ago it was decided it would be a good idea to
have the route-manager, GPS AP work in aircraft which never had such things
in real-life (Spitfires, Cubs…) , so we have to (in C++) decide if the user is
asking for a simulated GPS (which should obey electrical power, and often needs
manual synchronisation of the GPS course - CDI course, and maybe no AP at all
all), or if they are asking for the internal features to 'just work'
regardless.
Anyway, for now the fix is just to go back to the old situation, where we
assume the user wants the GPS to drive the AP all the time.
Longer term, I think I will contemplate a more radical renaming to fix the
issue, where explicit simulated GPSs such as the Garmins and so on use a
different instrument name. ('real-gps' or something) Then I could assume any
aircraft requesting a 'gps' instrument is legacy and wants the old behaviour,
but remove all the awkward defaults for people who really want full simulation.
Regards,
James--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
Anyway, for now the fix is just to go back to the old situation, where we
assume the user wants the GPS to |drive the AP all the time
If you refer to your last fix (yesterday) , it is not sufficient,
since like said the /autopilot/settings/gps-driving-true-heading property
is not set to true.
Thank
Ahmad
On 17 June 2013 15:50, James Turner zakal...@mac.com wrote:
On 17 Jun 2013, at 14:41, grtuxhangar team hohora...@gmail.com wrote:
though not sure
gps.cxx line 774
if (!_config.driveAutopilot() || !_defaultGPSMode) {
_apDrivingFlag-setBoolValue(false);
isn't it that strange ?
_apDrivingFlag is ever set to false
Yes, the problem is I assumed aircraft with an explicit GPS instrument are
using a fully configured setup, but in fact many (such as yours) are
listing an explicit GPS in instrumentation.xml, but relying on the default
configuration.
These problems are because long ago it was decided it would be a good idea
to have the route-manager, GPS AP work in aircraft which never had such
things in real-life (Spitfires, Cubs…) , so we have to (in C++) decide if
the user is asking for a simulated GPS (which should obey electrical power,
and often needs manual synchronisation of the GPS course - CDI course, and
maybe no AP at all all), or if they are asking for the internal features to
'just work' regardless.
Anyway, for now the fix is just to go back to the old situation, where we
assume the user wants the GPS to drive the AP all the time.
Longer term, I think I will contemplate a more radical renaming to fix the
issue, where explicit simulated GPSs such as the Garmins and so on use a
different instrument name. ('real-gps' or something) Then I could assume
any aircraft requesting a 'gps' instrument is legacy and wants the old
behaviour, but remove all the awkward defaults for people who really want
full simulation.
Regards,
James
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
On 17 Jun 2013, at 15:41, grtuxhangar team hohora...@gmail.com wrote: If you refer to your last fix (yesterday) , it is not sufficient, since like said the /autopilot/settings/gps-driving-true-heading property is not set to true. No, I need to make further tweak this evening, don't worry :) Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Turbulence should affect YaSim and JSBSim the same way
On Sun, 16 Jun 2013 19:09:40 -0600, Jon wrote in message 005a01ce6af7$58b69470$0a23bd50$@net: ..my oversimplification: http://wiki.flightgear.org/YASim guesses how it flies from how it looks, while http://wiki.flightgear.org/JSBSim knows how it flies and tries to show us how that looks, e.g. stalls are assymetrical in YASim but (still?) symmetrical in JSBSim. ..if I guess FG progress correctly, we need to model downwash correctly, and if you want assymetrical stalls in JSBSim, you need 2 halved JSBSim models per plane so each wing etc surface calculation is run independently. I have not tried modeling a piston aircraft in quite some time. [Hal Engel's P-51D does stall in either direction, does it not?] ..I haven't tried the P-51Ds much, but yeah, my stalls went both ways on both FDMs AFAIR, but here I'm going on what I remember from when YASim was introduced here, and whatever I've picked up on how they differ, and on my WAG these things have changed since I last checked the P51Ds 3 or 4 years back. My big problem was always too low framerates on T/O. ;o) In any case, it should be possible to model aerodynamic effects from the propeller in the XML model file for any JSBSim aircraft (in the aerodynamics section) - effects that would affect stalling, I suspect. It's not that JSBSim doesn't support asymmetric stalls - JSBSim doesn't *not* support it. ..my (flawed?) understanding of JSBSim is both wing halves sees the same wind because they are calculated together as one wing, where YASim cuts up the wing and calculates the wing sections independently and adds them up together, AFAIRI from the discussion way back here. But, I'm not sure anyone has crafted the aerodynamic/propulsion interactions that would effect that. This isn't necessarily the fault of users, either. We (JSBSim development community) would ideally make available more examples and documentation. JB -- ..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. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] reminder: entering feature freeze now
Hi everybody, for most of us, it's June, 17th which marks the day for the feature freeze period, lasting until July, 17th. Everybody is invited to walk through the lessons learned section of our release plan at http://wiki.flightgear.org/Release_plan the bugtracker at http://code.google.com/p/flightgear-bugs/ and contribute to the changelog for the next release at http://wiki.flightgear.org/Next_Changelog As of today, the set of new features should be complete. The usual question at this point is: What version number will we give to the new release? Are we ready for a 3.0 or is it 2.12? Regards, Torsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraSync libSVN replacement testing
Does this affect the code freeze? -Original Message- From: Alan Teeder Sent: Tuesday, June 11, 2013 8:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] TerraSync libSVN replacement testing James As requested (windows 7, MSVC10 (32bit build): (Sorry) Alan 3 terrasync.cxx 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(58): error C2059: syntax error : 'constant' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(65): error C2143: syntax error : missing ';' before '}' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(65): error C2238: unexpected token(s) preceding ';' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C2146: syntax error : missing ';' before identifier 'failure' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C2270: 'failure' : modifiers not allowed on nonmember functions 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(68): error C2059: syntax error : 'private' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(69): error C2270: 'isBare' : modifiers not allowed on nonmember functions 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2059: syntax error : '}' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2143: syntax error : missing ';' before '}' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2059: syntax error : '}' 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(90): warning C4067: unexpected tokens following preprocessor directive - expected a newline 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(90): warning C4067: unexpected tokens following preprocessor directive - expected a newline 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): error C2088: '[' : illegal for class 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): error C2088: '[' : illegal for class 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): fatal error C1903: unable to recover from previous error(s); stopping compilation 3 Generating Code... -Original Message- From: James Turner Sent: Tuesday, June 11, 2013 4:17 PM To: FlightGear developers discussions Subject: [Flightgear-devel] TerraSync libSVN replacement testing Hi, I've pushed some code to Git, which will ultimately replace our use of libSvn, and hence simplify build and deployment, especially on Mac and Windows. This has an immediate benefit for end-users too: TerraSync will use pretty much half the disk space it currently does, since unlike a real SVN client, we don't need to keep two copies of each file locally. In the longer term, there are many other improvements I will make - to reduce the number of network round-trips to check directories are in sync, to improve the interaction with the main thread so the splash screen waits for terrasync to update a location before finalising position, and others. These things will happen *after* 2.12, and once the code is tested everywhere. First, I need some help; for people to rebuild simgear with -DSG_SVN_CLIENT=1, and mv / erase their TerraSync dir. Then simply run FGFS as normal, as if you were starting on a new machine / account with no previous use of TerraSync. (Remember that TerraSync initially syncs the large Models and Airports dirs, which takes some time - be patient. Also expect some nav-cache rebuilds since the nav-cache will see the paths / stat-times change. This is nothing to do with the revised code, simply what happens if you change your TerraSync dir) If the testing is mostly positive, I will consider making the option default to ON for 2.12, but if people report problems (which cannot be easily fixed!), I will be cautious and leave it OFF by default for 2.12. Soon after 2.12 branches, 'next' will be switched to using the new code exclusively. (BTW, the option to use rsync or external, command-line svnclient still exists, and will be retained - though I am curious if anyone still uses those options!) James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] TerraSync libSVN replacement testing
Alan Sent: 17 June 2013 20:06 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] TerraSync libSVN replacement testing Does this affect the code freeze? -Original Message- From: Alan Teeder Sent: Tuesday, June 11, 2013 8:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] TerraSync libSVN replacement testing James As requested (windows 7, MSVC10 (32bit build): (Sorry) Alan 3 terrasync.cxx 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(58): error C2059: syntax error : 'constant' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(65): error C2143: syntax error : missing ';' before '}' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(65): error C2238: unexpected token(s) preceding ';' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C2146: syntax error : missing ';' before identifier 'failure' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C2270: 'failure' : modifiers not allowed on nonmember functions 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(68): error C2059: syntax error : 'private' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(69): error C2270: 'isBare' : modifiers not allowed on nonmember functions 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2059: syntax error : '}' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2143: syntax error : missing ';' before '}' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2059: syntax error : '}' 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(90): warning C4067: unexpected tokens following preprocessor directive - expected a newline 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(90): warning C4067: unexpected tokens following preprocessor directive - expected a newline 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): error C2088: '[' : illegal for class 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): error C2088: '[' : illegal for class 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): fatal 3error C1903: unable to recover from previous error(s); stopping compilation 3 Generating Code... -Original Message- From: James Turner Sent: Tuesday, June 11, 2013 4:17 PM To: FlightGear developers discussions Subject: [Flightgear-devel] TerraSync libSVN replacement testing Hi, I've pushed some code to Git, which will ultimately replace our use of libSvn, and hence simplify build and deployment, especially on Mac and Windows. This has an immediate benefit for end-users too: TerraSync will use pretty much half the disk space it currently does, since unlike a real SVN client, we don't need to keep two copies of each file locally. In the longer term, there are many other improvements I will make - to reduce the number of network round-trips to check directories are in sync, to improve the interaction with the main thread so the splash screen waits for terrasync to update a location before finalising position, and others. These things will happen *after* 2.12, and once the code is tested everywhere. First, I need some help; for people to rebuild simgear with - DSG_SVN_CLIENT=1, and mv / erase their TerraSync dir. Then simply run FGFS as normal, as if you were starting on a new machine / account with no previous use of TerraSync. (Remember that TerraSync initially syncs the large Models and Airports dirs, which takes some time - be patient. Also expect some nav-cache rebuilds since the nav-cache will see the paths / stat-times change. This is nothing to do with the revised code, simply what happens if you change your TerraSync dir) If the testing is mostly positive, I will consider making the option default to ON for 2.12, but if people report problems (which cannot be easily fixed!), I will be cautious and leave it OFF by default for 2.12. Soon after 2.12 branches, 'next' will be switched to using the new code exclusively. (BTW, the option to use rsync or external, command-line svnclient still exists, and will be retained - though I am curious if anyone still uses those options!) Haven't managed to get it to work for Win 7 64 bit either - still seems to want LIBSVN to build. Seems to be a cmake issue, but I'm not confident that I know how to fix this one. Vivian -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list
Re: [Flightgear-devel] TerraSync libSVN replacement testing
On 17 Jun 2013, at 21:25, Vivian Meazza vivian.mea...@lineone.net wrote: Haven't managed to get it to work for Win 7 64 bit either - still seems to want LIBSVN to build. Seems to be a cmake issue, but I'm not confident that I know how to fix this one. That's because I didn't yet remove the libsvn checks - that would be risky, this close to the freeze. It's strictly a new, optional feature until after 2.12 is branched. Alan, did you have any luck with the compiler errors? it builds on the Windows build slaves on Jenkins I believe. Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraSync libSVN replacement testing
Sorry James, I just reported ,and then left it. I can give it a go, but my C++ debugging is somewhat hit and miss. Alan From: James Turner Sent: Monday, June 17, 2013 9:38 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] TerraSync libSVN replacement testing On 17 Jun 2013, at 21:25, Vivian Meazza vivian.mea...@lineone.net wrote: Haven't managed to get it to work for Win 7 64 bit either - still seems to want LIBSVN to build. Seems to be a cmake issue, but I'm not confident that I know how to fix this one. That's because I didn't yet remove the libsvn checks - that would be risky, this close to the freeze. It's strictly a new, optional feature until after 2.12 is branched. Alan, did you have any luck with the compiler errors? it builds on the Windows build slaves on Jenkins I believe. Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
Once the version has been decided, will the branches be created? Saikrishna Arcot On Mon 17 Jun 2013 01:59:47 PM CDT, Torsten Dreyer wrote: Hi everybody, for most of us, it's June, 17th which marks the day for the feature freeze period, lasting until July, 17th. Everybody is invited to walk through the lessons learned section of our release plan at http://wiki.flightgear.org/Release_plan the bugtracker at http://code.google.com/p/flightgear-bugs/ and contribute to the changelog for the next release at http://wiki.flightgear.org/Next_Changelog As of today, the set of new features should be complete. The usual question at this point is: What version number will we give to the new release? Are we ready for a 3.0 or is it 2.12? Regards, Torsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraSync libSVN replacement testing
James I found this, in terrasync.cxx, line 91, but the compilation is still failing #if (defined(HAVE_SVN_CLIENT_H) or defined(SG_SVN_CLIENT)) should be ? #if (defined(HAVE_SVN_CLIENT_H) || defined(SG_SVN_CLIENT)) Alan From: Alan Teeder Sent: Monday, June 17, 2013 10:00 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] TerraSync libSVN replacement testing Sorry James, I just reported ,and then left it. I can give it a go, but my C++ debugging is somewhat hit and miss. Alan From: James Turner Sent: Monday, June 17, 2013 9:38 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] TerraSync libSVN replacement testing On 17 Jun 2013, at 21:25, Vivian Meazza vivian.mea...@lineone.net wrote: Haven't managed to get it to work for Win 7 64 bit either - still seems to want LIBSVN to build. Seems to be a cmake issue, but I'm not confident that I know how to fix this one. That's because I didn't yet remove the libsvn checks - that would be risky, this close to the freeze. It's strictly a new, optional feature until after 2.12 is branched. Alan, did you have any luck with the compiler errors? it builds on the Windows build slaves on Jenkins I believe. Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
Just tested with the Cub, working perfectly. Thank a lot Ahmad On 17 June 2013 16:42, James Turner zakal...@mac.com wrote: On 17 Jun 2013, at 15:41, grtuxhangar team hohora...@gmail.com wrote: If you refer to your last fix (yesterday) , it is not sufficient, since like said the /autopilot/settings/gps-driving-true-heading property is not set to true. No, I need to make further tweak this evening, don't worry :) Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
