[Flightgear-devel] Win32-downloads
Hello, I just glanced over the logfiles of my ftp-server and I realized, that people obviously are downloading the Win32 'fgsetup'-package like hell (at least compared to _my_ measures). Over 8.700 downloads since November. I find this really amazing. Where are all these people? I don't have the impression that they show up on any of the FlightGear mailing list - do they ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Clouds artefacts
Jim Wilson wrote: > We first ran into this problem with the old back to front scheme when David > did the first trees. But I'm wondering now why the prop disks are a problem. > Shouldn't the aircraft model be on the bottom of the stack anyway? Generally > there's nothing between it and the camera. The plane is in the same scenegraph than the terrain or other objects, except clouds. You have to draw them either before ( with terrain clipped or no clouds between the viewer and the terrain ), or after ( with prop disc problem ), or both like in the current situation. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Solaris binary package
Martin Spott wrote: > I created a Solaris binary package from the current release: > > ftp://ftp.ihg.uni-duisburg.de/FlightGear/Solaris/fgfs-0.9.4-Solaris.tar.gz I redid the package in order to follow the filesystem-layout as proposed by Erik, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] PA-28 model
David Megginson wrote: > Martin Spott wrote: >> Today I took the PA28 in FlightGear and I was terribly surprised that >> the feeling of the model matches the original aircraft _that_ close. > Thank you very much for the feedback. I know what you mean about yanking > the Cherokee off the runway -- with a 172, as soon as you raise the nose, > the plane flies off; with a PA-28, it feels like you have to give it a hard > yank. You can work around that in a couple of ways: > > 1. Use two notches of flaps even on a long, paved runway. The plane jumps > off the runway and climbs like a rocket. > > 2. Raise the nose and wait a few seconds -- the Cherokee really will fly > off, but it takes a bit longer because of the higher stall speed. I dislike 1.) a bit because I'm loosing speed. In case of an engine failure after liftoff I might get into serious trouble when I have the flaps set. In EDLN I'd be lucky because the runway is 1200 m long and followed by lots of flat grass land. At EDWJ you're supposed to crash into the dunes or plunge into water Number 2.) bears the 'risk' of going 90 kts and still having your feet on the ground :-) The Archer accelerates a bit faster than the C150 (what I'm used to). Rotating at 65 kts and liftoff _before_ 70 kts - as requested by my instructor - leaves very little room for a smooth transition but I'll accept this challenge :-)) > In landing, you have to keep up your approach speed right to the pavement. > You cannot do a high, gradual roundout like you do with a 172 or you'll drop > it in from a few feet up, because the speed decays so fast in the flare > (especially with full flaps). We use three notches of flaps and I am happy to say that landing with the PA28 feels _much_ easier to me than with one of the Cessna's. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Outsider opinion - really the last one
On Mon, 29 Mar 2004 04:17:25 +0200, Oliver wrote in message <[EMAIL PROTECTED]>: > That's why the Free Software Foundation Europe invented the FLA > as a workaround: > http://www.fsfeurope.org/projects/fla/fla.en.html ..another beautiful baseball bat. ;-) Thanks. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Outsider opinion - really the last one
On Monday 29 March 2004 03:19, Arnt Karlsen wrote: > > ..I dunno your guys or FLY! licensing for users contributions like > add-on planes, were you required to give up your copyrights? > > ..such an policy might deny you the right to put "your own add-on > FLY! planes" into FlightGear, because you have given up your > copyrights and transferred them to someone else. If he live in Germany or in some other European countrys this does not matter, because you can't transfer your Copyright to someone else in Germany (and some other European countrys). Such a contract would be voided by law. In other words a copyright holder remains the copyright holder. That's why the Free Software Foundation Europe invented the FLA as a workaround: http://www.fsfeurope.org/projects/fla/fla.en.html Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Outsider opinion - really the last one
On Mon, 29 Mar 2004 00:58:43 +0200, Georg wrote in message <[EMAIL PROTECTED]>: > Ok, I'll give not up with my goal to get clother together what's not > fitting so easily - two worlds with own rules and sight of the things, > remarkable incompatible, not yet realizing their big chance to bundle > their activities and power througout the next years - that would make > a really stronger alternative to M$. ..only beware of the licensing, on bundling, not all free beer and free speech licenses are compatible with the GPL, which we use here. ..I dunno your guys or FLY! licensing for users contributions like add-on planes, were you required to give up your copyrights? ..such an policy might deny you the right to put "your own add-on FLY! planes" into FlightGear, because you have given up your copyrights and transferred them to someone else. ..now, you ofcourse can write new stuff under whatever license you like. You will want to document the fact "that this here is my new gpl code and that old junk of mine over there is not", to avoid lawsuits from assholes who don't want you useing the GPL. ..here in FG, each one coder retains his own copyrights under the GPL and copyright laws, these 3 elements are what protects any and all GPL code. (Some people even assign their copyrights to _our_ lawsharks over at http://www.fsf.org/, to protect it better.) > I will write down some points to discuss within the next week in my > really bad but hopefully understandable German English(Flight Gear and > other alternative Flightsims: Visions, Goals and Strategies) and since > that might be annoying members of this list I will put a link here to > a private site. THEN everybody is FREE to have a look at it OR NOT, > read it, forget it or discuss with me. (Theme could be: meet the > aliens) THE LAST THING I want to do is induce bad emotion, aggressive > discussion, steal your valuable (share)time you need for other tasks. ..constructive criticism is allways welcome, as are new coders. ;-) > BUT Flight Gear has NOW got a quality, power and (sleeping) potential > not realized in the"outer" world and frustration effects of really > interested simmers not seriously noticed within your "closed loop > world". There have even been some new discussions around Flight Gear > in some forums (I read some posts on chance in the Flight Unlimited > Forum on AVSIM). Many arguments are unfair or even false, some are of > big value. Strategic decisions where to go and how to go have to be > made now or never on both sides of that unvisible"cutting-line" > between those sim-worlds as necessary development beside the"normal" > way will last years and many flightsimmers will go the (wrong) way > back to M$FS in the future due to no perspective with "their" > flightsims. If you want to read my proposals, look forward to the link > in this list. Otherwise just ignore it. I think that will be the best > solution not to get in conflict with anyone here as I am grateful for > your work and the lot of time you invest (I know myself as developing > and Beta-Testing for FLY!). ..well, the best way is bring your guys over here, the influence is weighted by the amount of code written here. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Pre-Releases and Releases
Jon Berndt said: > > "Jim Wilson" wrote: > > > Jon Berndt said: > > > > >> Is there any movement to suggest a minimum time span that a pre-release > > >> would have life? > > > > > > Ok. 12 hours. > > > > Haha, I _like_ silly jokes - but I assume Jon is really seeking a > > _constructive_ debate, > > I'm just not sure I agree with the seriousness of the problem (feel free to disgregard my drivel). Definately some folks were left out of the process that should not have been this time because of timing issues. > > Really. > > I can't believe Jim is making this into a joke. Fourteen hours is a *bare* > minimum to give Curt time to work 9 hours *and* get 5 hours of sleep in > between pre-releases. The rest of us can surely log in from work and do a > couple of hours of testing in that time... > > The nerve. > > Jon > ;-) Oh alright then, I can agree to 14. :::huff Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Outsider opinion - really the last one
Hi to all! Melchior wrote: >> No no no! I wasn't upset. << Sorry, I misunderstood you. That heals my wounds! Georg wrote: >> > sometimes I am a little bit NAIVE because I am so centered on helos > from sim to real. << Melchior replied: >> So am I. << Melchior (and naturally all others) then have a look at my (normally not used) website, where I actually placed the BO105 photos http://www.nord-com.net/vollnhals-bremen/BO105.htm And if you are a helo addict like me and want some more (BK117,BK117 Engines/Hydraulic/Mechanics),EC135,MDExplorer) then send me an eMail or tell it here and I will put some extra photos there - not professional ones, just made by me for my own. Melchior wrote: >>> Stay tuned, and don't take this list too seriously, at least not my contributions to it. <<< Ok, I'll give not up with my goal to get clother together what's not fitting so easily - two worlds with own rules and sight of the things, remarkable incompatible, not yet realizing their big chance to bundle their activities and power througout the next years - that would make a really stronger alternative to M$. I will write down some points to discuss within the next week in my really bad but hopefully understandable German English(Flight Gear and other alternative Flightsims: Visions, Goals and Strategies) and since that might be annoying members of this list I will put a link here to a private site. THEN everybody is FREE to have a look at it OR NOT, read it, forget it or discuss with me. (Theme could be: meet the aliens) THE LAST THING I want to do is induce bad emotion, aggressive discussion, steal your valuable (share)time you need for other tasks. BUT Flight Gear has NOW got a quality, power and (sleeping) potential not realized in the "outer" world and frustration effects of really interested simmers not seriously noticed within your "closed loop world". There have even been some new discussions around Flight Gear in some forums (I read some posts on chance in the Flight Unlimited Forum on AVSIM). Many arguments are unfair or even false, some are of big value. Strategic decisions where to go and how to go have to be made now or never on both sides of that unvisible "cutting-line" between those sim-worlds as necessary development beside the "normal" way will last years and many flightsimmers will go the (wrong) way back to M$FS in the future due to no perspective with "their" flightsims. If you want to read my proposals, look forward to the link in this list. Otherwise just ignore it. I think that will be the best solution not to get in conflict with anyone here as I am grateful for your work and the lot of time you invest (I know myself as developing and Beta-Testing for FLY!). Thank you for reading this. Best regards Georg, EDDW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Pre-Releases and Releases
> "Jim Wilson" wrote: > > Jon Berndt said: > > >> Is there any movement to suggest a minimum time span that a pre-release > >> would have life? > > > > Ok. 12 hours. > > Haha, I _like_ silly jokes - but I assume Jon is really seeking a > _constructive_ debate, > > Martin. Really. I can't believe Jim is making this into a joke. Fourteen hours is a *bare* minimum to give Curt time to work 9 hours *and* get 5 hours of sleep in between pre-releases. The rest of us can surely log in from work and do a couple of hours of testing in that time... The nerve. Jon ;-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] PA-28 model
Martin Spott wrote: Yesterday I did my first ride on a (real) PA28. I already got to know the C150 (which I use to train on) and the C172 (which we took when one of the sparks in the C150 didn't work). This saturday the C150 was already occupied and we decided to take the Archer this time. Naturally the PA28 behaves different than a C172 although both are sort of the same size: The PA28 behaves less 'hectically' on the flare and on takeoff you have to need to make distinct movements on the yoke to take the PA28 off the runway while it is sufficient for a 'clean' takeoff on the C150/C172 to rotate at the desired speed. O.k., this is the wording of a beginner and 'old' pilots are supposed to use other terms but I still think that this description somehow points into the right direction. Today I took the PA28 in FlightGear and I was terribly surprised that the feeling of the model matches the original aircraft _that_ close. Thank you very much for the feedback. I know what you mean about yanking the Cherokee off the runway -- with a 172, as soon as you raise the nose, the plane flies off; with a PA-28, it feels like you have to give it a hard yank. You can work around that in a couple of ways: 1. Use two notches of flaps even on a long, paved runway. The plane jumps off the runway and climbs like a rocket. 2. Raise the nose and wait a few seconds -- the Cherokee really will fly off, but it takes a bit longer because of the higher stall speed. In landing, you have to keep up your approach speed right to the pavement. You cannot do a high, gradual roundout like you do with a 172 or you'll drop it in from a few feet up, because the speed decays so fast in the flare (especially with full flaps). If you do find yourself a bit high in the flare, too slow, and otherwise out of options, add a bit of power with the throttle before you drop -- it will both raise the nose (to avoid a bounce) and ease the plane down. Mind you, those struts are built to take a lot of abuse. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug? [Was: Pre-Releases and Releases]
Alex Perry wrote: Jon, as commented elsewhere, that is a feature of the actual aircraft instrument and is intentionally present because is a source of fatal accidents. An example: Imagine walking out the back door of your house, to your grass strip, get in the plane, start the engine, taxi 100ft to the end of the runway, take off, turn on the autopilot, enter the overcast, start calling ATC to confirm time-off for the IFR departure, get hit by a gust, see a pitch/roll upset, the autopilot corrects it for you, die (unexpectedly). It's interesting to note that the newer STEC autopilots run off the electric turn coordinator instead of AI, so they're much more reliable, and less likely to kill you after a vacuum failure. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-Releases and Releases
"Jim Wilson" wrote: > Jon Berndt said: >> Is there any movement to suggest a minimum time span that a pre-release >> would have life? > > Ok. 12 hours. Haha, I _like_ silly jokes - but I assume Jon is really seeking a _constructive_ debate, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spinning gyro numeric model
On Sunday 28 March 2004 21:27, Alex Perry wrote: > > My objections to people fiddling with the gyro model is because they > usually want to take out the mechanical errors so it becomes a perfect > instrument. From your description, you seem to be trying to make it a more > accurate simulation of real life, which is certainly fine by me. Go for > it! Yes, that is exactly what I'm trying to do. Eventually I'll have a go at the turn indicator and the other gyro instruments to try and make them as true to real life as possible. > > > * The gyro is driven by a torque. It is slowed down by bearing > > * friction and air friction. > > * The gyro disk is defined by radius [m], width [m], and > > * material density [kg/m?]. The disk is a solid cylinder. > > Don't assume that the comments in the file, which were originally by me > and then modified by David to try and make sense of what my code did, > bear any relation to the actual engineering inside such a gyro unit. > It doesn't ... it is simply a description of the simplified physical > model that the code was written to implement. I created that model > because it would show most of the errors, not because it is correct. Oh! This code comment is mine, I wrote it for the newgyro.hxx. I included it in the post as a quick way to describe the principles I'm trying to model. > If you'd like to start from first principles and do a fully correct model, > I suggest you contact one of the manufacturers and ask for engineering > data. If you don't know who or how to go about doing that, let me know and > I'll try to arrange it for you. Actually I think I've got the spinning cylinder model nailed (except for the air friction on the flat sides). I tried to contact a manufacturer, I think it was SigmaTek, regarding their System20 Autopilot Turn Coordinator. I was forwarded to the engineering department but never got an answer. When I try to model the actual gyro instruments it would be wery helpful to have engineering data. I just hope I don't keep getting ignored. :-( -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Pre-Releases and Releases
Jon Berndt said: > > Please don't misunderstand me: I don't request _anyone_ to make a > > compromise in order to deal with the way _I_ can afford giving spare > > time to the FlightGear project. I just ask you (or whom it may belong > > to) to acknowledge that such a tight release process makes it > > _extremely_ difficult for part-time contributors (like me) to follow > > the track, > > > > Martin. > > > That's just it. Why should there even be a pre-release? The guys doing There were a couple bugs fixed this time. And the xcf files were removed from the final base package after they were found to be in the pre-release. > Now, this "observation" is not an invitation for some of you to bare your > teeth and throw yourselves out in front of an oncoming truck to "take one" > for Curt. It's thrown out for serious and constructive consideration in > resolving an obvious issue that has come up in our process. Obvious? > Does anyone have any suggestions? I noticed Norman's thought that branches > are one way to address this. I'm not comfortable with branches, really, but > I think that's because I have not used them a whole lot and perhaps we ought > to look into that, no? > > Is there any movement to suggest a minimum time span that a pre-release > would have life? Ok. 12 hours. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Clouds artefacts
Frederic Bouvier said: > Curtis L. Olson wrote: > > > Frederic Bouvier wrote: > > > > >I am leaning to a 4 level quality choice : > > > > > > 0 - actual state : clouds are making holes in mountains when seen from > > >below, > > > translucent surfaces are making hole in clouds underneath. > > > > > > 1 - clouds are blended with mountains > > > > > > 2 - translucent aircraft surfaces are blended with clouds but with > > > problem with underlying 3d static objects ( clouds between the > > >propeller > > > disc and 3d objects are not seen ) > > > > > > 3 - total correctness > > > > > >Perhaps 2 and 3 can be collapsed with no extra cost. There is already a > > >property to enable or disable the extra work. I will add quality on > > >rendering soon. > > > > > > > > > > Fred, > > > > At one point, clouds were drawn "back to front" with respect to > > altitude. This should avoid transparancy issues, except for things like > > trees, prop disks, and canopies that may get drawn earlier. Perhaps > > subsequent work on clouds caused this drawing order to be lost, but if > > we draw the clouds back to front based on altitude, it should reduce > > most or all of the issues you are working on without needing any sort of > > extra multi-pass effort. > > This simple scheme ( "back to front" ) works well with flat ground. It > begins to be tougher when things are going to interleave themselves. > What is back to front when you have a plane between cloud layers and the > viewer in that plane, a cloud layer in a valley, several static > objects with translucent faces ( like the bridges or any metallic > structure ) ? > > If we draw all clouds before the terrain and objects, depending > on the fact that we enable depth test or not, we will have clipped > mountains or no clouds blended with them. > > If we draw all clouds after the terrain and objects, we must use depth > test and then we have holes for canopy, trees or bridges ( without > alpha test, with it it's better but not perfect for half transparencies ) > > At the moment, I think we have the best overall result without extra > pass : we draw clouds above the viewer before the scene and clouds > below after. With extra passes, we can clear issues in their order > of annoyance, and it would be configurable to cope with the variety > of setup encountered in our user base. > > The main programming effort is done. I want to review the screenshot > rendering before releasing a patch. > BTW: do we respect a freeze period in case some annoying problem > show up and need a 0.9.4a release ? > We first ran into this problem with the old back to front scheme when David did the first trees. But I'm wondering now why the prop disks are a problem. Shouldn't the aircraft model be on the bottom of the stack anyway? Generally there's nothing between it and the camera. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Clouds artefacts
Melchior FRANZ said: > * Jim Wilson -- Sunday 28 March 2004 18:07: > > FWIW I don't think prop disks and plumes (as they are being done now) are > > worth the extra cost. Is there any problem with ignoring this particular > > issue for now, or can the triple pass be a separate command line option? > > FWIW I think that this bug has to be fixed, but also that it should be > a render option. > > http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-off-2.jpg > One way of fixing it is ditching the prop disk which isn't realistic anyway. But I'm not at all opposed to having an "option" triple rendering of the clouds. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds artefacts
Frederic Bouvier wrote: > Melchior FRANZ wrote: > > > * Jim Wilson -- Sunday 28 March 2004 18:07: > > > FWIW I don't think prop disks and plumes (as they are being done now) > are > > > worth the extra cost. Is there any problem with ignoring this > particular > > > issue for now, or can the triple pass be a separate command line > option? > > > > FWIW I think that this bug has to be fixed, but also that it should be > > a render option. > > > > http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-off-2.jpg > > I am leaning to a 4 level quality choice : > > 0 - actual state : clouds are making holes in mountains when seen from > below, translucent surfaces are making hole in clouds underneath. http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-lvl0.jpg > 1 - clouds are blended with mountains http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-lvl1.jpg > 2 - translucent aircraft surfaces are blended with clouds but with > problem with underlying 3d static objects ( clouds between the > propeller disc and 3d objects are not seen ) > > 3 - total correctness http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-lvl2-1.jpg the propeller disc doesn't appear well on overcast so the same over broken to show that it is still there : http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-lvl2-2.jpg > Perhaps 2 and 3 can be collapsed with no extra cost. Yes, they can, it is just a matter of drawing the aircraft after the other models In this area of the world, there is no impact on framerate with my hardware setup. At KSFO though, the difference is real. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Outsider Opinion
On Sun, 28 Mar 2004 15:26:27 +0200, Oliver wrote in message <[EMAIL PROTECTED]>: > On Sunday 28 March 2004 12:04, Melchior FRANZ wrote: > > > > > I don't care at all for trademarks on our aircrafts. If a trademark > > holder has a problem with free advertisement, he'll tell and we'll > > remove and make sure that his company will *never* again be > > considered for the free sim. > > I don't think that will work that way. :( > Today this works imho this way: > They will admonish you and you will pay and be forced to remove it > otherwhise you will pay a lot more, but you will pay. > > > I know this is very pity and sad but this is the typical way it works > today. :( > You can see this everywhere. ..ahem, that's why we have Groklaw and that nice legal defense fund over at OSDL, you know, to stop crime. ;-) ..one wee part of this is ask, whenever in doubt, a written ok is helpful evidence we _are_ ok, and worst case is they say nay upfront. If they sue, they have to show credible evidence that we caused damages, and that we're outside of the scope of fair use. ..and, face it, having a kanguroo hop around in a mine field with a nice big fat Microsoft Wintendo logo on itself, _is_ fair use. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim starter motor
On Sat, 27 Mar 2004 22:08:46 -0500, David wrote in message <[EMAIL PROTECTED]>: > Arnt Karlsen wrote: > > > ..these parameters can be set in a config file? Slowest cranking I > > saw start LN-AEB (a 60'ies PA28-140 with the standard 4-banger > > and quite likely a ditto vintage battery) was a blade every 5 > > seconds. It was usually a blade every 2 to 3 seconds. Facinating. > > ;-) > > So Arnt is suggesting a typical cranking speed of 10-15 rpm, ..typical for an _a_typical plane. ;-) > vs. my ...not too... ;-) > wild guess of 30 rpm. Neither one is blindingly fast. His worst case > example was 6 rpm. ..say 5 thru 300 rpm, for all piston engines. I have _once_ seen an engine unable to fire below 300, my Quadra|JoBu 361, with a pointless chain saw ignition, which served me a tennis elbow after an hour or so of pointless hand propping, it was too heavy for my 24V Sullivan and ripping off the cowling and yanking a string off the flywheel ofcourse had it purring on the first try. The damn thing refused to fire below 3000 rpm, for pointless chain saw safety! > I'll mention again that once the engine fires, the jump to normal RPM > is pretty-much instantaneous -- there's no gradual spin-up over a few > of seconds. ..correct., its over the next few firing cylinder charges, to take them from crank to idle speeds. > > ..do we model the compression's effect on crank speed fluctuation? > > We're a long way from anything like that. Right now, it's basically > just a fancy animation. If we wanted to model engine starts properly, > we'd have to model each cylinder individually. That would also allow > the engine to (possibly) run rough when leaned, based on different > air/fuel distribution to different cylinders, etc. (at least until we > installed virtual GAMIjectors on the fuel-injected engines). We could > also model fouled plugs -- that would encourage fgfs users to do a > proper runup before every flight. .. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Clouds artefacts
Curtis L. Olson wrote: > Frederic Bouvier wrote: > > >I am leaning to a 4 level quality choice : > > > > 0 - actual state : clouds are making holes in mountains when seen from > >below, > > translucent surfaces are making hole in clouds underneath. > > > > 1 - clouds are blended with mountains > > > > 2 - translucent aircraft surfaces are blended with clouds but with > > problem with underlying 3d static objects ( clouds between the > >propeller > > disc and 3d objects are not seen ) > > > > 3 - total correctness > > > >Perhaps 2 and 3 can be collapsed with no extra cost. There is already a > >property to enable or disable the extra work. I will add quality on > >rendering soon. > > > > > > Fred, > > At one point, clouds were drawn "back to front" with respect to > altitude. This should avoid transparancy issues, except for things like > trees, prop disks, and canopies that may get drawn earlier. Perhaps > subsequent work on clouds caused this drawing order to be lost, but if > we draw the clouds back to front based on altitude, it should reduce > most or all of the issues you are working on without needing any sort of > extra multi-pass effort. This simple scheme ( "back to front" ) works well with flat ground. It begins to be tougher when things are going to interleave themselves. What is back to front when you have a plane between cloud layers and the viewer in that plane, a cloud layer in a valley, several static objects with translucent faces ( like the bridges or any metallic structure ) ? If we draw all clouds before the terrain and objects, depending on the fact that we enable depth test or not, we will have clipped mountains or no clouds blended with them. If we draw all clouds after the terrain and objects, we must use depth test and then we have holes for canopy, trees or bridges ( without alpha test, with it it's better but not perfect for half transparencies ) At the moment, I think we have the best overall result without extra pass : we draw clouds above the viewer before the scene and clouds below after. With extra passes, we can clear issues in their order of annoyance, and it would be configurable to cope with the variety of setup encountered in our user base. The main programming effort is done. I want to review the screenshot rendering before releasing a patch. BTW: do we respect a freeze period in case some annoying problem show up and need a 0.9.4a release ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows release
Frederic Bouvier wrote: > Martin Spott wrote: > > > "Jon Berndt" wrote: > > > BTW, what's the requirement for a Windows release? I > > > > I just had a look and to my impression we already have one. Please see: > > > > ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/ > > I made them to allow Curt to assemble the fgsetup package. I could > have made it but I have the impression that he want to make it himself > like he did for 0.9.3 BTW: it would be nice if Lee's airplane would appear in fgrun. They just need a /sim/description property -Fred PS: The complete list of *-set.xml with no description : * a10-yasim * a10cl-yasim * a10fl-yasim * a10wl-yasim * an225-yasim * b52-yasim * fkdr1-v1-nl-uiuc * seahawk * sopwithCamel-v1-nl-uiuc ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] PA-28 model
Yesterday I did my first ride on a (real) PA28. I already got to know the C150 (which I use to train on) and the C172 (which we took when one of the sparks in the C150 didn't work). This saturday the C150 was already occupied and we decided to take the Archer this time. Naturally the PA28 behaves different than a C172 although both are sort of the same size: The PA28 behaves less 'hectically' on the flare and on takeoff you have to need to make distinct movements on the yoke to take the PA28 off the runway while it is sufficient for a 'clean' takeoff on the C150/C172 to rotate at the desired speed. O.k., this is the wording of a beginner and 'old' pilots are supposed to use other terms but I still think that this description somehow points into the right direction. Today I took the PA28 in FlightGear and I was terribly surprised that the feeling of the model matches the original aircraft _that_ close. Congratulations, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows release
Martin Spott wrote: > "Jon Berndt" wrote: > > BTW, what's the requirement for a Windows release? I > > I just had a look and to my impression we already have one. Please see: > > ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/ I made them to allow Curt to assemble the fgsetup package. I could have made it but I have the impression that he want to make it himself like he did for 0.9.3 -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spinning gyro numeric model
From: Roy Vegard Ovesen <[EMAIL PROTECTED]> > I've created a new model for the spinning gyro (Instrumentation/gyro.*xx). > [...] > Now, I know that the existing gyro model and heading indicator and attitude > indicator work great and that some might think that I am trying to fix > something that is already working. I would argue that I am trying to improve > on something that is already working ;-). But if nobody else share my point > of view, I might abandon the idea. My objections to people fiddling with the gyro model is because they usually want to take out the mechanical errors so it becomes a perfect instrument. >From your description, you seem to be trying to make it a more accurate simulation of real life, which is certainly fine by me. Go for it! > * The gyro is driven by a torque. It is slowed down by bearing > * friction and air friction. > * The gyro disk is defined by radius [m], width [m], and > * material density [kg/m?]. The disk is a solid cylinder. Don't assume that the comments in the file, which were originally by me and then modified by David to try and make sense of what my code did, bear any relation to the actual engineering inside such a gyro unit. It doesn't ... it is simply a description of the simplified physical model that the code was written to implement. I created that model because it would show most of the errors, not because it is correct. If you'd like to start from first principles and do a fully correct model, I suggest you contact one of the manufacturers and ask for engineering data. If you don't know who or how to go about doing that, let me know and I'll try to arrange it for you. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug? [Was: Pre-Releases and Releases]
From: "Jon Berndt" <[EMAIL PROTECTED]> > [...]. This resulted in a little tumble, but when I came out of it and > regained level flight, the ADI showed I had a left roll of about 40 degrees, > but the visual scene (and more importantly for me) the FDM property that > drives it showed a roll angle of about -4 degrees. Jon, as commented elsewhere, that is a feature of the actual aircraft instrument and is intentionally present because is a source of fatal accidents. An example: Imagine walking out the back door of your house, to your grass strip, get in the plane, start the engine, taxi 100ft to the end of the runway, take off, turn on the autopilot, enter the overcast, start calling ATC to confirm time-off for the IFR departure, get hit by a gust, see a pitch/roll upset, the autopilot corrects it for you, die (unexpectedly). The gyros still hadn't spun up, but the autopilot didn't know about that and acted on the assumed correct data. Had you been flying manually, the instrument scan cross check should have noticed the inconsistency among the gyro and non-gyro instruments and you would probably have survived. But, speaking to you specifically and your role as an FDM author, that's one of the reason why the HUD shows the raw uncooked data. It lets you find out what's _really_ happening in your models. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows release
"Jon Berndt" wrote: > BTW, what's the requirement for a Windows release? I I just had a look and to my impression we already have one. Please see: ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/ Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Clouds artefacts
Frederic Bouvier wrote: I am leaning to a 4 level quality choice : 0 - actual state : clouds are making holes in mountains when seen from below, translucent surfaces are making hole in clouds underneath. 1 - clouds are blended with mountains 2 - translucent aircraft surfaces are blended with clouds but with problem with underlying 3d static objects ( clouds between the propeller disc and 3d objects are not seen ) 3 - total correctness Perhaps 2 and 3 can be collapsed with no extra cost. There is already a property to enable or disable the extra work. I will add quality on rendering soon. Fred, At one point, clouds were drawn "back to front" with respect to altitude. This should avoid transparancy issues, except for things like trees, prop disks, and canopies that may get drawn earlier. Perhaps subsequent work on clouds caused this drawing order to be lost, but if we draw the clouds back to front based on altitude, it should reduce most or all of the issues you are working on without needing any sort of extra multi-pass effort. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Windows release
BTW, what's the requirement for a Windows release? I can do a CygWin binary, but maybe that's not desirable for it's requirement for the CygWin DLL. I have not even tried using MingW, yet. I could submit a CYgWin executable. I even have InstallShield (and have used it) if that would help. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Pre-Releases and Releases
> Please don't misunderstand me: I don't request _anyone_ to make a > compromise in order to deal with the way _I_ can afford giving spare > time to the FlightGear project. I just ask you (or whom it may belong > to) to acknowledge that such a tight release process makes it > _extremely_ difficult for part-time contributors (like me) to follow > the track, > > Martin. That's just it. Why should there even be a pre-release? The guys doing POV-Ray put out multiple beta's that are heavily tested for weeks if not months prior to the final release. In their case, however, the releases are much farther apart. Like I said before, maybe we should consider what pre-releases are for, why we do them, and what can be expected when a pre-release is thrown out - i.e. how long should we expect to have to test it? Now, this "observation" is not an invitation for some of you to bare your teeth and throw yourselves out in front of an oncoming truck to "take one" for Curt. It's thrown out for serious and constructive consideration in resolving an obvious issue that has come up in our process. Does anyone have any suggestions? I noticed Norman's thought that branches are one way to address this. I'm not comfortable with branches, really, but I think that's because I have not used them a whole lot and perhaps we ought to look into that, no? Is there any movement to suggest a minimum time span that a pre-release would have life? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-Releases and Releases
Andy Ross wrote: > Martin Spott wrote: >> Another example (among others) is the altimeter-dialogue that was >> recently introduced by DaveM. [...] I have to familiarize myself with >> that feature. How should this be done with such a short pre-release >> cycle ? > I don't follow. Are you trying to say that the feature should never > have gone out in the release, or that there is no use in providing > feedback and/or improving features once they have been released? [...] > Especially in this case, I can't see Curt holding this release back > due to a minor i18n issue with the altimeter dialog even if you had > been given a month to air your grievances. I have the impression that you're talking about something completely different. I'm took as an example that David added a new feature on March 23rd (tuesday) and Curtis did the release 3 days later on friday. How should anyone with a full-time job get the chance to explore and test a new feature in a sufficient manner. Please don't misunderstand me: I don't request _anyone_ to make a compromise in order to deal with the way _I_ can afford giving spare time to the FlightGear project. I just ask you (or whom it may belong to) to acknowledge that such a tight release process makes it _extremely_ difficult for part-time contributors (like me) to follow the track, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Clouds artefacts
Melchior FRANZ wrote: > * Jim Wilson -- Sunday 28 March 2004 18:07: > > FWIW I don't think prop disks and plumes (as they are being done now) are > > worth the extra cost. Is there any problem with ignoring this particular > > issue for now, or can the triple pass be a separate command line option? > > FWIW I think that this bug has to be fixed, but also that it should be > a render option. > > http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-off-2.jpg I am leaning to a 4 level quality choice : 0 - actual state : clouds are making holes in mountains when seen from below, translucent surfaces are making hole in clouds underneath. 1 - clouds are blended with mountains 2 - translucent aircraft surfaces are blended with clouds but with problem with underlying 3d static objects ( clouds between the propeller disc and 3d objects are not seen ) 3 - total correctness Perhaps 2 and 3 can be collapsed with no extra cost. There is already a property to enable or disable the extra work. I will add quality on rendering soon. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Clouds artefacts
* Jim Wilson -- Sunday 28 March 2004 18:07: > FWIW I don't think prop disks and plumes (as they are being done now) are > worth the extra cost. Is there any problem with ignoring this particular > issue for now, or can the triple pass be a separate command line option? FWIW I think that this bug has to be fixed, but also that it should be a render option. http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-off-2.jpg m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-Releases and Releases
Martin Spott wrote: > Another example (among others) is the altimeter-dialogue that was > recently introduced by DaveM. [...] I have to familiarize myself with > that feature. How should this be done with such a short pre-release > cycle ? I don't follow. Are you trying to say that the feature should never have gone out in the release, or that there is no use in providing feedback and/or improving features once they have been released? I can only disagree on both counts. If you don't like the alitimeter dialog, then write up your suggestions and it will be fixed. What does that have to do with release procedures? Especially in this case, I can't see Curt holding this release back due to a minor i18n issue with the altimeter dialog even if you had been given a month to air your grievances. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds artefacts
Frederic Bouvier said: > The previous try was not addressing hole made by prop disc or exhaust > plume in layers beneath. Only artefact created by upper layers. > > This time, with more passes, the result is quite correct in all cases : > > Without multi passes, depth buffer blocks cloud rendering through the prop > disk/quad : > http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-off-2.jpg (131kb) > > with multi pass, over a broken layer : > http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-on-3.jpg > > over an overcast layer : > http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-on-4.jpg > > It seems there is a significant framerate penalty ( 14 -> 11 fps ) : > cloud layers are drawn two or three times instead of one. > FWIW I don't think prop disks and plumes (as they are being done now) are worth the extra cost. Is there any problem with ignoring this particular issue for now, or can the triple pass be a separate command line option? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds artefacts
Frederic Bouvier wrote: > I manage to implement this algorithm tonight. The results are here : > > 1. /sim/rendering/multi-pass-clouds=false : > http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-off-1.jpg (204kb) > > 2. /sim/rendering/multi-pass-clouds=true : > http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-on-1.jpg (198kb) > > 3 /sim/rendering/multi-pass-clouds=true ( billboard tree detail ) : > http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-on-2.jpg (106kb) The previous try was not addressing hole made by prop disc or exhaust plume in layers beneath. Only artefact created by upper layers. This time, with more passes, the result is quite correct in all cases : Without multi passes, depth buffer blocks cloud rendering through the prop disk/quad : http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-off-2.jpg (131kb) with multi pass, over a broken layer : http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-on-3.jpg over an overcast layer : http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-on-4.jpg It seems there is a significant framerate penalty ( 14 -> 11 fps ) : cloud layers are drawn two or three times instead of one. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Spinning gyro numeric model
Hi all! I've created a new model for the spinning gyro (Instrumentation/gyro.*xx). /** * Complex model of a spinning gyro. * * The gyro is driven by a torque. It is slowed down by bearing * friction and air friction. * The gyro disk is defined by radius [m], width [m], and * material density [kg/m³]. The disk is a solid cylinder. */ In the model I consider bearing friction torque to be constant. Air friction is only modeled for the outer rim of the cylinder, _not_ for the two flat sides. Modeling air friction for the sides is more complex as the velocity increases with the radius-- a point close to the rim has a higher velocity than a point close to the center. I suspect that the friction contribution from the two sides would be higher than from the outer rim surface, so I definetely should model this too. Any suggestions on how to model air friction on a spinning flat surface? The output for this model is angular velocity, angular momentum and a normalized spin. Angular momentum can be used to model gyroscopic precession. I only added normalized spin in order to be able to interface with the existing heading indicator and attitude indicator models. Now, I know that the existing gyro model and heading indicator and attitude indicator work great and that some might think that I am trying to fix something that is already working. I would argue that I am trying to improve on something that is already working ;-). But if nobody else share my point of view, I might abandon the idea. Comments are welcome! -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug? [Was: Pre-Releases and Releases]
Jon Berndt wrote: This is supposed to be the correct behavior for real live ADI instruments. You should give it some time (15 minutes?) to reset itself. Erik Heh. Cool. I wondered about that. This is one of those: "My plane goes left at takeoff" kind of things. This time it just looks that way. Eirk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Bug? [Was: Pre-Releases and Releases]
> This is supposed to be the correct behavior for real live ADI > instruments. You should give it some time (15 minutes?) to reset itself. > > Erik Heh. Cool. I wondered about that. This is one of those: "My plane goes left at takeoff" kind of things. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Outsider Opinion
On Sunday 28 March 2004 12:04, Melchior FRANZ wrote: > > I don't care at all for trademarks on our aircrafts. If a trademark holder > has a problem with free advertisement, he'll tell and we'll remove and make > sure that his company will *never* again be considered for the free sim. I don't think that will work that way. :( Today this works imho this way: They will admonish you and you will pay and be forced to remove it otherwhise you will pay a lot more, but you will pay. I know this is very pity and sad but this is the typical way it works today. :( You can see this everywhere. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug? [Was: Pre-Releases and Releases]
Jon Berndt wrote: My first test flight revealed a potential bug, however. I simply typed: fgfs to run the default aircraft. After gaining some altitude, and while at full power, I began pulling back on the stick, and when my speed had descended to about 50 or so, I pulled back on the stick all the way and gave slight left roll input. This resulted in a little tumble, but when I came out of it and regained level flight, the ADI showed I had a left roll of about 40 degrees, but the visual scene (and more importantly for me) the FDM property that drives it showed a roll angle of about -4 degrees. I tried this repeatedly and got the same results. The ADI appears to get out of sync somehow. Is this instrument being driven through an intermediate "sensor" between the FDM property and the device display? This is supposed to be the correct behavior for real live ADI instruments. You should give it some time (15 minutes?) to reset itself. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Bug? [Was: Pre-Releases and Releases]
> Let's see what happens then. Can you still do some testing now > anyway? It is never too late to contribute a bug fix. > > Best, > > Jim I used my createfgfs script in a CygWin shell: ./createfgfs update all which updates all of plib, simgear, base package, and flightgear, then builds and installs them sequentially. It went off without a hitch. Very nice build. My first test flight revealed a potential bug, however. I simply typed: fgfs to run the default aircraft. After gaining some altitude, and while at full power, I began pulling back on the stick, and when my speed had descended to about 50 or so, I pulled back on the stick all the way and gave slight left roll input. This resulted in a little tumble, but when I came out of it and regained level flight, the ADI showed I had a left roll of about 40 degrees, but the visual scene (and more importantly for me) the FDM property that drives it showed a roll angle of about -4 degrees. I tried this repeatedly and got the same results. The ADI appears to get out of sync somehow. Is this instrument being driven through an intermediate "sensor" between the FDM property and the device display? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: BO105 infos, Melchior Franz
Hey, I made it into the subject! * Georg A. Vollnhals -- Sunday 28 March 2004 14:07: > Sorry, regularly we have a BK117 at our base. The BO105 only once has been > here as a back-up for some days. Therefore all those questions cannot be > answered by me. No problem. I'll continue improvising then. ;-) > Please excuse, it seemed that my post made you a little upset, [...] No no no! I wasn't upset. The parts that sounded critical were mostly an answer to the whole trademark/permission topic -- you were only the last who brought it up again, and your message was even trying to help out here. The rest of my answer was tongue-in-cheek. (Some people here hate smilies, yet I used *three* of them.) > sometimes I am a little bit NAIVE because I am so centered on helos > from sim to real. So am I. Again, an ADAC version might be an option, but not the primary layout. (Hey, 99% of subscribers here don't even know what ADAC means, and you can count me in. ;-) Stay tuned, and don't take this list too seriously, at least not my contributions to it. m. PS: I sound a whole lot different if I'm really upset. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-Releases and Releases
Hello, as I was the person to start this thread I'd like to add some meat tom my complaint :-) "Jim Wilson" wrote: > [...] We all know what it is like to suddenly have > a block of time available to do something and not be sure when we'll > see another. This is valid, but not only for Curt - although he's supposed to be the guy to whom belongs the greatest justification to make use of this chance. I'd like to express my point of view, my situation in such a release process - it should be considered as nothing more than an additional statement to the discussion but it represents a little part of my life. I'm trying to write some documentation for FlightGear and I'm trying to make it suitable for the releases. I spend almost 14 hours a day to earn my income (I assume I'm not the only one on this list) so I don't have much time during the week to run tests on FlightGear. As Jim already realized: > Do you ever have anything nice to say? :-) there are quite a few 'inconsistencies' within FlightGear that are worth pointing at and that show up during my test runs. Some of these inconsitencies show up after half an hour of simulated flight and everybody on this list can imagine that reproducing the feature/bug under known conditions can'd be done within a day or two when you don't have more than half an hour per day to deal with FlightGear (or even less). So I'd need probably a whole day to point at a specific bug. As I don't develop on the code myself I also have to make sure to rule out user errors. In case you might have something else to do on the weekend then you need at least a timeframe that includes two weekends to make useful statements on the 'feature' you've found. Another example (among others) is the altimeter-dialogue that was recently introduced by DaveM. This dialogue is really a great thing - but it is completely useless for those who have learnt flying according to European rules (please correct me if I'm wrong !) because you can't enter the reference pressure in hpa. Before I can write something useful about a new feature in FlightGear (whatever it is, not restricted to the alimeter dialogue) I have to familiarize myself with that feature. How should this be done with such a short pre-release cycle ? Just my opinion. Maybe this is the right time for someone else to take over the work on the "Getting Started" manual because my personal time-restrictions are completely incompatible to the development- and especially the release process. You have my support on the idea of having a one month's code freeze before 1.0. Thank you for listening, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] BO105 infos, Melchior Franz
M. Franz wrote:
>>>
I've found a lot of photos on the internet and 170 are already on my HD
But I could still use some more information. For example:
{...}
and whatever you find noteworthy.
<<<
Hi Melchior!
Sorry, regularly we have a BK117 at our base. The BO105 only once has been
here as a back-up for some days. Therefore all those questions cannot be
answered by me. Please excuse, it seemed that my post made you a little
upset, that was NOT intended, no bad emotions, sometimes I am a little bit
NAIVE because I am so centered on helos from sim to real.
All the best for your forthcoming project!
Best regards Georg
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.598 / Virus Database: 380 - Release Date: 28.02.2004
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] X-43A flight apparently successful
> Is the fuel stored as liquid hydrogen? > Are there any figures on fuel consumption? > Have they considered other fuels? This query at the NASA-Langley Technical Reports Server ought to help: http://192.42.75.20:8765/ltrs/query.html?rq=0&col=ltrs&qp=&qs=&qc=&ws=0&qm=0 &st=1&nh=10&lk=1&rf=0&oq=&rq2=0&qt=hyper If you can't get this to work, go to: http://techreports.larc.nasa.gov/ltrs/ltrs.html and enter "hyper" in the "Search LTRS" field. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Trademark violations, Arnt Karlsen
Arnt Karlsen wrote: ..so, we do need to keep our eyes open to avoid running into the next Microsoft funded ambushes in courts. Is as simple as reading license etc terms _first_, and then _carefully_ consider your theoretical options, they _are_ pretty real to Lindows in the Benelux area. ;-) Thank you Arnt, sometimes I see the world only through my local perspective. But you are fully right, money rules the world (and justice), those without have to be careful. Best regards Georg --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.598 / Virus Database: 380 - Release Date: 28.02.2004 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: 'fgfs --show-aircraft' gives a Segmentationfault
* Frederic Bouvier -- Sunday 28 March 2004 00:02: > Is it only a problem with glut ? This is a major problem that we use > exceptions on a system that can't safely handle them. The system can handle exceptions just fine. We are talking about a wrongly compiled libglut. Broken libs will break things on any system. And in this particular case, the distributor (SuSE, 8.?) acknowledged the bug and promised to fix it. Should be done beginning with 9.0. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim starter motor
David Megginson wrote: > I'm trying to remember how fast the blades go by while cranking. They are > slow enough that you can very easily count them -- by closing my eyes and > trying to remember, I get about a blade per second, [...] Yesterday I've flown our Archer for the first time (great aircraft !!) and I think it's a bit faster. I'd suggest 4 blades in 3 seconds, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] X-43A flight apparently successful
"Jon Berndt" wrote: > For general interest: LaRCSim author Bruce Jackson was involved in that > reflight effort, IIRC. I think, this fact automatically obliges that he creates a FlightGear model :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Solaris binary package
Hello, I created a Solaris binary package from the current release: ftp://ftp.ihg.uni-duisburg.de/FlightGear/Solaris/fgfs-0.9.4-Solaris.tar.gz The README says: "README file for FlightGear on Solaris binary release packages. --- This package includes the 'fgfs' binary, built for Solaris8/sparcv8 plus the two required GCC runtime libraries. You don't need to unpack these libraries if you already have the complete GCC-3.x or at least the corresponding GCC runtime freeware package installed. Make sure you have enough texture memory on your creator card." Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Outsider Opinion
* Georg A. Vollnhals -- Saturday 27 March 2004 01:14: > 4. BO105 helo livery > As far as the livery for the BO105 is concerned (I would like to have a > medevac livery) I could ask the ADAC for written permission [...] Texturing doesn't have priority, it will be one of the last things I do. I'll decide then which livree to take. But I'm not excited about an ADAC helicopter in KSFO or VHHH. I'll rather go for a generic rescue helicopter without obvious nationality (and *if*, then Austrian, and not German ;-). Anyway, I will provide a layered texture like Jim did for the p51d, so it should be easy to make a German version. It would certainly be nice to have an alternate ADAC version in the hangar. (And the ADAC may even use it and distribute FlightGear with it without having to pay me a Cent!) I don't care at all for trademarks on our aircrafts. If a trademark holder has a problem with free advertisement, he'll tell and we'll remove and make sure that his company will *never* again be considered for the free sim. (We can even distribute the request for removal in written form. ;-) It's obvious even for the dumbest judge that there's no harm in using a logo, and that the profit is on the trademark holder's side, not on ours (as we aren't even making money). Furthermore, there is no sign of a damage (as long as we don't mount missiles on the ac and let people shoot them at school busses). That MSFS comes without real-life logos/emblems is probably because the trademark holders didn't want to pay MICROS~1's fees. Don't assume that MS does advertisement (or anything) for free! > as I am flying > with their helos (NOT as a pilot) since nearly two decades I'm active member of the Autrian Red Cross and volunteer as a paramedic/ ambulance driver in Vienna ... and as such I have to complain that the Red Cross emblem is clearly too small on ADAC helicopters. :-P > We are flying a BK117 but had a BO105 in exchange for some days the last > year at our base. So if anyone is interested in some exteriour photos I made > at that time, I can eMail them to him. I've found a lot of photos on the internet and 170 are already on my HD But I could still use some more information. For example: where is the bottom strobe located? I guessed a place, but didn't see it in any picture. Is there a strobe on the belly at all? Furthermore, pictures of the interior would be useful. And general feedback, about things like beacon/strobe blinking/flashing frequencies etc, and whatever you find noteworthy. Thanks for your offer! m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] X-43A flight apparently successful
On Sunday 28 March 2004 06:35, Jim Wilson wrote: > Jon Berndt said: > > Today's hypersonic X-43A flight was apparently successful, though I have > > not seen much news on it, yet. It should appear here: I can see the benefits of hydrogen to propel a vehicle like that. I didn't see any reference to the following questions though, with possible applications of such an aircraft type in mind. Is the fuel stored as liquid hydrogen? Are there any figures on fuel consumption? Have they considered other fuels? Thanks, Chris. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: ..grok law, was: [Flightgear-devel] Outsider Opinion
Arnt Karlsen wrote: ..so, we do need to keep our eyes open to avoid running into the next Microsoft funded ambushes in courts. Is as simple as reading license etc terms _first_, and then _carefully_ consider your theoretical options, they _are_ pretty real to Lindows in the Benelux area. ;-) http://www.groklaw.net/article.php?story=200403251307269 I still fail to see why our judges think they are entitled to order a company to change the name of their product while that name is perfectly legal in the home country of *both* contesters! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
