[Flightgear-devel] Re: bo105 + patch
"Jim Wilson" <[EMAIL PROTECTED]> writes: > Those photos are really are nice! Wow! Mind me asking what you took > them with? i have a sony dsc-f717 digital camera (but now i want the dsc-f828 :-( ) the original pictures are 2560x1920 though. --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. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] bo105 + patch
Alex Romosan said: > recently i took a helicopter tour of san francisco, so i decided to > play a little bit more with the helicopter simulation in fgfs. it's a > lot of fun. a couple of things though. i use the keyboard mappings and > a mouse to "fly" and i noticed that the collective is mapped backwards > (up goes down and down goes up). also i find PageUp and PageDown to be > cumbersome, so i mapped the collective to the 1 and 2 keys (so i can > use my left hand). with these changes i managed to hover and even land > on top of the buildings in downtown sf. i've collected some of the > screenshots at http://caliban.lbl.gov/fgfs-heli/index.html. for > comparison (although we didn't land on top of any of the buildings :-( > ) the real pictures of sf are at > http://caliban.lbl.gov/sfhelitour/index.html. > Alex, Those photos are really are nice! Wow! Mind me asking what you took them with? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
It will be good if we can have some generic Graphic Interface for FlightGear. Not only can it be used on the CDU, it can also be used on other flight displays. Regards, Ampere On August 6, 2004 05:58 pm, Harald Johnsen wrote: > I wanted to redo at least the ehsi display (for the eye candy). > Now there is a few problems with 3D gauges : can't draw text, can't draw > dynamic > occurence of sprite/texture. Similar limitations with 2d gauges > concerning the > dynamic part. So I was thinking about draw to texture technique and some > graphical > api in Nasal to generate that kind of display... This would have delayed > the ehsi too much. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: bo105 + patch
> * Alex Romosan -- Saturday 07 August 2004 00:36: > > you can clearly hear the woman say that if you lift the collective you > > increase the pitch of the blades so you get more lift and you'll go > > up. so it would seem that collective up means helicopter goes up. > > maybe in austria they do it differently. > > Chauvinist bullshit ends every discussion, thanks. > Ok, I'm lost here. All he was doing was explaining what the instructor on the video was saying. Loosen up and unbolt, will ya? Jeeze. :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
Melchior FRANZ <[EMAIL PROTECTED]> writes: > * Alex Romosan -- Saturday 07 August 2004 00:36: >> you can clearly hear the woman say that if you lift the collective you >> increase the pitch of the blades so you get more lift and you'll go >> up. so it would seem that collective up means helicopter goes up. >> maybe in austria they do it differently. > > Chauvinist bullshit ends every discussion, thanks. as a matter of fact it does seem that european helicopters behave differently from american ones. http://www.helicopterpage.com/html/terms.html would seem to indicate the rotor spins in different directions. there is a nice description there of the takeoff procedure. the relevant passage is: As you increase collective pitch, you need to push the left pedal (In American helicopters...right pedal for non-American models) to counteract the torque you generate by increasing pitch. and on the page describing the forces at work http://www.helicopterpage.com/html/forces.html the author states: The thrust it produces tends to push the aircraft sideways at a hover. We compensate for this by adding left cyclic control inputs (On American Helicopters, the opposite in foreign manufactured aircraft, because their rotor systems turn the opposite way from ours). This makes the helicopter hang left skid, or wheel, low at a hover. so i am not sure why you are upset. i thought the same might apply to the collective. --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. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: bo105 + patch
i am not sure what the collective has to do with the throttle. if i understand this correctly, the collective changes the pitch of the rotor blades. i thought helicopters don't have a throttle the way fixed wing aircraft do: i.e. the engine is always at a constant rpm. but then i am not a helicopter pilot so i might be wrong. the collective controls the pitch of the rotor blades, yes, but since the air drag increases with the pitch the throttle of the engine also have to be increased to hold the rotor rpm in 'the green arc' (eg. for the bo105 is it at 450 RPM) . This is made by a mechanical device called correlator, in some piston driven helis an electronic govenor prevents additionally rpm drops (due to the significant lower rpm of a piston engine, the engine would full stop, not so nice...). In Flight Simulators the collective is usually laid on the throttle due to the limitations of input devices (joysticks). Regards Ron ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
* Alex Romosan -- Saturday 07 August 2004 00:36: > you can clearly hear the woman say that if you lift the collective you > increase the pitch of the blades so you get more lift and you'll go > up. so it would seem that collective up means helicopter goes up. > maybe in austria they do it differently. Chauvinist bullshit ends every discussion, thanks. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: bo105 + patch
Alex Romosan wrote: > Melchior FRANZ <[EMAIL PROTECTED]> writes: > > > * Alex Romosan -- Friday 06 August 2004 21:31: > >> and i noticed that the collective is mapped backwards > >> (up goes down and down goes up). > > > > Yes, and that's the way it should be and there's no way in hell to have > > this changed. If you don't like how helicopters work, don't fly them. There > > are enough fixed wing aircrafts. > > > > PLEASE DON'T APPLY! > > okay, then you should change the default so the helicopter starts with > the collective up so the helicopter doesn't just take off once you > start the rotor. as for the "there's no way in hell to have this > changed" i beg to differ: i've already made the change in my local > copy and i intend to keep that way :-) In helicopters, you push the collective to go down and pull to go up. PageUp is usually used to push, PageDown to pull. > >> also i find PageUp and PageDown to be > >> cumbersome, so i mapped the collective to the 1 and 2 keys (so i can > >> use my left hand). > > > > Collective is where all aircrafts have the throttle. That's because there's > > no alternative for the collective on joysticks other than the throttle. > > I don't mind *additional* keys for collective, though. > > > > > > i am not sure what the collective has to do with the throttle. if i > understand this correctly, the collective changes the pitch of the > rotor blades. i thought helicopters don't have a throttle the way > fixed wing aircraft do: i.e. the engine is always at a constant rpm. > but then i am not a helicopter pilot so i might be wrong. The yasim model has constant rpm. It is the throttle axis ( joystick, keyboard or mouse ) that is mapped on the collective. If you look at a 4 axis joystick, you push the lever to go down and pull it to go up. On a fixed wing aircraft, you push to increase throttle and pull to decrease. So here is the rationale for this. If you invert the way the collective react to input, you will be at the opposite of the real thing. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
* Alex Romosan -- Saturday 07 August 2004 00:28: > okay, then you should change the default so the helicopter starts with > the collective up so the helicopter doesn't just take off once you > start the rotor. Yes, a solution for keyboarders would be desirable. But it may only influence the keyboard config, not the FDM settings! Overriding the PgDn & PgUp keys with reversed meaning, and additionally defining 1 and 2 with the same meaning is fine with me. But the (FDM) throttle stays reversed! > as for the "there's no way in hell to have this > changed" i beg to differ: i've already made the change in my local > copy and i intend to keep that way :-) Heh ... that's cheating! > i am not sure what the collective has to do with the throttle. if i > understand this correctly, the collective changes the pitch of the > rotor blades. the main rotor blades, yes > i thought helicopters don't have a throttle the way > fixed wing aircraft do: i.e. the engine is always at a constant rpm. Wrong. Helicopters do have throttles. They are adjusted at startup and during flight. You see the normal operation range on the dual tacho. The bo105 does indeed not have a throttle yet. But it's important to use the throttle settings for the collective, as this is what the "input" system delivers for the js "throttle" lever (even if it's really used as a collective for the bo). > but then i am not a helicopter pilot so i might be wrong. I'm no helicopter pilot, either. But the modeler and maintainer of the bo105. I care for its (joystick controlled) behavior. I don't care that much for keyboard hacks. (You won't ever get happy with a helicopter controlled only by a keyboard, anyway. It's bad enough if you don't have pedals. ;-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
Melchior FRANZ <[EMAIL PROTECTED]> writes: > * Alex Romosan -- Friday 06 August 2004 21:31: >> and i noticed that the collective is mapped backwards >> (up goes down and down goes up). > > Yes, and that's the way it should be and there's no way in hell to have > this changed. If you don't like how helicopters work, don't fly them. There > are enough fixed wing aircrafts. > > PLEASE DON'T APPLY! one more thing. i just went to http://science.howstuffworks.com/helicopter6.htm and they have a video on how the collective control works (http://static.howstuffworks.com/mpeg/heli-collective.mpg). you can clearly hear the woman say that if you lift the collective you increase the pitch of the blades so you get more lift and you'll go up. so it would seem that collective up means helicopter goes up. maybe in austria they do it differently. --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. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
Melchior FRANZ <[EMAIL PROTECTED]> writes: > * Alex Romosan -- Friday 06 August 2004 21:31: >> and i noticed that the collective is mapped backwards >> (up goes down and down goes up). > > Yes, and that's the way it should be and there's no way in hell to have > this changed. If you don't like how helicopters work, don't fly them. There > are enough fixed wing aircrafts. > > PLEASE DON'T APPLY! okay, then you should change the default so the helicopter starts with the collective up so the helicopter doesn't just take off once you start the rotor. as for the "there's no way in hell to have this changed" i beg to differ: i've already made the change in my local copy and i intend to keep that way :-) > >> also i find PageUp and PageDown to be >> cumbersome, so i mapped the collective to the 1 and 2 keys (so i can >> use my left hand). > > Collective is where all aircrafts have the throttle. That's because there's > no alternative for the collective on joysticks other than the throttle. > I don't mind *additional* keys for collective, though. > > i am not sure what the collective has to do with the throttle. if i understand this correctly, the collective changes the pitch of the rotor blades. i thought helicopters don't have a throttle the way fixed wing aircraft do: i.e. the engine is always at a constant rpm. but then i am not a helicopter pilot so i might be wrong. --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. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
* Alex Romosan -- Friday 06 August 2004 21:31: > and i noticed that the collective is mapped backwards > (up goes down and down goes up). Yes, and that's the way it should be and there's no way in hell to have this changed. If you don't like how helicopters work, don't fly them. There are enough fixed wing aircrafts. PLEASE DON'T APPLY! > also i find PageUp and PageDown to be > cumbersome, so i mapped the collective to the 1 and 2 keys (so i can > use my left hand). Collective is where all aircrafts have the throttle. That's because there's no alternative for the collective on joysticks other than the throttle. I don't mind *additional* keys for collective, though. > http://caliban.lbl.gov/fgfs-heli/index.html On the positive side: nice screenshots! :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FMC
> Would it work to have one node in the property tree that would contain > the text on the CDU display ? > The 3D cockpit could listen for changes to this node and when one > happens, update the CDU display in the 3D cockpit... I like this idea, the text could be use for the FG cockpit or for some external CRT CDU. Except that the 3D cockpit can't handle text display atm. The 2D panel can. > Using a dynamic - non library-based - approach, possibly utilizing > Nasal for it, would probably be preferable if all the stuff is available > within the Nasal scope, that way one could easily borrow fragments of > code from other FMC implementations and add it to your own FMC. > ... My first idea was to write everything in Nasal ;) But due to some limitations in FG I have decided to start with an external FMC. Once it start to work I'll see how to make a buildin version. We are talking of an FMC but of course I wanted to redo at least the ehsi display (for the eye candy). Now there is a few problems with 3D gauges : can't draw text, can't draw dynamic occurence of sprite/texture. Similar limitations with 2d gauges concerning the dynamic part. So I was thinking about draw to texture technique and some graphical api in Nasal to generate that kind of display... This would have delayed the ehsi too much. > So, you'd mainly want to have access to all the relevant data, > the first thing that comes to mind would be functions to > interactively retrieve data from the navaids/airports file > in order to deal with those value accordingly, I don't think > that Nasal can already retrieve such data !? It's not difficult to add a few interfaces to acces this data. Even waypoints can allready be added just by touching the right property but the code in auto_gui.cxx is too restrictive about the type of wp one can insert. > In order to really determine what data and functions to access > it would be necessary, one would first need to look into a > FMC manual and find out what data sources are being used to > compute the stuff, OR what -flightgear based data- could > ALTERNATIVELY be used for that purpose. FG has the needed databases for the routes (airports, runways, nav, airways). > here, but actually there's still a bit more to it - which is probably > easier to find if you really get your hand on a FMS (training) manual, > actually that would be quite a sufficient source because you could > design the whole FMS -> page by page <- after it. I am looking the web to find the information and I try to understand the different pages. Some are obvious, some not, I don't have a real manual. And of course I never used a real FMC. > Another idea I just had: Why not put all the general algorithms needed > in an average FMC into a library (possibly as part of SimGear). > Things like performance calculations, (access to) route databases, input > validation (eg: airport code exists?, does this airport have a runway > xxR?),routing calculations,... > > This library could then be used/linked to build an FMC, either withing fgfs our > as a standalone program. Sure, and the external version is allready using part of FG code, as is or modified. When we are more advanced in the project we will see where to put back all the adds. > An approach like the one suggested by Jim would certainly have > the potential to add many variations of FMCs simply because it > would be mainly a thing of specifying the appeareance and logics > using a XML file with some Nasal code. Right. > Or... how about implementing it outside of flightgear at first and then > hooking it in when the code is somewhat stable? Yes. > Maybe Harald can provide some more details about what he want to > take into consideration and if there are any things that weren't > yet mentioned in that thread. Thanks for the feedback. Concerning the implementation of the fmc I will continue with the external version for now because I think it's the one that can be ready the first in time. As I said before I don't have all the knowledge to build it enterely by myself so I will need a lot of feedback at the beginning (the fonctions of the fmc but also the look and feel). The gui (with skins) and the ability to build new looks/functionalities with XML config and nasal code is a great idea. I talked a bit about the ehsi allready, I don't know how to enhance the one in FG without using opengl code. Harald. ps: I hope you can read me, english is not my first tongue. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] bo105 + patch
On Fri, 06 Aug 2004 12:31:13 -0700 Alex Romosan <[EMAIL PROTECTED]> wrote: > > i've collected some of the > screenshots at http://caliban.lbl.gov/fgfs-heli/index.html. These are gorgeous, my compliments. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpcEQo6DzTJz.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] bo105 + patch
Alex Romosan wrote: > i've collected some of the > screenshots at http://caliban.lbl.gov/fgfs-heli/index.html. for > comparison (although we didn't land on top of any of the buildings :-( > ) the real pictures of sf are at > http://caliban.lbl.gov/sfhelitour/index.html. The screenshots are nice but I love the real pictures. They are already one my harddisk for my next modeling session. The fog going down the mountain is really amazing. BTW: I really doubt the real building top are so flat it is possible to land an heli on them. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Will someone volunteer to draw diagrams?
Ampere K. Hardraade wrote: > One more: > http://www.fas.org/man/dod-101/sys/ac/Fig1big.JPG > > Regards, > Ampere > > On August 7, 2004 03:36 pm, Ampere K. Hardraade wrote: > > That question was asked on this page: > > http://flightgear.org/Docs/fgfs-model-howto.html > > > > There is no need for someone to draw the diagrams anymore. I have > > subumbled across one: > > http://www.fas.org/man/dod-101/sys/ac/Fig2big.JPG Could you add the sign of the directions ? I mean -X <-> +X, -Y <> +Y Thanks, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
"Curtis L. Olson" <[EMAIL PROTECTED]> writes: > Great pictures and screenshots. If you have one or two screenshots > you are especially fond of, it might be worth putting them on the FG > page since I haven't updated screen shots in quite some time. i really like http://caliban.lbl.gov/fgfs-heli/fgfsheli05.jpg and http://caliban.lbl.gov/fgfs-heli/fgfsheli23.jpg. i have the original fgfs screendumps in 1600x1200 resolutions if you want them. --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. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Will someone volunteer to draw diagrams?
One more: http://www.fas.org/man/dod-101/sys/ac/Fig1big.JPG Regards, Ampere On August 7, 2004 03:36 pm, Ampere K. Hardraade wrote: > That question was asked on this page: > http://flightgear.org/Docs/fgfs-model-howto.html > > There is no need for someone to draw the diagrams anymore. I have > subumbled across one: > http://www.fas.org/man/dod-101/sys/ac/Fig2big.JPG > > Regards, > Ampere > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Will someone volunteer to draw diagrams?
That question was asked on this page: http://flightgear.org/Docs/fgfs-model-howto.html There is no need for someone to draw the diagrams anymore. I have subumbled across one: http://www.fas.org/man/dod-101/sys/ac/Fig2big.JPG Regards, Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] bo105 + patch
Alex Romosan wrote: recently i took a helicopter tour of san francisco, so i decided to play a little bit more with the helicopter simulation in fgfs. it's a lot of fun. a couple of things though. i use the keyboard mappings and a mouse to "fly" and i noticed that the collective is mapped backwards (up goes down and down goes up). also i find PageUp and PageDown to be cumbersome, so i mapped the collective to the 1 and 2 keys (so i can use my left hand). with these changes i managed to hover and even land on top of the buildings in downtown sf. i've collected some of the screenshots at http://caliban.lbl.gov/fgfs-heli/index.html. for comparison (although we didn't land on top of any of the buildings :-( ) the real pictures of sf are at http://caliban.lbl.gov/sfhelitour/index.html. Great pictures and screenshots. If you have one or two screenshots you are especially fond of, it might be worth putting them on the FG page since I haven't updated screen shots in quite some time. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] bo105 + patch
recently i took a helicopter tour of san francisco, so i decided to play a little bit more with the helicopter simulation in fgfs. it's a lot of fun. a couple of things though. i use the keyboard mappings and a mouse to "fly" and i noticed that the collective is mapped backwards (up goes down and down goes up). also i find PageUp and PageDown to be cumbersome, so i mapped the collective to the 1 and 2 keys (so i can use my left hand). with these changes i managed to hover and even land on top of the buildings in downtown sf. i've collected some of the screenshots at http://caliban.lbl.gov/fgfs-heli/index.html. for comparison (although we didn't land on top of any of the buildings :-( ) the real pictures of sf are at http://caliban.lbl.gov/sfhelitour/index.html. attached is the patch: ? bo105.patch cvs diff: Diffing . Index: bo105-set.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/bo105/bo105-set.xml,v retrieving revision 1.10 diff -u -r1.10 bo105-set.xml --- bo105-set.xml 6 Aug 2004 11:12:32 - 1.10 +++ bo105-set.xml 6 Aug 2004 19:25:11 - @@ -153,6 +153,28 @@ + +1 +Collective Down + + nasal + + controls.incThrottle(-0.01, -1.0) + + + + + +2 +Collective Up + +nasal + +controls.incThrottle(0.01, 1.0) + + + + Index: bo105.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/bo105/bo105.xml,v retrieving revision 1.9 diff -u -r1.9 bo105.xml --- bo105.xml 6 Aug 2004 11:12:33 - 1.9 +++ bo105.xml 6 Aug 2004 19:25:11 - @@ -34,7 +34,7 @@ - cvs diff: Diffing Instruments cvs diff: Diffing Instruments/asi cvs diff: Diffing Instruments/tach cvs diff: Diffing Models --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. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler wrote: On Sat, Aug 07, 2004 at 12:51:02PM -0400, Ampere K. Hardraade wrote: I think newer Airbus aircrafts have CDU's that have a more advanced GUI. http://www.flug-revue.rotor.com/FRheft/FRHeft04/FRH0401/FR0401c1.JPG looks like the A380. Is the overhead panel really a screen ? It looks like a big LC Display... yes it is, but not in the actual aircraft - many of these preview pictures are based on computer generated images for media purposes, on the other hand there are also simulators being developed that cannot yet make use of the real hardware and hence seem to use a workaround - using a LCD (touchscreen) as the overhead panel does reduce development costs, you don't need to use -not yet existing- hardware but can rather display a basic representation of the controls that are supposed to be available and can easily integrate an interface with the rest of the simulator components, but there are more recent pictures of the A380 available at airbus.com. --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler wrote: On Fri, Aug 06, 2004 at 02:26:12PM +0200, Boris Koenig wrote: x11 yes, but what if not OpenGL capable. well, in that specific example I was referring to the case where a secondy machine would running dedicatedly for the purpose of displaying a CDU for a FMS - so GENERALLY I would I migth have misunderstood you. I thought you meant running the CDU in a slaved fgfs. no, I was rather suggesting to use some basic xserver<->client mechanism to display graphics created and provided by FlightGear ON EXTERNAL hardware - without the need for that hardware to be sophisticated, using network compression there would not even be the need for much bandwidth, in particular if you take into account that it would be mainly the screen component of a CDU that needs regular refreshing, so much of the actual data transmission could be conditionalized. Ususally, homebuilt CDUs consist of a small LCD w/ TV or VGA interface, the pushbuttons and a piece of plastic resembling the CDU panel. Use an older PC to drive the LCD with a CDU/FMC software running on it (or remotely if using X11) is the latter really an already established mechanism, I was really under the impression for it to be a spontaneous idea :-) SimGear itself is rather meant to provide a generic framework for simulations - so, the things that you are mentioning would be rather specific to flight simulator applications hence it would certainly make more sense to directly integrate it into FG itself. If you look at some stuff in SimGear, you'll see that there are flightsim specific things... and if someone wanted to write a FMS procedure trainer, he could link simgeear in, but wouldn't need any flightgear stuff. AFAIR, Flightgear doesn't build any libs that are used by 3rd party programs. I see your point To me, SimGear seems the perfect for the kind of routines I mentioned. but see my previous post: using SimGear as a backend for the calculations there would not be a reason to drop the mainly Nasal based approach for the actual implementation of the logics involved - which would then have many advantages talking of flexibility. In order to really determine what data and functions to access it would be necessary, one would first need to look into a FMC manual and find out what data sources are being used to AFAIK FMCs (at least the ones used onboard Boeings) use airdata, IRS, and possibly GPS. They can control (nav-)radio tuning, ACARS... > They interface with the autopilot, flight control computer and probably > a bunch more. > I also remember something about weight&balance. yes sure, that's the common sense knowledge that most of us have here, but actually there's still a bit more to it - which is probably easier to find if you really get your hand on a FMS (training) manual, actually that would be quite a sufficient source because you could design the whole FMS -> page by page <- after it. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler wrote: On Fri, Aug 06, 2004 at 02:34:07PM -, Jim Wilson wrote: ... waiting for a decent open source B744 FMC implementation :) I'd say that would not really that much depend on the availabilty of a "FMC/CDU" SDK but rather getting your hands on the right docs, as soon as these have been collected it should be much more realistic to that done, I think the idea is great - so, gathering all available information and determining what needs to be done is certainly something that could come in to actually develop the mentioned "FMC SDK" - because you could use a test implementation of a 737/747 FMS in order to determine the needs and architectural modifications required. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler wrote: On Fri, Aug 06, 2004 at 01:37:11AM +0200, Boris Koenig wrote: Regarding the GUI, this may be really mainly about adding support for skins and defining clickable regions and possibly different states of buttons - but I would not be that much in favour of using basic Yes, and this would not depend whether the FMC in internal or external to fgfs. That's somewhat correct, one could certain re-use such code if it was general enough and could then optionally integrate it natively into FlightGear as soon as it's mature enough for that purpose. Most of the internal logics could certainly be very well handled using Nasal that then accesses the flight parameters via the Property Tree directly. The maths involved for the FMC calculations should also be possible to be realized using Nasal, I'd think - and then there'd still be the option of adding the more complicated stuff as a separate command. Yeah, Nasal seems to be a way to implement a FMC within flightgear. IF you really intend to link to SimGear (I read about it in the thread) you could still use Nasal even externally, as Nasal is not only a separate linkable lib available but also seems to be integrated into SimGear directly, so there's no reason to differentiate between a FlightGear based implementation and a SimGear based version I think. That way the CDU could be implemented using some basic skinning mechanism and defining those regions that are "clickable" and where Nasal should act and then there would need to be a general control for screen output, possibly defining some basics like fonts, rows/colums and available colors - as well as possibly some minor controls like LEDs to display a status information or anything like that. This is something you'd wanna have in both variants, FMC implemented inside of fgfs or outside as a standalone program. Maybe Harald can provide some more details about what he want to take into consideration and if there are any things that weren't yet mentioned in that thread. I guess the person who wirtes the software will ultimately decide. Right, but as soon as it's ready there shouldn't be any reasons for other people to add custom stuff, stuff which might not have been taken into account in the original version - a modular implementation would then of course come in handy. Or... how about implementing it outside of flightgear at first and then hooking it in when the code is somewhat stable? dito :-) I like the unix philosophy: for every task a seperate program that does only the one thing its designed for. ( make each program do one thing well) I know this is not always appliceable esp. for a flightsimulator, but it could be a good idea in this case. I don't even mention that this whole thread ultimately brings us back to the plugins discussion :-) --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Co-Pilot controls.
I'm working on a Beech 99 here and I see evidence that the co-pilot brakes operate independently of the pilot brakes. The two yokes I believe are linked together so when one moves, the other moves, as do the rudder pedals, but it appears that the two sets of brakes operate independently. Does anyone have any objection to me adding right/left co-pilot brake values to the FGNetCtrls structure? Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
On Sat, Aug 07, 2004 at 12:51:02PM -0400, Ampere K. Hardraade wrote: > I think newer Airbus aircrafts have CDU's that have a more advanced GUI. > > http://www.flug-revue.rotor.com/FRheft/FRHeft04/FRH0401/FR0401c1.JPG looks like the A380. Is the overhead panel really a screen ? It looks like a big LC Display... Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
I think newer Airbus aircrafts have CDU's that have a more advanced GUI. http://www.flug-revue.rotor.com/FRheft/FRHeft04/FRH0401/FR0401c1.JPG Regards, Ampere On August 6, 2004 08:26 am, Boris Koenig wrote: > I am not aware of any current CDUs that really > make use of advanced graphics - most CDUs could be really > implemented by using a simple alpha-numerical display mechanism > without the need to really draw advanced graphics. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
On Fri, Aug 06, 2004 at 02:26:12PM +0200, Boris Koenig wrote: > > x11 yes, but what if not OpenGL capable. > > well, in that specific example I was referring to the case > where a secondy machine would running dedicatedly for the > purpose of displaying a CDU for a FMS - so GENERALLY I would I migth have misunderstood you. I thought you meant running the CDU in a slaved fgfs. > I see - but even though this was mainly only a thought.I really > think that there's no need for any OpenGL requirements in order > to display something as trivial as a CDU. Yes. That was my point. > > Or homebuilt cheap external CDUs :-) > > don't know about these, if you've any experience with these > it might be interesting, maybe just for the sake of adding well, I have some parts at home. Not finshed. Doing the electronics interface currently. (details: http://cockpit.varxec.net/electronics/PHCC.html) Ususally, homebuilt CDUs consist of a small LCD w/ TV or VGA interface, the pushbuttons and a piece of plastic resembling the CDU panel. Use an older PC to drive the LCD with a CDU/FMC software running on it (or remotely if using X11) > support to deal with that stuff, there's probably some > basic specification using RS232 or USB for data exchange, > I'd guess ? both is possible. > SimGear itself is rather meant to provide a generic framework for > simulations - so, the things that you are mentioning would be rather > specific to flight simulator applications hence it would certainly > make more sense to directly integrate it into FG itself. If you look at some stuff in SimGear, you'll see that there are flightsim specific things... and if someone wanted to write a FMS procedure trainer, he could link simgeear in, but wouldn't need any flightgear stuff. AFAIR, Flightgear doesn't build any libs that are used by 3rd party programs. To me, SimGear seems the perfect for the kind of routines I mentioned. > In order to really determine what data and functions to access > it would be necessary, one would first need to look into a > FMC manual and find out what data sources are being used to AFAIK FMCs (at least the ones used onboard Boeings) use airdata, IRS, and possibly GPS. They can control (nav-)radio tuning, ACARS... They interface with the autopilot, flight control computer and probably a bunch more. I also remember something about weight&balance. > compute the stuff, OR what -flightgear based data- could > ALTERNATIVELY be used for that purpose. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
On Fri, Aug 06, 2004 at 02:34:07PM -, Jim Wilson wrote: > Maybe something like that could work. There are some good suggestions in this > thread, but you know in the end these details are up to whoever takes the > initiative to write the code. There will always be room for further contribution. Yes. (I wrote that in my other post in this thread) > Which reminds me that I forgot to make it clear that I am very excited to hear > of this proposal. This feature is something we really need, especially for > the airliners. Yes, same here :-) ... waiting for a decent open source B744 FMC implementation :) Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler said: > Another idea I just had: Why not put all the general algorithms needed > in an average FMC into a library (possibly as part of SimGear). > Things like performance calculations, (access to) route databases, input > validation (eg: airport code exists?, does this airport have a runway > xxR?),routing calculations,... > > This library could then be used/linked to build an FMC, either withing fgfs our > as a standalone program. Maybe something like that could work. There are some good suggestions in this thread, but you know in the end these details are up to whoever takes the initiative to write the code. There will always be room for further contribution. Which reminds me that I forgot to make it clear that I am very excited to hear of this proposal. This feature is something we really need, especially for the airliners. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler wrote: On Fri, Aug 06, 2004 at 01:54:06AM +0200, Boris Koenig wrote: Of course, if there's running X11 on that other machine, FlightGear could still provide the graphics for such an externally displayed CDU via network without the need to explicitly be running on that machine :-) x11 yes, but what if not OpenGL capable. well, in that specific example I was referring to the case where a secondy machine would running dedicatedly for the purpose of displaying a CDU for a FMS - so GENERALLY I would doubt that for the display of a CDU there's any openGL stuff necessary, I am not aware of any current CDUs that really make use of advanced graphics - most CDUs could be really implemented by using a simple alpha-numerical display mechanism without the need to really draw advanced graphics. That would exclude running anthoer flightgear instance on that machine. (I'm thinking about old cheap computers. Often those you can get for free) I see - but even though this was mainly only a thought.I really think that there's no need for any OpenGL requirements in order to display something as trivial as a CDU. Indeed, most of the graphics being displayed would be mainly non-active, such as for example the keyboard graphics - which at most _could_ be animated in very basic ways to indicate that a button's been pressed. The only thing that would really dynamically change during runtime would be mainly the screen component on the virtual CDU as well as some minor LED icons. professional users who are building their own cockpits or simply those users that are using those expensive external standalone CDU units. Or homebuilt cheap external CDUs :-) don't know about these, if you've any experience with these it might be interesting, maybe just for the sake of adding support to deal with that stuff, there's probably some basic specification using RS232 or USB for data exchange, I'd guess ? On the other hand I think one has to ponder about the pros & cons, and certainly it would be more of an advantage for the AVERAGE user to have a GENERAL xml-configurable mechanism to add support for FMCs/CDUs to FlightGear than having merely a way to code your own stuff by accessing the property tree via network. Another idea I just had: Why not put all the general algorithms needed in an average FMC into a library (possibly as part of SimGear). Things like performance calculations, (access to) route databases, input validation (eg: airport code exists?, does this airport have a runway xxR?),routing calculations,... SimGear itself is rather meant to provide a generic framework for simulations - so, the things that you are mentioning would be rather specific to flight simulator applications hence it would certainly make more sense to directly integrate it into FG itself. On the other hand, I really think that it's mainly about having on the one hand the right data available and on the other hand doing the right calculation with that data. Most calculation can probably already be done using Nasal, there were some examples on the Nasal webpage at plausible.org using a maths function, IIRC. Using a dynamic - non library-based - approach, possibly utilizing Nasal for it, would probably be preferable if all the stuff is available within the Nasal scope, that way one could easily borrow fragments of code from other FMC implementations and add it to your own FMC. Also, this would not require any changes to the FlightGear core, but rather new additions to a FMC could easily be integrated using only a scripting language. So, you'd mainly want to have access to all the relevant data, the first thing that comes to mind would be functions to interactively retrieve data from the navaids/airports file in order to deal with those value accordingly, I don't think that Nasal can already retrieve such data !? In order to really determine what data and functions to access it would be necessary, one would first need to look into a FMC manual and find out what data sources are being used to compute the stuff, OR what -flightgear based data- could ALTERNATIVELY be used for that purpose. For example, one would certainly not want to create virtual GPS or IRS units in order to simulate behaviour such as mapshifts in the beginning. Rather, one could directly use the positional data for these computations. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
On Fri, Aug 06, 2004 at 01:54:06AM +0200, Boris Koenig wrote: > Of course, if there's running X11 on that other machine, > FlightGear could still provide the graphics for such an > externally displayed CDU via network without the need to > explicitly be running on that machine :-) x11 yes, but what if not OpenGL capable. That would exclude running anthoer flightgear instance on that machine. (I'm thinking about old cheap computers. Often those you can get for free) > professional users who are building their own cockpits or > simply those users that are using those expensive external > standalone CDU units. Or homebuilt cheap external CDUs :-) > On the other hand I think one has to ponder about the pros & cons, > and certainly it would be more of an advantage for the AVERAGE > user to have a GENERAL xml-configurable mechanism to add support > for FMCs/CDUs to FlightGear than having merely a way to code > your own stuff by accessing the property tree via network. Another idea I just had: Why not put all the general algorithms needed in an average FMC into a library (possibly as part of SimGear). Things like performance calculations, (access to) route databases, input validation (eg: airport code exists?, does this airport have a runway xxR?),routing calculations,... This library could then be used/linked to build an FMC, either withing fgfs our as a standalone program. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
On Fri, Aug 06, 2004 at 01:37:11AM +0200, Boris Koenig wrote: > Regarding the GUI, this may be really mainly about adding support for > skins and defining clickable regions and possibly different states > of buttons - but I would not be that much in favour of using basic Yes, and this would not depend whether the FMC in internal or external to fgfs. > Most of the internal logics could certainly be very well handled > using Nasal that then accesses the flight parameters via the > Property Tree directly. The maths involved for the FMC calculations > should also be possible to be realized using Nasal, I'd think - > and then there'd still be the option of adding the more complicated > stuff as a separate command. Yeah, Nasal seems to be a way to implement a FMC within flightgear. > That way the CDU could be implemented using some basic skinning > mechanism and defining those regions that are "clickable" and where > Nasal should act and then there would need to be a general control > for screen output, possibly defining some basics like fonts, > rows/colums and available colors - as well as possibly some minor > controls like LEDs to display a status information or anything > like that. This is something you'd wanna have in both variants, FMC implemented inside of fgfs or outside as a standalone program. Maybe it could be implemted similarly to jsbsim where there is a standalone version plus a compiled-into-fgfs version... I guess the person who wirtes the software will ultimately decide. Or... how about implementing it outside of flightgear at first and then hooking it in when the code is somewhat stable? > An approach like the one suggested by Jim would certainly have > the potential to add many variations of FMCs simply because it > would be mainly a thing of specifying the appeareance and logics > using a XML file with some Nasal code. Nothing that could'nt be done outside of fgfs... :-) I like the unix philosophy: for every task a seperate program that does only the one thing its designed for. ( make each program do one thing well) I know this is not always appliceable esp. for a flightsimulator, but it could be a good idea in this case. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] updated ThrustMaster FCS config
Eric L Hathaway wrote: Hello all, The following patch updates the ThrustMaster FCS joystick configuration. I have "Nasal-ized" the joystick bindings, drawing ideas from the Cyborg-Gold-3d-USB configuration file. I also changed some of the bindings, so the joystick setup is more like the default four-axis-joystick config. When I submitted the original config file, I had the hat switch bound to the rudder and elevator trim. Since the vast majority (all?) of the other joystick configs use the hat switch to control view direction, I think it would be best for the defaults for this joystick to conform to the rest in order to obey the "principle of least surprise" for the unsuspecting user. Good to see all "programmable" joysticks are adopting the same layout and functionality. This has been committed to CVS. Thanks Eric! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fixed xml for Saitek Cyborg Evo joystick
Dave Perry wrote: I am attaching an edit of this file that should work with either Windows or Linux. As of a few days ago, the CVS file did not work at all. This has been committed now. Thanks! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
