RE: [Flightgear-devel] JSBsim with Solaris8/Sparc and GCC-3.4.1
Norman Vine said: > Martin Spott writes: > > > > Erik Hofman wrote: > > > > > They really should be fabs() in both cases, both GetState() and > > > GetTolerance() return a double instead of an int. > > > > Thanks ! > > Any idea why this doesn't show up on other platforms ? > > gcc is getting *much* pickier on the road to being c++ standards compliant > In other words, they are finally fixing it. Allowing casts from double to int with just a warning is "not a good thing". :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] change view
Benno Rieger said: > I'm searching for this point in "Flightgear source code" where my > current position in the scenery will be calculatet new , after hit 'v'. > > Thanks > Ben > Look at the FGLocation class: /simgear/scene/model/location.?xx This is accessed by the viewer/fdm/ai/scenery/model subsystems, etc. Basically, to answer your question, the viewer and scenery just switch from one "FGLocation" instance* to another when you hit the "v" (see also viewmgr.cxx). It doesn't recalculate per se. Those other positions are still there, they just aren't rendered. Best, Jim * actually, to be a little bit more accurate, you are switching "FGView" instances and each of those has references to the "FGLocation" of the camera. Things that move stuff write position data to the FGLocation (fdm/ai) and rendering components read position data from FGLocation (scenery/model/viewer). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VC jitter
Mathias Fröhlich said: > On Dienstag 07 September 2004 19:35, Lee Elliott wrote: > > In a/c that have one or more VC views there's a visible 'jitter' when > > looking at parts of the a/c, most notably in my experience, with the > > windshield/canopy frames. > Yep, and most notably when you look at 3d instrtuments. > > This is a problem with the OpenGL transform matrices being single precision. > The transforms include translations to the cenery center and back. This > jitter is the roundoff of thode two treanslations ... > > Making all this stuff double precision would help. > > But these matrices are stored in ssg* (=plibs simple scene graph) classes > which use single precision values. Sadly there is no double precision > aequivalent available. So this requires something more intelligent that what > I have investigated some time ago ... Ah...hmmm. That won't help. Probably the only thing that will work is rendering the aircraft seperately at a 0,0,0 origin when the view is inside the cockpit. There are quite a few values being passed around as floats in the FGViewer and SGLocation classes. It "might" help some to change a few of those to double, especially anything related to view position. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] shaders for flightgear
Roman Grigoriev said: > So I think that we have to rework threaded scenery loading scheme because I > have hangups during loading tiles on high speed aircrafts. and maybe Are you below 250kt under 10k agl? It works fine for legal flights doesn't it ;-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] sky-writing
David Culp said: > One of the uses of the new submodel code - sky writing :) > > http://home.comcast.net/~davidculp2/sky-writing.jpg > Hehethat's great! Can we set that one up in the base package (so the novice submodeler's can try it out)? Which a/c did you use? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.5-1
Erik Hofman said: > Matevz Jekovec wrote: > > > Why not simply name it 0.9.5.1 (latest kernel is 2.6.8.1 as well as they > > found a tiny bug in 2.6.8 version). Letters behind a version could mess > > with things like a for Alpha, b for Beta, RC for Release Candidate and > > so on. I think 0.9.5.1 is the only logical explenation to what happened > > to us and why are we releasing a new version. > > To be honest, I don't really mind what it's called like. This might be a > good idea after all, as long as there will be an update to the latest > release version. > > There were enough changes (both fixes and updates) to justify one (IMHO). > I almost agree with that :-). It seems like folks are pretty busy now and not a lot is being added to cvs. That means this could be a great time to get a fairly stable release out. It seems like it should just be called 0.9.6 and I we should avoid last minute changes now (otherwise, why bother?) and I have no idea what effort is required on Curt's part to do this. So I won't say much other than we should stay on the same numbering scheme. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery Loading
"Curtis L. Olson" said: > > I don't know how this scenery loading message/pause was implimented, but ... > The most recent changes from Fred work great. I made the original fix in order to correct the problems doing in air starts near KSFO before the release, without thinking about the frame rate issue. All it did was suspend FDM updates, so despite the "observation" that there was a delay, scenery was loading at the same rate it always did. > We should modify the code to simply load all the models in the queue > (i.e. flush it) at startup, rather than doing one-per-frame and hacking > around that with turn draw-otw=false. IMO that would be a *much* better > solution. This sounds pretty much like what the latest patch does. It just holds the splash screen up until the queues are flushed, rather than rendering the whole scene with a popup dialog. (The splash will also reappear during "teleports"). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mouse frozen after running fullscreen
Erik Hofman said: > David Megginson wrote: > > Erik Hofman wrote: > > > >>> I think that the fix will be simply to force the mouse pointer to be > >>> visible before exiting FlightGear. > >> > >> > >> This is in CVS now. Could you please test it? > > > > > > That solves the problem completely. Thank you very much, Erik. > > Great! > It wasn't too difficult, since you already told what to do :-) > What happens on a kill/int/segfault? Can it be changed to something like a single pixel or some other unobtrusive thing instead? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New JSBSim Newsletter
Jon Berndt said: > Greetings: > > The July (!) issue of "Back of the Envelope" is up and linked from the main page of the > JSBSim web site, www.jsbsim.org. In this issue, Erik shares his experiences in creating > the flight model for the F-16. There is also an article about data output from JSBSim, and > an in depth review of modeling aerodynamics in JSBSim. > Very cool! Already downloaded and printed. Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: ALERT: Losing the DAFIF
Melchior FRANZ said: > * Peter L -- Saturday 14 August 2004 07:31: > > > That's a bit euphemistic. > > > Yeah, I was a bit more polite than normal. Just put it down to not knowing > > you guys yet... > > No problem. And I didn't want to make it sound as if you pardoned a criminal. :-) > > I just wanted to make clear that this was *not* "some unaware pilot" who "cuts the > cable". He knew the cable was there. He wanted to fly under it and make a nice > film, which was common practice in this unit at Aviano/Italy. Even their > commander did it (and lost his command because of that). > > The cable was around 85 to 95 m AGL (~300 ft), and the minimum altitude allowed > in this area was 150 m (~500 ft) at this time. This was afterwards raised > to 600 m (~2000 ft). > > m. > > > Ref.: http://www.cnn.com/WORLD/9803/10/italian.crash.report/ The U.S. Marine motto is "The few, the proud", not "the most intelligent" :-) I think "the few" is important. Unfortunately, it's hard to train folks to be potential killers, and expect civility and common sense to always prevail. We've got a training field nearby and this is a fairly rural area. I can say that I haven't seen anything marginal come from there. The private jets are another story. I'm amazed at the crap they get away with over the Maine woods. And then of course there are the cruise missle tests... Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: ALERT: Losing the DAFIF
Melchior FRANZ said: > * Peter L -- Saturday 14 August 2004 05:14: > > > Was it the USAF? I couldn't remember anymore, just that it happened.. > > > > Actually, marines. Very unfortunate accident in clear weather in 1998 in > > Italy. US marine training flight, the plane returned with some damage. > > > > The route was a well used one, but it appears they flew lower than normal. > > That's a bit euphemistic. They flew lower than allowed, against clear orders. > And the pilot filmed the whole thing to show off to his friends (IIRC). Despite > killing 20(?) people the fines were AFAIK ridiculously low. He would have > sat a few years in prison in most legal systems ... > There were no fines. The official line: http://www.dod.gov/news/Feb1998/n02101998_9802105.html The media: http://www.pbs.org/newshour/bb/military/jan-june99/marines_2-3.html http://www.cnn.com/US/9902/26/marines.cable.car.02/ The result: http://www.cnn.com/US/9903/04/marines.cablecar.03/ Back to Erik's original comment: note that if the information regarding the charting of the cable was _key_ to the defense in this case. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ALERT: Losing the DAFIF
David Megginson said: > Lee Elliott wrote: > > > I'm pretty sure that information/data can't be copyrighted - but the design of > > the presentation of the information/data can. > > I hope not, but every country has its own (bizarre) laws about this kind of > thing -- for example, in Commonwealth countries, including Canada and > Australia, the Book of Common Prayer has a perpetual copyright in the name > of the Queen. Jeppesen does draw its own approach plates, updated based on > the information in the Australian AIP (I'd assume), so it really looks like > a data grab from the little I've seen so far. > > Before I bash Oz any more, I'll repeat the problem that Garmin had with my > own government recently. The Garmin 296 handheld GPS includes terrain > obstructions (such as towers), which could save of lives; however, the > Canadian government refused to provide obstruction information for Canada > unless they got a royalty for each unit sold -- as a result, Canadian pilots > do not see towers displayed on their Garmin 296 units, and at least a few > will likely crash in the next few years as a result, costing the Canadian > government millions in search and rescue, medical bills, lost taxes, etc. etc. > But people don't mind paying all sorts of taxes for emergency services. It is those behind the scene revenue streams (e.g. "royalties"), which can be used to fund politically unpopular line items, that government officials find hard to come by. Best, Jim (the pesimistic american) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ALERT: Losing the DAFIF
David Megginson said: > Chris Metzler wrote: > > > Is there an official announcement of this somewhere? I've looked all > > around the NGA and NACO sites but haven't found anything. How did he > > hear about this? Is there any kind of timetable? Were there reasons > > stated? > > According to the message I quoted, the Australian government is suing > Jeppesen for publishing information obtained from Australian aviation > publications. That's bad news not only for the flying community but for the Ah...oh. H. What is the "AIP"? I hadn't read "government" into that first posting at all, but maybe there was a typo. If it is the RAAF or Aussie government in some form, this could be a serious problem for information on the web, that goes a bit beyond this one data set. Uggh...greed. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: bo104 - patch
Martin Spott said: > Arnt Karlsen wrote: > > On Sat, 7 Aug 2004 16:57:24 +0200, Melchior wrote in message > > <[EMAIL PROTECTED]>: > > > > Yes, that's widely known. But nobody would seriously assume that > > > anywhere the collective lever is pushed down to raise, and pulled up > > > to sink. > > > > ..heh, precicely this is done by many R/C heli pilots. ;-) > > R/C pilots use to have a long standing culture discussing how to to do > it 'right' :-) > > To my knowledge there are mostly two parties: Those who know at least a > little bit how things work on a real helicopter and thos who don't. You > even can convince some of the second group to try a change by letting > them sit im a real heli > Mostly, but how about a third party that knows what a collective lever looks like, realizes that the joystick looks nothing remotely like one and thinks that binding the keyboard one way and the joystick the other way is not a good idea. My preference would probably be Alex's original patch. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Newbee
Al West said: > > There are plenty of friendly folks hanging out on IRC always ready to help, That's best after you've got some experience. I used to have to advise certain people to stay away from certain #unix/#linux irc channels. Back in the early/mid 90's when home internet was just making it to parts of Maine I had this guy from one of the fledgling ISPs call me and tell me that he typed cd /;rm -rf * on his mail server after asking how to solve some minor problem on IRC. I guess that did get rid of the problem. Looking recommended commands up in the manual (e.g. typing "man rm") before using them is a very good idea. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Newbee
David said: > What IDE do you suggest me? No ide is necessary for this type of app. A good editor like emacs is fine. Half the time I just run the first gui editor I think of to do quick edits, just because they'll usually support the common shortcut keys. > What O.S.? For this use any OS you want. A lot of folks using Linux, most any distro will do. Mandrake is actually fine, gentoo might require a bit more experience (or at least patience) to get started. > Where do I start with OpenGL and C++ and FlightGear? > What manual would you suggest? Stroustrup is the standard reference for C++. Not sure of any learning books. OpenGL Programming Guide (The red book) is a standard. There is a new OpenGL version and the books aren't going to be out yet. You can actually develope using plib (the game library used by FlightGear) without knowing much about OpenGL, but you may find the red book useful just for basic understanding anyway. Starting with FlightGear will probably involve finding something you'd like to change (start small) and dive in. Welcome and good luck! Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Newbee
Arnt Karlsen said: > ..and you will wanna listen to David M (Magginson) on setting up Emacs; > if it can cook coffee, it can fly your chopper robots. ;-) > http://tldp.org/HOWTO/Coffee.html Hey that's handy! Now if *nix only had a gui environment that supported simple cut and paste of plain ascii text between apps as consistently as on the winblows and mac systems, we might even have a useful (to the average person) desktop OS. :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: bo105 - patch
Melchior FRANZ said: > * Jeff Sinsay -- Saturday 07 August 2004 16:28: > > Yes indeed, when looking from the top down American Helicopters > > rotate-counter clockwise, while European/Russian Helis rotate > > clockwise. > > Yes, that's widely known. But nobody would seriously assume that > anywhere the collective lever is pushed down to raise, and pulled up > to sink. And that's what we were talking about. And implying that > Austria would do it that braindead way isn't exactly friendly. > (And that's even ignoring the fact that the bo was mostly built > in Germany.) But anyway. ;-) > And I've yet to see a joystick that has a lever that pulls up! This should probably just default to what folks expect rather than pretending we've got a "realistic" solution. Maybe single property value that would cause the mapping to reverse (e.g. --invert-throttle-control-mapping) would make sense? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] bo105 + patch
Alex Romosan said: > recently i took a helicopter tour of san francisco, so i decided to > play a little bit more with the helicopter simulation in fgfs. it's a > lot of fun. a couple of things though. i use the keyboard mappings and > a mouse to "fly" and i noticed that the collective is mapped backwards > (up goes down and down goes up). also i find PageUp and PageDown to be > cumbersome, so i mapped the collective to the 1 and 2 keys (so i can > use my left hand). with these changes i managed to hover and even land > on top of the buildings in downtown sf. i've collected some of the > screenshots at http://caliban.lbl.gov/fgfs-heli/index.html. for > comparison (although we didn't land on top of any of the buildings :-( > ) the real pictures of sf are at > http://caliban.lbl.gov/sfhelitour/index.html. > Alex, Those photos are really are nice! Wow! Mind me asking what you took them with? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler said: > Another idea I just had: Why not put all the general algorithms needed > in an average FMC into a library (possibly as part of SimGear). > Things like performance calculations, (access to) route databases, input > validation (eg: airport code exists?, does this airport have a runway > xxR?),routing calculations,... > > This library could then be used/linked to build an FMC, either withing fgfs our > as a standalone program. Maybe something like that could work. There are some good suggestions in this thread, but you know in the end these details are up to whoever takes the initiative to write the code. There will always be room for further contribution. Which reminds me that I forgot to make it clear that I am very excited to hear of this proposal. This feature is something we really need, especially for the airliners. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Harald said: > - it's an external application because there is no need to put it in FG > code and there would be some complication with the display and keyboard > part ; It would actually be very nice to have a FlightGear subsystem for this. Even nicer if it was possible to configure features via an xml config file (since not all FMCs are exactly the same). You can still manipulate data through the property system. It should be very easy to use the NewGUI feature (xml gui) to present a display with buttons as well as pc keyboard input. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: yasim + bo105 + vrp + @#%$#@ == argh!
Melchior FRANZ said: > * Jim Wilson -- Wednesday 04 August 2004 20:49: > > Can you post what you have, with the model fixed and the target-offsets in, etc? > > attached > > m. That "looks" fine (at least from pitch and roll angles). It is off a little bit because the model offsets (in the Models/bo105.xml file) don't match how far the 3D model is off of 0,0,0. Also that fdm config really should be fixed, because that will throw off your rotations as well. Just make your fuselage ax,ay,az = 0 and then increase the other x and z values by .17 and .51 respectively. If all the values are updated then the FDM will operate the same, just with a different origin. Of course it is possible to just call the origin -0.17,0,-0.51 and adjust the model to that, but now you would really be getting tricky :-) Also, in the case of the c310u3a model, I actually went into ac3d and and moved the model. Then adjust the animation entries. It took a couple minutes but then at least I didn't have to worry about using the model offsets any longer. You might have noticed that the gear numbers are all screwed up too (x,y,z mixed up). I'm not sure what effect that would have other than maybe making things on the ground a little strange. It does look like the aircraft yaws a little weird when looked at exactly as you described. But I'm not really sure what the behavior should be. And of course we'd probably never notice that type of error in a non-hovering aircraft. Where should the pivot axis be when a bo105 is exactly hovering (something I have trouble doing)? What effect would centrifugal force have on that axis once movement began? In any case, it doesn't seem to rotate exactly around the nose. Sometimes it is behind the nose and sometimes it is in front of the nose. But as you say, the axis isn't located near the main rotor shaft. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: yasim + bo105 + vrp + @#%$#@ == argh!
Melchior FRANZ said: > > > Did you put the target offset in the right place, in the right file? > > I think so, yes. (Well, I hope so, at least. :-) > Can you post what you have, with the model fixed and the target-offsets in, etc? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: yasim + bo105 + vrp + @#%$#@ == argh!
Jon Berndt said: > Curt quipped: > > > If you want to use the same 3d model for multiple FDM configurations > > which choose different reference points, then that makes life a lot > > harder. I think that is what the JSBsim VRP is for. > > I had to laugh when reading these two sentences together. It sort of read ( to me ) like: > > "The JSBSim VRP is for making life a lot harder." > > Without the VRP, JSBSim would simply report the location of the CG to FlightGear. With the > VRP specified in the JSBSim config file, instead of reporting the CG, JSBSim will report > the lat/lon/alt (the position) of the VRP instead. By convention, we say that the nose of > the aircraft is what we want the VRP to represent. This can be advantageous (I think) > because everyone knows where the nose of the aircraft is. This should make 3D model > placement in the scene easy. > Ah, that I don't know. So AC_VRP is not just an offset, it is a switch as well? If it isn't specified, then you are reporting lat/lon/alt the old way (at the current center of gravity)? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: yasim + bo105 + vrp + @#%$#@ == argh!
Melchior FRANZ said: > I know. But still, YASim's origin (the nose) is the (unchangeable) VRP, or what > JSBSim calls "VRP", right? And the 3D model would also have to be moved such > that the nose is at YASim's 0/0/0, too. But the bo105 does only turn around the > CG if the main *rotor axis* wrongly is at YASim's *nose*. The only difference is JSBSim has the extra feature of specifying the VRP which is an offset from where 0,0,0 ends up being specified. It saved changing all the entries for existing flight model configs that had 0,0,0 at the firewall, etc. You could say the YASim VRP is unchangable, but that's partly a misstatement as there is no VRP defined in YASim. It sounds like you pretty much understand what is going on, but just keep in mind this FDM side is only about where the lon/lat/alt gets reported in FlightGear. We talk about "Nose" but that's just a convenient way for the 3D modeler to know how to position the Model so it represents where the FDM thinks the aircraft is. You may as well put the bo105 with the origin at the nose and then address any other issues after, because that is where it ought to be. BTW I noticed that the bo105 fuselage in CVS is not anchored exactly to 0,0,0 but it is offset (I think it is 0.17 forward and 0.51 down). This should probably be fixed. > Not so quick! I knew about the target offset and had considered it, but still > the model rotated around the nose: I had the bo105 parked on the ground with > the nose over a taxiway corner, then I slightly increased the collective, turned > the bo with pedal input, and looked at it from above. The bo clearly rotated > around the nose, if I had shifted the 3d model correctly in place. That was > hardly and optical illusion. > Keep in mind that exactly straight down isn't possible, and remember the camera is moving too. So yeah that "illusion" can work from any direction, even with what appears to be a good fixed reference. The solver places the bo105 CG as follows on my copy: -2.491, -0.000, 1.091 I'm not really sure how the aircraft should turn and what relation rotation would have to CG. Note that your FDM thinks the nose is 1.5 meters (add the offset I mentioned above) below the CG. If there is a bug in YASim this would be the first I've seen of it. Is it possible that you never had the model positioned with the target offset correct all at the same time? Did you put the target offset in the right place, in the right file? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] yasim + bo105 + vrp + @#%$#@ == argh!
Melchior FRANZ said: > I'm less successful with the VRP scheme than Jim with the c310u3a. The bo105 > looked quite OK all the time, but that's just a coincidence. Actually, there > must be a bug somewhere ... in YASim? > > The bo105 yasim config treats the nose 'tip' as the origin. But the 3d model > thinks the main rotor axis is the origin. So one would assume that the xml > should translate the model accordingly. It doesn't and never did! Still, the > model seemed to behave OK. Turns happened around a z-axis through the CG > (approx. the main rotor axis). > > When I noticed that the skids didn't work correctly, I found this VRP bug. > I shifted the model so that the VRP would agree with the YASim origin > and changed the view look-at point accordingly. This fixed the skid problem. > But now it became obvious that yasim turns the bo around the origin (nose > tip) rather than the CG! This was masked by the VRP bug. Actually it wasn't, and has nothing to do with VRP. VRP is just JSBSim's way of shifting the location where longitude, latitude, and altitude are reported at. It has nothing to do with YASim. This actually enables JSBSim to report location at something other than 0,0,0. YASim on the otherhand always reports at 0,0,0. We've often talked about standardizing with the "Nose" at 0,0,0 and reporting the location (lon,lat,alt) there. Jon added the VRP to JSBSim so that models already configured with an origin elsewhere could add a parameter that shifts the reporting location (lon,lat,alt) to the "Nose" without having to mess with the flight dynamics configuration. > And now I'm out of ideas. Is it a YASim bug? A bug in YASim's rotor parts? > A bug in my brain? > Yes, it is a bug in your brain. Actually everyone's brain. I've added the "solution" to the Flight Gear wiki. This Seed Wiki seems to be a little clunky, but for now it is the only way we have for getting updated docs online: http://www.seedwiki.com/page.cfm?doc=3D%20Model%20Rotates%20Around%20Nose%20in%20FlightGear&wikiid=2418&wpid=150075 Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [OT] was ..update script tardiff (or cvs) idea, was: fgfs aborted with the dc3
Arnt Karlsen said: > On Mon, 02 Aug 2004 16:08:52 +0200, Boris wrote in message > <[EMAIL PROTECTED]>: > > > A "short" message for Arnt ! > > ..Winston Churchill had a great way of having bureaucrats trim > their language; it had to be readable without glasses, from across > the room, on one sheet of paper, nailed to the wall. ;-) > Hmmm...do you have a reference for that? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Flight Instrument Accuracy
John Wojnaroski said: > > - Original Message - > From: "Jim Wilson" <[EMAIL PROTECTED]> > To: "FlightGear developers discussions" <[EMAIL PROTECTED]> > Sent: Monday, August 02, 2004 2:58 PM > Subject: Re: [Flightgear-devel] Flight Instrument Accuracy > > > > John Wojnaroski said: > > > > > Jim Wilson writes: > > > > > > > > If it wasn't for the great work on JSBsim and YASim we'd have very few > > > > aircraft. But I think those config files, along with the "source > code" > > > that > > > > ends up interpreting and processing them, both make up the FDMs. > There is > > > > considerable skill and effort involved in producing accurate flight > models > > > for > > > > new aircraft isn't there? > > > > > > > Hmmm, speaking of accuracy. Do all the new aircraft use the output of > the > > > Instrumentation model to drive the flight instruments? If that is the > case, > > > then the 747, YF-23, T-38, 737, etc, etc are using data based on a light > > > aircraft pitot-static ssytem and vacuum driven gauges and the associated > > > lags and delays. For my 747 project I've decided to dig into JSBSim to > get > > > the "raw data" and pass that through an INS/ADC model to drive the glass > > > displays. > > > > > > Depending on your purpose and application it might be a don't care, but > it > > > would have an impact on things like autopilots and error > > > tracking/man-machine interface research. Just a thought > > > > The 747-400 3D models of displays and instruments do not use the cooked > > "instrumentation" outputs. Off the top of my head the backup AI might be > an > > exception...not sure. In any case I've assumed the modern airliner > displays > > to be quite accurate and responsive and just run directly off the FDM > output. > > > > Best, > > > > Jim > > > > > Have you looked at the .xml files in the base package? I'm not all that > conversant in xml or how the properties work, but it appears that some of > the pressure instrument readings are drawn from the instrumentation property > node and some for the /orientation node and in the case of the 737 some from > the /fdm/jsbsim nodes. > > Perhaps someone could prove me wrong, but I can't find another altimeter > model in the source except for the one in the /Instrumentation directory. > The steam.cxx has been removed ( was it 0.9.1 or 0.9.2 ) > > Some other excerpts from instruments-3D > > > /instrumentation/airspeed-indicator/indicated-speed-kt > > /instrumentation/altimeter/indicated-altitude-ft > > > /instrumentation/vertical-speed-indicator/indicated-speed-fpm perty> > > > /instrumentation/magnetic-compass/indicated-heading-deg > The 747 xml files myself and they are stored in the Aircraft/747/Models directory. It looks like that analog backup altimeter and backup airspeed indicator are using the cooked values. The glass displays and the attitude indicator do not. FWIW it is somewhat better to work with the standard FDM interface properties rather than the fdm/JSBSim properties. If there is something you need that isn't already published (in the standard: position/ orientation/ velocities/ engine/ gear/ surface-positions/ paths) then maybe it needs to be added somewhere. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Flight Instrument Accuracy
John Wojnaroski said: > Jim Wilson writes: > > > > If it wasn't for the great work on JSBsim and YASim we'd have very few > > aircraft. But I think those config files, along with the "source code" > that > > ends up interpreting and processing them, both make up the FDMs. There is > > considerable skill and effort involved in producing accurate flight models > for > > new aircraft isn't there? > > > Hmmm, speaking of accuracy. Do all the new aircraft use the output of the > Instrumentation model to drive the flight instruments? If that is the case, > then the 747, YF-23, T-38, 737, etc, etc are using data based on a light > aircraft pitot-static ssytem and vacuum driven gauges and the associated > lags and delays. For my 747 project I've decided to dig into JSBSim to get > the "raw data" and pass that through an INS/ADC model to drive the glass > displays. > > Depending on your purpose and application it might be a don't care, but it > would have an impact on things like autopilots and error > tracking/man-machine interface research. Just a thought The 747-400 3D models of displays and instruments do not use the cooked "instrumentation" outputs. Off the top of my head the backup AI might be an exception...not sure. In any case I've assumed the modern airliner displays to be quite accurate and responsive and just run directly off the FDM output. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Yasim strangeness
Matthew Law said: > David Megginson wrote: > > > I cannot reproduce it on my system: > > > > fgfs [EMAIL PROTECTED] --aircraft=j3cub > > > > I put on the parking brake (who'd have thought the J3 Cub had a > > parking brake?) and tried moving all of the control surfaces. They > > had no effect on the aircraft, either with the engine on or with the > > engine off. > > I'm not surprised you couldn't replicate it. I found a pesky old > .fgfsrc file containing: > > [EMAIL PROTECTED] > > > I'll get my coat :-/ > Lol... nah don't go. We've all done something like that. Well, maybe not everyone... ;-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Data source battle?
Jon Berndt said: > > I don't use real weather because most of my flying is to test the fdms I'm > > working on, > > Just so I am clear, when you say "fdms" are you referring to Flight Dynamics Model source > code, or are you referring to something I'd call an Aircraft Flight Model (AFM) or > Aircraft Flight Model Definition (AFMD). I don't mean to sound snobbish, but when I think > of FDM I think of math (equations of motion). The aircraft definition files - whether it > be a JSBSim aircraft definition file, a YASim one, or whatever - define the aircraft - > which the FDM code interprets and "brings to life". > > We've never really discussed terminology as far as I can remember, but maybe a > clarification would be good - if only so that my filter rules don't categorize messages > incorrectly. :-) > If it wasn't for the great work on JSBsim and YASim we'd have very few aircraft. But I think those config files, along with the "source code" that ends up interpreting and processing them, both make up the FDMs. There is considerable skill and effort involved in producing accurate flight models for new aircraft isn't there? Or maybe I'm just not very good at it :-) Heh...probably the later! Anyway, I knew exactly what Lee meant. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Adding external nasal bindings & fgcommands to FlightGear by using Plugins ?
Boris Koenig said: > Back to the plugins discussion ... I am really about to get famous here > for my unpopular views ;-) > It sounds like you are anticipating something here. My recommendation is that you spend quite a bit more time getting familiar with FlightGear. It isn't that your idea or view isn't good, you just haven't come up with an application for it that strikes me as "you know that would be really cool" (I'm not speaking for anyone else). Once you are into the project a bit more I'm sure you'll find folks receptive, because you'll understand better what's interesting to them and really know better how a new interface would fit in. If you don't have the patience for that approach there is a second option. You could code up an interface, make an example plugin and post it to the list so folks can try. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Erik Hofman said: > Jon Berndt wrote: > > > One more thing: think of a baseball or better yet a lightweight ball. How do those things > > curve? > > I wouldn't know. I haven't thought about that one yet. My first > impression would be that of the cohesive and adhesive forces again. > Well "Jim's make it up as you go along Physics manual" says that there is greater pressure against the air molecules in front of the moving ball. Thus there is greater friction against those molecules than the air molecules to the side or behind. If the ball has a sidespin, then the slightly better traction (friction) on the front side will cause the ball to move in the direction opposite that of the forward surface of the spinning ball (as a result of something Newton said). Adding this "sideways" movement to the ball's trajectory produces a curve. The ball's momentum (speed), air density, size of the ball (amount trailing air turbulance), alignment of the planets, proximity to Fenway park, political persuasion, and the rate of spin will affect outcome. For a demonstration (or proof that I am wrong) see: http://www.grc.nasa.gov/WWW/K-12/airplane/foil2b.html Disclaimer: Use this information at your own risk. I will not be responsible for any broken noses, windows, or egos that result from the application of this theory. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear base package request & --version parameter to fgfs
Boris Koenig said: > Jim Wilson wrote: > > > > There are no pre-release tags, but you could probably do a cvs checkout by > > date if you wanted to be sure. > > yes, thanks for that - actually, that's also what I've come up with in > the meantime, just checked the 1.11 revision out ... but a compressed > download of the entire directory structure would certainly have been > faster :-) > Also there is -of course- quite a lot of CVS related stuff in the > checkout. > > A couple of minutes ago I created the patch, don't know if it works > though, as I don't have the actual pre2-release installed locally, > will need to wait for feedback - posted the link to the users > mailing list. > > > This link to a cvs log shows the date/time that pre2 was finalized: > > http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/version?cvsroot=FlightGear-0.9 > > > > Note that this log happens to refer to the file that contains the version > > number. It's called "version" and is located in the base package directory. > > Yes, sure - I did see that file (and also checked its contents) when I > looked for version information about the base package, but it states > only "0.9.4" - this even though I am _definitely_ using 0.9.5 *PRE*, so > having at least the exact version information of the base package > available would certainly make sense-including details about > PRE-releases etc. > > But then, also not to have to rely on cvs-specific files which would not > necessarily be available in a release version and hence won't be > suitable to determine the base package version in general. > That's true. You are probably just too late this time around. It is an interesting idea having release to release patch files, but I am not sure what would be involved. On the subject of versions, if you do not have the correct matching base package version installed then FlightGear should give a message like this: "Base package check failed ... Found version 0.9.4 at: ../../Base/fgfsbase Please upgrade to version: 0.9.5-pre3" That is pretty straight forward, so I doubt you are seeing a mismatch. I suppose if somehow you had an issue with autoconf (the version number for the program is set in configure.ac)... This wouldn't make much sense. Why don't you experiment a little (look at your configuration, etc) and maybe even change the number in the "version" file to see if you get the message. Perhaps there is a bug there. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Ready for next release?
Erik Hofman said: > Jim Wilson wrote: > > "Curtis L. Olson" said: > > >>Sounds fine, I wasn't planning on rolling out the official release today > >>anyway. Tomorrow is probably the earliest ... more likely friday. > > > > Just a heads up: there is a minor (as in easy to fix) issue with building > > SimGear using gcc 2.96 that was introduced earlier today. I emailed Erik > > about it. > > Which should be fixed by now. > It is. Thanks! Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear base package request & --version parameter to fgfs
Boris Koenig said: > Hi ! > > As a user on the FG user list requested a patch from base package > pre2->pre3 in order to reduce download size/time, I was looking for the > required pre2 package, it doesn't seem to be available on > ftp.flightgear.org anymore - so I decided to look what base package I am > currently using in order to see whether I could simply tar my current > base directory and use this as a patch basis, but there doesn't seem to > be any version information included in the base directory either, nor > does fgfs --version provide _any_ information at all, I think > particularly the version information via command line > should be added ASAP, possibly even directly available from within > FlightGear. There are no pre-release tags, but you could probably do a cvs checkout by date if you wanted to be sure. This link to a cvs log shows the date/time that pre2 was finalized: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/version?cvsroot=FlightGear-0.9 Note that this log happens to refer to the file that contains the version number. It's called "version" and is located in the base package directory. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Ready for next release?
"Curtis L. Olson" said: > Durk Talsma wrote: > > >Curt, > > > >I'd say "almost". My stuff has been checked in and seems to work fine now. My > >only concern is that I just downloaded pre3 about two hours ago and haven't > >even had a chance to compile it. Therefore, I'd prefer to wait just a little > >longer. Probably just a day or so to see if anything unexpected shows up. > >(if your schedule allows that of course). > > > >How's that sound? > > > > > > Sounds fine, I wasn't planning on rolling out the official release today > anyway. Tomorrow is probably the earliest ... more likely friday. > Just a heads up: there is a minor (as in easy to fix) issue with building SimGear using gcc 2.96 that was introduced earlier today. I emailed Erik about it. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DC-3 Sounds
David Megginson said: > Jim Wilson wrote: > > > There is a modified sound config in cvs that at least partially addresses the > > problems. I hope Erik doesn't mind. BTW if anyone wants to mess with any of > > the aircraft sound configs that I've commited in the past, have at it. It > > isn't as easy (or fun) as it first appears :-). > > Thanks -- it's a bit better, but it still doesn't sound right on my sound > card. There is very little difference between the engines at full power and > the engines at idle. > What I did was make the parameters more reasonable for OpenAL. Actually we've got sound issues all over the place for this release. We really don't have good tools for testing different sound configurations and it is just going to be time consuming and difficult until we have them. In the meanwhile I've commited a few more tweaks, but it is pretty much the same as it was. Needs work. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfs aborted with the dc3.
Dave Perry said: > fgfs aborted with the dc3. > > > [EMAIL PROTECTED]:/usr/local/FlightGear> ./bin/fgfs --aircraft=dc3 > > Object TrimElevation not found > > Initializing OpenAL sound manager > > Oops AL error in sample set_volume()! -0.2 for > > /usr/local/FlightGear/Aircraft/dc3/Sounds/engine_running.wav > > Oops AL error in sample set_volume()! -0.2 for > > /usr/local/FlightGear/Aircraft/dc3/Sounds/engine_running.wav > > Aborted > > [EMAIL PROTECTED]:/usr/local/FlightGear> > Run with --log-level=debug to see which SubSystem that occurs in. Could be an xml bug. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] blender --> AC3D: one texture file per object??
Josh Babcock said: > AC3D does not support multiple textures per object, AFAIK. > Josh This is correct. http://www.ac3d.org/ac3d/man/ac3dfileformat.html It is possible to group multiple "objects" under a single name. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Taildragger takeoff and landing
Richard Bytheway said: > > -Original Message- > > From: Jon Berndt > > Sent: 28 July 2004 3:47 pm > > To: FlightGear developers discussions > > Subject: RE: [Flightgear-devel] Taildragger takeoff and landing > > > > > > > I've heard it described several ways (lift); I think you're > > pretty close. I don't know if > > I'd say "partial vacuum", though, which might give an > > exaggerated impression. Thinking of > > Bernoulli's nozzle example from elementary physics, the flow > > over the top, curved surface > > of a wing sees faster airflow, and lower pressure. > > Integrating the pressure over the lower > > and upper surfaces of the wing results in a net upward force > > (assuming steady-state > > flight). Probably there is a bit of both pushing _and_ > > pulling going on. If the lower > > surface of the wing is at a positive alpha, it's not too > > difficult to think that there is > > some "pushing" going on. > > > > Well, it would be interesting to get Tony's impression, and > > of course a physicist will > > describe this in his own way, too. > > > > Jon > > > > Well as a physicist (but with no formal aeronautical education), I always think of it as the wing is pushing air down, which causes an "equal and opposite force" (to quote Newton) of the air pushing the wing up. Hence acrobatic aircraft with symmettrical wings can still fly. The key to wing shape design is to keep the air flow attached to both the upper and lower surface so that you can change the direction of airflow. Once the flow detaches (a stall), you are not pushing the air down any more, so it isn't pushing you up. > This suggests that both bernoulli and the pushing (gravity) are at play, depending on the airfoil. My (uneducated) guess is the pushing is almost all of it and that the bernoulli effect only augments: http://observe.arc.nasa.gov/nasa/exhibits/planes/planes_1c.html Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Minor logic bug re: starting location initialization?
Chris Metzler said: > Hi. It appears that in initialization, if an airport and heading are > specified on the command line, a runway is immediately chosen based > upon the heading, and latitude/longitude is set to that runway's > threshhold. This is sensible if the user is starting *at* the airport; > but if the user is starting somewhere else, and using the airport > as a reference point via --offset-azimuth and --offset-distance, > the result is that starting position can jump by a large amount > simply by changing the starting heading. Changing the heading > changes the runway fg_init thinks is relevant, and the offset is > taken from the position that's been set to an irrelevant runway > threshold location. > > I ran into this tonight while trying to contrive some aliases for > quickly starting FlightGear with the ufo at a specific vantage > point near a structure I'm modelling. I decided I wanted to be on > the other side of the structure, so I added a couple of degrees to > my --offset-azimuth value, and changed my heading by 90 degrees. > Upon restart, I didn't see the structure. I spent quite a while > trying to determine why it wasn't loading before I realized that > it *was* loading, and that the reason I didn't see it was because > I was a kilometer and a half away from where I thought. > > Not very important at all -- it probably takes a fairly contrived > situation (like mine) to get bit by this -- but figured I'd > mention it. > True, but it is actually it is a fairly contrived feature. And I could see a user wanting to start on a downwind leg or something like that. I'd call it a bug as well. At the very least we ought to be able to change the behavior during air starts, but then how would we choose a location to "offset" from? What happens if you specify a runway? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
David Megginson said: > Jim Wilson wrote: > > > You are right, that doesn't sound right. At least if a positive value did > > point down, it would be in conflict with the AOA parameter. That said, are > > you sure the DC-3 is supposed to have a negative incidence? I just looked up > > the p51 and the diagram clearly shows a positive incidence. The tail is +2.0 > > degrees (so that at level AoA=0 on main wing, the tail would have a AoA of 2.0 > > degrees). > > The role of the horizontal stabilizer is to produce negative lift to keep > the nose from dropping -- you balance the plane so that it is slightly > nose-heavy, then use the hstab (which is on a long lever arm) to apply just > enough down force to keep the nose balanced. Flying with an aft CG is more > efficient, since you're not making as much (if any) downforce with the > hstab, but it can also result in pitch control problems and violent stalls. > > On typical non-aerobatic aircraft, the horizontal stabilizer has a lower > angle of attack than the main wings in any given flight regime, but there > are two ways to accomplish that: > > 1. give the hstab a lower physical incidence angle than the wings; and/or > > 2. take advantage of the downwash from the wings, which comes from above > rather than straight on (will not work for a t-tail, obviously). > > Since YASim does not model downwash, we have to adjust the incidence angle > to simulate it where the hstab should be according to its relative airflow > as well as its physical incidence angle. This isn't an issue for nose-wheel > aircraft, since the front wheel keeps them from nosing over most of the > time, but it makes a significant difference for controlling taildraggers on > the ground. > Excellent, thanks for the clarification. Just looking at the cub you can see down-wash is a major design feature. The DC-3 has a high tail, but I can see the incidence in the main wing is pretty high. I wonder what happens when you increase the wing incidence and set the horizontal stabilizer to 0 or whatever it is supposed to be. As for the P51-D, here is a page out of the reference: http://www.spiderbark.com/fgfs/sec1_0001.JPG http://www.spiderbark.com/fgfs/sec1_0001a.JPG For some reason the designers seem to be going the opposite direction (positive tail incidence). I'd like to understand the reason in order to make a decision on the p51d fdm config. It did seem to handle better with the negative incidence number. But down-wash certainly isn't present on the hstab and the diagram appears to show positive incidence. The other related problem I'm not sure of is that with or without reducing the incidence value, I can't seem to take off in a moderate cross-wind (> 12kts). The tail always blows around and the rudder/brakes can't stop it. Does anyone know if this is normal behavior? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
David Megginson said: > Andy Ross wrote: > > > The number is a (conventional, right handed) rotation about the Y > > axis, which in YASim's coordinate system points out the left wingtip. > > So a positive incidence points down. Unless there's a sign bug (or > > three, or five...) in there somewhere. > > A positive incidence points down?? So if I set the incidence angle of the > wings to 3 degrees, the angle of attack of the wings when the fuselage is > level will be -3 degrees? That doesn't seem to be happening with the models. > You are right, that doesn't sound right. At least if a positive value did point down, it would be in conflict with the AOA parameter. That said, are you sure the DC-3 is supposed to have a negative incidence? I just looked up the p51 and the diagram clearly shows a positive incidence. The tail is +2.0 degrees (so that at level AoA=0 on main wing, the tail would have a AoA of 2.0 degrees). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Andy Ross said: > Jim Wilson wrote: > > Have I had this backwards all along? I knew of the incidence angle > > on the hstab, but always thought that positive values meant the > > leading edge was higher than with a negative incidence angle > > The number is a (conventional, right handed) rotation about the Y > axis, which in YASim's coordinate system points out the left wingtip. > So a positive incidence points down. Unless there's a sign bug (or > three, or five...) in there somewhere. > Well maybe two or four, because it seems to be working as expected. I'm going to commit a change to the p51 as well. It still works fine going with full stick/yoke back on landings (assuming you've landed in a stall). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
David Megginson said: > I've been frustrated with the tendency of the DC-3 (--aircraft=dc3) to > noseover during the takeoff and landing rolls, and of the J3 Cub > (--aircraft=j3cub) to nose over during wheel landings. I've fiddled with > the YASim files a lot in the past but have never found a good solution. > > Finally, today, I had a DUH! moment. On non-aerobatic planes, the > horizontal stabilizer is set at a negative angle of incidence so that it > will not stall before the wings (tail stalls are rarely recoverable). I set > the hstab on the J3 Cub and DC-3 to -3 degrees of incidence, and the > tendency to nose-over has virtually disappeared. The takeoff roll of the > DC-3 is a joy, and for both planes, I can now use the technique described in > STICK AND RUDDER for taildragger wheel landings -- just as the wheels touch > the pavement, push the stick or yoke full forward. > Have I had this backwards all along? I knew of the incidence angle on the hstab, but always thought that positive values meant the leading edge was higher than with a negative incidence angle (assuming the trailing edge stays the same). IIRC P51 specs I have show a positive number for this. On the P51-D I generally hold the stick back a bit to keep things under control which is actually compensating for the extra tail-incidence (combined with the attitude of the a/c on ground). I believe this is normal procedure. In general though, I do not think that the ground modeling is very accurate in any of the flight models (a bold statement for a non-pilot :-)). What you are saying regarding stall angle makes sense, but this web page describes an opposite technique than the one you've quoted from Stick and Rudder: "Once on the ground the elevator control should be 'sucked into your gut,' that is, it is held back firmly as far as it will go. This places weight on the tail wheel and provides more steering authority. If the airplane touched down in the three-point attitude, moving the elevator control full aft will prevent bouncing or skipping." see http://www.mountainflying.com/taildrag2.htm Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
Arnt Karlsen said: > On Fri, 23 Jul 2004 16:00:08 +0100, Al wrote in message > <[EMAIL PROTECTED]>: > > > On Friday 23 July 2004 15:23, Jim Wilson wrote: > > > > > > Sure enough, it's right there in Stroustrup. The strange part is > > > never having noticed this before now. What is it with these > > > developers at microsoft anyway? ;-) > > > > > > > Since when have they had developers? > > ..define "developer", the SCO Group claims to have > "4000 world wide". ;-) > Hehe...well let's see: anyone who ever purchased any of SCO's Compilers/Development Packages (since 1982) plus everyone who ever purchased or downloaded SCO's skunkware CD that with gcc on it. Then add 20% for piracy and that gives you 3981. Close enough :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Is 'Scenery Loading...' mandatory ?
Frederic Bouvier said:
> Is there a way to avoid the initial lock for scenery loading ?
> I understand this is a must have for users, but it slows
> down development speed dramatically when you have to test the
> apparence of a new building or landmark.
>
> Another point: FPS counter is off by default now. It was on
> before. Is it intended ?
>
> -Fred
>
Hi Fred,
Just look in main.cxx where it sets:
fgSetBool("sim/sceneryloaded",false);
This line could probably just be removed (afik it'll default to false), then
if you set it true in your .fgfsrc file it won't pause the FDM. Otherwise you
could use second configuration property and use an if/else to set the above
flag true or false at initialization.
An even better solution for development might be a variation of "reset" that
dumps and reloads the scenery. Especially if it left your view position the same.
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?
Alex Romosan said: > "Frederic Bouvier" <[EMAIL PROTECTED]> writes: > > > Is there a way to avoid the initial lock for scenery loading ? > > I understand this is a must have for users, but it slows > > down development speed dramatically when you have to test the > > apparence of a new building or landmark. > > i think the fix for the scenery loading is not quite right. with it i > get a very strange spitfire cockpit (i.e. i can see through the > instrument panel and the body of the aircraft). looks like z-buffer > ordering is not done properly (screen depth is 16bp, using the radeon > freedesktop drivers). if i disable it, the cockpit looks normal again. > if could only figure out how to start the damn plane... That has got to be a bug elsewhere. This only pauses the FDM. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] proposed message degrade in ATC code
For now anyway can we reduce this a level? This makes the airport not found
message (in ATC code only) warning level. I'm amazed at how often this gets
called.
Index: src/ATC/ATCutils.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/ATC/ATCutils.cxx,v
retrieving revision 1.11
diff -u -r1.11 ATCutils.cxx
--- src/ATC/ATCutils.cxx23 Jan 2004 17:18:25 - 1.11
+++ src/ATC/ATCutils.cxx23 Jul 2004 17:39:07 -
@@ -315,7 +315,7 @@
result = globals->get_airports()->search( id );
if ( result.id.empty() ) {
-SG_LOG( SG_GENERAL, SG_ALERT,
+SG_LOG( SG_GENERAL, SG_WARN,
"Failed to find " << id << " in basic.dat.gz" );
return false;
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Visual Reference Point scheme works
It has been a while since this feature was added, but I thought Jon might like to know that using his VRP feature I've succeeded in positioning the Cessna 310 (U-3A) visual model identically under both JSBSim and YASim flight dynamics models. The YASim config for the c310 has the origin placed at the nose. The changes are in CVS now. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OpenAL sound breaking up
I noticed that the least bit of extra CPU/Bus activity can cause the sounds to stutter after our switch to OpenAL. This might be a reason to remain conservative with our sound files (e.g. 8bit Mono). This is especially noticable on my system with the 16bit/44khz/Stereo merlin sample with the Spitfire. Running a P4 2.4 ghz with SBLive. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Tried the Spitfire
Very nice! Ok if I borrow the pilot dude for the p51 cockpit? Now, should it come up running like the other A/C? My personal preference is to not, but I think in the past folks have prefered aircraft already started. FWIW (after release) I think a preset "e.g. --auto-start" that defaulted to true, and was overridden as true automatically for mid air starts, but otherwise could be set false by the user so aircraft never come up running on the ground would be nice. Along this line it should be possible to have aircraft running after reset as well if --auto-start was enabled. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
Bernie Bright said:
> Jim Wilson wrote:
> >>
> >>globals->get_tile_mgr()->all_queues_empty() and cur_fdm_state->get_inited())
> >>{
> >>^^^
> >>^^^
> >>Same here.
> >
> >
> > That's a head scratcher. Never would have thought that would compile like
> > that. Learn something new everyday.
>
> C++ provides keyword equivalents to some operators:
>
> and &&
> and_eq &=
> bitand &
> bitor |
> compl ~
> not !
> or ||
> or_eq |=
> xor ^
> xor_eq ^=
> not_eq !=
>
> However it seems that we should use the traditional operators to prevent
> msvc from choking.
>
Sure enough, it's right there in Stroustrup. The strange part is never having
noticed this before now. What is it with these developers at microsoft
anyway? ;-)
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] fix for scenery load non standard code
Fix for those picky c++ compilers that actually insist on c++ syntax. cvs diff file: http://www.spiderbark.com/fgfs/sceneryloadpascaloops.diff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
Frederic Bouvier said:
> Erik Hofman wrote:
>
> > Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
> > In directory baron:/tmp/cvs-serv28544/src/Main
> >
> > Modified Files:
> > fg_init.cxx main.cxx
> > Log Message:
> > Jim Wilson: This patch prevents FDM execution until intial scenery load
> completes making
> > midair starts in the KSFO area possible again.
> >
> [...]
>
> > ! if ( global_multi_loop > 0) {
> > ! // first run the flight model each frame until it is intialized
> > ! // then continue running each frame only after initial scenery
> load is complete.
> > ! if (!cur_fdm_state->get_inited() or
> fgGetBool("sim/sceneryloaded")) {
>
> ^^
> Are we silently migrating the code to Pascal ?
> This doesn't compile with MSVC.
>
> > ***
> > *** 1331,1334
> > --- 1340,1350
> > // END Tile Manager udpates
> >
> > + if (!fgGetBool("sim/sceneryloaded") and
> globals->get_tile_mgr()->all_queues_empty() and cur_fdm_state->get_inited())
> {
> ^^^
> ^^^
> Same here.
That's a head scratcher. Never would have thought that would compile like
that. Learn something new everyday. Most of my day job work has been in java
lately...which certainly doesn't allow such englishisms :-)
The only time I ever did any Pascal programming was back in the eighties, for
a this guy I knew with a chain of video stores. He bought some program from a
company that went under and need something fixed.
Sorry about that :-)
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cvs broken now and log-level doc issue
Durk Talsma said: > I just saw this overhere as well, although I didn't check the log files so > carefully. This is probably caused by a the missing aircraft, because I don't > see this in my CVS version. > > The short term solution is going to be that we're removing MD-11 traffic. > I don't see any traffic files at all so maybe that is the problem. It looks like it all got removed on the last update. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] shrinking dialogs
This is a workaround for an issue where the xml dialogs were shrinking on
subsequent pops.
Andy Ross says:
That looks like it should be fine for a release-time workaround. The
2 pixel border on dialogs is at best a minor feature, and probably
invisible since the sub-frames all have their own padding.
Clearly the right fix would be to find out where the code is getting
confused by the previous layout. In principle, the layout should be
idempotent: if you don't change the layout constraints, it shouldn't
change its layout. There's still a bug in there somewhere.
Index: src/GUI/layout.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/GUI/layout.cxx,v
retrieving revision 1.2
diff -u -r1.2 layout.cxx
--- src/GUI/layout.cxx 14 May 2004 17:16:35 - 1.2
+++ src/GUI/layout.cxx 22 Jul 2004 19:16:08 -
@@ -24,7 +24,10 @@
int LayoutWidget::padding()
{
int pad = isType("group") ? 0 : 4;
-if(isType("dialog")) pad = 2;
+// As comments above note, this was being set to 2. For some
+// reason this causes the dialogs to shrink on subsequent pops
+// so for now we'll make "dialog" padding 0.
+if(isType("dialog")) pad = 0;
if(hasParent() && parent().hasField("default-padding"))
pad = parent().getNum("default-padding");
if(hasField("padding"))
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] create craters and smoke effect
Andy Ross said: > CHANDRASEKHAR ACHALLA wrote: > > I am doing a project for Boeing where I am trying to incorporate a > > few additional features they want into Flightgear. Initially I need > > to create a crater (hole) if a plane crashes (or a missile ). > > Boing wants craters? :) That's it! I'm flying on Aerobus airliners only from now on. > > Alternatively, I suppose you could alpha-blend a "2D" crater image on > top of the existing geometry; something along the lines of the "bullet > holes" that first person shooter games like to draw on walls. For a > flight simulator where the viewpoint isn't likely to be very near the > crater, this might be sufficient. Yes and much easier. You could even just make a model that was mostly flat but had a crater lip with burnt dirt texture and all that and just plop it on the ground in the right spot. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] cvs broken now and log-level doc issue
Just tried CVS and we're aborting right after the log entry for Traffic Manager. BTW I noticed in the command line help we're showing "0=verbose, 5=alerts only", but I think the numbers do not apply. I'd change it, but I'm not 100% sure what all the log-level options are. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in newgui code
Andy Ross said:
> Jim Wilson wrote:
> > On my system (CVS), the xml dialogs keep shrinking, just like Mike
> > Teevee.
>
> Confirmed. Unfortunately my analysis has been delayed by the need to
> google the Mike Teevee reference. :)
>
> Seriously, I'm really busy right now at work, so I'm hoping someone
> else can hack at this for the 0.9.5 release. The essence of this bug
> is that something isn't properly deleting the "height" and "width"
> values on the top-level dialogs before doing the layout. So the
> second time the dialog pops up the layout manager thinks the dialog is
> asking for the size it had the last time, applies (maybe?) a padding
> correction, and lays it out a little smaller than last time.
>
> The code looks correct, but clearly I missed something. It might have
> to do with the top-level PUI frame that gets added automatically by
> the dialog code? It looks like this is the only object that has its size
> changed. The rest of the dialog layout seems to be static across
> invocations?
>
I just tried this and it seems to work. Is this bad? Everything seems to
look ok here with this patch in place.
Best,
Jim
Index: src/GUI/layout.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/GUI/layout.cxx,v
retrieving revision 1.2
diff -u -r1.2 layout.cxx
--- src/GUI/layout.cxx 14 May 2004 17:16:35 - 1.2
+++ src/GUI/layout.cxx 22 Jul 2004 19:16:08 -
@@ -24,7 +24,10 @@
int LayoutWidget::padding()
{
int pad = isType("group") ? 0 : 4;
-if(isType("dialog")) pad = 2;
+// As comments above note, this was being set to 2. For some
+// reason this causes the dialogs to shrink on subsequent pops
+// so for now we'll make "dialog" padding 0.
+if(isType("dialog")) pad = 0;
if(hasParent() && parent().hasField("default-padding"))
pad = parent().getNum("default-padding");
if(hasField("padding"))
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] to fix SegFault in SimGear animation code
Erik Hofman said: > Jim Wilson wrote: > > Correct a typo that produces segfault during cleanup on some systems. > > Committed. Thanks. > Cool. Also, I posted a second patch for the scenery startup issue. I ended up using an xml dialog instead of nasal for the "Scenery Loading" message so it could also pop-up when teleporting to different airports. Probably I could have used nasal, but I'm just not up to speed on it yet, and I wanted to get a fix in for this issue before release. Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] Pause FDM while initial scenery load completes
This patch prevents FDM execution until intial scenery load completes making midair starts in the KSFO area possible again. Here is cvs diff: http://www.spiderbark.com/fgfs/sceneryloadpause.diff.gz Here is tar of whole files: http://www.spiderbark.com/fgfs/sceneryloadpause.tar.gz Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Bug in newgui code
On my system (CVS), the xml dialogs keep shrinking, just like Mike Teevee. To reproduce: 1) start flightgear 2) hit esc to bring up exit dialog 3) click cancel button 4) repeat step 2 & 3 six times. You'll see the dialog box shrink a couple pixels each time. Label and button positions or sizes don't change. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Thermal Modeling / Ridge Soaring
Jeffrey Sinsay said: > I'm pretty new to FlightGear, but am interested in > using it for a engineering project I have, but I need > to model sailplane soaring in a dynamic environment. I > noticed that currently thermals are implimented as an > AI object similar to the old thermal patches in MSFS. > Has anyone been working on modeling thermals based on > surface temp/lapse rate/terrain type, etc? (Perhaps > even using data from BLIPMAPs ( > http://www.drjack.info/BLIP/index.html )to generate > soaring conditions. Also does FlightGear model ridge > lift? > > More than willing to do significant coding for this to > happen. Just wanted to know what has been tried and if > there is anyone out there with a grand vision on how a > soaring environment should be implimented in FGFS. It > seems to me that doing something this dynamic through > the AI model may not sense. > I've thought about this a little. It became interesting when my father-in-law showed me the BLIPMAP site. To start with you probably want to come up with a method for distributing updraft velocities over a grid of some sort. Maybe something similar to the scenery tile cache (see src/Scenery/*.cxx) where thermals will be created and deleted as you move over the terrain. This is where the meat of designing the soaring function will be. The reason for using a grid is because (as I think you know) thermals are irregular shapes, depending on terrain, wind etc. You could design templates for a couple of shapes, like oval or two with the highest velocity off center and two or three levels surrounding. The shapes would look kind of like BLIPMAPS or terrain elevation MAPS, if you were to graph them. Start with two or three of these templates specified as a matrices. Then as you fly into a new zone you can instantiate "thermal objects" that are of a given template, centered at a given location (lon/lat), scaled to a certain size, and have a X max velocity that the outer band will subtract from to derive varying speeds across the thermal's area. Then on each frame (program cycle) you will need to query the grid (lon/lat spot) to see what the velocity of the updraft is at that location, and then update the environment data as required. Once you've got a way to place templates of thermals semi-randomly over a lon/lat grid and query them for velocties then you can add other features like ridge soaring (a long skinny template), as well as BLIPMAP input and placing thermals based on terrain properties. And actually if you were to get the basics going you might even find help from folks interested in making some of the thermals visible in the form of 3D clouds. I'm not a pilot so I'm sure there are lots of holes in this, but like I said it is an interesting problem. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] to fix SegFault in SimGear animation code
Correct a typo that produces segfault during cleanup on some systems.
Index: simgear/scene/model/animation.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/model/animation.cxx,v
retrieving revision 1.24
diff -u -r1.24 animation.cxx
--- simgear/scene/model/animation.cxx 20 May 2004 14:18:15 - 1.24
+++ simgear/scene/model/animation.cxx 21 Jul 2004 21:25:25 -
@@ -963,8 +963,7 @@
SGTexMultipleAnimation::~SGTexMultipleAnimation ()
{
- // delete _table;
- delete _transform;
+ delete [] _transform;
}
int
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] segfault in AIManager
Just took another look and realized the trace was fine. The bug really is in the animation code. I'll post the patch in a bit. Best, Jim Jim Wilson said: > There appears to be something still broken in the AIManager::update(). I'm > rebuilding without threads to see if I can get a better backtrace. The crash > is moderately intermittent and somewhat random except that it always occurs > early on, just a few frames after system initialization (but before scenery > loading is complete). > > I have not been able to reproduce with --disable_ai_models on command line. > > Best, > > Jim > > #0 0x4207afcc in chunk_free () from /lib/i686/libc.so.6 > #1 0x4207ad24 in free () from /lib/i686/libc.so.6 > #2 0x4006edc6 in __builtin_delete (ptr=0xc37) at ../../gcc/cp/new2.cc:-1 > #3 0x084cc1f0 in SGTexMultipleAnimation::~SGTexMultipleAnimation > (this=0xc1db498, __in_chrg=3) at animation.cxx:909 > #4 0x085465c7 in ssgDeRefDelete (s=0xc1db498) at ssg.cxx:89 > #5 0x085496d5 in ssgBase::~ssgBase (this=0xc36fee8, __in_chrg=0) at > ssgBase.cxx:75 > #6 0x0854d2ae in ssgEntity::~ssgEntity (this=0xc36fee8, __in_chrg=0) at > ssgEntity.cxx:53 > #7 0x08549bde in ssgBranch::~ssgBranch (this=0xc36fee8, __in_chrg=0) at > ssgBranch.cxx:60 > #8 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc36fee8, > __in_chrg=0) at ssgBaseTransform.cxx:50 > #9 0x0855b70d in ssgTexTrans::~ssgTexTrans (this=0xc36fee8, __in_chrg=3) at > ssgTexTrans.cxx:53 > #10 0x085465c7 in ssgDeRefDelete (s=0xc36fee8) at ssg.cxx:89 > #11 0x08549d7a in ssgBranch::removeKid (this=0xc364c38, n=8) at ssgBranch.cxx:97 > #12 0x08549dde in ssgBranch::removeAllKids (this=0xc364c38) at ssgBranch.cxx:112 > #13 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc364c38, __in_chrg=3) at > ssgBranch.cxx:59 > #14 0x085465c7 in ssgDeRefDelete (s=0xc364c38) at ssg.cxx:89 > #15 0x08549d7a in ssgBranch::removeKid (this=0xc254e58, n=0) at ssgBranch.cxx:97 > #16 0x08549dde in ssgBranch::removeAllKids (this=0xc254e58) at ssgBranch.cxx:112 > #17 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc254e58, __in_chrg=0) at > ssgBranch.cxx:59 > #18 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc254e58, > __in_chrg=0) at ssgBaseTransform.cxx:50 > #19 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xc254e58, __in_chrg=3) at > ssgTransform.cxx:53 > #20 0x085465c7 in ssgDeRefDelete (s=0xc254e58) at ssg.cxx:89 > #21 0x08549d7a in ssgBranch::removeKid (this=0xc07a3d8, n=0) at ssgBranch.cxx:97 > #22 0x08549dde in ssgBranch::removeAllKids (this=0xc07a3d8) at ssgBranch.cxx:112 > #23 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc07a3d8, __in_chrg=3) at > ssgBranch.cxx:59 > #24 0x085465c7 in ssgDeRefDelete (s=0xc07a3d8) at ssg.cxx:89 > #25 0x08549d7a in ssgBranch::removeKid (this=0xc2e8fd8, n=0) at ssgBranch.cxx:97 > #26 0x08549dde in ssgBranch::removeAllKids (this=0xc2e8fd8) at ssgBranch.cxx:112 > #27 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc2e8fd8, __in_chrg=0) at > ssgBranch.cxx:59 > #28 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc2e8fd8, > __in_chrg=0) at ssgBaseTransform.cxx:50 > #29 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xc2e8fd8, __in_chrg=3) at > ssgTransform.cxx:53 > #30 0x085465c7 in ssgDeRefDelete (s=0xc2e8fd8) at ssg.cxx:89 > #31 0x08549d7a in ssgBranch::removeKid (this=0xc27f778, n=0) at ssgBranch.cxx:97 > #32 0x08549dde in ssgBranch::removeAllKids (this=0xc27f778) at ssgBranch.cxx:112 > #33 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc27f778, __in_chrg=0) at > ssgBranch.cxx:59 > #34 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc27f778, > __in_chrg=0) at ssgBaseTransform.cxx:50 > #35 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xc27f778, __in_chrg=3) at > ssgTransform.cxx:53 > #36 0x085465c7 in ssgDeRefDelete (s=0xc27f778) at ssg.cxx:89 > #37 0x08549d7a in ssgBranch::removeKid (this=0xbea9d08, n=73) at ssgBranch.cxx:97 > #38 0x08549dde in ssgBranch::removeAllKids (this=0xbea9d08) at ssgBranch.cxx:112 > #39 0x08549bc7 in ssgBranch::~ssgBranch (this=0xbea9d08, __in_chrg=3) at > ssgBranch.cxx:59 > #40 0x085465c7 in ssgDeRefDelete (s=0xbea9d08) at ssg.cxx:89 > #41 0x08549d7a in ssgBranch::removeKid (this=0xc08d868, n=0) at ssgBranch.cxx:97 > #42 0x08549dde in ssgBranch::removeAllKids (this=0xc08d868) at ssgBranch.cxx:112 > #43 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc08d868, __in_chrg=0) at > ssgBranch.cxx:59 > #44 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc08d868, > __in_chrg=0) at ssgBaseTransform.cxx:50 > #45 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xc08d868, __in_chrg=3) at > ssgTransform.cxx:53 > #46 0x085465c7 in ssgDeRefDelete (s=0xc08d868) at ssg.cxx:89 > #47 0x08549d7a in ssgBranch::removeKid (this=0xbe0ce50, n=0) at ssgBranch.cx
[Flightgear-devel] segfault in AIManager
There appears to be something still broken in the AIManager::update(). I'm rebuilding without threads to see if I can get a better backtrace. The crash is moderately intermittent and somewhat random except that it always occurs early on, just a few frames after system initialization (but before scenery loading is complete). I have not been able to reproduce with --disable_ai_models on command line. Best, Jim #0 0x4207afcc in chunk_free () from /lib/i686/libc.so.6 #1 0x4207ad24 in free () from /lib/i686/libc.so.6 #2 0x4006edc6 in __builtin_delete (ptr=0xc37) at ../../gcc/cp/new2.cc:-1 #3 0x084cc1f0 in SGTexMultipleAnimation::~SGTexMultipleAnimation (this=0xc1db498, __in_chrg=3) at animation.cxx:909 #4 0x085465c7 in ssgDeRefDelete (s=0xc1db498) at ssg.cxx:89 #5 0x085496d5 in ssgBase::~ssgBase (this=0xc36fee8, __in_chrg=0) at ssgBase.cxx:75 #6 0x0854d2ae in ssgEntity::~ssgEntity (this=0xc36fee8, __in_chrg=0) at ssgEntity.cxx:53 #7 0x08549bde in ssgBranch::~ssgBranch (this=0xc36fee8, __in_chrg=0) at ssgBranch.cxx:60 #8 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc36fee8, __in_chrg=0) at ssgBaseTransform.cxx:50 #9 0x0855b70d in ssgTexTrans::~ssgTexTrans (this=0xc36fee8, __in_chrg=3) at ssgTexTrans.cxx:53 #10 0x085465c7 in ssgDeRefDelete (s=0xc36fee8) at ssg.cxx:89 #11 0x08549d7a in ssgBranch::removeKid (this=0xc364c38, n=8) at ssgBranch.cxx:97 #12 0x08549dde in ssgBranch::removeAllKids (this=0xc364c38) at ssgBranch.cxx:112 #13 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc364c38, __in_chrg=3) at ssgBranch.cxx:59 #14 0x085465c7 in ssgDeRefDelete (s=0xc364c38) at ssg.cxx:89 #15 0x08549d7a in ssgBranch::removeKid (this=0xc254e58, n=0) at ssgBranch.cxx:97 #16 0x08549dde in ssgBranch::removeAllKids (this=0xc254e58) at ssgBranch.cxx:112 #17 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc254e58, __in_chrg=0) at ssgBranch.cxx:59 #18 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc254e58, __in_chrg=0) at ssgBaseTransform.cxx:50 #19 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xc254e58, __in_chrg=3) at ssgTransform.cxx:53 #20 0x085465c7 in ssgDeRefDelete (s=0xc254e58) at ssg.cxx:89 #21 0x08549d7a in ssgBranch::removeKid (this=0xc07a3d8, n=0) at ssgBranch.cxx:97 #22 0x08549dde in ssgBranch::removeAllKids (this=0xc07a3d8) at ssgBranch.cxx:112 #23 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc07a3d8, __in_chrg=3) at ssgBranch.cxx:59 #24 0x085465c7 in ssgDeRefDelete (s=0xc07a3d8) at ssg.cxx:89 #25 0x08549d7a in ssgBranch::removeKid (this=0xc2e8fd8, n=0) at ssgBranch.cxx:97 #26 0x08549dde in ssgBranch::removeAllKids (this=0xc2e8fd8) at ssgBranch.cxx:112 #27 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc2e8fd8, __in_chrg=0) at ssgBranch.cxx:59 #28 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc2e8fd8, __in_chrg=0) at ssgBaseTransform.cxx:50 #29 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xc2e8fd8, __in_chrg=3) at ssgTransform.cxx:53 #30 0x085465c7 in ssgDeRefDelete (s=0xc2e8fd8) at ssg.cxx:89 #31 0x08549d7a in ssgBranch::removeKid (this=0xc27f778, n=0) at ssgBranch.cxx:97 #32 0x08549dde in ssgBranch::removeAllKids (this=0xc27f778) at ssgBranch.cxx:112 #33 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc27f778, __in_chrg=0) at ssgBranch.cxx:59 #34 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc27f778, __in_chrg=0) at ssgBaseTransform.cxx:50 #35 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xc27f778, __in_chrg=3) at ssgTransform.cxx:53 #36 0x085465c7 in ssgDeRefDelete (s=0xc27f778) at ssg.cxx:89 #37 0x08549d7a in ssgBranch::removeKid (this=0xbea9d08, n=73) at ssgBranch.cxx:97 #38 0x08549dde in ssgBranch::removeAllKids (this=0xbea9d08) at ssgBranch.cxx:112 #39 0x08549bc7 in ssgBranch::~ssgBranch (this=0xbea9d08, __in_chrg=3) at ssgBranch.cxx:59 #40 0x085465c7 in ssgDeRefDelete (s=0xbea9d08) at ssg.cxx:89 #41 0x08549d7a in ssgBranch::removeKid (this=0xc08d868, n=0) at ssgBranch.cxx:97 #42 0x08549dde in ssgBranch::removeAllKids (this=0xc08d868) at ssgBranch.cxx:112 #43 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc08d868, __in_chrg=0) at ssgBranch.cxx:59 #44 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc08d868, __in_chrg=0) at ssgBaseTransform.cxx:50 #45 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xc08d868, __in_chrg=3) at ssgTransform.cxx:53 #46 0x085465c7 in ssgDeRefDelete (s=0xc08d868) at ssg.cxx:89 #47 0x08549d7a in ssgBranch::removeKid (this=0xbe0ce50, n=0) at ssgBranch.cxx:97 #48 0x08549dde in ssgBranch::removeAllKids (this=0xbe0ce50) at ssgBranch.cxx:112 #49 0x08549bc7 in ssgBranch::~ssgBranch (this=0xbe0ce50, __in_chrg=0) at ssgBranch.cxx:59 #50 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xbe0ce50, __in_chrg=0) at ssgBaseTransform.cxx:50 #51 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xbe0ce50, __in_chrg=3) at ssgTransform.cxx:53 #52 0x085465c7 in ssgDeRefDelete (s=0xbe0ce50) at ssg.cxx:89 #53 0x08549d7a in ssgBranch::removeKid (this=0xbea3fa0, n=0) at ssgBranch.cxx:97 #54 0x08549dde in ssgBranch::removeAllKids (this
Re: [Flightgear-devel] Loading scenery message
Erik Hofman said: > Jim Wilson wrote: > > Erik Hofman said: > > >>It's easy to do with a tiny Nasal script, which remains visible when a > >>property (/sim/initialized ?) is false. > > > > Wouldn't that end up getting invoked every frame for the life of the program? > > This is just a one shot thing. > > No, a Nasal program is in essence a one-shot program. With some tricks > it is possible to get it running forever (during FlightGear's execution > time).. > Ah ok. Sounds good. How do I launch the script then? Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Loading scenery message
Erik Hofman said: > Jim Wilson wrote: > > I've got the FDMs waiting while the scenery loads on startup. Mid air starts > > are smooth again and even ground starts are a little nicer, especially if > > you've left the throttle on the joystick open full. The screen shows the > > scene as it always does, the aircraft just isn't moving. Someone mentioned > > putting up a "Loading Scenery" message while this is going on. What's the > > best way to do this? At the moment I'm not interested in doing a fuel gauge. > > Just a pop-up would suffice. > > It's easy to do with a tiny Nasal script, which remains visible when a > property (/sim/initialized ?) is false. > Wouldn't that end up getting invoked every frame for the life of the program? This is just a one shot thing. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Loading scenery message
I've got the FDMs waiting while the scenery loads on startup. Mid air starts are smooth again and even ground starts are a little nicer, especially if you've left the throttle on the joystick open full. The screen shows the scene as it always does, the aircraft just isn't moving. Someone mentioned putting up a "Loading Scenery" message while this is going on. What's the best way to do this? At the moment I'm not interested in doing a fuel gauge. Just a pop-up would suffice. Tomorrow night I'll look and see if the technique still makes sense when more awake (I have a slightly different approach in mind anyway). Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 Sounds
David Megginson said: > > How do the current DC-3 sounds come across on other people's computers? They > don't sound so hot on mine, but that might just be my sound card. > David, There is a modified sound config in cvs that at least partially addresses the problems. I hope Erik doesn't mind. BTW if anyone wants to mess with any of the aircraft sound configs that I've commited in the past, have at it. It isn't as easy (or fun) as it first appears :-). Basically the factors and methods in the config were wrong given the OpenAL inputs (we all knew this would be an issue with switching to OpenAL...and other aircraft still need work). Those dc-3 sound files are pretty good. There's a noticable looping click in the "engine running" sound that someone who is good with a sound editor might be able to fix. FWIW, I think eventually we're going to find that the easiest approach to sound configuration is going with interpolation tables instead of the "mathematical" techniques. Smoothly mixing and transitioning different sound loops as engine rpm and other operating conditions vary is the tricky part. I didn't do this with the dc3, so it is still a little rough. Should be better than it was though. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Not a good idea (was Re: [Flightgear-devel] Advertisements on the FG web site?)
David Megginson said: > check with people who know. I don't know U.S. professional fees that well, > but I'd guess that a full audit would leave a person at least USD 5K-10K > poorer just in accounting and/or legal fees, even if the auditors do not end > up finding anything wrong. > Well...not with a Schedule C-EZ ;-) Despite the odd and usually unconfirmed horror story, the IRS is actually quite fair and reasonable. Professional fees should always be proportional to the sums at risk. Otherwise you are wasting time and money and so is the IRS. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 Sounds
David Megginson said: > Jim Wilson wrote: > > >>What is the origin of the DC-3 sounds in the base package? Listening to the > >>individual samples, they sound an awful lot more like turbine engines than > >>piston -- granted, a few DC-3's have had turbine conversions. > > > > In the base package see the read-trev.txt file for credit and contact info. > > If the sounds were actually recorded in flight, then they are the sounds of > *two* engines plus wind and airframe noises. It might make more sense for > us to go back to synthetic sounds, since we need a separate sound for each > component. Yeah I ran into that with the P51. Ultimately I only used the initial cough and starter sound. One problem is part of the sound varies with RPM and other parts shouldn't. These sounds were originally donated for use by MSFS community modelers, and IIRC they were pretty highly talked about. But then again...maybe my memory isn't so good on that :-) > How do the current DC-3 sounds come across on other people's computers? They > don't sound so hot on mine, but that might just be my sound card. > I'll give it a try too. I need to check some other A/C as well. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] slow start-up
David Culp said: > > Try 'hdparm -d /dev/hdxx to check status of drive > > Yep, DMA checks on. I'm sure Curt has the problem figured out. What to do > about it is another issue. Some possible solutions: > > 1) Extend the appearance of the splash screen until all the loading is > finished. > > 2) Put a progress bar in the middle of the screen. > > 3) An hour-glass cursor? > > 4) A message box "Scenery Loading. Stand By..." > I may take a stab at this later in the week. If it is possible to query the tile loading queue then you can have the initialization delay the fdm until the loader is caught up (queue gets emptied). I'm not sure, but I think something like that would work. It'd be good to have this fixed for the release. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Not a good idea (was Re: [Flightgear-devel] Advertisements on the FG web site?)
David Megginson said: > Jim Wilson wrote: > > > You see, at least on the federal level you can collect quite a large sum of > > money as "gifts" before you have to put anything on your tax return. > > I am not intimately familiar with U.S. tax laws, but I would be very > surprised if the IRS allowed Curt to count advertising revenue as a gift. I > will admit that I do not know what the case would be for voluntary > donations, so a PayPal donation button might be an OK choice. > > > So in a nutshell my advice is: (1) Think about the project image issue. (2) > > Don't be afraid of small business. People do it every day. It doesn't have > > to be complex or "commercial". > > The overhead is not horrible, but it's important not to underestimate it -- > you'll be hard-pressed to find any small business owner who was not > surprised by the amount of non-billable work involved and dismayed by the > number of regs to learn (and I understand that the U.S. is much worse than > Canada in this regard). I've set up three corporations and have been running > my own small business since 1998, and the extra time required is by no means > a full-time or even half-time job, but it is there. I've never done > anything disasterous, but I did have to write off USD 18K in accounts > receivable from a customer that went bankrupt, and I lost another USD 9K to > the government early on because of tax laws I didn't fully understand yet (I > wrote myself a bonus cheque a couple of months later than I was supposed to, > and ended up with a mini-audit from the province of Ontario and USD 1.5K in > accounting fees on top of the tax penalty). > > I don't regret going into business for myself, but it's a big commitment, > not a side project. If someone already has too little time available, as is > Curt's problem, spending even more time managing customer relationships, > sending out invoices, chasing down bad accounts, filling in tax forms, etc. > might not be the best choice, especially if the potential revenue is (as I > suspect) a couple of thousand dollars per year at best. > > > P.S. Note, I am not a CPA or a lawyer, but I've been intimately involved in > > starting up corporations (one was my own) and have filed a few schedule C > > forms over the years. Talk to a CPA who understands that you want to "keep it > > simple". Generally speaking business lawyers don't know what "keep it simple" > > means (or rather they recognize that "simple" != "legal fees"). > > The problem is that the CPA's fee alone will probably represent a > significant percentage of the potential annual revenue. > I'm not disagreeing with you, but collecting a few donations from PayPal shouldn't require anything. That's the point. If (only if) it is required, a simple schedule C is routine for little things on the side and usually takes about 15 minutes to complete. Probably a million or more get filed in the US every year. There's even a short form version that covers most side hobby type things. Maybe I've missed something in this thread, I am not talking about a consulting business with customers, time billing, etc. Such a business is just exactly as you describe, except maybe for folks that just do a little moonlighting in the local neighborhood. Yes, schedule C would probably be required for advertizing revenues (if the proceeds are above the annual minimum which has got to be at least $500). That's why I mentioned it earlier. FWIW I'm not keen on the ad idea either. I don't think it would produce much anyway. As far as the CPA is concerned, of course they charge a good fee for their time if you ask them to structure a business or do a plan, financial statements, returns, etc. There are at least a couple in town here who will answer a simple question they don't have to research like "how much can I collect in donations before filing a schedule C" (just don't make the call during tax season :-)). For that matter the IRS 800 number offers the same info and probably the website does too. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with compiling FlightGear-0.9.5-pre1
golla Minoli said:
> I'm new to flightgear, though I allways wanted to play
> it. Nearly the first thing I did on my new compu, was
> to try to compile FG. Unluckyly I ran into three
> problems.
>
> First one is with the file
> "src/FDM/JSBSim/FGJSBBase.h". It requires
> "numeric_limits" included for limits.h. This is only
> implemented in a newer version of stdc++, which I
> sadly don't have. So I would have to find out the
> smallest possible change of a double and float
> variable.
>
> The second problem is that the Makefile in src/Network
> would like to compile a jpg-httpd.cxx. I could remove
> that from that makefile and also the missing
> src/Network/jpg-httpd.hxx from the makefile in
> src/Main and it would compile, though I dont know if
> it would be missed later on.
>
> My last problem was a missing file fg_os.cxx in
> /src/Main. Again I tried to replace it with
> fg_os_sdl.cxx.From the name of that file I guessed
> that this would be a bad idead, as I would like opengl
> and not sdl.
>
> Thanks a lot,
> Stefan
Ummm...hmmm...anyone read this yet (first preview feedback)? This issue has
been fixed in JSBSim and needs to be rolled into FlightGear at some point.
Perhaps this one fix should be added to FlightGear anyway before the next preview.
Meanwhile, below is the patch as found in JSBSim CVS:
Stefan, you can apply the patch to your source if you want.
Best,
Jim
Index: FGJSBBase.h
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/FDM/JSBSim/FGJSBBase.h,v
retrieving revision 1.15
diff -u -r1.15 FGJSBBase.h
--- FGJSBBase.h 27 Jun 2004 19:35:54 - 1.15
+++ FGJSBBase.h 20 Jul 2004 17:28:14 -
@@ -38,7 +38,7 @@
INCLUDES
%%*/
-#include
+#include
#ifdef FGFS
# include
@@ -204,7 +204,7 @@
@param b second value to compare
@return if the two values can be considered equal up to roundoff */
static bool EqualToRoundoff(double a, double b) {
-double eps = 2.0*std::numeric_limits::epsilon();
+double eps = 2.0*DBL_EPSILON;
return fabs(a - b) <= eps*max(fabs(a), fabs(b));
}
@@ -213,7 +213,7 @@
@param b second value to compare
@return if the two values can be considered equal up to roundoff */
static bool EqualToRoundoff(float a, float b) {
-float eps = 2.0*std::numeric_limits::epsilon();
+float eps = 2.0*FLT_EPSILON;
return fabs(a - b) <= eps*max(fabs(a), fabs(b));
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 Sounds
David Megginson said: > What is the origin of the DC-3 sounds in the base package? Listening to the > individual samples, they sound an awful lot more like turbine engines than > piston -- granted, a few DC-3's have had turbine conversions. > > In the base package see the read-trev.txt file for credit and contact info. This is the aircraft: http://www.airliners.net/search/photo.search?regsearch=N763A&distinct_entry=true Also (author's website): http://douglasdc3.com/ Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Not a good idea (was Re: [Flightgear-devel] Advertisements on the FG web site?)
David Megginson said: > So, in the end, my advice is not to do it. If you want to make a living or > partial living from FlightGear, set up a separate commercial site and be > prepared to learn about CRM, tax laws, incorporation laws, legal fees, > insurance, NDA's, contracts, and all the other fun that comes with running > your own small business. Well...hmm. This is a little pessimistic in tone. Non-profit can be handled with reasonable ease, at least in the US. Find someone who will set it up for a reasonable fee (free if possible), get a cost for registering and solicit contributions to do so. It isn't that bad. However, before doing this, I would consider what is really required here. You see, at least on the federal level you can collect quite a large sum of money as "gifts" before you have to put anything on your tax return. Even if Curt, or someone handling the money, did have to file a Schedule C (which is generally a no brainer for something like this) all he'd have to do is make sure the money got spent to avoid liability. The main reason for registering as a non-profit is to offer your contributors a way to take deductions off of their taxes. The second reason comes into play if "employees" are hired. That would be down the road a bit, I would guess. So in a nutshell my advice is: (1) Think about the project image issue. (2) Don't be afraid of small business. People do it every day. It doesn't have to be complex or "commercial". Best, Jim P.S. Note, I am not a CPA or a lawyer, but I've been intimately involved in starting up corporations (one was my own) and have filed a few schedule C forms over the years. Talk to a CPA who understands that you want to "keep it simple". Generally speaking business lawyers don't know what "keep it simple" means (or rather they recognize that "simple" != "legal fees"). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] How FlightGear handles 3ds
"Ampere K. Hardraade" said: > On July 8, 2004 09:47 am, Andy Ross wrote: > > Not to pass the buck, but this is really a plib question. > Why did I have a feeling that I was going to get that answer? =P > > In the short term, I guess I can export those parts that need illumination > into ac format, thus bypassing the whole 3ds illumination problem altogether. > However, I don't think this can be a permanent solution. As far as I can > tell, illumination in ac format seems to be an all or nothing deal -- either > the entire object illuminates, or no illumination at all. If my observation > is correct, this means that it won't be possible to create effects such as > lighting fall off. So in the long term, it will probably be a good idea to > sort out the effects (illumination, glossness, specular level, transparency, > perhaps reflection, etc.) within FlightGear before passing things to plib for > rendering (without breaking the encapsulation of course). > I'm not sure what you are saying here. It is certainly possible to have emissivity values set at intermediate levels, and to have them specified per vertex (actually per surface). There currently isn't any support for fading (dynamically changing) emissive properties in our animation code, but it probably could be done. Actually it is on my list of things to investigate "when I get a few extra minutes" (tm) as it would be great for the modeling of 3D cockpit/panel lighting. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 777 Model
"Ampere K. Hardraade" said: > On July 10, 2004 08:25 pm, Norman Vine wrote: > > Ampere K. Hardraade writes: > > > Anyway we can get the plib group to look into their method for rendering? > > > > Have at it ! > How do I reach them? > > > > > Note PLib's scenegraph is SSG < Simple Scene Graph > > > Since this model is anything but simple IMO it doesn't really > > qualify for SSG < Simple Scene Graph > :-) > Well, their method of rendering is capable of rendering that 350 millions > triangle monster in under 10 seconds. If using that method means that the > framerates of FlightGear goes up plus more detail scenery, then it certainly > worths look into in my opinion. Hmmm... that 777 Model page didn't mention a GPU. In any case, I gather from reading just the first paragraph on the OpenRT page you'd be looking at having plib utilize the OpenRT API in lieu of OpenGL's. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 777 Model
Jon Stockill said: > Wow! > > http://graphics.cs.uni-sb.de/MassiveRT/boeing777.html > > How long until we're using models with that level of detail then? ;-) > WAG: 8 years on high end retail hardware. ;-) ..fwiw...which isn't much. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim compile failing on Redhat 7.3
Jon S Berndt said: > On Wed, 7 Jul 2004 17:35:31 - > "Jim Wilson" <[EMAIL PROTECTED]> wrote: > >Mathias Fröhlich said: > > > >> On Mittwoch, 7. Juli 2004 17:30, Jim Wilson wrote: > >> > There doesn't seem to be support for the std::numeric_limits > >>references > >> > added in the June update. Can we work around this? > >> Done in JSBSim's cvs. > >> > >> Please check out a new version. > >> > > > >I don't see anything in JSBSim CVS that addresses this problem. Did > >you read the later posts? > > Jim: > > If you are browsing CVS, there is a lag between what is committed and > what is presented, I think. If you downloaded from CVS and there is > still a problem, that would be surprising - CVS is "immediate." Are > you still seeing the offending code? That would explain the problem. I'm using the browser. Currently no changes show. Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim compile failing on Redhat 7.3
Mathias Fröhlich said: > On Mittwoch, 7. Juli 2004 17:30, Jim Wilson wrote: > > There doesn't seem to be support for the std::numeric_limits references > > added in the June update. Can we work around this? > Done in JSBSim's cvs. > > Please check out a new version. > I don't see anything in JSBSim CVS that addresses this problem. Did you read the later posts? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim compile failing on Redhat 7.3
Jon S Berndt said:
> On Wed, 7 Jul 2004 15:30:14 -
> "Jim Wilson" <[EMAIL PROTECTED]> wrote:
> >There doesn't seem to be support for the std::numeric_limits
> >references added
> >in the June update. Can we work around this?
> >
> >e.g.:
> >
> >In file included from FGFCSComponent.h:46,
> > from FGDeadBand.h:40,
> > from FGDeadBand.cpp:40:
> >./FGJSBBase.h:41:18: limits: No such file or directory
> >
> >>From FGJSBBase.h:
> >
> >#include
>
> Looks like Mathias added this. It looks like it compiles under CygWin.
> It's present under IRIX, and it's also present under whatever Linux
> Mathias is using. Strange. In any case, the #include
> statement needs to be put in the correct #ifdef block, similar to the
> rest of the c++ headers.
>
In FGKinemat.cpp,
Would
while ( 0.0 < dt && fabs(Input - Output) < 0.1) {
work for this rather than:
while ( 0.0 < dt && !EqualToRoundoff(Input, Output) ) {
???
Sometimes the simplist solutions are best. I would think that in many cases
integrating variations in precision on different platforms would not always be
a good thing to do.
The above line of code is the only place the limits and the EqualtToRoundoff
functions built with them, are referenced.
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] JSBSim compile failing on Redhat 7.3
There doesn't seem to be support for the std::numeric_limits references added in the June update. Can we work around this? e.g.: In file included from FGFCSComponent.h:46, from FGDeadBand.h:40, from FGDeadBand.cpp:40: ./FGJSBBase.h:41:18: limits: No such file or directory >From FGJSBBase.h: #include Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Concorde
Jon S Berndt said: > >> copy direct.xml from some other engine directory to > >> Aircraft/Concorde/Engines. it worked for me. > > > On Wed, 7 Jul 2004 13:15:42 - > "Jim Wilson" <[EMAIL PROTECTED]> wrote: > > >Just in case someone, in the future, searches the archives for a > >solution to this particular error... This is NOT a good thing to do. > > A few weeks ago there was a change made to the propulsion system code > such that engines could be stored - not only in the engine/ directory > - but in the same directory that the aircraft config file is in. This > might cause some problems that were unforeseen because the thruster is > probably searched for in the same directory as the aircraft, too. If > that has not ALSO been moved over (the thruster file, that is; in this > case direct.xml), then the load will fail. > Ah ok...no I see I was late reading that thread. There was a direct.xml file in the directory already and I did not realize I was seeing that because Curt had added it after the posting. Sorry :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Concorde
Alex Romosan said: > "Curtis L. Olson" <[EMAIL PROTECTED]> writes: > > > I have commited a first stab at a Concorde model, first created by > > Melchior and the further enhanced by Thierry (a mailing list reader, > > but non-poster.) However, when I try to run it with the latest cvs > > version of FG, I get an endless string of: > > > > Unknown identifier: EOF in engine file: Olympus593Mrk610 > > Unknown identifier: EOF in engine file: Olympus593Mrk610 > > Unknown identifier: EOF in engine file: Olympus593Mrk610 > > Unknown identifier: EOF in engine file: Olympus593Mrk610 > > Unknown identifier: EOF in engine file: Olympus593Mrk610 > > Unknown identifier: EOF in engine file: Olympus593Mrk610 > > copy direct.xml from some other engine directory to > Aircraft/Concorde/Engines. it worked for me. Just in case someone, in the future, searches the archives for a solution to this particular error... This is NOT a good thing to do. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] L1011-500
tiagogusmao said: > You can take a look at these screenshots: > http://tiagogusmao.home.sapo.pt/l1011/finalv1.jpg > this one is my first try, there are missing parts, and the tail is horrible. > Current version is this one: > http://tiagogusmao.home.sapo.pt/l1011/tail-hstab.jpg > It's just a matter of finishing the tail, and add small details > > It has around 1 tris and 7000 vertices, is that ok for FG? > Looks like they (the vertices) have been wisely used. Nice job, good detail. If you have a doubts compare to some of the other models. That many vertices is a little heavy, but first impression from the screenshots is the usage is not unreasonable. Just make sure you aren't wasting any. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] help groking the code
Josh Babcock said: > I want to write a program that, given a lat/lon, will return the ground altitude > ASL and the slope (strike and dip). I have poked around in the simgear and > flightgear code a bit, and am having trouble finding where the tiles get loaded > to use as an example. Can someone point me in the right direction so I can get > up to speed? In the mean time, I think I'll go dust off my copy of > Deitel/Deitel. It's been a while :) > > Thanks, > Josh Look in Scenery/tilemgr.cxx, FGTileMgr::updateCurrentElevationAtPosition(). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
Josh Babcock said: > Jim Wilson wrote: > > > Modelers could perhaps build at the "aircraft specific" versions, so > > that they are there, and the program would default to ignoring these. Users > > who wanted the alternate versions could then deliberately enable them. > > > > Best, > > > > Jim > > > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > > What if there were an intermediate layer, call it functions. Each key in a key > configuration is bound to a function, say key 's' -> function 'aero-braking'. > Then a plane config could simply say I need function 'aero-braking' defined and > so on. Then the user just picks a key config that has all the appropriate > functions, (or even one that doesn't, but this should generate a warning so our > user can fix his key config). When the user what's to activate his speedbrake, > or drogue chute or whatever aero-braking system that their plane has, they just > press 's' or whatever they have defined. Loads a different plane, different > plane author, different, but similar, braking system maybe, but the function > name stays the same across planes, and the actual key that Joe user presses > stays the same. > > The only caveat is that we would have to make sure everyone is using the same > function names, but that's a lot easier than doing it with keys, since keys are > finite but there are an endless number of potential function names. If we start > with a broad enough list of functions to bind keys to, people should be able to > work within the system without having to add a new function too often. When > they do, the user just has to edit his key config and add a key for that function. > > Josh, still convinced that aircraft shouldn't be able to define the interface. > That sounds great Josh. And the "functions", independant of any binding would be on the order of "increase-flaps" or "decrease-flaps" rather than current single binding definition with "mod" entries (e.g. mod-shift). Your example ought be two functions: "aero-braking-on" and "aero-braking-off", two different bindings that could be attached to keys, key combos (like shift+key) or joystick buttons. It is possible that something might have a similar function, e.g. aero braking and still be deployed separately...so it might be difficult to generalize in many cases. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
Christian Brunschen said: > > Just one personal opinion ... > > What would be really good is if it were possible for the *user* to > define an arbitrary number of keyboard / joystick configurations. These > could also be named and grouped together; and there should be an easy > way to switch between these configurations, from the keyboard or > joystick itself if so desired. > > This would allow the user to set up different control configurations > for flying different types of aircraft. For instance, a plane that > doesn't have a retractable undercarriage won't need those controls at > all, and the keys that would otherwise have controlled the > undercarriage could then be used for something else. > > Also, it would allow people to set up different control configurations > for different flight regimes with the same aircraft. For instance when > flying a motorglider, you might want to switch between 'powered' and > 'gliding' flight regimes, and have the throttle lever alternatively > control the engine or the airbrakes; Setting up different control sets > and being able to switch between them easily would make that sort of > thing very easy and would probably be very useful and improve the user > experience a lot. > > Behind all of this, there would of course be a _default_ configuration > for the keyboard, for each type of joystick, etc, but the user should > be able to set up as many of their own configs as they want. > > And the configurations woul also be able to vary by which physical > controllers were actually available. A laptop user might have a big > hefty joystick at home, but might also want to fly > 'keyboard-and-mouse-only' when elsewhere; and might need different > keyboard configurations for these settings. > > The reason I mentioned grouping configurations together is to allow the > user to specify, say, that three configs - 'fighter takeoff, fighter > dogfight, fighter landing' - all belong together. Combine this with a > 'cycle to next configuration in set' function which could be assigned > to the same button in each fighter config, the user could easily switch > back and forth between regimes as neccessary - without involving the > four helicopter and two motorglider configurations they've _also_ made, > but which are of course irrelevant when flying a fighter plane. The > particular configuration group could be chosen in a menu (being a > relatively infrequent operation). Aircraft might also be able to > provide hints, so that a suitable control configuration set could be > loaded automatically. > > But I digress ... I hope you don't mind these musing from an > interested-but-not-actively-coding reader of this mailing list. > Sounds like a cool idea. Reminds me of how much television I'd have to watch to ever get good at using that universal remote control :-) Modelers could perhaps build at the "aircraft specific" versions, so that they are there, and the program would default to ignoring these. Users who wanted the alternate versions could then deliberately enable them. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
David Megginson said: > Jim Wilson wrote: > > > Sorry for the dumb question: why are they offending? I'm in favor of limiting > > aircraft specific key bindings to a very small number of keys (like 1 or 2), > > but I'm also not clear why the input binding configuration needs to be handled > > differently than it is now. > > It's a layering violation: I know that sounds like a technicality, but it > has serious effects on usability and system management. > > Once we set up a GUI for bindings, the user should not be surprised by > having new, unrequested key bindings appear simply because (s)he chose a > different airplane. For example, if the user binds '/' to fire an > afterburner then loads a plane that uses '/' to deploy slats, we have broken > the prime directive of user apps and discarded the user's input without > warning. The only reason this hasn't been a problem so far is that changing > key bindings without a GUI is too complicated for non-power users. > > From a management point of view, let's say that we decide to use '/' by > default to open a save file. With the current system, that will work fine > until the user happens to load a plane that uses '/' for something else, and > then it will fail to work, even if the user switches back to the original > plane, because the rebinding will outlive the aircraft that triggered it. > > So, let's see if we can fix this: keyboard.xml is long overdue for a rewrite > anyway. > My earlier thought on this is that we should allocate aircraft specific keys by creating a dummy binding in keyboard.xml that would "reserve" the key. This came up in a discussion a few weeks ago. We could simply reserve maybe 2 or 3 or some small number that can be used. And they would be purposefully held to a very small number so that only features that are truly aircraft specific would be included. One idea on this that I haven't really worked out would be separating the functional properties of the bindings from the keys that make them work. So basically you'd have a configuration of "named bindings" that could be attached to keys or buttons. All the property tree references, scripts, and so on would be in the named bindings xml. Anyway...just a vague notion. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
David Megginson said: > Through the magic of find and grep, here are the offending aircraft Sorry for the dumb question: why are they offending? I'm in favor of limiting aircraft specific key bindings to a very small number of keys (like 1 or 2), but I'm also not clear why the input binding configuration needs to be handled differently than it is now. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
Andy Ross said: > David Megginson wrote: > > Does anyone have code that depends on having bindings for the > > keyboard, mouse, and joystick(s) visibile in the main property tree? > > Some of the joysticks (at least the X45, maybe others) use a "mode" > property under /input/joysticks/js[0] to track switch positions. But > this can easily be moved somewhere else; or just left in place as a > lonely, vestigial relic of code gone by. > Forgot about that one. This could be a problem for some folks. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
David Megginson said: > Does anyone have code that depends on having bindings for the keyboard, > mouse, and joystick(s) visibile in the main property tree? I'm planning a > cleanup of the input subsystem, and part of that will be reading XML > configuration files directly like we do for models and other parts of > FlightGear. That will also make it possible to reload new bindings at > runtime without stopping and restarting FlightGear. > It seems that doing aircraft specific bindings relies on the current method. I think we should be thinking about the possibility of providing binding dialogs, including the ability to change individual bindings on the fly and also save those changes so that they are in place during subsequent executions. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bones and IK
Lee Elliott said: > > Actually, it's easy enough too, to work out the exact anim axis by measuring > them in whatever 3d app you're using - simple enough maths that even I can do > it. I'm behind (this message is a week ago!) :-) That's true, it is easy, but I think the method where you define the axis using the end points (x1-m,y1-m,z1-m) and (x2-m,y2-m,z2-m) provides better documention to less experienced users and of course does away with the need for even "simple" math. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3d instruments
Roy Vegard Ovesen said: > On Tuesday 15 June 2004 14:49, Jim Wilson wrote: > > I can probably answer your question, but I don't know what you mean by > > "alias feature". Is that a 2d panel thing? Maybe that answers your > > question? ;-) > > Yes, the alias feature is a 2d panel thing. It is usefull when you have two > identical instruments that should be "connected" to different properties, for > example two nav radios or two CDIs. With aliases, one defines which > properties to use, for that particular instrument instance, in the panel > config file when including the instrument config file. This is a very usefull > feature, and it would be just as usefull for 3d instruments for exactly the > same reasons as it is for 2d instruments. > > Because of aliases apparently not being implemented, the Piper has two CDIs > that are connected to the same nav radio, and consequently display the same > information. You can have more than one xml wrapper for the same model. It really wouldn't be all that awkward to have something like this: /Aircraft/Instruments-3D/vor/vor-nav1.xml /Aircraft/Instruments-3D/vor/vor-nav2.xml /Aircraft/Instruments-3D/vor/vor.ac /Aircraft/Instruments-3D/vor/vor.rgb For things like switches that are very numerous I'm wondering how big a deal it would be to be able to reference an array of models in a single xml wrapper. Well actually... h... Right now we're referencing xml files in the "path" property of the model arrays ( tags). What happens when you add animation tags inside a tag and make the path reference the .ac file instead of another wrapper? I think that might work. Like this: /pathname/switch.ac animation definition for this particular switch... Repeat for each switch. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: default weather
"Curtis L. Olson" said: > We currently have the ability to sync with real METAR weather reports as > we fly. > > I would like to propose that we set the default weather to zero winds, > zero turbulence, and maybe (?) zero clouds. > > Those that want interesting weather by default can use the METAR > fetching feature, and those that are trying out FG for the first time > will have fewer surprises. What do you think? > Sounds ok. Then Denver won't be in the clouds all the time. Maybe a pui dialog option(s) that offered a non-metar weather scenario or two or three would be good. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DME bias question
"Curtis L. Olson" said: > medical equipment for sale. :-( Anyone remember when google used to be > useful? And I thought it was just me! Too many people messing around with shill pages, stupid blogs and what not. Is there better? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
