Re: [Flightgear-devel] c310 origin
David Megginson wrote: OK, finally I understand the problem. What we need to do, then, is apply the euler angles to the CG rather than the origin when rotating the 3D model. We need only two steps: 1. have the FDMs report the current CG relative to the origin (if they don't already); and 2. add a couple of transforms to acmodel.cxx so that we use the CG as the centre of rotation. This will be especially nice for modelling out-of-balance situations (like 500lb of baggage in the back of a 172) -- everything will come out looking right. It will also be valuable for aircraft that have massive balance shifts, like a military aircraft dropping ordnance. I don't expect that this will be a big job. What does everyone else think? Ultimately we can ask the aero designers to add just *one* other location, being the (pre defined) 3D model location of origin. This takes the weight off of the 3D designers and places it where it belongs, at the back of the aero designes. The 3D model location of origin should be available *inside* the aero config file, but should be propagated to FlightGear. (All, if you ask me). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ~30 new GPL'd models that work w/ FlightGear
Arnt Karlsen wrote: Helicopters --- Bell AH-1S SuperCobra Kaman K1200 K-max Sikorsky UH-60 BlackHawk ..use/develop the fdm from http://autopilot.sourceforge.net/ ? I *think* we get the message by now ... ;-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c310 origin
Norman Vine [EMAIL PROTECTED] said: In your example you may not see the error but . What I meant was that offseting to the varible center of gravity wouldn't be visible either outside or inside the aircraft. The FDM already provides the attitude effects, it is the change in axes that wouldn't be noticable. Actually you know if we did offset the camera and model to center of gravity it could have a very minor negative effect. Assuming that some day we have a dialog to configure payload, we'll see the 3D model shift back and forth on the tarmac as we add fuel, passengers and luggage and the 3D origin changes :-) You certainly want to offset the camera to its real location if you ever want to be able to move your head inside of the cockpit That works already. It really is no big deal to do this just one translate per iteration of the main loop, and once implemented it will just work for all view modes Thats right. We just need to vector to the offset location and come up with the adjusted lon/lat/alt at that location. I just think that 3D model origin should be a fixed location with the x axis at the leading edge of the wing and the z axis going through the nose. The question is this: If the FDM's agree to use the nose as the origin, we'll have an offset to the 3D model's origin, right? Where would we put the setting so that it was available to both the model and the viewer, defined per aircraft type? IMHO it'd make the most sense to put the offset (from the nose or tail) to the 3D model origin location into the FDM's aircraft config xml file. This location should be on the leading edge of the wings and z axis centered on the nose as described above. The 3D modeler's could refer to that data for getting the model right, and the fdm should simply report lon/lat/alt at *that* location. This is how the YASim 747 currently works and it seems fine. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] c310 origin
IMHO it'd make the most sense to put the offset (from the nose or tail) to the 3D model origin location into the FDM's aircraft config xml file. This location should be on the leading edge of the wings and z axis centered on the nose as described above. The 3D modeler's could refer to that data for getting the model right, and the fdm should simply report lon/lat/alt at *that* location. This is how the YASim 747 currently works and it seems fine. Maybe I am off=base on this, or misunderstanding the problem, but in my previous experience with 3D modeling and IRIXGL some years ago one had to be careful where the origin of the 3D model was, and the order of rotation/translation. This is what I interpret your concern to be about. In the past day or two Tony, David, Andy, and myself have moved close (I think) to what the FDM can do to help 3D modelers place the model properly. If we can come up with a standard reference frame for the an aircraft model (insofar as it deals with the FDM), would this help? And since the CG can move during flight, we need a way to have a common anchored reference point for both 3D modelers and FDMs. The suggested standard reference frame for FDMs is: === X positive out the tail Y positive out the right side Z positive to complete the system, upward origin as desired or as specified in the manufacturers structural frame, or whatever ... but: KEY: The farthest forward point on the aircraft, i.e. nose, or prop hub, must be specified in the FDM config file, so the relationship between the FDM origin and 3D model origin can be obtained. Also, all measurements are in inches. === I have seen posts to the effect that there IS a problem with properly communicating the origin, and that this problem deals with rotating the 3D model as specified by the FDM Euler angles, but NOT accounting for the fact that the FDM assumes rotation about the CG, and the 3D model rotates about a different point, such that the CG moves improperly and perhaps puts the gear underground or something. Is this correct? Jon smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] c310 origin
On Sat, 2002-12-14 at 07:26, Jon Berndt wrote: IMHO it'd make the most sense to put the offset (from the nose or tail) to the 3D model origin location into the FDM's aircraft config xml file. This location should be on the leading edge of the wings and z axis centered on the nose as described above. The 3D modeler's could refer to that data for getting the model right, and the fdm should simply report lon/lat/alt at *that* location. This is how the YASim 747 currently works and it seems fine. Maybe I am off=base on this, or misunderstanding the problem, but in my previous experience with 3D modeling and IRIXGL some years ago one had to be careful where the origin of the 3D model was, and the order of rotation/translation. This is what I interpret your concern to be about. In the past day or two Tony, David, Andy, and myself have moved close (I think) to what the FDM can do to help 3D modelers place the model properly. If we can come up with a standard reference frame for the an aircraft model (insofar as it deals with the FDM), would this help? And since the CG can move during flight, we need a way to have a common anchored reference point for both 3D modelers and FDMs. The suggested standard reference frame for FDMs is: === X positive out the tail Y positive out the right side Z positive to complete the system, upward origin as desired or as specified in the manufacturers structural frame, or whatever ... but: KEY: The farthest forward point on the aircraft, i.e. nose, or prop hub, must be specified in the FDM config file, so the relationship between the FDM origin and 3D model origin can be obtained. Also, all measurements are in inches. === I have seen posts to the effect that there IS a problem with properly communicating the origin, and that this problem deals with rotating the 3D model as specified by the FDM Euler angles, but NOT accounting for the fact that the FDM assumes rotation about the CG, and the 3D model rotates about a different point, such that the CG moves improperly and perhaps puts the gear underground or something. Is this correct? Are we sure we want to put the 3D model origin to cg offsets in the FDM config file. IIRC, having multiple 3D models for any one aero model is pretty standard fare in the MSFS world. Jon -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] whoops
Umm the patch for the hsi and rmi was slightly broken. The c310-ifr-set.xml was not right, so I changed that and everything is working again. patch is here http://members.verizon.net/~vze3b42n/patch9.1.tar.gz updated screenshot http://members.verizon.net/~vze3b42n/fgfs-screen-001.jpeg Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] BA-609, V-22 derivative aircraft
Martin Spott wrote: This does not have to be as difficult as it is with the V-22. The Osprey is designed for being stuffed into _very_ small space below a ship's deck. If they had more space then it would have been possible to improve security simply by increasing the wing span, The problem, I think, is not in the wing span. In transition the aircraft is working around the stall speed for the wings. I would think that a larger wing would decrease rather than increase stability, no? Oh, you get heavily increased torque from the ailerons for manouverability and you get much more lift from large wings at low speed - especially because on the current design at least 90 % of the wing area suffers from the down-wind generated by the two the rotors, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c310 origin
Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: In your example you may not see the error but . What I meant was that offseting to the varible center of gravity wouldn't be visible either outside or inside the aircraft. The FDM already provides the attitude effects, it is the change in axes that wouldn't be noticable. Actually you know if we did offset the camera and model to center of gravity it could have a very minor negative effect. Assuming that some day we have a dialog to configure payload, we'll see the 3D model shift back and forth on the tarmac as we add fuel, passengers and luggage and the 3D origin changes :-) OK but when in tet to be implemented external 'flier mode' similar to the existing static external view, which should be tied to the Model Origin, you should see the difference in the effects of a rotation of the plane when the plane's Center of Gravity moves The question is this: If the FDM's agree to use the nose as the origin, we'll have an offset to the 3D model's origin, right? Yes but we don't care where it is as long as Model explicitly states where it is in reference to the 'bounding sphere' or 'bounding box' of the model Where would we put the setting so that it was available to both the model and the viewer, defined per aircraft type? in the Model-set.xml file, this way a FDM may be used by more then one model IMHO it'd make the most sense to put the offset (from the nose or tail) to the 3D model origin location into the FDM's aircraft config xml file. This location should be on the leading edge of the wings and z axis centered on the nose as described above. The 3D modeler's could refer to that data for getting the model right, and the fdm should simply report lon/lat/alt at *that* location. This is how the YASim 747 currently works and it seems fine. If we use a position relative to a 'bounding shape' then this can actually be determined at run time Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Request for updates on Developer Locations and FAQ
Man, I've been busy with real life lately[1][2], so I need you guys to tell me what I need to know in order to update the FAQ[3] and Developer Locations page[4]. If you have any questions you are tired of answering, send me the question and answer, and I'll work it into the FAQ. Some things have changed recently as well, so if you notice anything in the FAQ that is incorrect, please let me know. It's been a couple months since I've had a chance to actually play with FG, so I've sort of out of the loop. :-( Also, if you are a developer and wish to be listed on our locations page, follow the directions at the bottom of that page to get your info to me. Thanks for your help. [1] http://www.dilbert.com/comics/dilbert/archive/dilbert-20021206.html [2] I've actually been through that dilbert situation twice now, so I'm doing the work of 3 people these days. :-/ [3] http://flightgear.org/Docs/FlightGear-FAQ.html [4] http://unbeatenpath.net/software/fgfs/Developers/Developers.html -- Cameron Moore [ How can there be self-help groups? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] comments
[Flightgear-devel] patch and screenshot John Check [EMAIL PROTECTED] Fri, 13 Dec 2002 16:05:52 -0500 Previous message: [Flightgear-devel] patch and screenshot Next message: [Flightgear-devel] Fwd: Re: preferences.xml change Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] On Thursday 12 December 2002 4:45 pm, paul mccann wrote: I put a patch at my webserver for the hsi and rmi on the c310, if any one wants to try it. Maybe fix it up too. I was using fgfs version 9.1 for this. http://members.verizon.net/~vze3b42n/patch9.1.tar.gz This looks good. Do we have any objections to using this, or should we add this and keep the old one too? Comments? John Thanks for response and If it works correctly I set it up so it loads the old c310-vfr panel, with the changes I made. I renamed it c310-ifr and it loads from comand line with that. That way I did not mess up any of the other c310s'. I did it on the current 9.1 version of flightgear. Seems to work ok in the other aircraft too but the 3d cockpits were it border seems to wiggle a little. Don't know why that is? Paul Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] whoops
On Saturday 14 December 2002 12:17 pm, paul mccann wrote: Umm the patch for the hsi and rmi was slightly broken. The c310-ifr-set.xml was not right, so I changed that and everything is working again. patch is here http://members.verizon.net/~vze3b42n/patch9.1.tar.gz Cool thanks. I'll commit it shortly updated screenshot http://members.verizon.net/~vze3b42n/fgfs-screen-001.jpeg Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] comments
On Saturday 14 December 2002 1:06 pm, paul mccann wrote: [Flightgear-devel] patch and screenshot John Check [EMAIL PROTECTED] Fri, 13 Dec 2002 16:05:52 -0500 Previous message: [Flightgear-devel] patch and screenshot Next message: [Flightgear-devel] Fwd: Re: preferences.xml change Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] On Thursday 12 December 2002 4:45 pm, paul mccann wrote: I put a patch at my webserver for the hsi and rmi on the c310, if any one wants to try it. Maybe fix it up too. I was using fgfs version 9.1 for this. http://members.verizon.net/~vze3b42n/patch9.1.tar.gz This looks good. Do we have any objections to using this, or should we add this and keep the old one too? Comments? John Thanks for response and If it works correctly I set it up so it loads the old c310-vfr panel, with the changes I made. I renamed it c310-ifr and it loads from comand line with that. That way I did not mess up any of the other c310s'. I did it on the current 9.1 version of flightgear. Seems to work ok in the other aircraft too but the 3d cockpits were it border seems to wiggle a little. Don't know why that is? It has to do with precision, when the location is straddling the border of two pixels, the image jitters. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] c310 origin
Tony wrote: Are we sure we want to put the 3D model origin to cg offsets in the FDM config file. IIRC, having multiple 3D models for any one aero model is pretty standard fare in the MSFS world. The only thing we'd do different in JSBSim is to say where the nose/prop tip is. This would give a *known* common reference point between the two - and something that does not move over time as fuel is burned off. The question is: is this what the 3D modeler guys are looking for? Jon smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] c310 origin
Jon Berndt [EMAIL PROTECTED] said: IMHO it'd make the most sense to put the offset (from the nose or tail) to the 3D model origin location into the FDM's aircraft config xml file. This location should be on the leading edge of the wings and z axis centered on the nose as described above. The 3D modeler's could refer to that data for getting the model right, and the fdm should simply report lon/lat/alt at *that* location. This is how the YASim 747 currently works and it seems fine. Maybe I am off=base on this, or misunderstanding the problem, but in my previous experience with 3D modeling and IRIXGL some years ago one had to be careful where the origin of the 3D model was, and the order of rotation/translation. This is what I interpret your concern to be about. Nope. We've got that covered. What I'd like to see is the reported position data (lon/lat/alt) be at a location in the aircraft which lines up with the leading edge of the wing and on the longitudinal axis. For example, the light grey lines in this image more or less illustrate the kind of location (although this example is maybe slightly aft): http://www.spiderbark.com/fgfs/u3aorigin.png That really could be developed as a standard, and specified in the terms you suggest. However, we can translate any origin you choose. That one just seemed to be the easiest as it'll work for the current rendering code without incorporating new offsets. Really we just need the FDMs to agree on something. Or maybe not...maybe the idea of sharing 3DModel configs between FDMs (c310-jsbsim, c310-yasim pointing to the same model.xml) is impratical or too complex? Certainly if one FDM models gear compression and the other doesn't, that is an issue when it comes to configuring the 3d model. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] c310 origin
Jon Berndt [EMAIL PROTECTED] said: Tony wrote: Are we sure we want to put the 3D model origin to cg offsets in the FDM config file. IIRC, having multiple 3D models for any one aero model is pretty standard fare in the MSFS world. The only thing we'd do different in JSBSim is to say where the nose/prop tip is. This would give a *known* common reference point between the two - and something that does not move over time as fuel is burned off. The question is: is this what the 3D modeler guys are looking for? That would work and would need to be different for various models of the c310 since the nose length varies. It would be easiest if the fdm simply reported the lon/lat/alt at the point on the same longitudinal axis as the nose/proptip but back where the leading edge of the wing was. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] c310 origin
Really we just need the FDMs to agree on something. Or maybe not...maybe the idea of sharing 3DModel configs between FDMs (c310-jsbsim, c310-yasim pointing to the same model.xml) is impratical or too complex? Certainly if one FDM models gear compression and the other doesn't, that is an issue when it comes to configuring the 3d model. It's neither impractical nor complex. FWIW, there really is a standard already out there, and we use it. That is, the structural frame, as I have outlined before. The only problem I see is that the FDM and the 3D model rendering code need to have a static common point of reference - that's why I mentioned the farthest point forward, such as the nose or prop hub. Using the wing leading edge is unsatisfactory: think of the F-16, or the space shuttle. What do you use in those cases? In the case of the X-15, do you use the point where the wing meets the fuselage as the leading edge or the point where the leading edge would intersect the centerline? The nose tip or prop hub is unmistakable. We would report this position to FlightGear and you would then have intimate knowledge of what to rotate about. smime.p7s Description: application/pkcs7-signature
[Flightgear-devel] comments
John Check [EMAIL PROTECTED] Sat, 14 Dec 2002 13:52:27 -0500 Previous message: [Flightgear-devel] comments Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] On Saturday 14 December 2002 1:06 pm, paul mccann wrote: [Flightgear-devel] patch and screenshot John Check [EMAIL PROTECTED] Fri, 13 Dec 2002 16:05:52 -0500 It has to do with precision, when the location is straddling the border of two pixels, the image jitters. OK Thanks, I noticed the other instruments don't jitter as much in the 3d cockpits as the hsi I was working on. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] c310 origin
Jon Berndt [EMAIL PROTECTED] said: It's neither impractical nor complex. FWIW, there really is a standard already out there, and we use it. That is, the structural frame, as I have outlined before. The only problem I see is that the FDM and the 3D model rendering code need to have a static common point of reference - that's why I mentioned the farthest point forward, such as the nose or prop hub. Using the wing leading edge is unsatisfactory: think of the F-16, or the space shuttle. What do you use in those cases? In the case of the X-15, do you use the point where the wing meets the fuselage as the leading edge or the point where the leading edge would intersect the centerline? The nose tip or prop hub is unmistakable. We would report this position to FlightGear and you would then have intimate knowledge of what to rotate about. Yes, I knew this would sound a little complicated with swept,delta,body wing aircraft. But making it the nose really just puts the decision on to the 3D Modeler where to some degree the flight model designer could have a better idea. Isn't there some way of deriving an average or nominal c.g. that we could just lock in as the fixed point? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] c310 origin
Yes, I knew this would sound a little complicated with swept,delta,body wing aircraft. But making it the nose really just puts the decision on to the 3D Modeler where to some degree the flight model designer could have a better idea. Isn't there some way of deriving an average or nominal c.g. that we could just lock in as the fixed point? I don't really think that the CG (or anything like it) should have anything to do with a common reference point. I think it should be something you can readily see. The nose/prop hub tip is about as unambiguous as it gets. Due to the nature of defining the flight dynamic model, and the nature of defining the 3D model - both people will know where nose/prop hub are located. A question: is all the rotational/translation stuff figured out so that if a pilot eyepoint is defined that the view will be properly rendered with that in mind - even when the CG is askew because of fuel burnoff? Jon smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] c310 origin
Jon Berndt [EMAIL PROTECTED] said: I don't really think that the CG (or anything like it) should have anything to do with a common reference point. I think it should be something you can readily see. The nose/prop hub tip is about as unambiguous as it gets. Due to the nature of defining the flight dynamic model, and the nature of defining the 3D model - both people will know where nose/prop hub are located. Documenting a distance back from the nose for each aircraft would work fine. Whoever does the first flightmodel gets to pick the spot. The standard doesn't have to be all that unambiguous. Using the nose standard you've got 3D modelers deciding where on the airframe the aircraft should appear to rotate... which... umm... I guess is ok :-) A question: is all the rotational/translation stuff figured out so that if a pilot eyepoint is defined that the view will be properly rendered with that in mind - even when the CG is askew because of fuel burnoff? If the fuel burnoff is refelected in the reporting of position and orientation by the FDM then the answer is yes. I would assume that would be the case :-) The chase view is really the only place we get screwed up if the origin isn't back on the wing. It looks funny. Not wrong, just funny. And it's kind of nice if the 3D model is in the middle of the screen instead of off to one side. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] BA-609, V-22 derivative aircraft
Martin Spott wrote: Martin Spott wrote: ... Oh, you get heavily increased torque from the ailerons for manouverability and you get much more lift from large wings at low speed - especially because on the current design at least 90 % of the wing area suffers from the down-wind generated by the two the rotors, Ah yes, prop wash helps improve control effectivity at low speeds. It isn't going to be great, but should help. So how smooth is it when lift become significant on the wings? The wash off the rotors should be strong, but very turbulent. Air flow around the wings ought to be one very nasty numerical analysis problem, especially near wing stall. I can only imagine what surprises it held for the designers. Regards, Charlie H. -- You're not drunk if you can lie on the floor without holding on. ---Dean Martin ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Segfault with Friday evening CVS update
I updated SimGear, FlightGear, and fgfsbase Friday the 13th in the evening. I also updated the nvidia driver to 1.0-4191 using source RPMS. After compiling the fgfs stuf and installing the new nvidia drivers, I get a segfault trying to load the first tiles. I went back to a version of FlightGear made from CVS early in Dec. and everything runs even with __GL_FSAA_MODE=2 __GL_DEFAULT_LOG_ANISO=3 in my .rcbash. With the recent (12/13) CVS and the 1.0-3123 nvidia drivers, I can get things to work by turning off FSAA. But I cannot get the recent CVS to not segfault with the new nvidia drivers no matter whad depth or resolution or with both the above options disabled. By the way, even with the 1.0-3123 nvidia drivers I have been experiencing lockups at the same place unless I disable the splash screen. The segfaults are actually better as I don't have to do a hard rset to recover. I have an AMD XP 1800+ and RH8.0 uptodate kernel. My graphics card is a GF3, Is anyone else having similar issues. - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac OS X 0.9.1 build available
On Saturday, December 14, 2002, at 08:20 pm, darrell.l.walisser.1 wrote: I would like to get joystick support included soon (this would involve working on PLIB). Is anyone else already working on this? I am about to, by porting Max Horn's work in SDL to plib. I've got as far as reading over Max's code (IOKit HID hell), just thinking how to fit it to the PLIb API. Beofre going any further I wanted to ping the PLIB guys and check no one else was planning to work in that area. I should get the joystick stuff done 'this week' but if you want to have a go, just say the word. BTW, I submitted a bunch of fixes to Curt which mean that, 'so far', SimGear and flightGear CVS compile fine under Jaguar. I'm planning to do up a bundle eventually, I'm just not sure how to handle add-on files (mapping the FGFS data directory to Library/FlightGear? ) .. anyway that's longer term. HH James -- The lack of planning on your part does not constitute to an emergency on mine ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Fault modeling
I'm looking at doing some fault modeling ... things like failing various instruments, CDI, GS, to/from flag failing, and quite a few other things with avionics, electrical, fuel, flaps, engines, etc. What makes the most sense to me is to create a section for faults in the property tree /sim/faults/ Once this subtree is populated, the the various instruments could use these in condition statements to decided what to draw (or not draw) in the case of a failure. Since the failures are flagged in the property tree, it would be easy to build an instructor gui to set/unset them. Does this sound reasonable? Thanks, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Fault modeling
What kind of failts would you model. In the Big Sims (as you have probably seen) you may have the ability to set particular variables to a particular value, or delta-value, at a scripted time, or several at once, along with flags, etc. How do you plan on implementing fault values? A malfunction flag? Settable parameters? I'm looking at doing some fault modeling ... things like failing various instruments, CDI, GS, to/from flag failing, and quite a few other things with avionics, electrical, fuel, flaps, engines, etc. What makes the most sense to me is to create a section for faults in the property tree /sim/faults/ This sounds fine to me ... Once this subtree is populated, the the various instruments could use these in condition statements to decided what to draw (or not draw) in the case of a failure. Since the failures are flagged in the property tree, it would be easy to build an instructor gui to set/unset them. This would be cool. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac OS X 0.9.1 build available
I just got the MacOS X 10.1 version of FlightGear build and submitted to Darrell. The compiler used by 10.1 REALLY doesn't like the GL* type warnings that are present in the 3D cloud subsystem. It always aborted the build, even though they were warnings instead of errors. Any idea as to how long MacOS X 10.1 should be supported? Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] fault modeling
yeah this is great idea especially for instrument training, something like the attitude indicator, plus single engine flight in the twins is always interesting. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
