Re: [Flightgear-devel] reminder: entering feature freeze now
> What version number will we give to the new > release? Are we ready for a 3.0 or is it 2.12? Looking through my list of goals for the last coding period: > * Get a high-quality model shader running under Atmospheric Light Scattering This is now available, working for random buildings and for several aircraft. A reminder to aircraft creators using the ubershader - normal mapping requires to declare tangent, normal and binormal generation airplane-side. These need to be also declared as vertex attributes in a numbered technique - in order for this to work, the technique n=4 matching the model ubershader effect in model-combined.eff for ALS has to be added, otherwise normal maps do not work and the model receives incorrect lighting. > * Implement a scheme for generating autumn colors procedurally The scheme exists and generates autumn colors in central Europe. Since the majority of feedback for this was rather skeptical, I have not pursued the idea much further or extended it to tree autumn coloring, but Stuart has implemented his tree work in a nice way that trees shed all leaves in late autumn, so it's not as good as it could be, but reasonably plausible. At least I like changing the colors a bit. Since autumn coloring doesn't work correctly everywhere in the world (I've mainly adjusted Europe and the North Atlantic Islands), I would regard it as experimental. >* make clouds render faster Stuart has done the main work on this one with a LOD scheme dropping sprites beyond some distance. Since this mutilated faint clouds which have just 1-2 sprites to begin with, I recently pushed a way that these clouds are not treated by the LOD system at all. I'd say we need feedback from users playing with the LOD distance if it improves framerates while keeping the visuals or not. We now have overall cloud density, draw distance and the LOD distance to configure the framerate impact of 3D clouds - is this enough? In what form should this best be exposed to the user? What are reasonable defaults? >* Improve cloud appearance from high altitude This is mostly done - I've introduced three quite sophisticated cloudlet placement scheme, and it does miracles from high altitude. There are still the rather blocky 8/8 cover scenarios remaining when clouds tend to cover the whole square tile - I wanted to do something to the edges, but haven't gotten around to doing so. Not sure if this qualifies as a bugfix or a novel feature, but I think it's harmless. >* The 'ultra' terrain shader This is done - at highest landmass and transition slider setting, the terrain shader renders details to a quality that you can park your helicopter in the scene and have a nice ground resolution (the smallest details are cm-sized, and they move with the wind). From my side, this would be the main selling point for a 3.0 release. The water shader also has received upgrades with color and reflectivty variations of the water and a trick to generate surf at steep coasts. Also drift ice and be procedurally drawn on the water. In arctic regions, we have drifting icebergs by default now. > * Regional texturing Since the last release, I've added Indonesia, Madagascar, North Atlantic Islands (Greenland, Faroe, Shetlands,...) and Middle East and Vivian added UK definitions. Combined with Hawaii, Iceland, Caribbean and tropical South America which we've had previously, this is already a substantial variation to illustrate how FG can look like. Especially Hawaii can serve very well as a showcase scenery now. >* Atmospheric light scattering and Rembrandt There hasn't been a volunteer to help me look into this from the Rembrandt side, and so according to the plan there has been no development. Based on my current test results, my computer doesn't seem to be able to get Rembrandt fast enough for this to make any sense, although I don't understand this finding. While things can always be better, from my side that's a clear vote for 3.0. With the hires terrain shader and wind effects on terrain and vegetation, combined with the pixel post-processing effects, we can offer much higher resolution visuals on the terrain than before (and I understand with the autum color effect or drift ice some genuine novel effects which are in no other flightsim). * 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
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 wrote: > > On 17 Jun 2013, at 15:41, grtuxhangar team 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
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 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] 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
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 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] TerraSync libSVN replacement testing
On 17 Jun 2013, at 21:25, Vivian Meazza 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
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 > 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(58): error C2059: > syntax error : 'constant' > 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(65): error C2143: > syntax error : missing ';' before '}' > 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(65): error C2238: > unexpected token(s) preceding ';' > 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C2146: > syntax error : missing ';' before identifier 'failure' > 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C4430: > missing type specifier - int assumed. Note: C++ does not support default-int > 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C2270: > 'failure' : modifiers not allowed on nonmember functions > 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C4430: > missing type specifier - int assumed. Note: C++ does not support default-int > 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(68): error C2059: > syntax error : 'private' > 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(69): error C2270: > 'isBare' : modifiers not allowed on nonmember functions > 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2059: > syntax error : '}' > 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2143: > syntax error : missing ';' before '}' > 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2059: > syntax error : '}' > 3>C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(90): warning > C4067: unexpected tokens following preprocessor directive - expected a > newline > 3>C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(90): warning > C4067: unexpected tokens following preprocessor directive - expected a > newline > 3>C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): error > C2088: > '[' : illegal for class > 3>C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): error > C2088: > '[' : illegal for class > 3>C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): fatal > 3>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!) > 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-de
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 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(58): error C2059: syntax error : 'constant' 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(65): error C2143: syntax error : missing ';' before '}' 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(65): error C2238: unexpected token(s) preceding ';' 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C2146: syntax error : missing ';' before identifier 'failure' 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C2270: 'failure' : modifiers not allowed on nonmember functions 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(68): error C2059: syntax error : 'private' 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(69): error C2270: 'isBare' : modifiers not allowed on nonmember functions 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2059: syntax error : '}' 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2143: syntax error : missing ';' before '}' 3>C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2059: syntax error : '}' 3>C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(90): warning C4067: unexpected tokens following preprocessor directive - expected a newline 3>C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(90): warning C4067: unexpected tokens following preprocessor directive - expected a newline 3>C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): error C2088: '[' : illegal for class 3>C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): error C2088: '[' : illegal for class 3>C:\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 https://lists.sourceforge.net/lists/l
[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] 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 > 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
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
On 17 Jun 2013, at 15:41, grtuxhangar team 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] 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 wrote:
>
> On 17 Jun 2013, at 14:41, grtuxhangar team 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 14:41, grtuxhangar team 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 ?
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 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 wrote:
>
>>
>> On 16 Jun 2013, at 15:46, grtuxhangar team 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
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 ?
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 wrote: > > On 16 Jun 2013, at 15:46, grtuxhangar team 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] 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 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
[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
[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
