Re: [Flightgear-devel] RFC: Keybinding Changes for Powerplant
Alex Perry writes: Comments? Objections? Cheers of encouragement? Fine by me. Where you want to put elevator trim ? Where would it be convenient? We have to consider two cases: desktop computers with numeric keypads, and notebooks without. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFC: Keybinding Changes for Powerplant
In fact, it you're going to fuss about a change in CG or drag when the gear cycles ( about 4-10 secs) then you should really do something about realistic engine performance for a two or three hour cruise. Might I suggest some sort of random number generator, throw the dice for each engine, and set the performance characteristics. Now it's up to the pilot to set the right mixture, prop setting, rpm, manifold to get the best performance or best economy. go to warp and see how you did? I'd say first things first. We have various levels within the flight model and we are getting somewhat spotty with high detail in some areas and no detail in others. I'd sooner wait with this one just a little bit until we get all the bugs worked out of the current level. I suppose we ought to create a list of priorities and basic capabilities we are lacking and go for those before we go on to the finer details like realism and random failures. You think? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFC: Keybinding Changes for Powerplant
David Megginson writes: I'd like to propose changing some of the default keybindings. Most PC keyboards have a 3x2 cluster of keys at the top, with Insert/Delete on the left, Home/End in the middle, and Page Up/Page down on the right. I'd like to rebind those as follows: Are you sure that GLUT maps these keys differently then the ones on the numpad ?? Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFC: Keybinding Changes for Powerplant
Norman Vine writes: Are you sure that GLUT maps these keys differently then the ones on the numpad ?? Unfortunately, not -- that's why I wanted to check. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFC: Keybinding Changes for Powerplant
I proposed that as an example, but you need to design in the ability for expansion now or you might wind up ripping out a lot of code later. IMHO you need to start worrying about weight and balance now, before some of the other items on the table. I don't see anything to account for # of pax and crew, cargo/luggage, fuel load, and tips. Fuel load, tanks, fuel drain, etc. are accounted for. Additional weighted objects are not a problem. Seriously, the class heirarchy and design of JSBSim allows for expansion already quite well. We are always open to suggestions, which is one reason the design we have is so open. Modeling more complex systems is not a geometric progression, it may not even be exponential, NP? Sorry, I'm preaching to the choir. Given the design we have evolved to this point, modeling more complex systems really ought to be fairly painless. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFC: Keybinding Changes for Powerplant
I suppose we ought to create a list of priorities and basic capabilities we are lacking and go for those before we go on to the finer details like realism and random failures. You think? I proposed that as an example, but you need to design in the ability for expansion now or you might wind up ripping out a lot of code later. IMHO you Oh, I forgot to add this: modeling realism and malfunction code isn't really too bad. This feature specifically won't require much in the way of rework or anything even if we wait. I've had this in mind for some time (I have modeled malf.s for shuttle training simulators, USAF, NASA, etc. so this is very familiar territory). To model malfunctions properly, however, the correct behaviour has to first be there. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFC: Keybinding Changes for Powerplant
David Megginson writes: Are you sure that GLUT maps these keys differently then the ones on the numpad ?? Unfortunately, not -- that's why I wanted to check. AFAIK It does NOT ! see $glut_src / test / glut / keyup_test.c I propose we investigate runtime assignment to the keyboard esp the number pad as it is such a natural interface for many things. ie- we start with a 'standard' binding what we have now and then assign keys to 'push' a different set of functions we need a general purpose 'pop' a set of bindings too. then we can use the numpad to control everything by just 'pushing' the appropriate set of bindings. I have found that in practice this is quite easy todo and after a little getting use to is a very 'natural' interface with great flexibility. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Keybinding Changes for Powerplant
Oh, I forgot to add this: modeling realism and malfunction code isn't really too bad. This feature specifically won't require much in the way of rework or anything even if we wait. I've had this in mind for some time (I have modeled malf.s for shuttle training simulators, USAF, NASA, etc. so this is very familiar territory). To model malfunctions properly, however, the correct behaviour has to first be there. So you can appreciate the redundancy ( there's that word again! ) that goes into a complex system and the interaction and possible configuration/states that might occur given a set of failures. In working on the glass displays, I'm seeing a lot of that in terms of the various display modes and configurations each panel can have depending on the flight segment and crew selected options, and haven't even begun to consider abnormal operations or anamolies. JW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Keybinding Changes for Powerplant
Yes, yes, my comment was not intended as a slam. No offense taken, and I didn't see it as a slam. I just wanted to communicate that we have thought of many of those things. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Keybinding Changes for Powerplant
John Wojnaroski writes: Some want to work spins, prop contact points, etc. But a LOT of accidents occur because the PIC failed to do a proper weight and balance, overloaded the A/C, and/or exceeded the CG limits. Something to consider - how about a weight and balance sheet to fill out before one can start engines ( it could be a file ), but no tickee no engine start. Surely it would be more realistic if the engines would happily start without filling out the weight and balance, but a random and possibly dangerous CG would be assigned... Cheers - Dave-- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Keybinding Changes for Powerplant
Dave Luff wrote: John Wojnaroski writes: Some want to work spins, prop contact points, etc. But a LOT of accidents occur because the PIC failed to do a proper weight and balance, overloaded the A/C, and/or exceeded the CG limits. Something to consider - how about a weight and balance sheet to fill out before one can start engines ( it could be a file ), but no tickee no engine start. Surely it would be more realistic if the engines would happily start without filling out the weight and balance, but a random and possibly dangerous CG would be assigned... I'd have to agree. Not that a computerized WB is a bad idea -- I think it'd be really nifty. But it strikes me that the appropriate training behavior for an out-of-spec c.g. would be to allow the pilot to take off just fine, and *cause* one of those pilot killing accidents. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
