Dear Jim, I checked myself several times but cannot find a mistake at the moment. Somebody else with a FEM package could check my calculations. I fiddled a bit around with the constraints but these do not make much difference.
I also got your model running. It looks very nice indeed. The model is also behaving much more friendly then the java script program from the Internet as was already mentioned before. kind regards, Marcel Wittebrood ADSE -----Original Message----- From: [EMAIL PROTECTED] [mailto:flightgear-devel-request@;flightgear.org] Sent: vrijdag 18 oktober 2002 19:36 To: [EMAIL PROTECTED] Subject: Flightgear-devel digest, Vol 1 #1081 - 15 msgs Send Flightgear-devel mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit http://mail.flightgear.org/mailman/listinfo/flightgear-devel or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Flightgear-devel digest..." Today's Topics: 1. Re: runway lighting (Curtis L. Olson) 2. Re: runway lighting (Curtis L. Olson) 3. Re: Wright flyer wing warping (Jim Wilson) 4. Re: Elite Simulator (Alex Perry) 5. Re: Elite Simulator (Alex Perry) 6. Re: Licensing issues (Alex Perry) 7. Re: Elite Simulator (Curtis L. Olson) 8. Re: runway lighting (David Megginson) 9. Re: runway lighting (Curtis L. Olson) 10. Change in runway type... (Fabien ILLIDE) 11. Re: Elite Simulator (David Megginson) 12. Re: Elite Simulator (David Megginson) 13. Re: runway lighting (Frederic BOUVIER) 14. re: Change in runway type... (David Megginson) 15. Re: Licensing issues (Brandon Bergren) --__--__-- Message: 1 Date: Fri, 18 Oct 2002 07:35:34 -0500 From: "Curtis L. Olson" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] runway lighting Reply-To: [EMAIL PROTECTED] John Check writes: > > If you want to fly this yourself, you can grab: > > > > http://www.flightgear.org/tmp/KSFO.btg.gz > > > > Does anybody have a copy or a proper link? it seems to be 404. My fault, didn't push my change out to the web server ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org --__--__-- Message: 2 Date: Fri, 18 Oct 2002 07:38:23 -0500 From: "Curtis L. Olson" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] runway lighting Reply-To: [EMAIL PROTECTED] Martin Spott writes: > Curt, > > > No one commented on my last runway lights message so I figured I'd > > send some more picts of the latest: > > Yesterday night it was simply too late to give appropriate comment .... > I am _really_ amazed. In my eyes this this is the most valuable visual > feature in FlightGear since I'm watching this project. > > > Essentially the state of things is that if we regen all the airports > > they will all get as much lighting as I've implimented. > > .... but in reality not every airport _has_ lightning. Mybe it would be > appropriate to stick to the information on airport lightning that is present > in the airport database, Right, our database does have lighitngn information, and the airport generator honors it. If you fly around SFO with the new lighitng you'll see an ALSF-II approach, an SSALS, and SSALR, and a couple REIL's. Also you'll see some runways with centerlines, some without, and some runways have touchdown zone lighting. Our world (once I finishe with the other lighting schemes, and once it's regenerated) will be as close to reality as our database allows. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org --__--__-- Message: 3 Date: Fri, 18 Oct 2002 13:24:16 -0000 To: <[EMAIL PROTECTED]> Subject: Re: [Flightgear-devel] Wright flyer wing warping From: "Jim Wilson" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Very interesting, but from the photos there seems to be much more movement than that. Are you sure you are scaled correctly? Also remember that Orville claims the leading edges stayed parallel (although I suppose at 0.8mm it'd be hard to tell). Best, Jim Marcel Wittebrood <[EMAIL PROTECTED]> said: > Sorry, I made a mistake, > =20 > I contour plotted the beam bending moment in the last mail and wrote = > some nonsense to talk the large deflection value straight.:-)))))))))) > =20 > This picture is probably correct............=20 > =20 > Only 6.011 mm at the back spar tip, 0.8 mm at the front spar tip. So for = > 80 N force input you get about atan((6.011-0.8) /1180) =3D 0.25 deg (The = > aerodynamic forces are working against this value, so the real warping = > is less !!). > =20 > The 40 N force input translates to about 300 N at the hip saddle if I am = > correct (There are 4 wings) > =20 > kind regards, > =20 > =20 > --__--__-- Message: 4 Subject: Re: [Flightgear-devel] Elite Simulator To: [EMAIL PROTECTED] Date: Fri, 18 Oct 2002 08:52:22 -0700 (PDT) From: Alex Perry <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] > I spent most of the time practicing holding patterns. I'm still > trying to decide whether to love or hate them: I'll write a tutorial > for sim users some day if anyone is interested. I understand that ATC > almost never uses holds any more A lot of approach plates, needing a course reversal, either use a procedure turn or a hold. The former is easier, but needs a depicted hold somewhere else in most cases, the latter. Thus, I've been given radar vector, direct to navaid when able, then hold, efc for the approach at specific time. So far, I've never had a hold enroute, before getting into terminal airspace. --__--__-- Message: 5 Subject: Re: [Flightgear-devel] Elite Simulator To: [EMAIL PROTECTED] Date: Fri, 18 Oct 2002 08:55:47 -0700 (PDT) From: Alex Perry <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] > Once we get > full approach lighting implimented it's going to be hard to find > significant reasons not to do a 1.0 release ... Instructor console, intuitive enough that non-software-engineers can operate it without being trained by someone already familiar with it. But that's about it. --__--__-- Message: 6 Subject: Re: [Flightgear-devel] Licensing issues To: [EMAIL PROTECTED] Date: Fri, 18 Oct 2002 09:03:09 -0700 (PDT) From: Alex Perry <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Christian (and others): The purpose of my two bits of text, which you quoted, was to formally state on the mailing list what _my_ policy is for _this_ project. I was not trying to tell anybody else how their patches/code should be treated ... I wrote the message to avoid putting GPL copyright notices on the top of every little patch I routinely send through the mailing list. I should explicitly mention that my policy may be different on other projects. Thus, I encourage you to disagree with my personal policy (grin). > > I think I've said this before. If I submit a patch against someone > > else's file, the patch is intended to inherit the copyright and any > > current or future licensing of the containing file or code fragment. > > When I create a file, or submit a large patch to a file without an > > identified copyright owner, the intent is to retain the copyright > > in my name and apply _only_ the then-current GPL license version. --__--__-- Message: 7 Date: Fri, 18 Oct 2002 11:12:48 -0500 From: "Curtis L. Olson" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Elite Simulator Reply-To: [EMAIL PROTECTED] Alex Perry writes: > > Once we get > > full approach lighting implimented it's going to be hard to find > > significant reasons not to do a 1.0 release ... > > Instructor console, intuitive enough that non-software-engineers > can operate it without being trained by someone already familiar with it. > But that's about it. Yes, good point, a better/more complete GUI is something we would also really need to add. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org --__--__-- Message: 8 From: David Megginson <[EMAIL PROTECTED]> Date: Fri, 18 Oct 2002 12:29:51 -0400 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] runway lighting Reply-To: [EMAIL PROTECTED] Curtis L. Olson writes: > Our world (once I finishe with the other lighting schemes, and once > it's regenerated) will be as close to reality as our database > allows. Have you patched TerraGear to eliminate runway edge lights for unlighted runways? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ --__--__-- Message: 9 Date: Fri, 18 Oct 2002 11:38:50 -0500 From: "Curtis L. Olson" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] runway lighting Reply-To: [EMAIL PROTECTED] David Megginson writes: > Curtis L. Olson writes: > > > Our world (once I finishe with the other lighting schemes, and once > > it's regenerated) will be as close to reality as our database > > allows. > > Have you patched TerraGear to eliminate runway edge lights for > unlighted runways? Well, patched maybe isn't the best word, but essentially yes. Now we only generate the runway lighting schemes that we understand: ASLF-II, MALS, MALSF, MALSR, SSALS, SSALF, SSALR, REIL ... Threshold, edge, and center line lighting are seperate entries in our database and those are generated accordingly. There are still more approach lighting arrangements that need to be implimented ... Robin has a list of 20-25 in his docs. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org --__--__-- Message: 10 Date: Fri, 18 Oct 2002 18:59:42 +0200 From: Fabien ILLIDE <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Change in runway type... Reply-To: [EMAIL PROTECTED] Hi, Sorry if I'm oftopic. Well, I don't know if it has be "solved" in 0.8.0 cause I still haven't install it on my new Gentoo GNU/Linux. With previous version of FGFS on Mandrake GNU/Linux, on the airport of my home-little-french-town, there was a runway still in grass, and it's in "hard" since a long time. _My question is_ : how modify this ? (or : where to ask such questions) In fact, I plan to do a GNU/Linux install-party here, and invite people from airschool to it. Then show them FGFS, and the pretty cool way to have quite all the world scenery for free. Then, I will be very pleased if I could show them by facts the way of Free "Libre" Software. I mean : "your airport is not up-to-date, you're concerned users, then do it if you can, or ask to do it and be active with your software evolution." I hope you see what I mean. So please don't change that runway now ! ;-) Thanks, Fabien ILLIDE --__--__-- Message: 11 From: David Megginson <[EMAIL PROTECTED]> Date: Fri, 18 Oct 2002 13:00:30 -0400 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Elite Simulator Reply-To: [EMAIL PROTECTED] Alex Perry writes: > A lot of approach plates, needing a course reversal, either use a > procedure turn or a hold. The former is easier, but needs a > depicted hold somewhere else in most cases, the latter. Thus, I've > been given radar vector, direct to navaid when able, then hold, efc > for the approach at specific time. So far, I've never had a hold > enroute, before getting into terminal airspace. I haven't seen a hold instead of a PT yet in Canadian approaches, but then I haven't looked at approaches for mountainous areas. I can see where a hold (possibly with a shuttle descent) could be valuable near high terrain. By the way, here's an interesting bit of trivia: Canadian approaches have almost completely abandoned OMI markers (completely for middle and inner). Instead, at high traffic airports, they use an NDB a few miles from the threshold for the FAF (and often the IAF as well), so you have to use the ADF (or DME) together with ILS to establish the FAF; there's sometimes another NDB off the far end of the runway for missed approach. It looks like I'm not going to see a marker light at any point in my instrument training. Here's an example from the DAFIF (without a second NDB for the missed approach, since the VOR is nicely lined up): http://164.214.2.62/products/digitalaero/terminals/v0211/CANADA/OTTAWA_MACDONALD_CARTIER_INTL/V_ILS_OR_NDB_RWY_32.PDF I can think of three advantages to switching from OMI to NDB: 1. ATC can still allow instrument approaches using the NDB (to higher minima) when the ILS is U/S. 2. ATC can vector traffic directly to the IAF or FAF more easily. 3. VFR traffic can use the NDB to line up in marginal VMC conditions. Can anyone think of other benefits to throwing out the OMI markers? What are the disadvantages? As you might guess, it's rare to see an IFR Canadian plane without an ADF radio, especially since the majority of approaches at smaller airports are still NDB or NDB/GPS, and many smaller towns are joined by NDB air routes rather than Victor airways. Without RNAV, I could not even fly to Kingston from Ottawa IFR without an ADF. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ --__--__-- Message: 12 From: David Megginson <[EMAIL PROTECTED]> Date: Fri, 18 Oct 2002 13:01:01 -0400 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Elite Simulator Reply-To: [EMAIL PROTECTED] Alex Perry writes: > Instructor console, intuitive enough that non-software-engineers > can operate it without being trained by someone already familiar with it. > But that's about it. Course plotting should be part of that. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ --__--__-- Message: 13 Date: Fri, 18 Oct 2002 19:08:05 +0200 (MET DST) From: "Frederic BOUVIER" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: Re: [Flightgear-devel] runway lighting Reply-To: [EMAIL PROTECTED] Curtis L. Olson <[EMAIL PROTECTED]> wrote : > > David Megginson writes: > > Curtis L. Olson writes: > > > > > Our world (once I finishe with the other lighting schemes, and onc= e > > > it's regenerated) will be as close to reality as our database > > > allows. > > > > Have you patched TerraGear to eliminate runway edge lights for > > unlighted runways=3F > > Well, patched maybe isn't the best word, but essentially yes. Now we > only generate the runway lighting schemes that we understand: > > ASLF-II, MALS, MALSF, MALSR, SSALS, SSALF, SSALR, REIL ... > > Threshold, edge, and center line lighting are seperate entries in our > database and those are generated accordingly. > > There are still more approach lighting arrangements that need to be > implimented ... Robin has a list of 20-25 in his docs. There are airports that have intermitent, remotely switchable with onboar= d radio, lighting. When you arrive in the vicinity of such an airport, you = "push" (sorry, lack of english vocabulary here) say 7 times in 5 seconds on the = radio button to switch it on. It switch off automatically after 15 minute= s or you can switch it off with 9 pushes. Is there description for such an arrangement in the airport database=3F U= sually, details on this are in the Sectional Chart. Cheers, -Fred --__--__-- Message: 14 From: David Megginson <[EMAIL PROTECTED]> Date: Fri, 18 Oct 2002 13:10:01 -0400 To: [EMAIL PROTECTED] Subject: re: [Flightgear-devel] Change in runway type... Reply-To: [EMAIL PROTECTED] Fabien ILLIDE writes: > _My question is_ : how modify this ? (or : where to ask such > questions) The easy part is to edit the entry in $FG_ROOT/Airports/default.apt.gz. The hard part is to regenerate the scenery for that tile. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ --__--__-- Message: 15 Date: Fri, 18 Oct 2002 10:04:45 -0500 From: Brandon Bergren <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Licensing issues Reply-To: [EMAIL PROTECTED] Erik Hofman wrote: > Okay, here's my view. > > I've spent numurous hours of work into FlightGear (sometimes even almost > as a day job) not only for the fun of it, but also because it's Free > (for everyone). The fun would stop for me if I noticed my work ens up in > a commercial application as an easy way to make money. You don't want to > know how much time I've spent creating the F-16 configuration file and > some of the texture (realy, you don't). > > That said, if the product will clearly state it's based on FLightGear > _and_ provided the URL to the website, I'm willing to accept almost > anything because that assures me there won't be any commercial > compettitor which directly affects FlightGear. > > For instance, if there ever will be a sailing simulator based on large > parts of FLightGear, I would have no obligations because it doesn't > affect FlightGear itself. However, if for example the textures end up > included in a commercial flight simulator just because it saves them > time, I will strongly disagree. > > On the other hand, if one or more of the active FlightGear developers > get the opportunity to spent their life developing FlightGear that way > (which *is* a donation to FlightGear if you ask me) I would have no > obligations at all. > > Erik Erik, I don't think there's any movement to change the license on the base package. I believe this discussion is on moving useful code routines from fg to sg, to make simgear a more useful and attractive platform. --Brandon Bergren --__--__-- _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel End of Flightgear-devel Digest _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
