Re: [Flightgear-devel] the garden of forking xml
On 12/26/2008 08:24 PM, Ron Jensen wrote: IMHO we would be way ahead of the game if DP's upgrades had been incorporated in the library copy in Aircraft/Instruments-3d/, rather than being confined to a private pa24-only copy. Sometimes it pays to put all your eggs in one basket, and then do a really good job of looking after that basket. In theory its a good idea, in practice it has not worked as well. The Instruments-3d folder is a morgue, its impossible to make changes to the instruments there without coordinating the change with any and every aircraft developer who might have used the instrument, and the panel lighting standards used in Instruments-3d aren't the best choices. Well, to me that sounds like the result of not-too-wise coding and not-too-wise project management in the past. That does not convince me that things cannot be done better in the future. And I have evidence to support what I am saying. Specifically, just now I modified the c172p to use the same ADF as the pa24-150. 1) That immediately made the c172p in some ways better and in no ways worse. In particular, it fixed multiple bugs having to do with the on/off switch and/or master switch off. 2) I then went over to the pa24-250 and did some minor clean-ups of button and hotspot positions. And guess what? The c172p automagically got better also. It was not more debugging to make the c172p get better in phase (2); it was _less_ debugging. Why should we have to go looking for the same bugs over and over again? The patch is at: http://www.av8n.com/fly/fgfs/adf.diff The next step is to teach the c182 and c182rg to use the same ADF. That would fix about ten more bugs at low cost. In the Real World, you can replace the King radio in one aircraft with the corresponding radio from another aircraft, as easy as π. If we can't come up with Sim World radios that are comparably compatible from airplane to airplane, I'd be astonished and very disappointed. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 1.9.0 feedback
James Turner wrote: I'm noticing quite a few people on the forums with difficulty running 1.9.0 - either long delays on startup, hangs while loading scenery, crashes or rendering issues. Some of these are certainly driver issues, especially with ATI and the dreaded Intel chipsets. And of course people who're having problems are the most vocal on forums :) In fact, sadly it seems pretty difficult to find a positive comment about 1.9 :( Unfortunately, it appears that nowadays pretty much every FG developer runs NVidia, and often Linux, so we're simply not using the same platform as a lot of our users. I think it's something we need to bear in mind for the next release. We'll need to put more effort to get external testing of RCs on Windows/ATI. It does seem as if the message that 1.9.0 is a release *leading towards* 2.0 has not been communicated very clearly outside this list, though - I'm not sure if there's any way that could be achieved? We need people to run the code to get feedback, obviously, but some people seem to think that 1.0 has been 'replaced', and while that's sort of true, I figured both would remain available in parallel until the 2.0 timeframe. Except that the aircraft downloads etc. on the flightgear website are now only 1.9... Given that the only announcement for 1.9 is a single line on the website, this isn't surprising. As far as I am aware, we haven't really announced 1.9 either through the -user mailing list, or the Forum. Durk - do we have a change-log we can advertize yet? -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 1.9.0 feedback
Hi, On Saturday 27 December 2008 10:11:46 Stuart Buchanan wrote: I think it's something we need to bear in mind for the next release. We'll need to put more effort to get external testing of RCs on Windows/ATI. Yes, I agree, but the problem is how to do that. For this release, we've had two release candidates, for both of which we've had full fledged windows packages, and -as far as I can tell- we've received no comments regarding the problems I'm reading reports about in the forums now. Unfortunately, it usually happens this way. It would be great if we could manage to get some more user feedback on the release candidates. Given that the only announcement for 1.9 is a single line on the website, this isn't surprising. As far as I am aware, we haven't really announced 1.9 either through the -user mailing list, or the Forum. Durk - do we have a change-log we can advertize yet? It seems to me that the release procedure isn't finished yet. I haven't seen an announcement on flightgear-announce, and the gallery is still pointing to the 1.0.0 one. IIRC, Curt used to sent the announce mails, but I could be wrong here. If so, I'll do that later. In the mean time, here is the changelog. Cheers, Durk FlightGear 1.9.0 FlightGear 1.9.0 represents a fundamental code rearrangement, incorporating over two years of development. After finishing the 1.0.0 release in December 2007, the FlightGear development team has directed their full attention to finishing the code overhaul that had already started in October 2006. The current 1.9.0 version of FlightGear is built upon the critically acclaimed OpenSceneGraph library, thereby widely expanding FlightGear's graphical capabilities. To make use of FlightGear's rich feature set, OpenSceneGraph 2.7.3 is minimally required (OpenSceneGraph 2.7.8 is recommended to avoid rendering bugs). The switch to OpenSceneGraph marks an important milestone for FlightGear, as it allows us to make full use of the advanced rendering options already available in OpenSceneGraph, such as stereographic view modes on screen statistics, easy definition of cameras for multiscreen systems, onscreen statistics, native OpenSceneGraph 3D model loaders and much more. While the most dramatic changes to FlightGear have been taking place under the hood, the latest version does offer many new exciting features not found in any previous version. Some highlighted new features include: Major new developments and features: - Major overhaul of the graphics code. FlightGear 1.9.0 makes use of the OpenSceneGraph library - Easy setup of multidisplay systems using multiple OpenSceneGraph Cameras driven by one single instance of FlightGear. - Multithreaded 3D model loader leads to much smoother performance - New particle system based precipitation code - configurable XML particle animations for smoke, spray, fire, etc - New dynamically configurable 3D Clouds. - pick animations, which allow for better clickable instrument panels - multiplayer specific on-screen menu - AI code can generate wingmen - At selected airports, it is now possible to start at a predefined parking position, as an alternative to starting at the runway. - Support for Lighter than air vehicles - Shader based tree rendering. This new feature allows For much denser tree density without any frame rate loss. - Support for jpg and png textures - A new multikey command mode, where multiple key strokes can be combined to form a command. - Detailed buildings at various airports and major cities around the world - Scenery can be kept up-to-date by downloading it from an SVN repository using TerraSync - Over 200 Aircraft are now available for separate download. Code Improvements: - Improved Flight Dynamics - Several Improvements to animations - Improved behavior of Taxiing AI Aircraft. - Miscellaneous GUI improvements - Major improvements to FlightGear's route/waypoint manager code. - Improved runway management - Improved encapsulation of Navaids - Improved nasal scripting security - Improved behavior of VOR radios when close to their maximum range. - Configurable Heads up displays - Improved support of GPS instruments - Easier definition of AI traffic patterns - Improved accuracy of coastlines -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 1.9.0 feedback
On 27 Dec 2008, at 09:39, Durk Talsma wrote: On Saturday 27 December 2008 10:11:46 Stuart Buchanan wrote: I think it's something we need to bear in mind for the next release. We'll need to put more effort to get external testing of RCs on Windows/ ATI. Yes, I agree, but the problem is how to do that. For this release, we've had two release candidates, for both of which we've had full fledged windows packages, and -as far as I can tell- we've received no comments regarding the problems I'm reading reports about in the forums now. Unfortunately, it usually happens this way. It would be great if we could manage to get some more user feedback on the release candidates. Right - realistically, in the real world, people don't run -RCs, they wait until they see a release announcement, then test and complain. That just seems to be the way of software development :) I've got a Radeon X1600 in my MacBook Pro, and don't see these issues, but I guess the OS-X ATI driver stack is quite different from the Windows stack. It'd be lovely to know if there are Windows ATI users who *can* run 1.9.0 without problems. James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/math SGGeodesy.cxx, 1.8, 1.9
James Turner wrote: On 27 Dec 2008, at 08:16, Tim Moore wrote: Modified Files: SGGeodesy.cxx Log Message: Fix include path snip *** SGGeodesy.cxx26 Dec 2008 12:08:28 - 1.8 --- SGGeodesy.cxx27 Dec 2008 08:16:03 - 1.9 *** *** 22,26 #include cmath ! #include structure/exception.hxx #include SGMath.hxx --- 22,26 #include cmath ! #include simgear/structure/exception.hxx #include SGMath.hxx This is interesting - since we're in an implementation file, not a public header, I regard my version as a 'better' choice than using a system include, with the simgear prefix. Are you changing this for the sake of style, consistency or correctness? (Or maybe all three :) Correctness, in the sense that I can't compile SimGear without this change. Also consistency, since in SimGear we consistently refer to headers from other SimGear modules using #include simgear/ The important part of the change is adding simgear to the include path. doesn't necessarily mean public header, just (at least, in gcc) look in standard places, including those added by -I. Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/math SGGeodesy.cxx, 1.8, 1.9
On 27 Dec 2008, at 10:19, Tim Moore wrote: Correctness, in the sense that I can't compile SimGear without this change. Also consistency, since in SimGear we consistently refer to headers from other SimGear modules using #include simgear/ The important part of the change is adding simgear to the include path. doesn't necessarily mean public header, just (at least, in gcc) look in standard places, including those added by -I. Interesting - I'm testing all these changes on a VMware-Ubunutu image, and this compiled fine. I do have simgear 'installed' to /usr/local though, maybe that means it's picking up the installed headers anyway. The different semantic meanings of vs is something I've struggled with in the past, and there are some Mac-specific conventions which are probably rather too strongly embedded in my brain, so I shall simply cease to worry about this, and stick to the house style. As you noted, GCC doesn't make much distinction at all. James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/math SGGeodesy.cxx, 1.8, 1.9
Tim Moore wrote James Turner wrote: On 27 Dec 2008, at 08:16, Tim Moore wrote: Modified Files: SGGeodesy.cxx Log Message: Fix include path snip *** SGGeodesy.cxx 26 Dec 2008 12:08:28 - 1.8 --- SGGeodesy.cxx 27 Dec 2008 08:16:03 - 1.9 *** *** 22,26 #include cmath ! #include structure/exception.hxx #include SGMath.hxx --- 22,26 #include cmath ! #include simgear/structure/exception.hxx #include SGMath.hxx This is interesting - since we're in an implementation file, not a public header, I regard my version as a 'better' choice than using a system include, with the simgear prefix. Are you changing this for the sake of style, consistency or correctness? (Or maybe all three :) Correctness, in the sense that I can't compile SimGear without this change. Also consistency, since in SimGear we consistently refer to headers from other SimGear modules using #include simgear/ The important part of the change is adding simgear to the include path. doesn't necessarily mean public header, just (at least, in gcc) look in standard places, including those added by -I. Hmmm, neither version compiles here with MSVC9. Gives the following error: source\simgear\math\SGMisc.hxx(27) : error C2059: syntax error : 'L_TYPE_raw' followed by hundreds of errors like this: 1d:\cygwin\simgear-cvs\source\simgear\math\SGMisc.hxx(28) : error C2143: syntax error : missing ')' before '}' 1d:\cygwin\simgear-cvs\source\simgear\math\SGMisc.hxx(28) : error C2143: syntax error : missing '}' before ')' Perhaps Fred has the answer Vivian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Atlas download
Hello, Does anybody know what happened to the Atlas website (atlas.sourceforge.net)? All links (including the downloads) one have been inactive for a few days. Fabian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 1.9.0 feedback
Hi, I have very limited net access and I only check my mailbox. Could someone post a digest of the problems reported so far ? Compiled CVS snapshots for Windows are available weekly. 2 rc have been built. Now, as already said, the real stable version is 1.0.0 and it shouldn't disappear from the website. Now, if GC manufacturers find an interest in supporting FG, they could forward some of their products to a panel of developers ! -Fred -- message original -- Sujet: Re: [Flightgear-devel] 1.9.0 feedback De: Durk Talsma d.tal...@xs4all.nl Date: 27.12.2008 09:42 Hi, On Saturday 27 December 2008 10:11:46 Stuart Buchanan wrote: I think it's something we need to bear in mind for the next release. We'll need to put more effort to get external testing of RCs on Windows/ATI. Yes, I agree, but the problem is how to do that. For this release, we've had two release candidates, for both of which we've had full fledged windows packages, and -as far as I can tell- we've received no comments regarding the problems I'm reading reports about in the forums now. Unfortunately, it usually happens this way. It would be great if we could manage to get some more user feedback on the release candidates. Given that the only announcement for 1.9 is a single line on the website, this isn't surprising. As far as I am aware, we haven't really announced 1.9 either through the -user mailing list, or the Forum. Durk - do we have a change-log we can advertize yet? It seems to me that the release procedure isn't finished yet. I haven't seen an announcement on flightgear-announce, and the gallery is still pointing to the 1.0.0 one. IIRC, Curt used to sent the announce mails, but I could be wrong here. If so, I'll do that later. In the mean time, here is the changelog. Cheers, Durk FlightGear 1.9.0 FlightGear 1.9.0 represents a fundamental code rearrangement, incorporating over two years of development. After finishing the 1.0.0 release in December 2007, the FlightGear development team has directed their full attention to finishing the code overhaul that had already started in October 2006. The current 1.9.0 version of FlightGear is built upon the critically acclaimed OpenSceneGraph library, thereby widely expanding FlightGear's graphical capabilities. To make use of FlightGear's rich feature set, OpenSceneGraph 2.7.3 is minimally required (OpenSceneGraph 2.7.8 is recommended to avoid rendering bugs). The switch to OpenSceneGraph marks an important milestone for FlightGear, as it allows us to make full use of the advanced rendering options already available in OpenSceneGraph, such as stereographic view modes on screen statistics, easy definition of cameras for multiscreen systems, onscreen statistics, native OpenSceneGraph 3D model loaders and much more. While the most dramatic changes to FlightGear have been taking place under the hood, the latest version does offer many new exciting features not found in any previous version. Some highlighted new features include: Major new developments and features: - Major overhaul of the graphics code. FlightGear 1.9.0 makes use of the OpenSceneGraph library - Easy setup of multidisplay systems using multiple OpenSceneGraph Cameras driven by one single instance of FlightGear. - Multithreaded 3D model loader leads to much smoother performance - New particle system based precipitation code - configurable XML particle animations for smoke, spray, fire, etc - New dynamically configurable 3D Clouds. - pick animations, which allow for better clickable instrument panels - multiplayer specific on-screen menu - AI code can generate wingmen - At selected airports, it is now possible to start at a predefined parking position, as an alternative to starting at the runway. - Support for Lighter than air vehicles - Shader based tree rendering. This new feature allows For much denser tree density without any frame rate loss. - Support for jpg and png textures - A new multikey command mode, where multiple key strokes can be combined to form a command. - Detailed buildings at various airports and major cities around the world - Scenery can be kept up-to-date by downloading it from an SVN repository using TerraSync - Over 200 Aircraft are now available for separate download. Code Improvements: - Improved Flight Dynamics - Several Improvements to animations - Improved behavior of Taxiing AI Aircraft. - Miscellaneous GUI improvements - Major improvements to FlightGear's route/waypoint manager code. - Improved runway management - Improved encapsulation of Navaids - Improved nasal scripting security - Improved behavior of VOR radios when close to their maximum range. - Configurable Heads up displays - Improved support of GPS instruments - Easier definition of AI traffic patterns - Improved accuracy of coastlines --
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/math SGGeodesy.cxx, 1.8, 1.9
Hi, add#undef max #undef min at the top of that SGMisc.hxx, just before class ... I thought it was a local problem at my end cause I'm always changing things, heh. It's been that way for a few days. hth, yon On Sat, Dec 27, 2008 at 12:21 PM, Vivian Meazza vivian.mea...@lineone.netwrote: Hmmm, neither version compiles here with MSVC9. Gives the following error: source\simgear\math\SGMisc.hxx(27) : error C2059: syntax error : 'L_TYPE_raw' followed by hundreds of errors like this: 1d:\cygwin\simgear-cvs\source\simgear\math\SGMisc.hxx(28) : error C2143: syntax error : missing ')' before '}' 1d:\cygwin\simgear-cvs\source\simgear\math\SGMisc.hxx(28) : error C2143: syntax error : missing '}' before ')' Perhaps Fred has the answer Vivian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/math SGGeodesy.cxx, 1.8, 1.9
On 27 Dec 2008, at 11:21, Vivian Meazza wrote: Hmmm, neither version compiles here with MSVC9. Gives the following error: source\simgear\math\SGMisc.hxx(27) : error C2059: syntax error : 'L_TYPE_raw' followed by hundreds of errors like this: 1d:\cygwin\simgear-cvs\source\simgear\math\SGMisc.hxx(28) : error C2143: syntax error : missing ')' before '}' 1d:\cygwin\simgear-cvs\source\simgear\math\SGMisc.hxx(28) : error C2143: syntax error : missing '}' before ')' Perhaps Fred has the answer Yuck, sorry about this Vivian - I'm not sure what's going on there. Maybe I introduced some odd whitespace or line-endings to the header or source file? As far as I know, all my editors are set to soft-tabs and LF line-endings, and that's what all the existing sources use. Again, apologies. James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/mathSGGeodesy.cxx, 1.8, 1.9
That fixes Tim's version. Thanks Vivian -Original Message- From: Yon Uriarte [mailto:yon.uria...@gmail.com] Sent: 27 December 2008 11:53 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/mathSGGeodesy.cxx, 1.8, 1.9 Hi, add #undef max #undef min at the top of that SGMisc.hxx, just before class ... I thought it was a local problem at my end cause I'm always changing things, heh. It's been that way for a few days. hth, yon On Sat, Dec 27, 2008 at 12:21 PM, Vivian Meazza vivian.mea...@lineone.net wrote: Hmmm, neither version compiles here with MSVC9. Gives the following error: source\simgear\math\SGMisc.hxx(27) : error C2059: syntax error : 'L_TYPE_raw' followed by hundreds of errors like this: 1d:\cygwin\simgear-cvs\source\simgear\math\SGMisc.hxx(28) : error C2143: syntax error : missing ')' before '}' 1d:\cygwin\simgear-cvs\source\simgear\math\SGMisc.hxx(28) : error C2143: syntax error : missing '}' before ')' Perhaps Fred has the answer Vivian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/math SGGeodesy.cxx, 1.8, 1.9
James Turner wrote On 27 Dec 2008, at 11:21, Vivian Meazza wrote: Hmmm, neither version compiles here with MSVC9. Gives the following error: source\simgear\math\SGMisc.hxx(27) : error C2059: syntax error : 'L_TYPE_raw' followed by hundreds of errors like this: 1d:\cygwin\simgear-cvs\source\simgear\math\SGMisc.hxx(28) : error C2143: syntax error : missing ')' before '}' 1d:\cygwin\simgear-cvs\source\simgear\math\SGMisc.hxx(28) : error C2143: syntax error : missing '}' before ')' Perhaps Fred has the answer Yuck, sorry about this Vivian - I'm not sure what's going on there. Maybe I introduced some odd whitespace or line-endings to the header or source file? As far as I know, all my editors are set to soft-tabs and LF line-endings, and that's what all the existing sources use. Again, apologies. It's just MSVC9 being picky, not your fault, no apology needed. Vivian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/mathS GGeodesy.cxx, 1.8, 1.9
Or -DNOMINMAX in the compiler options -Fred -- message original -- Sujet: Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/mathSGGeodesy.cxx, 1.8, 1.9 De: Vivian Meazza vivian.mea...@lineone.net Date: 27.12.2008 13:06 That fixes Tim's version. Thanks Vivian -Original Message- From: Yon Uriarte [mailto:yon.uria...@gmail.com] Sent: 27 December 2008 11:53 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/mathSGGeodesy.cxx, 1.8, 1.9 Hi, add #undef max #undef min at the top of that SGMisc.hxx, just before class ... I thought it was a local problem at my end cause I'm always changing things, heh. It's been that way for a few days. hth, yon On Sat, Dec 27, 2008 at 12:21 PM, Vivian Meazza vivian.mea...@lineone.net wrote: Hmmm, neither version compiles here with MSVC9. Gives the following error: source\simgear\math\SGMisc.hxx(27) : error C2059: syntax error : 'L_TYPE_raw' followed by hundreds of errors like this: 1d:\cygwin\simgear-cvs\source\simgear\math\SGMisc.hxx(28) : error C2143: syntax error : missing ')' before '}' 1d:\cygwin\simgear-cvs\source\simgear\math\SGMisc.hxx(28) : error C2143: syntax error : missing '}' before ')' Perhaps Fred has the answer Vivian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Git advice (was Re: Refresh of the GIT mirror on 'mapserver.flightgear.org')
On 26 Dec 2008, at 16:37, Timothy Moore wrote: I recommend that you use git-cvsimport -k. It can be a bit time- consuming, but I've never had the kind of inconsistencies that I would see with taylor, and it knows how to do deletes! I could benefit from some advice on using git to track (various) local changes I'm working on. (note, in the following discussion, I suspect for 'branch' you can also read 'tree') Essentially I'd like: - a branch that tracks CVS - a branch that is close to CVS, that I can test commits on before getting them into CVS 'somehow' (a patch against a CVS checkout, I guess) - branches for chunks of stuff I'm working on - a working head where I can combine from the various chunks-of-work- branches, and play with the end result I assume that when I want to commit to CVS, I'd merge/generate-patches from a 'work' branch, apply it to the 'close to CVS' branch, check everything builds, and somehow get that into CVS. What I'm not clear on is what's the best master to use, and which of the above steps are best done with a git merge, or by generating and applying patches to a non-git tree, or what. Obviously I want to be able to rebase the work branches as CVS moves forward, so presumably the should be branched 'from' the pure CVS copy? And hence the pure CVS branch is in fact the master? (I'm guessing wildly now) I\m sure all of the above is possible, and maybe even easy, but as ever with git I struggle with documentation. I've already managed to lose work by doing something dumb on a second machine. James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atlas download
Fabian == Fabian Grodek writes: Fabian Hello, Does anybody know what happened to the Atlas Fabian website (atlas.sourceforge.net)? All links (including the Fabian downloads) one have been inactive for a few days. In fact, it's been broken for at least a month or more. It seemed to coincide with the SourceForge site reorganization. Unfortunately, I don't have administrator access to the project, so I can't fix the website (well, that and the fact that I don't know much about HTML :-)). I've sent a note to the administrators to ask for help. Brian -- Brian Schack 19 Xǔchāng Street 2Fphone: 2381 4727 Taipei 100 fax:2381 2145 TAIWAN -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Git advice (was Re: Refresh of the GIT mirror on 'mapserver.flightgear.org')
James Turner wrote: I could benefit from some advice on using git to track (various) local changes I'm working on. Here's my workflow for using git with the FlightGear sources in CVS. Note that there are separate repositories for Fightgear, Simgear and the Flightgear data. This is inconvenient and there may a workaround using git submodules, but I haven't explored that yet. Essentially I'd like: - a branch that tracks CVS I have three git repos that I use only to track CVS using git-cvsimport. You could use the mapserver.flightgear.org mirrors instead; I like to have control over my imports, refresh them when I need to, etc. I think you could also do the mirroring in a working git repo directly, but keeping separate mirrors is less confusing. The incremental update using git-cvsimport is time-consuming, especially for the data tree, so I can fire off the update and keep working in my regular git repo. Also, using two repos on a single machine doesn't use twice the disk space because git uses hard links to do the clone. - a branch that is close to CVS, that I can test commits on before For Flightgear, Simgear and data I have one repo each where I do actual work. These were initially cloned from my CVS mirror repos. Whenever I update the mirrors I bring the updates into the working repos using git-fetch origin. The master branch in these repos contains work that I intend to check into CVS soon; they should track CVS, more-or-less. I use git-rebase to keep the master branch + new work synched with the CVS mirrors. getting them into CVS 'somehow' (a patch against a CVS checkout, I guess) I keep a check-out of the CVS repositories, done using CVS of course. When I'm ready to check something into CVS I use git-cvsexportcommit, which does everything necessary to the CVS tree except the actual commit. After committing I update my mirrors, suck the changes into the working repos, and then git-rebase. Poof, my master branch is synched with the current CVS state of the world. - branches for chunks of stuff I'm working on - a working head where I can combine from the various chunks-of-work- branches, and play with the end result These are just normal git topic branches. I periodically rebase mine against the master branch. I assume that when I want to commit to CVS, I'd merge/generate-patches from a 'work' branch, apply it to the 'close to CVS' branch, check everything builds, and somehow get that into CVS. See above. What I'm not clear on is what's the best master to use, and which of the above steps are best done with a git merge, or by generating and applying patches to a non-git tree, or what. If we were already using git, then master would be the branch that you would push to share your commits with the rest of us; i.e., it would be your local version of the master sources. So that's the branch on which you do development you intend to share soon. Obviously I want to be able to rebase the work branches as CVS moves forward, so presumably the should be branched 'from' the pure CVS copy? And hence the pure CVS branch is in fact the master? (I'm guessing wildly now) You want to think of the pure CVS branch as remotes/origin/master. Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 1.9.0 feedback
On Sat, Dec 27, 2008 at 10:11 AM, Stuart Buchanan stuart_d_bucha...@yahoo.co.uk wrote: James Turner wrote: I'm noticing quite a few people on the forums with difficulty running 1.9.0 - either long delays on startup, hangs while loading scenery, crashes or rendering issues. Some of these are certainly driver issues, especially with ATI and the dreaded Intel chipsets. And of course people who're having problems are the most vocal on forums :) In fact, sadly it seems pretty difficult to find a positive comment about 1.9 :( Unfortunately, it appears that nowadays pretty much every FG developer runs NVidia, and often Linux, so we're simply not using the same platform as a lot of our users. FYI, the black rectangle also occurs on linux, especially with older nvidia cards only supported by the legacy driver (no possibility to upgrade). The bug appeared with the change to 2 cameras. Tim said he might have some workaround for this. The splash-screen bug might be some timing issue and it has been mostly reported by single-core users. These facts still fit into the not-many-developers-run-that-kind-of-configs theory, but point away from windows and ati. Also, FG had a reputation of running nicely on low-end hardware, I guess this is changing now. -- Csaba/Jester -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 1.9.0 feedback
On Dec 28, 2008, at 1:24 AM, Csaba Halász wrote: FYI, the black rectangle also occurs on linux, especially with older nvidia cards only supported by the legacy driver (no possibility to upgrade). The bug appeared with the change to 2 cameras. Tim said he might have some workaround for this. The splash-screen bug might be some timing issue and it has been mostly reported by single-core users. Way too long splash-screen occur on my MacBook Pro with core 2 duo, so this is not only for single core users. In that case I quit it during the splash screen, and then launch it again. The second trial usually works fine. Only the problem I have in that case is that FG crashes with sigsevg if you quit it during splash screen. This is another issue but it must also be fixed. I've not yet reported that any Mac has a black box problem, but I've reported one crash with nVidia GeForce ti4x00 driver bug exactly the same as GeForce 7x00GT. Tat -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] fix for NaN if no wind in METAR
Hi! This fixes a source of NaNs when the METAR doesn't contain wind information. These NaNs could have propagated into the scene graph (for example through the windsock animation) resulting in the infamous CullVisitor message. Thanks to Alexis (xiii) for pinpointing the problem. -- Csaba/Jester Index: src/Environment/fgmetar.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/Environment/fgmetar.cxx,v retrieving revision 1.6 diff -u -r1.6 fgmetar.cxx --- src/Environment/fgmetar.cxx 7 Dec 2008 08:19:54 - 1.6 +++ src/Environment/fgmetar.cxx 27 Dec 2008 23:35:05 - @@ -99,6 +99,8 @@ _wind_range_from = _wind_range_to = _wind_dir; } +if (_wind_speed == SGMetarNaN) +_wind_speed = 0.0; if (_gust_speed == SGMetarNaN) _gust_speed = 0.0; -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
