Re: [Flightgear-devel] Dual-licensing question
On Wed, 15 Jun 2011 18:39:20 -0700, Ryan wrote in message 1308188360.7422.1.camel@linux-toshiba-laptop: Stupid question about dual-licensing: Can I dual-license an aircraft under both GPL2 and CC-BY (no -SA or -NC), and still have it placed into fgdata? ..if you own it, you decides. Distributed with fgdata will be under the GPL only, but your users may fetch it elsewhere, e.g. from your sales hangar chain under your CC-BY. ..I must sell your aircraft under the GPL, if I want to sell it with FG, the CC-BY is not compatible with the GPL: http://www.gnu.org/licenses/license-list.html ..and, there are some other issues: http://www.gnu.org/licenses/license-list.html#which-cc -- ..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. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
ThorstenB wrote: But this and other posts today show [...] This is by far the best characterization of The FlightGear Projects age-old disease I've ever read, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
On Thu, 2011-06-16 at 07:35 +, Martin Spott wrote: ThorstenB wrote: But this and other posts today show [...] This is by far the best characterization of The FlightGear Projects age-old disease I've ever read, As I see it there are two sides to the story, users who criticize too quickly but also developers who don't seem to handle criticism particularly well (not that I'm accusing Thorsten here). Add to that that non native English speakers might sound a bit short cut to native English speakers and that non native English speakers might find comments from other non native speakers insulting because of these misunderstandings while there's actually no intention to do so and there's a problem. Personally I like the idea of being able to fetch new scenery from within FlightGear itself. Working a bit more towards what users expect and appreciate isn't a bad thing, it could even attract new developers who might just want to work on the areas you think FlightGear is lacking (scenery, selecting a new aircraft at runtime). That's how it has always worked so far. The first 3d models weren't particularly attractive but showed that it works and that attracted new developers. Because of that the 3d models created these days are just about the best you can get. Erik -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
ThorstenB wrote: ... snip ... On 15.06.2011 23:30, Vivian Meazza wrote: And less clever users, which is most of the people out there, won't. I include myself in that category, since I have failed to make it work so far. I sometimes wonder if we really expect the average user to poke around in preferences.xml? But then, we have FGRun that does most of that for us. There should be no need to edit anything in preferences.xml. You should be able to enter the directory in the GUI (yes, I know, no directory dialog). Or you could also provide it via a new command-line option (--terrasync-dir). And it's preserved across sessions. So you only need to provide/edit it once. I had responded to your email yesterday in private, hinting that you probably somehow managed an incomplete fgdata pull (which you later confirmed). Maybe something is still broken - maybe with my code or still on your system. Or maybe I forgot to push something. Yes - _I_ know that your code does not require anything done to preferences.xml by the user. And, as I said, the average user should not be required to do so. So, I am really sorry, Vivian, that you were still unable to make the system work for you - on day 2 (though it seems people only started trying to use it _today_). I'm reasonably sure it's something here. But the latest Hudson build #331 doesn't work here either, with the same error messages as my local build. The trouble is, I have no idea how to fix it. But this and other posts today show our general FG mailing list tendency: being negative. It's the almost natural response to any change. Oh crap! Doesn't work! Don't like it... I've spent _loads_ of time into FG in recent months. I have worked the bug tracker almost daily. I have fixed countless bugs other people have introduced - _some_ even hidden in absolutely crappy code (so much on the design issue). I have searched and fixed memory leaks and investigated performance issues. I've fixed loads of issues affecting systems that I personally never use. So, if anything wasn't working with my _own_ addition now - only in GIT for two days, remember - I think it should've been more than obvious that I'd be absolutely willing to explain/test/resolve things - and help anyone who was really interested. And to make it work as expected: to provide an easier solution in accessing scenery (read the forums, if you want to know how users do get along with existing terrasync). But that's not how FG works. It's normal that any slight malfunction is immediately criticized as hell. No attempts in being positive, trying to encourage / motivate other people in improving their work - and to keep them working on FG. When something isn't working, start complaining and being negative. Just look at this list's recent history. Yes, you have done very well for FG, and I'm sure everyone is very grateful, even if they don't say it. I know I am. But, if you suddenly thrust something into FG which hasn't been announced or trailed in any way, for which no clear need has been established, and which apparently doesn't work, at least for some (or possibly only me), you will get a majority of seemingly negative comments. That's just inevitable - for those who are happy won't say anything and those that are unhappy will be vociferous. At the end of the day, they are just other peoples' opinions: you can either accept them or ignore them. FWIW - on the few occasions in the past when I made major contributions to FG I ensured that they were tested on both Linux and Windows by others before they the ever saw the light of day. I'm always ready to test stuff for you or anyone else. This is actually what I was trying to do on this occasion. So, you're all hoping for a better FG. A large redesign, so we can make use of multi-core systems, can even distribute parts across multiple machines. Can separate the GUI. Get Nasal outside the main simulation loop. Well, so do I. But I'm becoming more and more convinced, that this indeed is _not_ going to happen. No, not because of that new library and such tendencies (while in fact that library is much better prepared to be driven by HLA or something similar than most other parts). No, we're very likely to not get any of this since we're absolutely unable to motivate - or at least keep people motivated on working on our project. That's a major issue we have. Everyone who spends time is welcomed by negative comments - and surprisingly many leave. And I'm sorry to say, after reading emails like the above, I do have difficulties in keeping myself motivated. On 15.06.2011 23:59, Gene Buckle wrote: I have the option of being able to just punt and keep using FSX. :D That was a dig at me - Gene and I were just joshing one another. Finally - I have this hanging in my study: http://www.kipling.org.uk/poems_if.htm Vivian
Re: [Flightgear-devel] Heads up: scenery download / built-in
I think Thorsten has been doing a marvelous job. I see the changes flow by in the commitlogs emails, and it probably goes unsaid too often, but it's clear who has been putting in the effort to deal with user bug reports, tricky bits of code, and a whole host of other issues. There are always a few negative voices in any forum and they often project too loudly and too often. Sometimes saying things once and then letting it be is a better strategy. Thoughts and ideas take time to sink in, and bashing people over the head repeatedly does not usually accelerate the process. There are a few developers who are very smart, have a good knowledge of FlightGear, and are well intentioned, but have trouble unwrapping a negative tinge from many of their messages. I think they find that this style is an effective way to communicate their concerns, and probably feel that it will motivate others to take their words more seriously. But I'm serious in saying that for each one of these, there are 50 or maybe 100 others out there who do see the effort and who do appreciate it, but hesitate to contribute to the discussion for any number of reasons. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
ThorstenB wrote: ... snip ... So, I am really sorry, Vivian, that you were still unable to make the system work for you - on day 2 (though it seems people only started trying to use it _today_). ... snip ... Getting back to the original purpose ... it's worse than I thought. Using Hudson Build #331 (the latest AFAIKS), Target Directory seems to stick, but I have made it run just once. I will file a proper bug report. Vivian -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Could We Sync JSBSim for 2.3.0, Please?
There are some valuable features in JSBSim now it would be nice to have in the release. Could someone please sync the latest JSBSim into the flightgear code please? Thanks, Ron -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Could We Sync JSBSim for 2.3.0, Please?
Am 16.06.11 22:09, schrieb Ron Jensen: There are some valuable features in JSBSim now it would be nice to have in the release. Could someone please sync the latest JSBSim into the flightgear code please? Does the new atmosphere code work well with FlightGear's atmosphere? I remember we had some issues when fg and jsbsim were fighting for the correct weather values. But you are right - there are some nice new features we should have in 2.4.0. There will be four weeks starting tomorrow (feature-freeze) before we branch for the release. Plenty of time to fix what might be broken. I think Erik is our sync-master? Torsten -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Could We Sync JSBSim for 2.3.0, Please?
Does the new atmosphere code work well with FlightGear's atmosphere? I remember we had some issues when fg and jsbsim were fighting for the correct weather values. But you are right - there are some nice new features we should have in 2.4.0. There will be four weeks starting tomorrow (feature-freeze) before we branch for the release. Plenty of time to fix what might be broken. I think Erik is our sync-master? Torsten I am very close to committing the new atmosphere code (and the new FGWinds) to JSBSim cvs. However, it would be prudent to first get a glitch or two fixed and then grab that code and put that in FlightGear first, just in case the newer atmosphere and winds code causes problems. Jon -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Clarification on YASIM input (actionpt)
Hello Folks... Was wondering if any nice souls will assist clear this doubt on mine... In YASIM, what does actionpt really refers to? Is it the point the engines pull the air through? which the point will be ahead of the engines or is it the point at back the end of the engine where the exhaust takes place? OR Do we have different application for actionpt based on the aircraft we are modeling. For example, if it is a passenger jet, the actionpt is ahead of the engines and if it is a military jet, then the actionpt is behind the nozzle? Thank you all for the clarifications cheers -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Clarification on YASIM input (actionpt)
On Fri, Jun 17, 2011 at 12:17 AM, xsaint xsa...@gmail.com wrote: Hello Folks... Was wondering if any nice souls will assist clear this doubt on mine... In YASIM, what does actionpt really refers to? Is it the point the engines pull the air through? which the point will be ahead of the engines or is it the point at back the end of the engine where the exhaust takes place? OR Do we have different application for actionpt based on the aircraft we are modeling. For example, if it is a passenger jet, the actionpt is ahead of the engines and if it is a military jet, then the actionpt is behind the nozzle? Thank you all for the clarifications cheers I've always understood actionpt to be the location where thrust should be applied with respect to the airframe. For a propeller-driven engine, I use the approximate location of the main thrust bearing. For a jet, I reckon it depends on the type of jet and the degree of bypass. An older jet engine develops its thrust from the exhaust chamber region. Modern engines with high bypass ratios develop more of their thrust from the fan, so the action point would likely move forward closer to where the main thrust bearings of the fan are located within the engine. I'm not an engine expert by any means, but these are the assumptions I've used. -Gary aka Buckaroo -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Clarification on YASIM input (actionpt)
On Friday 17 June 2011 07:17:45 xsaint wrote: Hello Folks... Was wondering if any nice souls will assist clear this doubt on mine... In YASIM, what does actionpt really refers to? Is it the point the engines pull the air through? which the point will be ahead of the engines or is it the point at back the end of the engine where the exhaust takes place? OR Do we have different application for actionpt based on the aircraft we are modeling. For example, if it is a passenger jet, the actionpt is ahead of the engines and if it is a military jet, then the actionpt is behind the nozzle? Thank you all for the clarifications cheers It should be the point of force application, which for a jet engine is the exhaust nozzle end, commonly found aft of the engine center of mass. For a prop, it should be the blade/hub linkage, and thus commonly found ahead of the engine center of mass. HTH Emilian -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Clarification on YASIM input (actionpt)
Thank you Emilian and Buck Ok i tested changing the location of the point to ahead of the engine and also behind the engine, near exhaust. Irrespective of the location, looking at the results at the Yasim solver, i do not see much impact. Surprisingly i do not see any change to Drag Coef or lift ratio. The only slight change seems to occur rightfully at Tail incidence and approach elevator... Is this how it is ment to be? Cheers On Friday 17,June,2011 12:51 PM, Emilian Huminiuc wrote: On Friday 17 June 2011 07:17:45 xsaint wrote: Hello Folks... Was wondering if any nice souls will assist clear this doubt on mine... In YASIM, what does actionpt really refers to? Is it the point the engines pull the air through? which the point will be ahead of the engines or is it the point at back the end of the engine where the exhaust takes place? OR Do we have different application for actionpt based on the aircraft we are modeling. For example, if it is a passenger jet, the actionpt is ahead of the engines and if it is a military jet, then the actionpt is behind the nozzle? Thank you all for the clarifications cheers It should be the point of force application, which for a jet engine is the exhaust nozzle end, commonly found aft of the engine center of mass. For a prop, it should be the blade/hub linkage, and thus commonly found ahead of the engine center of mass. HTH Emilian -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Clarification on YASIM input (actionpt)
On Friday 17 June 2011 08:15:36 xsaint wrote: Thank you Emilian and Buck Ok i tested changing the location of the point to ahead of the engine and also behind the engine, near exhaust. Irrespective of the location, looking at the results at the Yasim solver, i do not see much impact. Surprisingly i do not see any change to Drag Coef or lift ratio. The only slight change seems to occur rightfully at Tail incidence and approach elevator... Is this how it is ment to be? Cheers You'll most likely see the differences in flight, in asymetric configurations. AFAIK the solver uses just the thrust value, and of course the engine weight for COG determination. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
