Re: [Flightgear-devel] Next world scenery build
On Tuesday 20 December 2005 09:55 am, Martin Spott wrote: > ... After the 'standard' shapefile-based scenery has > proven to work we can start tackling issues like the Great Lakes > shorelines and such. I think whoever is the gate keeper for scenery improvements is going to be a VERY busy person! Once we have the tools to make permanent improvements to the scenery we'll have lots of people working on their favorite locales. Airplanes? This is about airplanes? ;) I'm still itching to get the approach light structures working at KSFO, and I think Curt's improvements will allow accurate modeling of unusual airports, like KLGA, where both runways are extended out over the water on "decks". Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear for PSP??
On Tuesday 13 December 2005 03:00 pm, bass pumped wrote: > ... > How hard would it be to put Flightgear on a PSP. > ... You know you're getting old when you have to google PSP to find out what it is. I always thought it was Pierced Steel Planking. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: JSBSim broken?
On Sunday 11 December 2005 08:02 am, Melchior FRANZ wrote: > * Dave Culp -- Sunday 11 December 2005 05:05: > > The reverser method has changed. You set the reverser now by adjusting > > the "/fdm/jsbsim/propulsion/engine[x]/reverser-angle" [...] > > The property "/engines/engine[x]/Reverser" doesn't work any more. > > It's the job of the glue code (JSBSim.cxx) to map internal values > to standard fgfs properties. This internal /fdm/jsbsim/foo thingy > will hardly ever be supported by the keyboard/joystick bindings. Agreed. The change wasn't my idea, and finishing the glue with FlightGear will take some time. I'll start after the v2.0 switch-over. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBSim broken?
On Sunday 04 December 2005 11:27 am, Joacim Persson wrote: > Reverser is also no functional. Can't tell if this is simply not > implemented or if this ... The reverser method has changed. You set the reverser now by adjusting the "/fdm/jsbsim/propulsion/engine[x]/reverser-angle" property (where x is the engine number), which is the reverser angle in degrees. 90 degrees gives you zero thrust. A good value is about 120 degrees. You have to set this for all engines if you are using one throttle for all engines. The property "/engines/engine[x]/Reverser" doesn't work any more. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [0.9.9] screenshots for flightgear.org
On Friday 09 December 2005 07:01 pm, Ampere K. Hardraade wrote: > We seem to be missing a screenshot of our online map. :) > http://www.cs.yorku.ca/~cs233144/onlineMap.jpg We may need a logical place at the FlightGear website to put more info up about the multiplayer capabilities. Right now I only see a one-line mention of it on the "features" page, under the "Networking" heading. This would be a good place to put a few multiplayer screenshots, including your online map screenshot and these two: http://home.comcast.net/~davidculp2/KSFO_parallels.jpg http://home.comcast.net/~davidculp2/fg_server_map.jpg (that second one needs to be redone with more traffic). I think we have enough information to make a multiplayer page and change the mention of multiplayer on the "features" page into a hyperlink to it. I would volunteer to write the page, but I'm sure someone out here knows a lot more about it, i.e. its history and who's involved. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Thesis Advice
On Thursday 08 December 2005 08:51 am, bass pumped wrote: > I'm trawling for topics to do my masters thesis on. My interest in > intelligent flight control. Anyone have any good ideas?? The money will be in automating air transport, beginning with replacing the current ATC system with a Freeflight type of system where all the airplanes deconflict themselves and set up their own arrival spacing. This is already being researched, but the more the merrier. This will allow airplanes to fly their most efficient paths, which saves lots of fuel, and also takes the people out of the ATC system, which will save a bundle. Once that is in place then the automated (pilotless) airplane comes next. Some hurdles are taxiing and weather avoidance. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Flight Director
On Wednesday 07 December 2005 03:54 pm, Curtis L. Olson wrote: > I'm thinking of doing some work to impliment a flight director (such as > the bendix-king KFC 200.) Has anyone made an AI that includes a movable > "V-bar"? I had a split axis type flight director working in the 737 panel back when I was making an autoflight system for it. It just displayed values from the middle of the controller cascades. I've since dropped it and lost all the work, but I can say it's do-able. Never did like the Collins style v-bar thingy. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 747-100 config problem
On Monday 05 December 2005 04:19 pm, Buchanan, Stuart wrote: > So, here my ignorance of aerodynamics comes to the fore: Why does ground > effect reduce drag? > I thought it only affected lift? It does both. It reduces drag by reducing the spanwise airflow, which gives the wing a higher "apparent" aspect ratio, which in turn reduces induced drag. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 747-100 config problem
On Monday 05 December 2005 03:40 pm, Dave Culp wrote: > It looks like the main problem with the 747-100 configuration file is the > ... Sorry, this was meant for the JSBSim list. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 747-100 config problem
It looks like the main problem with the 747-100 configuration file is the ground effect factor in the section. Here it is: Change_in_drag_due_to_ground_effect 11 aero/h_b-mac-ft none 0 0.048 8 0.515 16 0.709 24 0.815 32 0.882 40 0.928 48 0.962 56 0.988 64 1.0 72 1.0 80 1.0 The property used is called h_b-mac-ft. This is what is actually calculated in FGAuxiliary: FGColumnVector3 vMac = Propagate->GetTb2l()*MassBalance->StructuralToBody(Aircraft->GetXYZrp()); hoverbmac = (Propagate->GetDistanceAGL() + vMac(3)) / Aircraft->GetWingSpan(); Which is basically the altitude AGL divided by the wing span. Using a chart like this one: http://home.comcast.net/~davidculp2/groundeffect.png We see that ground effect starts at a height of about one wingspan. In the 747-100 config file the ground effect is occurring at 64 wingspans, which for a 747 means it occurs everywhere under 12000 feet. So, the author is off by a factor of 64. A better factor would be: Change_in_drag_due_to_ground_effect 9 aero/h_b-mac-ft none 0 0.048 0.125 0.515 0.250 0.709 0.375 0.815 0.500 0.882 0.625 0.928 0.750 0.962 0.875 0.988 1.000 1.0 I've flight-tested it and the drag looks much better. What's the protocol for fixing configs? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBSim broken?
On Sunday 04 December 2005 05:55 pm, Joacim Persson wrote: > Then for some reason all those numbers are ignored. Actually it seems that what's being ignored is my previous email. I'm not interested in helping you fix your problem if you aren't. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBSim broken?
On Sunday 04 December 2005 11:27 am, Joacim Persson wrote: > I couldn't help but notice that the JSB version of the 747 has a lift-ratio > which would make a sailplane pilot envious. One can glide about with full > flaps, gear out etc with AoA at 30--40° in 80 kias and keep it level. ;) > ... > The testbed being used here is a fresh cvs version. The first thing I would change is the idle thrust factor at 0 speed and 0 altitude. The value of 0.0836 was an old typo that got copied into several turbine config files. A value of 0.0317 looks better, and is what I'm using in the CFM-56 config. Also, there is no gear drag included. I would copy the gear drag coefficient out of the 737 config and paste it into the 747 config. Also, the newer turbine model allows one to knock off some thrust due to bleed/accessory/installation losses. I would knock off 4 percent. See the 737's CFM-56 config. As far as the drag values go, the CD0 looks good, and matches aeromatic well. The induced drag is calculated a different way than I do it, and I'd have to get the calculator out to compare results with the aeromatic method, which I hope to get to some time. I'm not a fan of the method used in the 747 config, even if the numbers turn out to be good. The flap drag looks good. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] post-incidence-angle-update tu154 4 problems feedback
On Saturday 03 December 2005 01:26 am, Vassilii Khachaturov wrote: > > > 2) when I hit the F3 to generate the above snapshot, I got an unusual > > > attitude, from which it was very difficult to recover > > > > Are you flying using the mouse? > > Affirmative. When you hit F3 the cursor is slewed to the bottom left corner of the screen. If you are using the mouse for control at the time then you get full up elevator and full left aileron. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] post-incidence-angle-update tu154 4 problems feedback
On Friday 02 December 2005 04:18 am, Vassilii Khachaturov wrote: > 2) when I hit the F3 to generate the above snapshot, I got an unusual > attitude, from which it was very difficult to recover Are you flying using the mouse? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/Lockheed1049/Models
On Sunday 27 November 2005 08:56 pm, Jon Berndt wrote: > No. The VRP defines the location of an agreed-upon reference point in > structural coordinates. The CG, eyepoint, gear locations, etc. are all > defined (in JSBSim) in structural frame. > ... That was my understanding of it, but it seemed to not work with ___'s Connie model. Upon further review it looks like ___'s Connie model has an x-offset of about 14 meters, and I can't figure out why. So, I'll drop my investigation of it. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Lockheed1049/Models
On Sunday 27 November 2005 05:19 pm, Martin Spott wrote: > > Sets correctly the VRP at the nose : > > Yep, the VRP appears actually to be located at the nose, but the offset > to the CG is still missing :-) > Have a try, look at the aircraft from an outside view (chase view w/o > yaw), activate the HUD and see where the center of the HUD points at: > It points at the nose whereas it _should_ point at somewhere near the > wing root, actually at the CG. Currently the FDM still 'thinks' the CG > is at the nose. One thing that may be confusing is that the VRP setting given by aeromatic is wrong. In the JSBSim configuration file If the CG location is X, Y, Z, then the VRP location is -X, -Y, -Z.I had thought that AC_VRP defines the location of the VRP, however it actually defines the location of the VRP *from* the CG (?). I never noticed it in the T-38 and other smaller airplanes because the effect is hard to see. In a big airplane like the 1049 you can see it. The above may seem authoritative, but I'm really only 90% sure it's correct :) I know you have all been waiting impatiently for another VRP thread. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [0.9.9] screenshots for flightgear.org
On Thursday 17 November 2005 10:58 am, Melchior FRANZ wrote: > IOW: This was intentional. :-P OK, but it still looks odd. BTW, very nice screenshots. If I may I'd like to include two screenshots showing FG capabilities that are also missing from the website. One from me: http://home.comcast.net/~davidculp2/contrails_001.jpg And one from Gerard, if he approves. This is my desktop wallpaper BTW: http://home.comcast.net/~davidculp2/A6_F8refuel.jpeg Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [0.9.9] screenshots for flightgear.org
On Thursday 17 November 2005 09:45 am, Melchior FRANZ wrote: > Here are four screenshot offerings for the FlightGear page. > ... > http://members.aon.at/mfranz/seafire-nimitz.jpg [70 kB] Well, *that's* a fine time for the engine to quit :) Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] thermals gone ?
On Wednesday 16 November 2005 11:37 am, Dave Culp wrote: > On Wednesday 16 November 2005 10:22 am, Patrice Poly wrote: > > well, there simply wasn't isn't any "Data/AI/" directory... > > Oops, maybe the "data/Data" directory has been renamed? There was talk > about this earlier. I'll check out pre3 and have a look. Yes, the "data/Data" directory is missing in pre3. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] thermals gone ?
On Wednesday 16 November 2005 10:22 am, Patrice Poly wrote: > well, there simply wasn't isn't any "Data/AI/" directory... Oops, maybe the "data/Data" directory has been renamed? There was talk about this earlier. I'll check out pre3 and have a look. > I got it from CVS, now sgs233 starts. > > When over the KSFO tower, the netto vario indication increases, and I can > see in the internal proprieties that "/environment/wind-from-down[0] " > increases. > > We are in the thermal, it works. > > But the glider doesn't seem to be affected, vario remains stable, and > altitude doesn't increase. I tried with higher values of thermal strengh -> > same. There was a bug (my fault) that caused the thermal strength to max out at 1 fps, regardless of what the configuration entry said. I fixed it this morning and sent the fix in to Erik, who commited it. So, try a cvs update and rebuild and this should be fixed for you. The Netto should read about 8 knots when you're in the middle of the thermal. As far as automatic generation of thermals, that's been discussed from time to time. The thermal model currently supports only cylindrical thermals, so ridge lift is not possible (yet), and if it is in the future it probably won't be modeled with an AI object. In any case, automated thermal generation would require testing the tile underneath the airplane to see if that tile should have a rising or falling air mass, then some system will have to blend the edges together to prevent discontinuities at the tile boundaries. I doubt I'll ever be able to get to this. The current method can be used to create a good soaring experience though. I had considered expanding the thermal_demo scenario to include many thermals, and some sinks, around the SFO area so that you could soar all the way around around SFO bay. That wouldn't be hard - just need a map and a couple hours time :) One note: If you put multiple thermals in a scenario give them the same diameter. If you don't the AIManager may give you lift from the wrong thermal (it judges by the *center* of the thermal, not the edge). Dave Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] thermals gone ?
On Tuesday 15 November 2005 10:26 pm, Patrice Poly wrote: > I've just tried the 0.9.9-pre3 > ... > but, what has happened to the thermal scenario ? I don't have pre-3 downloaded yet, but it works in pre-2. Do you have the file "data/Data/AI/thermal_demo.xml" ? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] c172-dpm.ac
The message: WARNING: ssgLoadAC: Failed to open '/home/dave/FlightGear-0.9.9-pre2/data/Aircraft/c172r/Models/c172-dpm.ac' for reading appears all the time now because FGAIMgr::init() attempts to pre-load this model even if the AI-Traffic system is disabled (and it's disabled by default).See src/ATC/AIMgr.cxx lines 78-95. It also assumes that the c172-dpm.ac model will exist. One solution is to fix FGAIMgr to not do this. Another solution would be to put the c172-dpm.ac model in the data/Models/Geometry directory and fix the FGAIMgr to look there instead. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 0.9.9 repost
On Friday 11 November 2005 08:31 pm, George Patterson wrote: > /home/dave/FlightGear-0.9.9-pre2/data/Aircraft/c172r/Models/c172-dpm.ac > Does this file exist? It exists in CVS data, but not in 0.9.9-pre2 data. I think the underlying question is the more interesting one. Why is FG trying to load it anyway? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 0.9.9 repost
Due to underwhelming response to my previous post concerning a test run of 0.9.9-pre2, I'll repost now. Here is the console output while running the F-16: Dent: .Dent: ..Dent: EHAMopening file: /home/dave/FlightGear-0.9.9-pre2/data/Navaids/carrier_nav.dat /home/dave/FlightGear-0.9.9-pre2/data/Navaids/TACAN_freq.dat WARNING: ssgLoadAC: Failed to open '/home/dave/FlightGear-0.9.9-pre2/data/Aircraft/c172r/Models/c172-dpm.ac' for reading Reading xml electrical system model from /home/dave/FlightGear-0.9.9-pre2/data/Aircraft/Generic/generic-electrical.xml Initialising callsign using 'Aircraft/f16/Models/f16.xml' I don't know what the Dent stuff is. The carrier and TACAN stuff is obviously carrier stuff. Every aircraft I've run tries to open a c172 model. Is this because the c172 model is the default and gets loaded even if it isn't needed, or is this the AI-Traffic manager trying to load GA traffic even when it's disabled by default? And the callsign thing, is this a multiplayer or ATC message? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.9-pre2
Aside from the already mentioned glitch about the missing cloudlayers.xml file, I was able to build 0.9.9-pre2 without any problems on my linux box. I am getting some extraneous console output, which perhaps needs to be cleaned up. (This is using the default log level, running the T-38 from command line script). [EMAIL PROTECTED] bin]$ t38 Dent: .Dent: ..Dent: EHAMopening file: /home/dave/FlightGear-0.9.9-pre2/data/Navaids/carrier_nav.dat /home/dave/FlightGear-0.9.9-pre2/data/Navaids/TACAN_freq.dat WARNING: ssgLoadAC: Failed to open '/home/dave/FlightGear-0.9.9-pre2/data/Aircraft/c172r/Models/c172-dpm.ac' for reading Reading xml electrical system model from /home/dave/FlightGear-0.9.9-pre2/data/Aircraft/Generic/generic-electrical.xml Initialising callsign using 'Aircraft/T38/Models/T38-model.xml' Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Joystick issues with throttleAxis()
On Wednesday 09 November 2005 12:58 pm, Ralf Gerlich wrote: > ... > some time ago a new version of the joystick configuration file for > Logitech Wingman FF 3D was committed, containing a change to the > throttle-handling. > > Shortly after that I couldn't get the engines down to idle. As I > noticed, jsdemo reports that the throttle axis returns +0.3 when on > idle. I'm using Linux on a 2.6.8 kernel. That configuration file applies an offset of -0.3 prior to the scale. That shouldn't be allowed, and I guess someone's personal configuration snuck in by accident? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] lightning
> Yes, the 3d clouds can draw good thunderstorm clouds and lightning and > rain, the weather system can detect when they are needed. The only part > missing is the accurate updrafts. OK, just looked at them. They look nice and sound great. Are they GUI controlled only? I couldn't find anything about them in preferences.xml. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] lightning
> >>Can you > >> set a piece of a model to flash somewhat randomly using only XML > >> animation code? > > That said, I really think the AIThunderstorm calls should be without a > visual model and should be called by the 3d clouds code and METAR > weather code instead. I don't understand. Are you saying there is no need for the AIStorm because the 3D clouds and METAR will handle this? I am not familiar with either of these, so I'll have to experiment with them. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] lightning
Currently, in CVS FlightGear, it's possible to place an AI thunderstorm in the FlightGear world which has both turbulence and lightning. See the AI scenario called bigstorm_demo.xml. The turbulence is controlled by each instance of the thunderstorm, so you could have several storm AI entries, each one defining an area of turbulence within a specified diameter and with a specified strength. (It's hoped that you'll define the turbulence diameter to correspond to the visual model's diameter. There is no way for the AIStorm object, which controls the turbulence, to automatically know the diameter of the 3D model. ) The lightning however is controlled from one property, "environment/lightning/flash". Because of this, if you have more than one storm they will all flash at the same time. I was thinking about changing this so that each instance of a storm will have its own property to be used as a flash trigger, however it would be best if the flashing could instead be completely a part of the 3D model animation, with no external trigger needed. All you experienced modelers, please tell me, is this possible? Can you set a piece of a model to flash somewhat randomly using only XML animation code? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Out of Town next week
On Monday 07 November 2005 12:39 pm, Durk Talsma wrote: > Tomorrow, I'm flying out to Canada I have two words for you: Sleeman Dark http://www.sleeman.com/en/html/beer/sl_brands/dark/index.htm Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildings?????
On Thursday 03 November 2005 01:14 pm, Mike Kopack wrote: > Or is this just a glaring big black hole with the FG scenery ... What is this? Crap on FlightGear week? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: document naming
On Sunday 30 October 2005 06:50 am, Melchior FRANZ wrote: > No, they aren't. KDE doesn't even look at the name. It looks at the > contents via "file"-derivative. (See $KDEDIR/share/mimelnk/magic) I have > never had problems with multiple dots in file names. I'd rather guess that > your setup has problems. Thanks Melchior, Somehow I managed to get a document type of "README.*", whiched caused the confusion. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] wish list for next release
> Ow, that I'm not sure of. > I guess it would be better to backport this code to support 2D panels > also then. The only thing lacking in the 2D code now is the ability rotate, translate, and *then* crop a texture. Maybe it would be required that the texture be drawn to a context in memory, rotated, translated, and then cropped and drawn to the screen? It's unlikely that I'll be learning OpenGL in the next few years, so it would be *really* great if someone could look into this issue. This would finally make the 2D panel code complete. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: document naming
On Sunday 30 October 2005 06:50 am, Melchior FRANZ wrote: > * Dave Culp -- Sunday 30 October 2005 13:29: > > Can we change the names of the documents so there is only one "dot" per > > name? For example "README.xmlpanel.html" should be > > "README-xmlpanel.html" or something like that. The file association > > settings in KDE get confused by multiple dots. > > No, they aren't. KDE doesn't even look at the name. It looks at the > contents via "file"-derivative. (See $KDEDIR/share/mimelnk/magic) I have > never had problems with multiple dots in file names. I'd rather guess that > your setup has problems. Ah, then I just have to find the correct mime type settings. The hunt is on. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] document naming
Can we change the names of the documents so there is only one "dot" per name? For example "README.xmlpanel.html" should be "README-xmlpanel.html" or something like that. The file association settings in KDE get confused by multiple dots. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] wish list for next release
On Sunday 30 October 2005 03:23 am, Erik Hofman wrote: > Dave Culp wrote: > > 2) Texture cropping for 2D panels so that Attitude Indicator ladders > > stay in bounds. > > This can be done now by using the texture animations; > texrotate and textranslate > > See FlightGear/data/Docs/model-howto.html for more information. This works for 2D panels? The document only mentions animations for 3D models. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] wish list for next release
Is it time to establish a wish list for the next release (or did I miss it?). Maybe this should be called a "things to wrap up" list, if it's too late for a wish list. BTW, I looked for a wish list at the flightgear.org website and found a "goals" page, which is a similar thing as a wish list, but this page looks pretty out-dated. Here are my wishes: 1) Oliver's multiplayer 2) Texture cropping for 2D panels so that Attitude Indicator ladders stay in bounds. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] allow-toggle-cockpit
Using CVS FlightGear I find that the "s" key switches instrument panels even when the property "/sim/allow-toggle-cockpit" is false. I see the key binding uses in the condition test. Shouldn't the not be there? Or not. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear CVS compile error
> > I'm getting these errors while compiling CVS FlightGear, with CVS > > SimGear. > ... > Please double-check your version of metar.hxx in SimGear. Mine (1.6) has > ... > Vassilii Thanks Vassilii, that was it. I must have botched my cvs commands earlier. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear CVS compile error
I'm getting these errors while compiling CVS FlightGear, with CVS SimGear. Using gcc version 3.4.1, linux system if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -I/usr/local/include -g -O2 -D_REENTRANT -MT environment_ctrl.o -MD -MP -MF ".deps/environment_ctrl.Tpo" -c -o environment_ctrl.o environment_ctrl.cxx; \ then mv -f ".deps/environment_ctrl.Tpo" ".deps/environment_ctrl.Po"; else rm -f ".deps/environment_ctrl.Tpo"; exit 1; fi environment_ctrl.cxx: In member function `virtual void FGMetarEnvironmentCtrl::update_metar_properties(const FGMetar*)': environment_ctrl.cxx:608: error: passing `const FGMetar' as `this' argument of `SGMetarVisibility& SGMetar::getMinVisibility()' discards qualifiers environment_ctrl.cxx:610: error: passing `const FGMetar' as `this' argument of `SGMetarVisibility& SGMetar::getMaxVisibility()' discards qualifiers environment_ctrl.cxx:612: error: passing `const FGMetar' as `this' argument of `SGMetarVisibility* SGMetar::getDirVisibility()' discards qualifiers environment_ctrl.cxx:642: error: passing `const FGMetar' as `this' argument of `std::vector >& SGMetar::getClouds()' discards qualifiers make[2]: *** [environment_ctrl.o] Error 1 Any Ideas? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] recent 737 autopilot change
> In the recent 737 autopilot change, > we see that the only improvement is the change of the target speet. > ... > However, I am surprised to see that the target speed is hardwired here. The autopilot for FlightGear's 737 is the "standard" FlightGear autopilot and doesn't reflect the way an actual 737 autoflight system works. I once built an autoflight system for the FlightGear 737, but gave up do to a lack of suitable controllers. It has since been erased during an OS change. The current method has some advantages: 1) no learning curve for those already using FG's autopilot 2) the code and GUI already exist 3) it makes a poor terrorist training device ...and some disadvantages: 1) the autopilot doesn't match the Mode Control Panel 2) it doesn't work like a Boeing autoflight system 3) it will forever bring complaints Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] problems experienced with the recent c150 updates
> Sometimes at the same time I also see the aircraft tumbling backwards and > having its tail going underground, controls held neutral, tailwind never > exceeding 7 knots. Could this be that the model doesn't account for the > pilot's weight? Tumbling backwards is usually an indication that the airplane has failed to ground trim properly. Maybe something has changed the ? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Winter Textures - screenshot
screenshot: http://home.comcast.net/~davidculp2/PC7-winter.jpg BTW, my lakes are still blue. Do we need an ice-water texture? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DME range
> Does anyone know if the DME calculation to a VORTAC is based on slant > range? Noticed when flying over a fix say at FL350, the range goes down > to zero at station passage. It should be the AGLvalue of the aircraft > over the station. > OTH a waypoint based on radial intersections or GPS would go to zero. I get slant range here. What property are you looking at? The DME in the 737 model uses the property: /instrumentation/dme/indicated-distance-nm Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
On Thursday 13 October 2005 01:13 pm, Ampere K. Hardraade wrote: > Is it a priority to have a voice comm at the moment? A voice comm would > serve no purpose if there is no one being the ATC. > > I think we should focus on text-based ATC first. With text, it would be > much more easier to create an automatic ATC. We can always expand it to > include some sort of speech-to-text engine later on. This sounds good to me. Voice-ATC in the real world is a dying technology anyway. In a few years it will be gone and replaced by data-link, at least for commercial flying. I do think, however, that plane-2-plane comm at the multiplayer arena is a good idea. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
> So what basically happens now is that at the (startup) airport the AGL > would be reported correctly, but once the terrain elevation increases > the reported AGL won't change (like in real life). This sounds more like HAA (height above airport) or HAT (height above touchdown). Height AGL should be the current height above the ground directly below the aircraft. Height AGL should change as the terrain below the aircraft changes. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Determining range?
> ... how do I get the distance from > my current Lat/Long to another Lat/Long? There's a function in SimGear that does this. See SimGear/simgear/math/sg_geodesy.cxx for a function called int geo_inverse_wgs_84() This may be overkill for your application. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Free simulator of the Frecce Tricolori aerobatic jet
> Since the MB-339 PAN is an on-going project, we plan to release > an improved version of the aircraft (with smokes?). We have smoke/contrails now, but they need a lot of work: http://home.comcast.net/~davidculp2/contrails.jpg They look OK from some angles, and look bad from others. I tried to add a smoke generator to the OV-10 model (The real OV-10 can inject oil into the right exhaust stack to make white smoke), but it doesn't look good enough to use. The present system makes smoke/contrails by releasing AI objects rapidly. There are three problems with it now: 1) Orienting the objects properly. Only applies for long (i.e. cylindrical, rectangular) models. 2) Matching the release rate to the airplane's speed. 3) Making a smoke model that merges well with the others. I've heard (on this list) that this may be a plib limitation. It may require the use of a different visual model, like billboards or particle fields. On the other hand, maybe a whole new tactic is needed. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Free simulator of the Frecce Tricolori aerobaticjet
> > Nice model. I particularly like the horizon ball. > > I particularly like the fact that they used FlightGear :-D And I also like the fact that they used JSBSim and started with aeromatic :) Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
>> ... > > This bug showed up about 10 days ago with an update from cvs. Any ideas > > what is broken? > I've got a hunch. Dave Culp may have an idea. I'll take a look, too. Sorry. I haven't been following the FG CVS logs. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] T38 and other aircraft xml files overwrite scenario settings
> Today i found out, that using the T38 overwrites other scenario settings > which are set in the preferences.xml file. It's been like that for over a year. > Scenarios should never be set in the aircraft's xml files. Unless the aircraft is demonstrating an AI capability. > Hunter/hunter-2tanks-set.xml: ship_demo > OV10/OV10-set.xml: thunderstorm_demo Thunderstorm and weather radar demo > T38/T38-set.xml: refueling_demo Refueling and air-air radar demo > sgs233/sgs233-set.xml: thermal_demo Thermal demo > The reason to remove them is, that it's not a good idea to set them in the > aircraft files when they overwrite other scenario settings that are set in > the user specific preferences.xml file. Unless the user(s) aren't aware of the capabilities demonstrated in this way. > Imagine that someone wants to use the sgs233 glider and fly around over the > Alps. > What does he do? > He will create a new scenario demo file to have thermals over the Alps and Not in my experience. What he'll do is complain that FlightGear doesn't have any thermals and that it sucks compared to any other sim. > Why does someone want to have thermals over KSFO when he wants to fly over > the Alps? That makes no sense. See above. > Is it possible to make flightgear be able to use more than one scenario > demo file at the same time? No. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
> > > So the question is: How can I easily calculate the distance and how
> > > many nautical miles are "out of reach" (thinking of e.g. radar systems)
> > > ?
> >
> > You can compute distance at an altitude using SimGear functions
>
> Ack, don't even *think* about doing the math in a GIS datum.
I agree. You don't need overkill here. A simple check of the bounding square
should work fine. Something like this:
/* Check if position 2 is within a square of side R nautical miles that has
position 1 at a corner. This is a fast approximation of checking the distance
between them, avoiding the use of trigonometric or sqrt functions. This
assumes latitude in the range (-90,90) and longitude (-180,180).
*/
bool IsWithinRMiles( double lat1, double lon1, double lat2, double lon2,
double R ) {
double nm_per_deg_lat = 60.313;
double nm_per_deg_lon = 60.109 - fabs(lat1 * 0.66788);
double lat_diff = fabs(lat1 - lat2);
double lon_diff = fabs(lon1 - lon2);
if (lon_diff > 180.0) lon_diff = 360.0 - lon_diff;
if ((lat_diff * nm_per_deg_lat) < R) {
if ((lon_diff * nm_per_deg_lon) < R) {
return true;
}
}
return false;
}
This should be good enough for deciding if object2 should be visible to
object1, as long the range you're checking for isn't too small. I would use
20 nm for a visibility test.
To get a more accurate distance check (for instance, radar range) you'll need
to call a sqrt function in the test:
if ( sqrt( (lat_diff * lat_diff * nm_per_deg_lat * nm_per_deg_lat) +
(lon_diff * lon_diff * nm_per_deg_lon * nm_per_deg_lon)) < R) {
return true;
}
To get even more accuracy you can use trigonometric functions in the
nm_per_deg calculations (see AIModel/AIBase.cxx for the feet_per_deg
formulas).
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fgrun & Fgfs
> Have been having a problem on my desktop PC where fgrun seg faults when > I hit the run button, so I can only start fg from the command line. > I bought a laptop last weekend and did a fresh install of > plib,simgear,fg cvs & fgrun cvs using fltk 1.4 (with threads) and I'm > getting the same problem. This is the same set of installations as my > desktop and both the laptop and the desktop are nvidia and both are > using Mandriva 2005 LE. Last time I tried fgrun I got this: terminate called after throwing an instance of 'char const*' Aborted I think one of the dialog input fields is wrong for linux. Mandrake 10.1 Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KSFO approach lights
> > > Anyone know the altitude of the approach lights in FlightGear? They > > > should be the same as the threshold, about 13 feet. They seem to be > > > much lower here, so they're covered by the light structures. > > > > The altitude of the approach lights vary based on viewer distance > > (and/or altitude?) because otherwise they would end up underneath the > > ground under certain circumstances. > > May be the approach lights should be shifted by that 13ft, and additionaly > moved above with the distance to them to avoid Z-buffer races? That sounds good, but I don't know where to start on that. Does anyone want the 28R light structure to play with? It's here: http://home.comcast.net/~davidculp2/28RLights.ac And the placement info goes in Scenery/Objects/w130n30/w123n37/942050.stg : OBJECT_STATIC 28RLights.ac -122.35186 37.61125 -0.1 62.0 Here are some photos of the real thing: http://home.comcast.net/~davidculp2/lights2.jpg http://home.comcast.net/~davidculp2/lights3.jpg If we can get the light-hiding problem fixed, then I'll make light support structures for all of the KSFO runways that need them. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] KSFO approach lights
I've been working on the approach light structures at KSFO. They look OK in the daytime: http://home.comcast.net/~davidculp2/lights_day.jpg But at night some of the approach lights are covered: http://home.comcast.net/~davidculp2/lights_night.jpg Anyone know the altitude of the approach lights in FlightGear? They should be the same as the threshold, about 13 feet. They seem to be much lower here, so they're covered by the light structures. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] readXML problems
> void
> readXML (istream &input, XMLVisitor &visitor, const string &path)
> {
> engine_filename = FindEngineFullPathname(engine_filename);
> readXML(engine_filename, *engine_file_parser);
The parameters don't match up for one thing. "engine_filename" is a string?
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] readXML problems
> void
> readXML (istream &input, XMLVisitor &visitor, const string &path)
> {
> XML_Parser parser = XML_ParserCreate(0);
> ...
> XML_ParserFree(parser);
> cout << "A-3" << endl;
>
> throw sg_io_exception("Problem reading file",
> sg_location(path,
> XML_GetCurrentLineNumber(parser),
What happens to parser after the call to XML_ParserFree(parser)? Can it still
be referenced after that?
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: latest OpenAL not compatable?
> > I just downloaded the latest OpenAL from CVS and can't get SimGear > > to compile with it. Here's the error: > > apply this patch > > --- openal_test1.cxx30 Apr 2004 00:44:04 - 1.5 > ... Thanks Alex, Just curious ... Is there any reason why OpenAl doesn't offer stable releases? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] latest OpenAL not compatable?
> What are you trying to compile it on? linux Mandrake 10.1 gcc 3.4.1 plib 1.8.4 Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] latest OpenAL not compatable?
I just downloaded the latest OpenAL from CVS and can't get SimGear to compile with it. Here's the error: if g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/usr/X11R6/include -g -O2 -D_REENTRANT -MT openal_test1.o -MD -MP -MF ".deps/openal_test1.Tpo" -c -o openal_test1.o openal_test1.cxx; \ then mv -f ".deps/openal_test1.Tpo" ".deps/openal_test1.Po"; else rm -f ".deps/openal_test1.Tpo"; exit 1; fi /usr/local/include/AL/alut.h: In function `int main(int, char**)': /usr/local/include/AL/alut.h:52: error: too few arguments to function `ALboolean alutInit(ALCchar*, ALCdevice**, ALCcontext**)' openal_test1.cxx:42: error: at this point in file Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] (OT) River Visual Rwy 19 DCA
Here's some guy flying the River Visual to Runway 19 at DCA. This is a 19MB avi file. I'll leave this up for a couple days, then remove it to put the hangar back up. http://home.comcast.net/~davidculp2/dca_visual_19.AVI Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
> I have started to add some volumetric shadows in Flightgear. Does the canopy frame cast a shadow on the cockpit interior? Do transparent surfaces cast shadows? ( I don't mean to be annoying, just curious. This would add a whole new level of realism to 3D cockpits :) Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
> http://sites.estvideo.net/tipunch/flightgear/lab/shadows.html > Let me know what you think of that. Wow, that looks great. How much of a frame rate hit did you get? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI for Ground Units
On Thursday 16 June 2005 06:52 pm, Drew wrote: > Is there an existing interface to allow non-ownship objects to be > positioned using the propery system? If there's an easy way to > specify lat, long, alt, roll, pitch, and heading, that would be really > helpful. I'm sending you a file off-list. It's an AI acenario file for my OV-10 simulator that puts about 45 AI objects around the Ramstein area. Some of the AI objects are static, four tanks and about 12 city signs. You'll need the CVS version of FlightGear to invoke these static objects, or you can make static objects out of "ships" if you have an earlier version. > I just read the documentation on AI models, and it doesn't seem like > any of the AI types tie models to properties. I'm not sure what your question is. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] poll
This is a poll. Does anyone really want the FDM to allow flying under the terrain, or was that a misunderstanding by me? If nobody wants it then I think it should be disallowed. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property cloning solution
> > //FDMctr++; > > Tested with my own "carrier landing patched" release : > IT IS OK ==> no clone now, JSB specific Functions working after reset. Thanks Gerard, I've commited the fix to the JSBSim CVS branches. Note that this will not allow multiple instances of JSBSim, which nobody is using right now (I don't think?). In the future we'll fix it so that the "user" instance of JSBSim is always the zeroeth instance, and other instances will start at instance number one. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] property cloning solution
Could some of you help me out and test this solution to the JSBSim property cloning-after-reset problem? In the file source/src/FDM/JSBSim/FGFDMExec.cpp, line 137, just comment out the FDM counter, like this: //FDMctr++; It works well here, but I'd like to make sure it works for those who might have slightly older versions of this file. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] crash handling options for JSBSim in FlightGear
Just checked in a JSBSim.hxx and JSBSim.cxx to JSBSim CVS that makes crash handling user-configurable. The default behavior is the current "subterranean flying" behavior. If the user sets the property "/sim/pause-on-crash" to true, then the sim will pause on crash, which is the same behavior Yasim has, so this should be the default for FlightGear. If the user sets the property "/sim/reset-on-crash" to true, then the sim will reset on crash. As for the "/fdm/jsbsim" property cloning problem, this has been around for some time now. Any reset of FlightGear while using a JSBSim aircraft will cause another "/fdm/jsbsim" node to be created. I've tried stopping that but have had no luck. There are several people using properties from "/fdm/jsbsim" to drive instruments and they are possibly used in some nasal scripts, so this problem breaks some of their panels, and maybe more things. I'm copying this to the flightgear-devel list. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] AI Ships (was: Airports Data + Zoom + SHIPs)
On Wednesday 08 June 2005 10:36 pm, Ampere K. Hardraade wrote: > Perhaps seperating land and water would be the next thing on the agenda? If this is in regard to the AI ships driving onto land, the AI ships and AI carrier can accept a flight plan, but the ability to follow the flight plan has not yet been implemented. I won't be hard to do. Once that is done, the carrier will follow a pre-defined path, and stay off of land. There are then two options: 1) make a race-track pattern 2) go straight to the flightplan end, then vanish and reappear at the start (like in the movie :) Of course option 1 is more realistic, but the ship will be going in the wrong direction over half the time. Option two would give you more fun with your entertainment dollar/euro, but you don't want to be on the ship when it teleports to the start again. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] After crash , Restart ?
Before I get too far on the property node cloning thing I want to make sure
this isn't a "feature" rather than a bug. Does anyone want there to be old
"/fdm/jsbsim" property nodes kept around whenever fgInitFDM() is called?
As background, when the sim is reset using this:
globals->get_commands()->execute("old-reinit-dialog", node);
the old instance of the FDM is destroyed and a new one created in fgInitFDM().
If this is a JSBSim FDM, then the property node "/fdm/jsbsim" stays and a new
one, called "/fdm/jsbsim[1]" is created. This happens again at every reinit.
This is a problem because some instruments are tied to properties in
"/fdm/jsbsim", so after a reset they are tied to inactive properties.
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] After crash , Restart ?
> It could easily check another property and then decide whether to use > the old behavior or automatically reset. That property could have a > user-friendly setting in preferences.xml, and everyone else could change > it locally. Yep, that would be best solution. I'll see if I can get to that today. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] After crash , Restart ?
> > I believe you are seeing the results of a new capability that Dave Culp
> > added to JSBSim recently.
>
> Aaah, I sense something: This might be a means to automagically
> re-incarnate crashed AI aircraft :-)
Actually I added the reset-after-crash to my OV-10 sim because it will be used
by the public, and they will crash often and not know why the crashed
airplane is floating under the surface of the earth. I added it to JSBSim,
thinking that nobody else wanted subterranean floating airplanes. Here's the
code location so you can remove it:
See source/src/FDM/JSBSim/JSBSim.cxx in the function named
copy_from_JSBSim(), at about line 848:
// force a sim reset if crashed (altitude AGL < 0)
if (get_Altitude_AGL() < 0.0) {
SGPropertyNode* node = fgGetNode("/sim/presets", true);
globals->get_commands()->execute("old-reinit-dialog", node);
}
It uses some pre-existing reset code that I found bound to a key in
keyboard.xml. It seems to work well here, although the report of
the /fdm/jsbsim property node being cloned after every reset is a problem.
You can comment out the code completely, or if you need lat/lon for the crash
site you can add that as console output in the above block of code.
I'll look into the node cloning today if I get a chance.
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Animation Was: jsbsim airstream info
>Anybody know where I can find the wind angles relative to >the aircraft? I don't think these exist in the property tree, but you can always take "/environment/wind-from-north" and "/environment/wind-from-east" and then convert these to body coordinates using the aircraft's heading. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] "no scenery below..."
After a couple hours of flying around the Sembach/Ramstein area I've twice gotten ground cache errors, with this console output: prepare_ground_cache(): trying to build cache without any scenery below the aircraft FGInterface is being called without scenery below the aircraft! altitude = 3.83573e-269 sea level radius = 0.711179 latitude = 34.7012 longitude= 1.66839e-265 I'm not familiar with the scenery tile processing, but I believe it occurs in a separate thread? Could it be that sometimes there *really isn't* scenery below the aircraft? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with todays CVS
> After a quick testing, (shorter than the compilation time) > my JSBSim aircraft prototypes are running, flying again. > > Mathias has found the cause. > > Which is not JSBSim itself. > > BUT, Why that "Freezing" version was working for Yasim > aircrafts ? The "no terrain below the aircraft" message comes from JSBSim.cxx, which is the interface between FlightGear and JSBSim. It contains a code block which checks for a valid ground cache solution, and prints the above message when an error is found. Yasim doesn't have this code block. Just submitted to JSBSim CVS is an updated JSBSim.cxx which should help collect some data on the freezing issue, and also avoid freezing. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Problems with todays CVS
> >> Only JSBSim doesn't. :-(
While we're finding out the cause and fixing the ground cache thing, how about
making a small modification to JSBSim.cxx that will spit out useful data and
*not* freeze the FDM? (about line 409)
// Compute the potential movement of this aircraft and query for the
// ground in this area.
double groundCacheRadius = acrad + 2*dt*Propagate->GetUVW().Magnitude();
double alt, slr, lat, lon;
FGColumnVector3 cart = Auxiliary->GetLocationVRP();
if ( needTrim && startup_trim->getBoolValue() ) {
alt = fgic->GetAltitudeFtIC();
slr = fgic->GetSeaLevelRadiusFtIC();
lat = fgic->GetLatitudeDegIC() * SGD_DEGREES_TO_RADIANS;
lon = fgic->GetLongitudeDegIC() * SGD_DEGREES_TO_RADIANS;
cart = FGLocation(lon, lat, alt+slr);
}
double cart_pos[3] = { cart(1), cart(2), cart(3) };
bool cache_ok = prepare_ground_cache_ft( State->Getsim_time(), cart_pos,
groundCacheRadius );
if (!cache_ok) {
SG_LOG(SG_FLIGHT, SG_WARN,
"FGInterface is being called without scenery below the aircraft!
\n");
cout << "altitude = " << alt << endl;
cout << "sea level radius = " << slr << endl;
cout << "latitude = " << lat << endl;
cout << "longitude= " << lon << endl;
//return;
}
I know it works fine in the air (I've been using it for a couple days while
trying to recreate the error conditions), but what happens if you get a bad
cache on the ground? Don't know.
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with todays CVS
> > well-loved "no scenery below the aircraft" ground cache message. > > I don't get it, I didn't see this behavior until after I committed the > patches, when I noticed it once. Melchior has these patches also applied > and didn't complain. Maybe this is something to do with OS, compiler, or video card? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
> Still, I didn't mean to blame the problems on the > FDMs. I just called it "FDM stuttering" because this is what the user sees > (and because the ground-cache code is in the FDM/ directory :-) But the FDM > only stuttered, because it wasn't called in time, because of unfortunate > groundcache/beacon interaction. The groundcache/beacon interaction was only effecting the Yasim FDM, correct? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Modifying nav.dat file and waypoints
> I'm actually working thru the same type of problem... my nav.dat files are > within the Navaid folder as a Zip file. I can open the file and make my > alterations, but returning the file to a zipped.dat file is escaping me. > This seems to be the case for apt.dat, awy.dat, and nav.dat. Has anyone > sucessfully returned altered data to the folder? I have unpacked all of these, removed most of the data, and then repacked them in gzip. They work fine. What are you using to gzip them? Make sure they are ".gz" and not ".tgz". Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D view goes away by itself
>> I finally took the > > easy way out and changed the airborne clip plane distance in renderer.cxx > > to 0.5, rather than 10. That solves my problem, but don't know if > > anyone else would like that move > The issue would only be related to the width of the Z buffer. I was > running a Voodoo card at the time I set up this feature where the depth > buffer was cleared and reset between the scenery and the cockpit rendering. > This may still be an issue for some current hardware configurations. > You'd have to do the math to see what the functional "far plane" limitation > is at 0.5m in order to anticipate what will and will not work. Visually, > the problem will appear as oddities on the horizon due to depth test > errors. Thanks Jim, I haven't seen any artifacts on the horizon, so it looks like setting the near plane to 0.5m works OK for me. FWIW, I'm running on nVidia MX-440. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D view goes away by itself
Thanks Curt and Phil. After looking around in the view manager and trying many different combinations of XML settings, I finally took the easy way out and changed the airborne clip plane distance in renderer.cxx to 0.5, rather than 10. That solves my problem, but don't know if anyone else would like that move :) Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
> Airports and Navigation Data Total > Before2 min 40 sec3 min 50 sec > After 1 min 40 sec2 min 50 sec > > It's still the most significant part of the load process - can we be even > more clever yet? How about an un-clever solution? Can we just divide the existing data up into regions, and let the user select which regions he wants before start up? Even the 737 I fly doesn't keep a worldwide data set. For the OV10 sim I cut out all but some of the German bits, and the load time for airports/navaids went from about 10 seconds to 0 seconds. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Crash detection (was FDM freeze)
> If you want to do push-mode handling with an FGCommand and make it > settable by the user, you can have the command call (or be) a Nasal > script that can be assigned by the user (e.g. globals.crashHandler = > myFunction). Or have it indirect through another FGCommand binding > found in the property tree, etc... Which reminds me, I'm using the command "old-reinit-dialog" in my crash handler, but I can't find where this is defined. It's not in FGCommand, so I assume it's a nasal script? I'm not sure what node should be provided as the second parameter. I'm using "/sim/presets", is that what's expected? I like the idea of a global crash handler script, but I don't know enough about nasal to write one. How would it be called from within the code? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 3D view goes away by itself
I have a cockpit view system set up for the OV-10 sim that uses a 2D forward
view and 3D side views (screenshot :
http://home.comcast.net/~davidculp2/2D_3D_views.jpg
It's controlled by some nasal scripts I bound to the arrow keys. Here are the
up(forward) and left bindings:
Left arrow
Look left.
nasal
node = props.globals.getNode("/sim/current-view");
if(node.getChild("view-number").getValue() == "0") {
setprop("/sim/current-view/heading-offset-deg",
getprop("/sim/view/config/left-direction-deg"));
node.getChild("internal").setBoolValue(1);
node.getChild("x-offset-m").setDoubleValue(0.0);
node.getChild("y-offset-m").setDoubleValue(1.1);
node.getChild("z-offset-m").setDoubleValue(-1.25);
node.getChild("pitch-offset-deg").setDoubleValue(0.0);
}
Up arrow
Look forward.
nasal
node = props.globals.getNode("/sim/current-view");
if(node.getChild("view-number").getValue() == "0") {
setprop("/sim/current-view/heading-offset-deg",
getprop("/sim/view/config/front-direction-deg"));
node.getChild("internal").setBoolValue(0);
node.getChild("x-offset-m").setDoubleValue(0.0);
node.getChild("y-offset-m").setDoubleValue(0.0);
node.getChild("z-offset-m").setDoubleValue(0.0);
node.getChild("pitch-offset-deg").setDoubleValue(-10.0);
}
It works fine on the ground, but about 10 seconds after takeoff the 3D side
views of the aircraft's engine/wing go away and never come back. I check
through the property browser and all the values look unchanged. It seems
like the "internal" boolean value must have changed, but the property browser
does not indicate a change (even after a refresh of course).
Any idea what causes the view to change by itself after takeoff?
Thanks,
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Crash detection (was FDM freeze)
> We should probably come up
> with some kind of standard way for the FDM to signal to the rest of
> the simulator that it has detected a collision and stopped.
I agree it's time for crash detection and handling. I just added a basic
version to my OV-10 sim (can't have public users wallowing around
underground, wondering what to do now :) One decision to make is what the
handler should do once a crash is detected. I have it calling the reinit
code in order to reset the sim to the starting position (below), while others
may prefer to have the sim close after a crash, or perhaps display a
crash-splash screen and/or console warning.
// force a sim reset if crashed (altitude AGL < 0)
if (get_Altitude_AGL() < 0.0) {
SGPropertyNode* node = fgGetNode("/sim/presets", true);
globals->get_commands()->execute("old-reinit-dialog", node);
}
The above went in JSBSim.cxx because I couldn't figure out where to put it so
that all FDM's could have the same crash detector/handler.
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FDM freeze
Just out of curiosity I removed the three tall scenery objects I had placed at Sembach, then flew around there for 30 minutes with no more ground cache errors. I think the problem comes from overflying the edge of a tall scenery object. Just a guess. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FDM freeze
> (2) I don't allow multiloop to become higher than, currently, 80.
>
>
> diff -u -p -r1.20 flight.cxx
> --- flight.cxx 22 Nov 2004 10:10:33 - 1.20
> +++ flight.cxx 26 May 2005 05:07:44 -
> @@ -83,7 +83,13 @@ FGInterface::_calc_multiloop (double dt)
>// ... ok, two times the roundoff to have enough room.
>int multiloop = int(floor(ml * (1.0 + 2.0*DBL_EPSILON)));
>remainder = (ml - multiloop) / hz;
> - return (multiloop * speedup);
> +
> + int result = multiloop * speedup;
> + if (result > 80) {
> + fprintf(stderr, "\033[31;1m_calc_multiloop=%d\033[m\n", result);
> + return 80;
> + }
> + return result;
> }
I tried your fix above and it didn't work for me :(
Here's a fix that I just tried and it works for me. In JSBSim.cxx, line about
number 423, I just commented out the return statement, so the FDM can
continue no matter what happens with the ground cache.
if (!cache_ok) {
SG_LOG(SG_FLIGHT, SG_WARN,
"FGInterface is beeing called without scenery below the
aircraft!");
//return;
}
No more freezes now :)
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FDM freeze
> prepare_ground_cache(): ac radius = 11.7738, # leafs = 0, ground_radius = 0 > prepare_ground_cache(): trying to build cache without any scenery below the > aircraft > FGInterface is beeing called without scenery below the aircraft! The last line comes from JSBSim.cxx line 425, inside the function FGJSBsim::update(). If there is a ground cache problem then the function returns without ever calling copy_to_JSBsim() or copy_from_JSBsim(). That would explain the freeze. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FDM freeze
I tried log-level=info and flew around Sembach until it happened again. Here's some console output: ... prepare_ground_cache(): ac radius = 11.7738, # leafs = 0, ground_radius = 0 prepare_ground_cache(): trying to build cache without any scenery below the aircraft FGInterface is beeing called without scenery below the aircraft! Updating Sun position Gst = 19.2257 t->cur_time = 1043061518 Sun Geodetic lat = -0.351757 Geocentric lat = -0.34959 sun angle relative to current location = 1.21658 Updating Moon position t->cur_time = 1043061518 Moon Geodetic lat = 0.307437 Geocentric lat = 0.305505 moon angle relative to current location = 1.86307 Updating light parameters. Sun angle = 69.7049 ambient = 0.2 diffuse = 0.977531 specular = 0.5 sky = 0.962797 prepare_ground_cache(): ac radius = 23.2997, # leafs = 0, ground_radius = 0 prepare_ground_cache(): trying to build cache without any scenery below the aircraft FGInterface is beeing called without scenery below the aircraft! ... I've heard others talk of this problem, but this is the first time I've seen it myself. Could it be the European terrain data resolution versus U.S. terrain data resolution? Anyway, it would seem that a fix would be to keep a copy of the last tile info, and if no tile is found on the next update then the last one can be used until a new one appears. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FDM freeze
> That happen often for me with message on the console: > >FGInterface is beeing called without scenery below the aircraf What logging level did you use? --log-level=? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FDM freeze
Lately I've been flying around German terrain and have been getting an FDM freeze at seemingly random occasions after flying for ten minutes or so. Here's a screenshot of the freeze: http://home.comcast.net/~davidculp2/fdm_freeze.jpg The user airplane is frozen, but other things keep running fine. The AI aircraft keep going, as does the clock, frame rate, GUI, key bindings, mouse. It looks like just the FDM froze. Anyone else getting this? BTW, the HUD lat/lon *never* matches the "actual" lat/lon, so I don't think that has anything to do with it. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] splash screen distortion
During sim startup, about 2 or 3 seconds before the "world" appears, the splash image is distorted, most often stretched vertically, sometimes split in two vertically. It's been doing this for a long time, maybe a year or more, but I've been ignoring it until now. Anyone else getting this? Mandrake 10.1 nVidia MX440 with latest driver cvs plib, SimGear, FlightGear glut, openal Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
> Is it ( the call) easily added to the JSBSim.cxx code as a local fix ? > I've looked at both the JSBSim.cxx and Yasim.cxx files, and although I > think I see the call in yasim, the similarities are beyond me... I'm a bit hazy on the reference frames, and I don't have a book handy, but it looks to me as if JSBSim doesn't calculate accelerations in the local frame (north, east, down). Maybe Jon or Mathias can weigh in on this, but looking at Propagate.h I see local-frame velocities available through GetVel(), body-frame accelerations available through GetUVWdot(), but I don't see a way to get local-frame accelerations. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Any UAV models?
> Does anyone know of any aircraft models for any UAV's? I don't really care > if it's a fixed wing or a rotary aircraft, but I'd like to find something > like a Predator or an X-35 UCAV or GLobal Hawk or Hunter or somethign along > those lines. I really don't need much of a cockpit (if any), just a visual > model and airframe and flight model. I took this as an oportunity to make my first from-scratch 3D model. Here's a screenshot: http://home.comcast.net/~davidculp2/RQ-1.jpg No textures yet, not that this thing really needs any :) It uses an 80 hp electric engine, which is always running and uses no fuel. The archive, with flight model (no cockpit, it uses the T-38 cockpit): http://home.comcast.net/~davidculp2/rq1.tar.gz Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
> > That's the Netto Variometer I believe. It works. > > No offence intended, but I've just removed it from what will become the > next release of the Colditz Glider. It's a bit anachronistic! The other > instruments were at least available in 1944/45 even if not fitted to > this particular machine. Good idea. I don't think the Colditz Glider could do much soaring anyway :) Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Any UAV models?
> A predator model is available here: > > http://www.simviation.com/fs2002military19.htm > > It will be in MDL format, which works in FlightGear, however if you want to > animate any part of it you'll have to convert it to *.ac format. Well, not so fast :( This model appears to be in a newer MDL format that plib can't use. Maybe there's an older MDL model somewhere. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Any UAV models?
> Does anyone know of any aircraft models for any UAV's? I don't really care > if it's a fixed wing or a rotary aircraft, but I'd like to find something > like a Predator or an X-35 UCAV or GLobal Hawk or Hunter or somethign along > those lines. I really don't need much of a cockpit (if any), just a visual > model and airframe and flight model. > > Anyone know of any sources? A predator model is available here: http://www.simviation.com/fs2002military19.htm It will be in MDL format, which works in FlightGear, however if you want to animate any part of it you'll have to convert it to *.ac format. For the flight dynamics model I recommend aeromatic (but then I would, because I wrote it :-). It can be found here (on menu bar at left) : http://jsbsim.sourceforge.net/ Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
> You'll notice a non-working digital ASI crept onto the panel somehow, > I've not spotted where that's coming from or I'd remove it! That's the Netto Variometer I believe. It works. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
>I'd be interested to know what drives Axx, Ayy, Azz.
The value Axx, for instance, is updated from src/Cockpit/cockpit.cxx in
function get_Ax(). Here is get_Ax:
float get_Ax ( void )
{
float Ax = current_aircraft.fdm_state->get_V_dot_north();
return Ax;
}
V_dot_north is set in src/FDM/flight.hxx in this function:
inline void _set_Accels_Local( double north, double east, double down )
{
v_dot_local_v[0] = north;
v_dot_local_v[1] = east;
v_dot_local_v[2] = down;
}
The JSBSim interface, /src/FDM/JSBSim/JSBSim.cxx never calls
_set_Accels_local() in
the function copy_from_JSBSim().
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model's xml properties
> I have added a tank to flightgear but the model is not to scale, appears
> below the ground, and doesn't face the right direction. If I understand
> correctly the model should have values to correct this in a xml file, but I
> can't find documentation for the properties to define them. Can someone
> point me in the right direction?
The offsets are defined in SimGear/simgear/scene/model/model.cxx. Here's the
code:
...
props.getFloatValue("/offsets/heading-deg", 0.0),
props.getFloatValue("/offsets/roll-deg", 0.0),
props.getFloatValue("/offsets/pitch-deg", 0.0),
props.getFloatValue("/offsets/x-m", 0.0),
props.getFloatValue("/offsets/y-m", 0.0),
props.getFloatValue("/offsets/z-m", 0.0));
...
To use these offsets you need to put an section in the model's XML
wrapper file, like this:
mymodel.ac
0.41
1.0
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
