Re: [Flightgear-devel] C172p 3D Turn-Coordinator
Hi Joe, > In case anybody is still working on the C172p-3D: Heiko and I currently maintain it, so we're interested in any bugs/suggestions. > While trying to describe how to fly turns with the c172p 3D-model I > noticed problems with the there used 3D-Turn-Coordinator/Indicator (as > well in the "old" version 1.9 as in the new version 2): > > 1) In the 3D-model there is used the very old style "Turn Indicator" > while in the 2D-model there is the modern "Turn Coordinator". In my old > "Pilots Operating Handbooks" of 172M (1976) and 172K (1977) there is > always shown the new style (like in the 2D-model). (See also e.g. > http://de.wikipedia.org/wiki/Wendezeiger Sorry: That old, outdated style > I found only in the German WIKI - seems all other nations forgot about > that old stuff already!) I'll do a bit of research to check if there is a particular reason we used a turn indicator rather than a turn coordinator. > 2) In addition the Turn-Indicator-Markings on that old style 3D-model > are mis-adjusted: The marks for a Standard-2min-Turn with 20° banking > are at 15° - in the 2D that is correctly centered at 20° banking. That sounds like a straight bug. I'll investigate and fix when I get the chance. Thanks, -Stuart -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] failed assertion
On 26 Jun 2010, at 21:00, Torsten Dreyer wrote: > Should be fixed now, thanks for reporting. And thanks to Torsten for fixing! James -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issues with compiling on Gentoo 64
Thanks for that. I have just been using a "git clone" and letting it decide on what was the working copy. I think it used v2.0.0-r4 or something. All 3 were done the same, I will change them to "next". only other nice thing would be a cut down of the fgdata so that I got only minimal data and do the whole shooting match as it is quite extensive and I tend to only fly with the default. any way thats the wish list, now back to seeing if using next branch works better Jason On Sat, 2010-06-26 at 13:36 +0200, Torsten Dreyer wrote: > > these were both pulled down from gitourious today with a git clone > > > command. > > Be sure to clone the branch 'next' from FlightGear and SimGear. This > is the branch for the latest changes. > > > > > > PS. is there a better way of doing things apart from git pull and > > > getting everything ever committed being downloaded in to my local > copy? > > git clone --depth 1 myurl > > Quote from the manpage: > > --depth > > Create a shallow clone with a history truncated to the specified > number of revisions. A shallow repository has a number of limitations > (you cannot clone or fetch from it, nor push from nor into it), but is > adequate if you are only interested in the recent history of a large > project with a long history, and would want to send in fixes as > patches. > > HTH, Torsten > > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > ___ Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] failed assertion
> if i try to set the time of day (--timeofday) to anything i get > > fgfs: sunsolver.cxx:60: void fgSunPositionGST(double, double*, double*): > Assertion `sun' failed. Abort > > without the timeofday flightgear starts normally. this is with the > latest git. > > --alex-- > Should be fixed now, thanks for reporting. Torsten -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] failed assertion
if i try to set the time of day (--timeofday) to anything i get fgfs: sunsolver.cxx:60: void fgSunPositionGST(double, double*, double*): Assertion `sun' failed. Abort without the timeofday flightgear starts normally. this is with the latest git. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows config.h-mscxx
On Saturday 26 June 2010 07:55:10 pm Frederic Bouvier wrote: > I forgot to mention I proposed this change in the CVS era before I had > commit privilege. It's obvious that now I could commit the file with the > correct version number, because I doubt a Linux developer will do it > spontaneously ;-). Unless that Linux Developer also happens to be the release coordinator and is properly briefed on the need to do so. :-) Cheers, Durk -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows config.h-mscxx
> I am away on vacation now so I can't promise when this will be done, > but it may be wise to remove the .in files and their reference in > configure.ac, and remove the target files from .gitignore Done and pushed. Have a great vacation! Torsten -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows config.h-mscxx
On 6/26/10 7:36 PM, Alan Teeder wrote: > Is there any need for this to be done by all new cloners before compilation? > It seems to be an unnecessary complication. The reason for having autoconf to replace the version string is that there should only be one place where the version string is set (configure.ac or some associated file depending on the build system setup). (Some) Mac and all(?) linux users use autoconf and there is no issue. I suppose the problem of copying the file and changing the string manually affects windows and mac xcode (I think) users. The source file is the .in file and that should be in the repository and nothing else. > All GIT users should be currently working with the same version (2.0.0) in > both simgear and flightgear. As and when a new version comes about both > these files can be updated and committed by whoever is responsible for > raising the issue number. Well, technically git users are working on 2.x (or 2.0.x or what ever the next version will be called). Again, the idea is that the version number should only be changed in one place and propagated by the build system. In your case it is a header for MSVC and for other developers the version will be propagated to other files. This type of scenario is error prone. Cheers, Jari -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Git merge oops.
On 26 Jun 2010, at 17:41, James Turner wrote: > I pushed a wrong branch by accident, which will mess up history in the repo. > Not the end of the world, but Tim can fix it if people avoid committing to fg > (simgear and fgdata are unaffected) until he's rolled back my mistake. > There's a separate issue that the build will be broken following my earlier > merge - I was trying to fix the build when I did the bad push. All fixed now, including the build issues. Apologies again, and thanks to Tim for the speedy fix. James -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows config.h-mscxx
- "Alan Teeder" a écrit : > Is there any need for this to be done by all new cloners before > compilation? > It seems to be an unnecessary complication. > > All GIT users should be currently working with the same version > (2.0.0) in both simgear and flightgear. As and when a new version comes about > both these files can be updated and committed by whoever is responsible for > raising the issue number. > > As an aside I tried to generate config.h-msc90 with cygwin autoconf - > but it failed with an error at line 799 in file configure.ac. I forgot to mention I proposed this change in the CVS era before I had commit privilege. It's obvious that now I could commit the file with the correct version number, because I doubt a Linux developer will do it spontaneously ;-). I am away on vacation now so I can't promise when this will be done, but it may be wise to remove the .in files and their reference in configure.ac, and remove the target files from .gitignore -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows config.h-mscxx
-- From: "Frederic Bouvier" Sent: Saturday, June 26, 2010 5:57 PM To: "FlightGear developers discussions" Subject: Re: [Flightgear-devel] Windows config.h-mscxx >> > The files config.h-msvc8 and config.h-msvc90 are necessary for a >> > windows build but are now in .gitignore making them inaccessible. >> > Natively windows has no method to generate these files from the .in >> > files, although this is probably possible by installing Perl, and GNU >> > versions of autoconf and automake. - and then learning how to use them >> > ! >> > >> > Could they be put back into the normal distribution path? >> It was me, who put them into gitignore because these files are created >> from the respective *.in files during the build. >> Maybe I am wrong, but if these files are created from some other >> sources, they don't belong under source control but the source files do. >> >> If I understand the current setup correctly, a run of autogen.sh and >> configure is required to create the config.h-msvcxx files from the .in >> files >> before a windows build can run. >> >> I think it is very unfortunate that some *nix system has to run a >> configure script to generate the files needed for a windows build, put >> them into the source control system to be accessible for windows users. >> >> Maybe Frederic can chime in here with a better idea of how to solve >> this? > > I originally included config.h-msvcxx in the autoconf system because there > was a long track record of releases made with the wrong version in these > files. autoconf is only used to substitute @VERSION@ by the right one. > > No need of perl or something else, just copy the .in file and replace > @VERSION@ by a string, ideally the right version number ;-) > > If someone is able to alter the project file to autogen this file with the > good version number, under Windows, without requiring additional tools, > go ahead... > > Regards, > -Fred Fred Thanks for that. I had just this minute run a diff check on config.h-msc90 (from my CVS archive) and config.h-msc90.in As you say the only difference is that each occurrence of "@VERSION@" is replaced by "2.0.0". This is exactly the change that has to be made in simgear/simgear.h.in before it is copied to simgear.h. Is there any need for this to be done by all new cloners before compilation? It seems to be an unnecessary complication. All GIT users should be currently working with the same version (2.0.0) in both simgear and flightgear. As and when a new version comes about both these files can be updated and committed by whoever is responsible for raising the issue number. As an aside I tried to generate config.h-msc90 with cygwin autoconf - but it failed with an error at line 799 in file configure.ac. Alan -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Official
Use of trademarked logos on liveries may possibly fall under nominative fair use, assuming they are accurate, as depiction of the trademarks are necessary to depict a publicly visible plane. To quote wikipedia with my own comments in brackets, and randomly using American Airlines as the example: The nominative use test essentially states that one party may use or refer to the trademark of another if: The product or service cannot be readily identified without using the trademark (e.g. trademark is descriptive of a person, place, or product attribute) [It is impossible to depict an American Airlines plane without an accurate AA livery] The user only uses so much of the mark as is necessary for the identification (e.g. the words but not the font or symbol) [The livery is accurate to what AA paints on their own planes, which are readily visible as a 'real-life' thing that anyone can see, and we simulate] The user does nothing to suggest sponsorship or endorsement by the trademark holder. This applies even if the nominative use is commercial, and the same test applies for metatags. [Since FG has _many_ liveries and isn't just, say, an American Airlines simulator, no reasonable person would believe sponsorship or endorsement by the airlines whose liveries are recreated in the simulation] At any rate, that only applies to U.S. trademark laws, so mileage may vary. At any rate I'd think we have fair use of trademarks on airliner liveries, so long as they are accurate. I think you'd run into trouble if you made up an 'imaginary' AA livery. Jim On 22 June 2010 16:20, Nathanael Rebsch wrote: > Reagan Thomas wrote: > > Nathanael Rebsch wrote: > > > >> i once took care of sorting out the legal situation of OpenTTD. > >> OpenTTD was reverse engeneered from Transport Tycoon (Deluxe, IIRC). > >> This work was done in Sweden, where now law prohibited the reverse > >> engeneering if lisence agreements (e.g. eula) did not take care of such > >> notices - on this very CD of Transport Tycoon Deluxe, this indeed was > >> missing. > >> > >> (Assumed) Copyright of TTD used to belong to Micropose - in fact they > >> only ever had production rights - copyright was still with the > >> manager-company of chris sawyer (to mee unknown at that time). > >> Micropose was bought by Atari, so i contacted their legal department (a > >> few times actually) - which is where chris sawyers managers were > >> mentioned to me. after lengthy talks i called the company in the UK. > >> > >> end result: they were well aware of OpenTTD, they were not happy, they > >> would like to take the matter to court... BUT a few things just stand in > >> the way: > >> OpenTTD is released under GPL, there is no money behind OpenTTD, so in > >> fact there is nothing they could archieve with taking OpenTTD to court. > >> > >> what i want to express: > >> Airlines will most likely be very familiar with Flightgear. They will > >> very much know that liveries exist, and that these are distributed under > >> GPL compatible lisences. > >> they probably have larger legal departments and know everything they > >> need to know about such a project. > >> and there is probably a very good reason why they did not contact > >> Flightgear before. > >> > >> Generally you can wait until you receive a notice, before needing to > >> take action - some companies even risk that - and there is usually a lot > >> more money to be gotten than with Flightgear or other GPL released > projects. > >> > >> greets > >> Nathanael Rebsch > >> > >> > >> > >> > > Out of curiosity, a few years ago I contacted American Airlines legal > > dept in charge of trademarks and asked if their livery could be used on > > aircraft made available for or with FlightGear. The short answer is, > > no, they won't permit it. By US law, trademarks *must* be actively > > protected by their holders or they become common and unprotected in the > > eyes of the law. With that in mind, they really have no choice but to > > officially refuse permission. > > > > However, reading between the legal weasel-words in their response and > > having had a glimpse into how the real world operates, you could put > > their AA logo on a nice, shiny aircraft model available for download and > > they will most likely turn their heads and look away. Overlay a vulgar > > work on top of their logo on your plane and you'll get a C&D letter as > > soon as they find out about it > > I doubt you'd even get a letter, even if they spot it (and they surely > will). > i guess in many cases they do not like it, however - they will probably > do nothing about it. and even if you have an aircraft with livery the > airlines could ask you to stop distributing - 1. damage is done, and > others may distribute, 2. FG is not responsible for liveries other > people release under GPL, this only affects the aircraft itself and > their authors. > i have no idea how FS does it, or XPlane. but as long as no money flows, > you are on a safe side. >
[Flightgear-devel] Git merge oops.
I pushed a wrong branch by accident, which will mess up history in the repo. Not the end of the world, but Tim can fix it if people avoid committing to fg (simgear and fgdata are unaffected) until he's rolled back my mistake. There's a separate issue that the build will be broken following my earlier merge - I was trying to fix the build when I did the bad push. (If you're looking at the Gitorious web interface, it's the push of 133 commits that is the issue) Apologies for the SNAFU, James -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows config.h-mscxx
> > The files config.h-msvc8 and config.h-msvc90 are necessary for a > > windows build but are now in .gitignore making them inaccessible. > > Natively windows has no method to generate these files from the .in > > files, although this is probably possible by installing Perl, and GNU > > versions of autoconf and automake. - and then learning how to use them ! > > > > Could they be put back into the normal distribution path? > It was me, who put them into gitignore because these files are created > from the respective *.in files during the build. > Maybe I am wrong, but if these files are created from some other > sources, they don't belong under source control but the source files do. > > If I understand the current setup correctly, a run of autogen.sh and > configure is required to create the config.h-msvcxx files from the .in files > before a windows build can run. > > I think it is very unfortunate that some *nix system has to run a > configure script to generate the files needed for a windows build, put > them into the source control system to be accessible for windows users. > > Maybe Frederic can chime in here with a better idea of how to solve > this? I originally included config.h-msvcxx in the autoconf system because there was a long track record of releases made with the wrong version in these files. autoconf is only used to substitute @VERSION@ by the right one. No need of perl or something else, just copy the .in file and replace @VERSION@ by a string, ideally the right version number ;-) If someone is able to alter the project file to autogen this file with the good version number, under Windows, without requiring additional tools, go ahead... Regards, -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issues with compiling on Gentoo 64
> these were both pulled down from gitourious today with a git clone > command. Be sure to clone the branch 'next' from FlightGear and SimGear. This is the branch for the latest changes. > > PS. is there a better way of doing things apart from git pull and > getting everything ever committed being downloaded in to my local copy? git clone --depth 1 myurl Quote from the manpage: --depth Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. HTH, Torsten -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with git v2.0.0 -- unable to run flightgear
> > any ideas as miss using flightgear and want to get back to using it > again soon Do you have the latest data from git but not the latest sources from git? Torsten -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows config.h-mscxx
> The files config.h-msvc8 and config.h-msvc90 are necessary for a windows > build but are now in .gitignore making them inaccessible. > > Natively windows has no method to generate these files from the .in files, > although this is probably possible by installing Perl, and GNU versions of > autoconf and automake. - and then learning how to use them ! > > Could they be put back into the normal distribution path? It was me, who put them into gitignore because these files are created from the respective *.in files during the build. Maybe I am wrong, but if these files are created from some other sources, they don't belong under source control but the source files do. If I understand the current setup correctly, a run of autogen.sh and configure is required to create the config.h-msvcxx files from the .in files before a windows build can run. I think it is very unfortunate that some *nix system has to run a configure script to generate the files needed for a windows build, put them into the source control system to be accessible for windows users. Maybe Frederic can chime in here with a better idea of how to solve this? Torsten -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] problem with git v2.0.0 -- unable to run flightgear
Hi all, finally got it all compiled but now I get lots (about 14600) of the following that ends in a segfault Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool After turning log level to bulk it first shows up with the following Initializing scenery subsystem Splash screen progress loading aircraft Reading sound sound from /usr/local/share/FlightGear/Aircraft/c172p/c172-sound.xml Loading sound information for: engstart Loading sound information for: crank Loading sound information for: cough Loading sound information for: engine Loading sound information for: propeller Loading sound information for: rumble Loading sound information for: squeal Loading sound information for: flaps Loading sound information for: wind Loading sound information for: stall Loading sound information for: KAP140Beep Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool any ideas as miss using flightgear and want to get back to using it again soon Jason -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
Good news, switching to Ubuntu 10.04 LTS solved all git problems for me. No idea why Xandros 4.5 gave me problems but Xandros seemed to have abandoned the desktop market anyhow. For what it's worth, I'm very pleased with Ubuntu so far. Erik -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issues with compiling on Gentoo 64
Jason Cox wrote: > 1. is simgear-cs & flightgear-cs still required or cn I just use th > gitorious versions? "simgear-cs" is just a customized version of SimGear for "terragear-cs" to run headless if you don't have a $DISPLAY available. It's not required for general operation of FlightGear. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
