Re: [Flightgear-devel] JSBSIm, aeromatic, crosswind taxiiing, et cetera
On Sunday 19 June 2011 10:50:01 John Denker wrote: On 06/19/2011 06:46 AM, Jon S. Berndt wrote: Maybe I've gone wrong somewhere here, but something similar might work. Also, in situations like a flat spin or tail slide this probably falls apart! Let's postpone discussion of exotic flight conditions such as flat spins and tail slides. There are much more prosaic situations that need to be addressed. Let's start by getting the aircraft to behave properly when a) _taxiing_ with a crosswind and/or tailwind, and b) _landing_ and _taking off_ with a crosswind and/or tailwind, These seem like basic and fundamental features. Snip speculation and rumor The value of these features can hardly be exaggerated. For example, according to page 4-3 of the POH the maximum demonstrated crosswind for a C-172 is 15 knots. Snip long ramble and speculation c) _engine out_ (asymmetric thrust) in a twin, We already model asymmetric thrust. d) simple _inverted flight_ ... not an inverted flat spin, just plain old inverted flight, such as people routinely do in a Cessna 150 Aerobat. Aerodynamically, inverted flight is already possible. e) The effect of propwash on trim and on elevator authority. This is a big deal in some aircraft, including the 152/172/182 family. Snip more long off-topic rambling and speculation So, I set up a soft field take off in JSBSim stand-alone with a 15 knot crosswind using the c172p that is in FGFS git: Rotation 13 seconds @41 knots 375 feet Lift off 19 seconds @58 knots 800 feet Distance over 50' 2150 feet Heading Error 45 degrees Then I added the induced thrust which was the topic of this thread in the first place: Rotation 1 seconds @3 knots 3 feet Lift off 20 seconds @55 knots 900 feet Distance over 50' 2550 feet Heading Error 3 degrees Rudder deflection 34% 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] Nasal updating properties in the menu
On Sunday, June 19, 2011 05:12:31 PM Ron Jensen wrote: On Sunday 19 June 2011 17:55:25 Hal V. Engel wrote: On Sunday, June 19, 2011 02:15:54 PM Ron Jensen wrote: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg3 02 08 .html gui.menuBind(radio, dialogs.Radio.open()); Thanks I knew I saw something about this on the list but I coundn't find the emails that covered it. When I try to use it it fails when I click on the menu item. snip Hal In the example case you are running in the namespace dialogs so, in the setfile you would have: nasal dialogs filemynasal.nas If you have something different, you need something different... Assuming you load the nasal in this block: nasal p51d fileAircraft/p51d/Nasal/over-ride-flaps.nas/file fileAircraft/p51d/Nasal/stores.nas/file fileAircraft/p51d/Nasal/limits.nas/file fileAircraft/p51d/Nasal/engine-start.nas/file fileAircraft/p51d/Nasal/sputter.nas/file fileAircraft/p51d/Nasal/climbrate.nas/file fileAircraft/p51d/Nasal/gear-doors.nas/file fileAircraft/p51d/Nasal/gear-lever.nas/file /p51d /nasal gui.menuBind(radio, p51d.radio.open()); Ron Ron, Thanks that was the issue. I had the radio nasal file in a SCR_522C section in my *set.xml file and I should have used SCR_522C.Radio.open() in the gui.menuBind() call. I have it working nicely now. I will have the radio code in my fgdata clone updated shortly and when this gets merged into fgdata it should be usable by anyone who is modeling a WWII/Korean war era US or UK military aircraft since almost all of these used this radio. At this point the radio control unit is fully modeled and fully functional. About the only area where it could use improvement is that it currently has no keyboard mappings but all of it's features can be manipulated with a mouse. Hal -- 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] FlightGear development entered state feature-freeze until July, 17th 2011
On Fri, Jun 17, 2011 at 8:47 PM, Torsten Dreyer wrote: Short version for the impatient reader: Please do _NOT_ push any major changes or new features to simgear, flightgear, fgdata until further advice! snip Please refrain from pushing new features or major infrastructure changes to our streams. Please note: this includes fgdata, too! We have no strict definition of what a major change might be - as a rule of thumb: avoid any trouble that can't be fixed by July, 17th. What's the position on aircraft updates? Gijs has some changes to the c172 that aren't committed yet, and there is at least one other aircraft update that the developer would like committed for the release. Obviously with the c172p we need to be extra careful, but I would assume aircraft updates are generally OK until code-freeze on 17th July? -Stuart -- 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] FlightGear development entered state
Stuart Buchanan wrote: On Fri, Jun 17, 2011 at 8:47 PM, Torsten Dreyer wrote: Please refrain from pushing new features or major infrastructure changes to our streams. Please note: this includes fgdata, too! [...] What's the position on aircraft updates? They're part of fgdata ;-) Indeed, the release procedure has been planned as written. Exceptions may be agreed upon on an individual basis, but aside from this, we'd ask you to refrain from applying major changes. Obviously with the c172p we need to be extra careful, but I would assume aircraft updates are generally OK until code-freeze on 17th July? No, not generally. Obvious fixes are ok, major overhauls are not, in case of doubt I'd propose that the changes in question should be reviewed (which is a darn good idea anyway ;-) Cheerio, 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] FlightGear development entered state
On Mon, Jun 20, 2011 at 9:11 PM, Martin Spot wrote: Stuart Buchanan wrote: On Fri, Jun 17, 2011 at 8:47 PM, Torsten Dreyer wrote: Please refrain from pushing new features or major infrastructure changes to our streams. Please note: this includes fgdata, too! [...] What's the position on aircraft updates? They're part of fgdata ;-) Indeed, the release procedure has been planned as written. Exceptions may be agreed upon on an individual basis, but aside from this, we'd ask you to refrain from applying major changes. Obviously with the c172p we need to be extra careful, but I would assume aircraft updates are generally OK until code-freeze on 17th July? No, not generally. Obvious fixes are ok, major overhauls are not, in case of doubt I'd propose that the changes in question should be reviewed (which is a darn good idea anyway ;-) Well, I _was_ planning to review the changes. :) Both of the changes in question are major model overhauls to the respective models (c172p, c150). I'll refrain checking them in until after 17th July then. -Stuart -- 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] FlightGear development entered state
On 20 Jun 2011, at 21:18, Stuart Buchanan wrote: No, not generally. Obvious fixes are ok, major overhauls are not, in case of doubt I'd propose that the changes in question should be reviewed (which is a darn good idea anyway ;-) Well, I _was_ planning to review the changes. :) Both of the changes in question are major model overhauls to the respective models (c172p, c150). I'll refrain checking them in until after 17th July then. Given this is the first time we're running the new release process, I'd personally support accepting aircraft updates on a case-by-case basis, after a review of course. Of course sticking to a release schedule is also important, and this is just my opinion. Equally the C172p is most people's first impression of FG, and we're only three days into the freeze, so I think a little bit of 'slush-iness' is reasonable. Regards, James -- 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] FlightGear development entered state
Hi Stuart, Stuart Buchanan wrote: Both of the changes in question are major model overhauls to the respective models (c172p, c150). Comments on the state of the c172 model went unheard for months, therefore I'd like to hear a really convincing reason why such major overhaul can't wait until the tree is open for the next development cycle. This is the first time we're aiming at having one release every six months and not everything will be perfect on the first attempt. Anyhow I'm still proposing to let us familiarize ourselves with the implications of having a release plan instead of making exceptions from the rule right from the beginning. Cheers, 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] FlightGear development entered state
Hi all, Stuart wrote: Both of the changes in question are major model overhauls to the respective models (c172p, c150). I need to correct that slightly. All I've been working on is a (c172p) new panel including the pedestal. There were a lot of faults and missing switches in the previous model. Therefore, startup procedure got slightly extended (being more realistic now) and that resulted in a slightly extended tutorial. I also did a little cleanup on the livery system, to make sure that our flagship is a good example for futher devleopers. When I'm finished (hope to be so on Thursday), I'll create a merge request, so everyone can have a look before it is commited. Cheers, Gijs -- 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] FlightGear development entered state
On Mon, Jun 20, 2011 at 9:52 PM, Martin Spott wrote: Comments on the state of the c172 model went unheard for months, therefore I'd like to hear a really convincing reason why such major overhaul can't wait until the tree is open for the next development cycle. Not quite unheard - just incorporated into Gijs' planned update which has been lower down his priority list than passing his exams, and partying on his 18th birthday :) I don't think there's a convincing reason why it can't wait until the next development cycle, but I was unclear as to whether aircraft were considered major features. Given that they should be self contained and shouldn't affect any other part of the sim, one could argue that it's safe to allow aircraft updates until later in the release cycle than features like the recent (excellent BTW) terrasync work. This is the first time we're aiming at having one release every six months and not everything will be perfect on the first attempt. Anyhow I'm still proposing to let us familiarize ourselves with the implications of having a release plan instead of making exceptions from the rule right from the beginning. Absolutely. I'm completely happy to go with the Release Manager's judgement on this. There's always going to be another release, and with the current plan it'll be sooner rather than later! -Stuart -- 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] FlightGear development entered state
Stuart Buchanan wrote: I don't think there's a convincing reason why it can't wait until the next development cycle, but I was unclear as to whether aircraft were considered major features. Ah, well, aircraft are a pretty prominent feature in flight simulation, don't they ;-) While we're at it, two ideas spring to my mind - feel free to discuss, if you see fit: a) With a bit of luck, a shorter development cycle will probably teach every of us to do things more incrementally, where possible. To pick an obvious and very simple example: There's no need to wait four months (!!) for an arcraft panel overhaul to occur just to revert one or two textures to their previous state. As a neat side effect, doing things more incrementally also facilitates debugging, where required - generally speaking :-) b) I'd say we may silently take for granted that those contributors who are committing major aircraft changes _after_ the freeze do expect the respective aircraft not to apply for getting included in the release package. Given that they should be self contained and shouldn't affect any other part of the sim, [...] Quite often aircraft changes _do_ affect other parts - at least in several cases they do affect the frame rate/latency because many 'improvements' also include cool automization features you don't want to miss or the like :-) This is probably not the case for Gijs' proposed panel update of the c172, therefore I'd like to emphasize that decisions about what to include after the freeze should be made on a case-by-case basis. There's always going to be another release, and with the current plan it'll be sooner rather than later! Exactly and since adding major features _now_ also carries the risk of delaying the current _plus_ the next release as well, I'm in favour of taking the release plan seriously. Cheers, 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] FlightGear development entered state
On 20 Jun 2011, at 21:52, Martin Spott wrote: This is the first time we're aiming at having one release every six months and not everything will be perfect on the first attempt. Anyhow I'm still proposing to let us familiarize ourselves with the implications of having a release plan instead of making exceptions from the rule right from the beginning. Fair point, I agree we ned to establish the rules before we break them :) James -- 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
I wrote: 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. I have now been working with Terrasync/Built in scenery download for over a week now. I though I might share with you some observations using Win XP and MSVC9 The bug which was stopping the built-in download running here was trivial - once we found it: a space in a directory name. Replaced with an underscore and it worked right out of the tin. Not quite - only the external mode was available. That turned out to be caused by a non-updated config.h file. Thanks to Fred for his help and guidance to solve that one. In doing this I noticed that both the built in and external variants seem to be functionally similar. I can't even work out how or why the external variant works - but it does. FG finds, starts, and stops the external SVN program. Either ThostenB has been very clever, or it's just serendipity here. I hope it's the former. I decided to revert my local build to external only, and then compare Terrasync started from FGRun with the internal (using Hudson's nightly build) and external variants (using my build). Using the Spitfire4b at Gatwick I discovered: 1. With no download the framerate was 42 with the local build and 33 with the Hudson build. I suspect that is caused by different compiler options. 2. With scenery download running each option costs about 10 fps. 3. The Terrasync/FGRun scenery pre-fetch option works well, and is useful. 4. It is handy to be able to switch off/on scenery download at runtime, but here you only get about 5 of the 10 fps back. I see that once started the svn program remains loaded: this might be the cause. 5. The automatic refresh works well. There is an occasional grey-out. Disconcerting at first, but actually not a problem. This is a major advantage over Terrasync 5. To use the built-in option requires 2 additional and quite large dependencies which will need updating etc from time to time. For those of us that build FG this is a bit of a pain. 6. Both the internal and external variants seem to be using the external svn.exe. Each variant relies on a different build. Both builds are using all 4 cores here while the download is running (FG normally uses only 1 and a bit) I _think_ that's good to see. Do we require Windows users to have installed svn? I have - and that seems to be what is being used. 7. The external variant would seem to meet Csaba's design ideal, without any apparent drawback. Except from the fact that, AFAIKS, apart from the menu item, both the external and internal variants are the same. Perhaps that's not the case for Linux builds. Or perhaps I'm wrong in my assessment. If the 2 builds are in fact different perhaps the build variant internal/external could be made conditional. Summary. We seem to have ended up with 3 overlapping systems, all with advantages and disadvantages. Would it be possible to combine them? It certainly would not seem sensible to maintain all 3. 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
Re: [Flightgear-devel] JSBSim Functions for Propwash and Downwash [was: Clarification on YASim input]
On Sunday, June 19, 2011 09:58:48 AM Bertrand Coconnier wrote: 2011/6/19 Ron Jensen w...@jentronics.com: On Saturday 18 June 2011 21:00:41 Jon S. Berndt wrote: Here's an example from Hal's P-51D Mustang. This is from an old version, so it may have changed by now, but it illustrates the approach. In the aerodynamics section of the config file - but outside of any axis element - is this definition of qbar due to propwash: [Note: v is shorthand for value, and p is shorthand for property.] function name=aero/thrust-qbar_psf product v 0.5 /v p atmosphere/rho-slugs_ft3 /p pow sum p velocities/u-aero-fps /p product p propulsion/engine/prop-induced-velocity_fps /p v 2.0 /v /product /sum v 2.0 /v /pow /product /function I recently added this function to the A6M2 Zero. I placed it on CYdr (rudder yaw) and dCLdf (flap lift delta) as well as CMde. It makes the plane fly much, much better during the initial takeoff roll. It probably should be used with CMdf (pitch due to flaps) as well. But why are you multiplying propulsion/engine/prop-induced-velocity_fps by 2? The total velocity of the air flow in the far slipstream is V+2*w where V is the velocity of the airplane and w is the induced velocity as computed by the momentum theory. See the following discussion in the JSBSim mailing list : http://sourceforge.net/mailarchive/forum.php?thread_name=201004181833.32417 .ghmalau%40gmail.comforum_name=jsbsim-devel Bertrand. I just added this to the P-51D this morning. I have this setup so that the propwash affects Roll_moment_due_to_rudder Cldr, Pitch_moment_due_to_flaps Cmflap, Delta_Lift_due_to_flaps dCLflap, Lift_due_to_Elevator_Deflection CLde, Pitch_moment_due_to_gear Cmgear, Pitch_moment_due_to_elevator Cmde and Pitch_moment_due_to_alpha_horiz_tail Cmht. It had a significant impact on low speed high power handling. The rudder has authority much earlier during take off and the tail lifts in a very natural way during the take off run. Over all these changes made take offs easier and more natural feeling. This also made it less likely to ground loop during the engine runup. This is an easy enhancement to do and it appears to improve ground handling and take off significantly. I have these changes checked in to my fgdata GIT clone if anyone wants to try them. Hal -- 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
