[Flightgear-devel] Bug: FG 0.9.8 won't start over land in Britain...
On Thu, 2005-02-17 at 15:09, Steve Hosgood wrote: Sounds bizarre, but this is quite reproduceable: if you *don't* have the w010n50 scenery tile loaded and use the command-line params --lat=51.6 --lon=-4.0 to start FlightGear, then it starts up just fine. However, if you *do* have that scenery tile loaded, fgfs just hangs, displaying the splash screen. This is with stock 0.9.8 FlightGear compiled by me on Fedora core 2 and with Nvidia's standard binary driver. It did it with 0.9.6 too, can't remember about 0.9.4 but I'm fairly sure things worked as expected with 0.9.2 There's more: Command-line params --lat=51.6 --lon=-10.1 *will* allow FlightGear to start, even with the w010n50 scenery tile present (you'll notice that that start location is ouside the scenry tile though). In fact, a start location that *is* inside the scenery tile, but over the sea will also work. After you've got running, you can change your longitude to -4.0 with "change internal parameters" and there you are, flying toward Swansea Airport in South Wales as you'd expect. This seems so obvious a glitch, yet no-one else seems to be reporting it! Steve Hosgood PS: Lat 51.6, Long 10.1 is over the Atlantic Ocean just west of Ireland. It is of course also outside the named scenery tile. I've not tried a start location over the sea *inside* the tile. I'll get back to y'all on that one ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug: FG 0.9.8 won't start over land in Britain...
On Thu, 2005-02-17 at 15:13, Steve Hosgood wrote: > PS: Lat 51.6, Long 10.1 is over the Atlantic Ocean just west of Ireland. > It is of course also outside the named scenery tile. I've not tried a > start location over the sea *inside* the tile. I'll get back to y'all on > that one > Sorry: poorly edited prototype message! As I'd said earlier, it does start under those conditions. What I don't know is what happens when you start over the sea, but with land in sight. So far my tests have been over land (fails) or well out to sea (works). Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug: FG 0.9.8 won't start over land in Britain...
On Thu, 2005-02-17 at 15:28, Frederic Bouvier wrote: > There is a numerical problem at startup. Try --lat=51.6 --lon=-4.001 > > -Fred AAAGH! So simple, and I never tried such a thing! Dammit, I grovelled through the -devel and -users archives for quite a while to see if this was already known (it seemed so glaring a problem). Sorry to waste your time, folks and thank you for the prompt response. Steve. PS: Might I propose the FGFS gods avoid causing pointless grief for newbies and insert a fragment of code in the command-line parsing to the effect of: /* KLUDGE: FIXME: avoid hang when starting on a tile boundary */ if (startup_long == floor(startup_long)) startup_long += 0.0001; if (startup_lat == floor(startup_lat)) startup_lat += 0.0001; (or whatever). ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug: FG 0.9.8 won't start over land in Britain...
On Thu, 2005-02-17 at 16:17, Frederic Bouvier wrote: > The tile boundary is not at integral degrees. They can be at .125, .250, .375, > .5, .625, .75 and .875 ( every 1/8 of a degree ) > Ah, it applies at that level does it? I suppose that's logical. OK, may I propose: /* KLUDGE: FIXME: avoid hang when starting on a tile boundary */ if (startup_long*8.0 == floor(startup_long*8.0)) startup_long += 0.0001; if (startup_lat*8.0 == floor(startup_lat*8.0)) startup_lat += 0.0001; Rule #1 of user interface design: don't expose the users to quirks of the implementation. In this case the above hack can be removed if/when anyone ever fixes the underlying tile-boundary problem, but until then it keeps the phone lines quiet at the help desk (!) and serves as a useful comment in the code to the effect that there's a bug to fix. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
On Fri, 2005-02-18 at 09:37, Frederic Bouvier wrote: > I think this is nearly impossible to have the position that match. It should > be > better to have areas of exclusion, either rectangular ( 2 points ), or > circular > ( center + radius ). > > -Fred Could you not have something like RPM's "Obsoletes: " mechanism? Then it would mean that your improved Eiffel Tower (say) could replace the default one which was mistakenly placed 3km northeast of the true location. If your improved Eiffel Tower claimed to replace everything in a 3km radius, it would make a big hole in the centre of Paris :-) Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Running probs
On Thu Feb 3 17:30:06 CST 2005, Ampere K. Hardraade wrote: > On February 1, 2005 03:36 pm, Dean Williams wrote: >> The installaton at "0x0938b08b" reference memory at "0x0b41d2ff". The> memory could not be written!...whatever that means.Perhaps this is an out of memory error? > > I have a similar problem in Linux a few weeks ago: > http://mail.flightgear.org/pipermail/flightgear-devel/2005-January/034368.html > > If these are indeed related, that means we can duplicate the error in > Linux and find out the exact cause of the problems. > > I don't know if anything more has been done on this (I don't see anything in the archive), but I can reproduce something very much like this on linux. Equipment: Stock Fedora Core 2. "2100+MHz" Athlon processor. At least 256Mb RAM (might be 512Mb - I'll check) at 266MHz Matrox G200 AGP video card supposedly with 3D acceleration working. Standard 0.9.8 Flightgear plus scenery for Western Europe area. If I just type "fgfs" or "fgfs --disable-sound", all I get is the splash screen and plenty of disk-grinding noises followed by the splash-screen disappearing and the single-word message "Killed" on stdout. (I tried the --disable-sound option to try and avoid possible troubles with OpenAL). I get exactly the same thing with the motherboard's native S3 "ProSavage" KN133 video card too (it has to use software rendering due to lack of DRI support). Interestingly, the FPS readout I see from "glxgears" is not radically different when comparing the two video cards. (About 150 - 180fps). This might indicate that I've not got the DRI running properly for the G200, or that the G200 is a total turkey(*). I do know that the G200 driver reports AGP x1, whereas I believe I should be able to get at least x2 from it. The same RPM of FlightGear 0.9.8 runs perfectly well on a 2GHz Intel P4 with an Nvidia Quadra graphics card (using Nvidia's binary driver). So it's not the build per se. I might suggest that those of us who've seen this sort of problem seem to have slow 3D rendering. Could it be possible that FlightGear is starting to send a screenfull of vertexes to the video card, but gives up (due to the slow card), aborts that frame and tries to start another. The same thing then happens again and again. This might trigger a slow memory leak internally which eventually leads to the "killed" message with nothing ever appearing on screen. It does seem that the length of time between the splash-screen appearing and the "killed" (or "aborted") message might be dependant on the amount of RAM (or maybe the amount of swap) available. If the rendering hypothesis above was true, presumably such a scenario could only happen if the scene renderer thought that it should be able to run the screen at a given FPS yet the hardware refuses to oblige. It's just thoughts.. Anyone got any good ideas for ways to test them? I'll run experiments on my failing machine at home if anyone has suggestions. The "correct" behaviour for FlightGear should be to run, but with a uselessly slow frame rate on screen, surely? It used to do that, maybe back at about 0.9.1 or 0.9.2 Steve (*) Or both ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Running probs + ATI framerate
On Thu, 2005-02-24 at 07:03, Jorge Van Hemelryck wrote: > On Tue, 22 Feb 2005 11:09:04 + > Steve Hosgood wrote: > > > If I just type "fgfs" or "fgfs --disable-sound", all I get is the splash > > screen and plenty of disk-grinding noises followed by the splash-screen > > disappearing and the single-word message "Killed" on stdout. > Actually, I've seen the exact same behaviour [...] glxinfo said that direct > rendering was enabled, but my fgfs (CVS compile > from a few days ago) behaved the same as Steve's. I haven't had a chance > to try it with Simon's suggestion (disabling dlists) yet. > Simon Hollier's suggestion worked for me! At altitude, I get about 40-60fps with fgfs running fullscreen on a G200. I've not checked when closer to the ground. Meanwhile, I get around 340 fps from glxgears in its default smallscreen startup configuration. I'd hardly have thought that this counted as "slow 3D rendering". > Which brings us back to try and detect features at runtime ? Is this > possible ? At the very least, Simon's suggestion about "use-display-list=false" should be in the FAQ or possibly have fgfs default to working that way out of the box, and a item under "display tuning" in the manuals suggest setting it to true under certain circumstances. Auto-detection would be nice too of course. The way things are now, it's a certain first-time-newbie killer, and unlikely to further fgfs's progress. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] C172P dihedral
...or lack of. My "real" flying experience is limited to the Solar Wings "Typhoon" Mk1 see: http://www.british-hang-gliding-museum.co.uk/acatalog/Online_Museum_Typhoon_196.html ..however, I'm surprised at the apparent lack of roll stability for the C172P default aircraft in FlightGear. Is the model right, or did someone enter the dihedral with the wrong sign? :-) I know the Wright Flyer had negative dihedral, but I didn't think any modern private plane would... Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] b-29 alpha
On Wed, 2005-04-06 at 18:13, Josh Babcock wrote: > Arnt Karlsen wrote: > > On Tue, 05 Apr 2005 22:22:48 -0400, Josh wrote in message > >>Be warned, racy but authentic nose art... > > > > ..cute. We need more of these, to remain authentic. ;o) > > > > > > Yeah, this is an excellent opportunity to spread some historical > information... Interactive history is certainly far better than dry facts in books, but we'd have to be careful how we "spread historical information". FlightGear might well be a great means of keeping the historical flying experience alive. The trouble is, AFAIK *no* airplane currently modelled in FlightGear has ever been verified against the original machine. I'm *not* knocking what Josh has done here - nor of course anyone else's efforts. FlightGear is great for all those people who (like me) cannot afford to pilot real aircraft, or who just don't want to. However, we can't ignore the fact that, good though it may be, FlightGear is basically a video game. [ I take it, Josh, that I'm right in assuming that you've not flown a real B29? Nor even put an accurate model of a B29 in a wind tunnel to check how well the FDM is doing its stuff? :-) ] That's not to be taken as a complaint, but if we don't make people aware of this, then in 100 years time they'll be trying to re-enact battles of WWII using your B29 model on "FlightGear 29.2.1 for HoloDeck" and wondering why the bomber jocks of WWII claimed certain feats which they can't duplicate in 2105. So they'll rewrite history books to reflect what the HoloDeck simulation showed (the historical accounts obviously being exaggerated!), and they'll be wrong. Just as we can tell that the ancient Egyptians had help from aliens in building the pyramids, 'cos they "obviously couldn't have done it by themselves". :-) Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] b-29 alpha
On Thu, 2005-04-07 at 15:45, Curtis L. Olson wrote: > >AFAIK *no* airplane currently modelled > >in FlightGear has ever been verified against the original machine. > > > > I'm not disagreeing, but I would like to point out that FlightGear has a > lot of stuff built in for those that want to move beyond a simple video > game. > Yeah, and I'm not knocking FlightGear and all the great work that's been put into it. As you say, the ability to connect it to dedicated cockpit simulators (even on a motion-platform?) moves it well away from "just a game". Some of the folk on this list are private pilots from what I see being discussed. How well do those pilots reckon the simulated aircraft in FlightGear mimic the real ones, given that the FDMs are (apparently) empirically created from the aircraft's basic layout and physical properties? > There are hooks and facilities to connect FlightGear up to realistic > cockpit controls, switches, etc., and connect up to lights, gauges, > etc. A cockpit mockup with the displays and controls in the correct > locations goes a long ways torwards turning FlightGear into a legitimate > training tool. We have the ability to syncronize multiple display > channels, which allows people to design advanced visual systems with > wrap around screens. FlightGear can drive projectors or monitors which > gives you a lot of flexibilty to create a display system appropriate for > your particular needs and budget. > Is there actually a way to connect a motion platform? I recall hearing about a "motion chair" connected to one of the old (0.5.6 ish) versions of FG, but I'm not sure if that's the same thing. Similarly, what about force-feedback to control-columns? > To be fair to Josh, this is big reason why big full motion simulators > for a specific aircraft cost millions of dollars. The flight dynamics > data (and the work to get it and validate it) alone can easily exceed a > million dollars. Josh has done some good work. Keep it up, Josh. Especially the nose art :-) Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: b-29 alpha
On Thu, 2005-04-07 at 13:24, Melchior FRANZ wrote: > * Steve Hosgood -- Thursday 07 April 2005 13:58: > > FlightGear is basically a video game. > > BS! No matter how much you detest it, it's still a simulator. I *knew* I'd get flamed by Melchior! I don't detest FG, it's a fine bit of work. True, the word "game" was a bit too harsh. > But given that you post this on the developers list: what are you going > to contribute ... > Anyone want an RPM packaging (for Fedora Core 2) for 0.9.8? I noticed that the previous attempt at RPMing hadn't been updated since 0.9.4. So I did my own. Also I packaged up scenery for "Great Britain & Ireland", "The Faroe Islands" and "France" as separate entities. The idea is to get the RPMs put on a YUM archive (or APT) so that newbies can just say "yum install FlightGear-Terrain-FR" and they'd get all that they needed for flying (in this case in France). The scenery RPMs would load the basic FlightGear program and base-files automatically if you didn't already have them (RPMs can auto-require other ones). I was planning on doing Benelux and Spain next, but if other people wanted to join in, they're welcome to my SRPMs to use as a basis for their own lands. It may not be much, but I do *try* to contribute! Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] b-29 alpha
On Thu, 2005-04-07 at 17:36, Erik Hofman wrote: > Martin Spott wrote: > > > To my knowledge there _are_ aircraft in FlightGear that are build upon > > real data. Right ? > > Yes, the C172p. At least and the F-104, F-15 and F-16 are based on > windtunnel data. The T-37 is partially based on flight test data. > And Both the Fokker 70/100 and Fokker 50 use available data where possible. > > None of them are extensively validated though (although I do trust the > windtunnel and test-flight data). > Now, maybe I was trolling a bit when I started this, but replies like this (and Curt Olson's) make it seem quite worthwhile! I'd never been able to find any claims on accuracy of FlightGear's FDMs; not from the FG website, the FAQs nor trawling the devel-list archives. And yet, here it is! Surely someone ought at least to mention this level of FDM fidelity on the FAQ? It could only help increase FG's street-cred. It's been interesting watching Josh's comments during the B29 development cycle, seeing what he could get from published diagrams, and what he had to estimate. It will be even more interesting if/when he can coax some of the current pilots of restored B29s to have a go. Good luck, Josh. I suspect you'll need a force-feedback control column though or the real pilots will complain that they can't "feel" the aircraft. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Colditz Glider
Over the winter of 1944/1945 certain Allied POWs were imprisoned in Colditz Castle (east of Chemnitz, Saxony). Some of the British prisoners got desperate enough to build a glider in an attic. They never launched because the war was effectively over by the time the machine was ready, but in 1999, Britain's "Channel 4" TV channel commisioned a replica to be built and flown. It flew surprisingly well. I've recently been working on a FDM for the Colditz Glider. If you'd like to try it, I've put it up for comments on: ftp://tallyho.bc.nu/pub/steve/flightgear/colditz_20050518.tgz I initially modelled the glider by entering the known physical dimensions of the machine into aeromatic and claiming that it was a "light aircraft with 0 engines" rather than a glider. It was, after all built of floorboards and random junk covered with bedsheets doped with porridge! So, it's rather heavy for its size (110kg/240lb) and was expected to carry two (70kg/160lb) men. My FDM correctly models the stated stall speed of about 28 knots and sink rate of 240fpm. I have personal experience with slow-flying gliders in the shape of early 1980's hang-gliders and so I've added modelling for a fairly serious nose-dive on stalling the glider, plus an entertaining amount of ground-effect to make landings resemble what I recall from the hang-glider days. All the photos and plans of the original Colditz glider show it to have had almost no dihedral on its wings. The photos of the 1999 replica show that this was the case for the copy too. My FDM has taken that into account too, and indeed you'll find when flying it that it's pretty unstable in roll. ** I would not have liked to have been the pilot who took this thing off the chapel roof in Colditz, at night, on its maiden and only flight. Stall it below 100m (300ft) from the ground and you're dead! It switches from flying like a glider to flying like a piano almost instantly. Oh, and 100m (300ft) is your launch height above the valley floor. The original glider had no instruments of course. For this model, I've pinched the instruments panel from the Schweizer 2-33 that was already in Flightgear. I did this to give me some idea of airspeed, to compensate for not having the wind in my face whilst flying! I did however re-scale the airspeed indicator to concentrate on the 10 - 90 knot range. ( I suspect that the Colditz glider would fall apart at much higher velocities! ) Disclaimer: This is a toy. It's fun, and probably isn't too far wrong from modelling the real Colditz Glider. However, I've never even *seen* the Colditz Glider replica (in the Imperial War Museum now, apparently) far less flown it. So I don't know. Please try it and if you have any suggestions, I'll be happy to take them on board. I'm expecting complaints about the stall characteristics which are probably too savage, but then, hang-gliders stall hard, so why not this machine? There's no 3D model, sorry. Suggestions for how to do one, or (better) offers of help gratefully received! Enjoy! Steve Hosgood. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Wed, 2005-05-18 at 12:10, Jon Stockill wrote: > Steve Hosgood wrote: > > > Disclaimer: > > This is a toy [...] I've never even *seen* the Colditz > > Glider replica (in the Imperial War Museum now, apparently) > > [...] assuming it's not been moved it's right up on the top floor. > There a few rather dark photos at the end of this collection: > > http://photos.stockill.org.uk/c1955.html > Hmm - the thumbnails aren't displaying for me. It makes it very difficult to find the one I'm looking for. > If the original was anything like the rebuild then it really was a > remarkable achievement. (Obviously with the rebuild they tried to stick > to similar materials, but did have the advantage the > Unfinished sentence? They did have the probable advantage (not shown on TV) of flying the thing from a nice high tow launch with a radio control "pilot" and a sack of cement for ballast! That way they'd have known if it flew at all before risking the real pilot who flew it for the cameras. It was nice to see that some of the the surviving POW designers and builders (Best and Goldfinch) were there to see their plane fly at last. Sadly, Jack Best died only months later. > > Please try it and if you have any suggestions, I'll be happy to take > > them on board. I'm expecting complaints about the stall characteristics > > which are probably too savage, but then, hang-gliders stall hard, so why > > not this machine? > > > > There's no 3D model, sorry. Suggestions for how to do one, or (better) > > offers of help gratefully received! > > How much information do you have? Unfortunately I'm the other end of the > country, so can't easily drop in to the war museum again, but I suspect > they'll be the best source of info. I've got my copy of "Colditz: The Latter Days" that I've had since I was a teenager. It contains a basic plan and elevations of the plane, but no details of (say) airfoil shape. It does talk a bit about materials used though. I scrounged around the net and came up with some photos of the original machine and the replica both on the ground and in flight and one of the jubilant ex POWs jumping up and down in celebration. Nothing scientific though. I'll do it again and publish the URLs, but I've not got time right now. I've got just one URL to hand: http://www.fiddlersgreen.net/aircraft/WWII/colditz/info/info.htm This shows the War Museum exhibit, and much more. * A while ago, I did my own calculations of what would happen to a 250kg glider when thrown off a 20m runway by a bathtub full of a ton of concrete dropped over the side. However, later I found other estimates suggesting 1800lb of concrete would have been used (which is more like 800kg) and that the runway (the roof of the chapel) was probably nearer 18m long, not 20m as I'd estimated. Not sure what the truth was, but assuming the latter conditions, the glider leaves the roof dangerously close to stall speed in nil-wind conditions. They'd have needed a slight headwind to give them a fighting chance in the thing, I reckon. I suppose I ought to provide for a very short-lived and weak "rocket engine" for the Colditz Glider model, so you could try taking off from stationary on an elevated surface. Who knows how to set rocket burn-time and thrust? BTW: If any eastern German subscribers on this list could do a detailed scenery add-on for Colditz castle and the surrounding countryside, it would be appreciated (hint, hint) :-) How many people from tu-chemnitz.de have we got on here I wonder? Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Wed, 2005-05-18 at 14:42, Jon Stockill wrote: > I bet you're running norton internet security aren't you :-) > Nope: Mozilla 1.7.3 on linux. > You'll need to fix your ad blocker. > Wasn't aware I was running with anything much more than standard Mozilla defaults. I'll take a look sometime. > [...] did have the advantage > of having "new" rather than "recycled" materials. > And presumably they used "proper" tools, not home-made ones. > > Nothing scientific though. I'll do it again and publish the URLs, but > > I've not got time right now. I've got just one URL to hand: > > > > http://www.fiddlersgreen.net/aircraft/WWII/colditz/info/info.htm > > The diagram on that page would give you a starting point. Yes, well, that's exactly what I *did* use as a starting point! The diagrams in Pat Reid's book included the front elevation as well, plus make it a bit more clear that the area of the rudder was 16.6sq ft, not 166sq ft(!) which is what it seems to say on the reproduction diagrams on that web page (and others). Next time you're in the War Museum, see if you can work out where the passenger sat. I've assumed for now that he was squished in behind the pilot, but it's a guess. He can't have gone side-by side with the pilot, the fuselage is too narrow. Also, next time you're there, take a set of giant external calipers (!) to the wing and try and get several readings of wing thickness starting at the leading edge and working back to the trailing edge every foot or so along the chord. Then we could try and find a close match amongst the NACA standard airfoils and thus get a closer idea of lift vs. alpha and drag vs. alpha and stall characteristics from the published figures. Pat Reid already stated (in "Latter Days") that the bottom of the wing was flat, so just the thicknesses ought to suffice. Chances are that Best and Goldfinch used a standard airfoil from the book in the castle library. It's just a case of finding which one. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Wed, 2005-05-18 at 15:24, Josh Babcock wrote: > It doesn't look like it would be too hard to do a 3D model. Not having > to do instruments would only make it easier. I would suggest making a > custom HUD instead of grafting fake instruments onto the model. A HUD is *so* not 1944! Point taken of course, but I already had the 2-33 instrument panel to hand from the Schweizer, so apart from changing the range of the ASI, I kept it as is. Complete with yaw-string (which might be a valid Colditz 'instrument' anyway). You'll notice a non-working digital ASI crept onto the panel somehow, I've not spotted where that's coming from or I'd remove it! > If > there's interest I think I could hack out a pretty nice textured model > in a few days. > That would be superb. You and Jon Stockill (see elsewhere in this thread) could do with getting in touch with each other since you've both indicated an interest in this. The external appearance of the Colditz Glider seems to be a fine check pattern of blue and white - standard POW issue bedsheets I believe. The wing struts are wood. Floorboards again, I presume. Aerofoiled and polished judging by the photos of the replica, but not so obvious that the original was so well finished. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Wed, 2005-05-18 at 16:43, Dave Culp wrote: > > You'll notice a non-working digital ASI crept onto the panel somehow, > > I've not spotted where that's coming from or I'd remove it! > > > That's the Netto Variometer I believe. It works. > Thanks, Dave. One of yours, I believe! No offence intended, but I've just removed it from what will become the next release of the Colditz Glider. It's a bit anachronistic! The other instruments were at least available in 1944/45 even if not fitted to this particular machine. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Wed, 2005-05-18 at 18:52, Josh Babcock wrote: > Ampere K. Hardraade wrote: > > You can always use sound as an indication of speed. ;-) > > No smiley needed - when flying in "seat of the pants" mode, that's one of the important "instruments" at your disposal. > > Record the sound of wind ripping across the microphone, and replay this > > with > > different volume when the glider is flying. =) > > It's a bit more complicated: the centre frequency of the noise distribution should move too. But, yeah, the principle is good. I'd guess the same idea would be true of a "more normal" glider with a canopy too. > And you could indicate altitude by looping a guy's voice going > "oshitoshitoshit" The lower you go, the faster and louder it gets. > Excellent! > Seriously, I think the wind noise thing is a really good idea. > It's not confined to the Colditz glider though. All gliders should have such things modelled, but I'm not sure where they go in terms of programming. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Wed, 2005-05-18 at 17:26, Dave Culp wrote: > I don't think the Colditz Glider could do much soaring anyway :) > Funnily enough, it was the sight of snowflakes drifting upwards in the air rising up the castle walls that gave Bill Goldfinch the idea of a glider in winter 1943. It wouldn't have been practical I'm sure, but given a suitable head-on breeze, the pilot of the glider *could* have flown several passes parallel to the castle walls in order to stay in the rising air for as long as possible and gain height before trying to cross the town and the River Mulde beyond. In reality, the glider would have been spotted and shot at of course. The pilot would have to get away from the castle walls as fast as possible. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Wed, 2005-05-18 at 18:30, Josh Babcock wrote: > So do you all want me to go ahead with a model? We can work out > instrumentation issues later. > Please do. Those .gif files on the URL I mentioned yesterday are pretty much all the information published on the shape of the thing, though Pat Reid's book does mention a few more dimensions. For instance: 1) Width of aileron = 14 inches (from which length of aileron must be about 14 ft to reach the stated aileron area of 16.5sq ft, allowing for the rounding-off of the shape near the wingtip). I'll see what more I can deduce tonight. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Thu, 2005-05-19 at 10:11, Steve Hosgood (that's me) wrote: > Width of aileron = 14 inches (from which length of aileron must be > about 14 ft to reach the stated aileron area of 16.5sq ft, allowing for > the rounding-off of the shape near the wingtip). > > I'll see what more I can deduce tonight. > Steve > Er - wait a minute! The entire wing was only 15 ft long! That can't be right! The diagram must imply that the *total* aileron area was 16.5 sq ft. That would make each aileron about 7ft long, slightly less than half the length of the wing. Which is closer to what we see on the diagrams, but seems a little long even so. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Wed, 2005-05-18 at 15:24, Josh Babcock wrote: > It doesn't look like it would be too hard to do a 3D model. Not having > to do instruments would only make it easier. I would suggest making a > custom HUD instead of grafting fake instruments onto the model. If > there's interest I think I could hack out a pretty nice textured model > in a few days. > Just spotted this: http://www.fg-warehouse.net/freebees/COLDITZ-GLIDER/COLDITZL.PDF These guys have produced a build-it-yourself paper aeroplane based on the Colditz glider, complete with blue&white chequered colour-scheme. Useful as a guide for Josh's 3D modelling efforts, I'm sure. However, the aerodynamic performance of the paper model are probably not useful for giving us any clues for the FDM. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Thu, 2005-05-19 at 11:34, Gerard ROBIN wrote: > http://www.ean.co.uk/Data/Bygones/History/Article/WW2/Colditz/html/body_glider_plans.htm > That's a straight scan of the plans exactly as presented in P. Reid's "The Latter Days at Colditz". Much the same as the .gif files I've referenced earlier, but with the addition of the front elevation. Useful, but probably illegal just to publish a scan out of a book like that! Josh - take a local copy of that file before the copyright nazis take the site down! Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Fri, 2005-05-20 at 02:37, Josh Babcock wrote: > I'll see what more I can deduce tonight. > Steve Didn't get anything much done, sadly, but I have taken a look at your fuselage images, Josh. Nice work! > Just an update. > > http://jrbabcock.home.comcast.net/flightgear/colditz/colditz1.jpg > http://jrbabcock.home.comcast.net/flightgear/colditz/colditz2.jpg > One small observation. It's hard to be sure, but I think the photos of the glider replica show that the "riser" forming the back of the pilot's seat is also the centre bolting-on point for the wings, and therefore comes to a narrow flat-top under the wing, not to a sharp point as you've modelled it. Looks like P.Reid's drawing (body_glider_plans.htm) shows it like that too. It would also seem that the wing overhangs forward of the top-of- the-seat bolt-on point too. This is where I assume the passenger was squashed in. He gets a bit of side-to-side view in there, but not much. He wouldn't see much at night anyway. Other opinions may differ of course. Annoyingly, the photos from the 1999 flight on the 'fiddler's green' site don't really have enough detail in that area to be sure of anything. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
I've just come across a few more details in: http://www.chicagolandglidercouncil.com/newsletter_files/CLGCNewsletterFeb02.pdf There's a comment by the pilot who flew the replica, to the effect that the glide ratio was about 18:1 That's pretty impressive! There's also a photo of the glider just off the ground on the lauch tow, and a comment that the wings were built by a Mr John Lee, who was also the pilot for the TV programme. Another comment (backing up Jon Stockill's statement) is that the glider was in the Imperial War Museum, London for a while, and was moved to their aircraft collection at Duxford (Cambridgeshire, England) later. Annoyingly, that's about 6 hours driving from here, or I'd go over there with a camera. ** Research is revealing that 99% of the info on the Colditz glider on the web is a copy of some part of someone else's page! The link mentioned above is a pleasant change from that! Here's another pleasant discovery: http://www.aae.uiuc.edu/m-selig/ads/aircraft.html This claims that the wing on the Colditz Glider is a "Clark YH" which is great because that's a standard wing and its lift / drag / stall characteristics are documented. Can't find much on the web, but there's some aircraft design books down in the university library that I will be interested to check out Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Colditz Glider MkII
Folks: As most of you know, I've recently been working on a FDM for the Colditz Glider. I was surprised and encouraged by the amount of comment that the original thread generated. I've not been sitting still, and have now got a second version that you may like to play with: ftp://tallyho.bc.nu/pub/steve/flightgear/colditz_20050525.tgz Changes are as follows: After *much* grovelling the net, I eventually discovered a reputable claim (from Michael Selig at UIUC) that the Colditz Glider used the classic 1930's "Clark YH" wing profile. This ties up with a comment from P.Reid's "The Latter Days at Colditz" to the effect that the bottom surface of the wing was flat (most of it is indeed flat in the Clark YH). So I went looking for lift and drag coefficients for the Clark YH, and found them after a long search in a tutorial document on the web originating from Strathclyde University in Scotland. The new Colditz Glider FDM now uses these stated figures for the Clark YH, and though I don't have proper stall hysteresis figures for that wing, it seems almost impossible to fly the Colditz Glider model so that the airfoil actually does stall anyway. As airspeed decreases, the glider just loses lift to the point of mushing through the air below about 32 knots. With the machine flying normally, its best-case rate of descent is about 4 or 5 ft/sec, agreeing fairly well with the estimates of the original designers in Colditz. Likewise, its glide ratio is about 18:1 as estimated by the pilot who flew the replica in 1999 or 2000. I've adjusted my estimate of the locations of the CG and locations of the pilot and passenger after measuring around the reproduction of the original plans. I've played with (but commented out) an attempt to model the launch catapult with a very short-lived rocket engine. Basically, I need a rocket with a burn-time of 2.2 seconds and a thrust of 1866N (that's about 420 pounds in Flintstones units). However, my attempts have failed so far. Suggestions welcome. For instance, what are the units of fuel capacity for the tanks and fuel usage for the engine? [ Presumably tank capacity is in American Gallons or maybe "Barrels", and fuel usage is in Bushels per Nanofortnight, eh? :-) No chance of litres per second or cubic metres per second around here I suppose? ). The next version might even include a 3D model. Josh Babcock is working on one right now. Thanks, Josh. Whatever - enjoy escaping from Colditz. You should be able to make the intended landing site on the far side of the Mulde from the castle roof with height to spare if the prisoners' estimated distance to that landing site was right. Does anyone here actually live in or near Colditz? Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider MkII
On Wed, 2005-05-25 at 17:57, Martin Spott wrote: > BTW, I don't remember if these URL's have already been > mentioned: > > http://www.pbs.org/wgbh/nova/naziprison/glider.html > http://www.colditz-4c.com/glider-l.jpe > I think they were mentioned before. I had already seen them as part of my researches before starting the FDM, but some readers may not, so thanks for the links anyway. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Fri, 2005-06-03 at 01:46, Josh Babcock wrote: > Gerard ROBIN wrote: > > Le jeudi 02 juin 2005 à 20:16 -0400, Josh Babcock a écrit : > > > >>Josh Babcock wrote: > >> > >>Not quite done yet, still need some stuff in the cockpit, landing gear There's not much of either of those! I put some instruments on my hack, just to make it easier to fly without physical clues like the wind in your face. The replica in 1999/2000 had a wind ribbon - no idea if they planned one for the original. Landing gear consists of just a skid. The 1999/2000 replica had a steel main skid because they wanted it to survive the landing and be able to fly again. The original designers commented that they didn't bother with more than a rudimentary wooden skid because all they wanted was landing protection - the glider would never fly again (for them at least). > >>and some animations. I'm not planning on putting in a pilot, though if > >>enough people want one I can give it a shot. > >> It would look nice, but it's probably a lot of work. I spotted a wartime photo of one of the builders somewhere. Mapping that onto the face of the pilot would be a neat touch! > >>http://jrbabcock.home.comcast.net/flightgear/colditz/colditz.tgz > >> Something to play with at lunchtime! > > > > Wohhh > > Very impressive, congratulation, it is a must of art. > > as an extension we could use the (coming) launchbar function, to take > > off, not from the Nimitz, but from a tower (somewhere... in > > Germany) > > Aha - there's a 'launchbar' coming soon is there? I was wondering about how to model catapult launches and glider tow-launches. What I tried to do (but failed) with the Colditz glider was to give it a small short-lived (and invisible) non-throttleable rocket engine to simulate the launch catapult. I calculated that about 1866N (that's about 420lb) for 2.3 seconds would do. You can see my attempt (commented out) in the 20050525 glider FDM release. Something wasn't working though - any ideas anyone? > > > > > Keep posted, I have some neat plans for the model, especially animating > the wind indicating ribbon (not included in the latest release). > Thanks, Josh. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Fri, 2005-06-03 at 01:46, Josh Babcock wrote: > Gerard ROBIN wrote: > > Le jeudi 02 juin 2005 à 20:16 -0400, Josh Babcock a écrit : > > > >>Josh Babcock wrote: > >> > >>Not quite done yet, still need some stuff in the cockpit, landing gear > >>and some animations. I'm not planning on putting in a pilot, though if > >>enough people want one I can give it a shot. > >> > >>http://jrbabcock.home.comcast.net/flightgear/colditz/colditz.tgz > >> OK, I give up! Unzipped .tgz into 'Models' directory of colditz glider. Moved the .rgb and .ac files to the 'Models' directory itself (they were in a 'Colditz' subdirectory otherwise). Checked that 'colditz-set.xml' mentioned Models/colditz.ac (it did). Ran fgfs. No 3D model. What did I do wrong please? Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Fri, 2005-06-03 at 14:31, Gerard ROBIN wrote: > Le vendredi 03 juin 2005 à 14:08 +0100, Steve Hosgood a écrit : > > OK, I give up! > > > > You should have > > Aircraft/colditz/Models/colditz.ac > > Yeah, I had that in the 'colditz-set.xml' file. I noticed that the c172p directory has the "" in c172p-set.xml pointing to Aircraft/c172p/Models/c172p.xml and that file contained a pointer to c172.ac along with a load of animation stuff. I tried using that system for the colditz glider, but it didn't work either. When I say I have no 3D model, I mean from the pilot's seat I can't see the 'plane. I assume I should be able to see the 'plane from there! I didn't try an external view. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Sat, 2005-06-04 at 00:42, Josh Babcock wrote: > OK, model's done, same address. Now I'm going to do the animation XML. > If I'm really cool I'll be able to make the wind ribbon look good. > Otherwise, just controls and control surfaces. > > Also, I didn't know what the rudder pedals looked like, so I left them > out. I would assume that it's just a stick on a pivot which would be > super easy to add. I'm not sure about historical accuracy though. Of > course, the entire inside of the cockpit is a WAG anyway. Thoughts? > For certain, it will just be a centre-pivoted piece of wood with two wires (probably connected to the far ends) running back to a similar piece of stick fixed to the rudder pivot. The POWs built the whole thing out of floorboards and intended it to survive just a single flight. They will have done nothing fancy. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Mon, 2005-06-06 at 14:31, Arnt Karlsen wrote: > On Mon, 06 Jun 2005 10:35:03 +0100, Steve wrote in message > <[EMAIL PROTECTED]>: > > The POWs built the whole > > thing out of floorboards and intended it to survive just a single > > flight. They will have done nothing fancy. > > ..don't be too sure [...] expect good workmanship on the floor board product, > it was built to > carry 2 POW's for about 5 minutes after being catapulted outta the attic > by a bathtub full of concrete. Don't get me wrong, folks! I do expect good workmanship, but kept simple. A centre-pivoted piece of 3cm x 4cm wood with wires attached to the far ends running back through the fuselage to the rudder would be all that they'd need. No need for fancy fretwork decoration or rubber footpads! Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Mon, 2005-06-06 at 19:44, Josh Babcock wrote: > Well, take a look at what I put in, no wires, though I could do that > with about zero trouble if people think it would add to the model. > Personally I don't think it would add much though. Agreed. > Also I think the bar > I put in there is pretty sensible. I'll 'fess up to not having looked yet. Maybe I'll get a chance lunchtime. > Now who's going to do the castle :) > I've asked a few times if anyone from Colditz itself (or Chemnitz or Dresden) might volunteer for the challenge, but no replies yet. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Sat, 2005-06-04 at 00:42, Josh Babcock wrote: > OK, model's done, same address. Now I'm going to do the animation XML. > If I'm really cool I'll be able to make the wind ribbon look good. > Otherwise, just controls and control surfaces. > > Also, I didn't know what the rudder pedals looked like, so I left them > out. I would assume that it's just a stick on a pivot which would be > super easy to add. I'm not sure about historical accuracy though. Of > course, the entire inside of the cockpit is a WAG anyway. Thoughts? > > Josh Superb job, Josh. Many thanks. Sorry it's been a while since you completed it, but I've been ill. I love the details (like the wonky surface on the leading-edge!). The details of the inside of the cockpit are, as you say, just a guess but look pretty feasable to me. It would be nice if anyone on this list was visiting the IWM's Aircraft Museum and could contribute any detailed photos of the replica. A polite request to the museum itself might mean that such a visitor could be let past the ropes to get really close up. I got the impression from photos of the 2000 flight of the replica that the wing struts were a lot chunkier than you've made them, but that's all I can contribute. I have a bit more tweaking to do on the CG, and then I'll release what will (for now) probably be a first complete tarball of the Colditz Glider aircraft addon. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
On Tue, 2005-06-14 at 18:36, Josh Babcock wrote: > Someone should commit this to CVS too. > Or at least, add the finished tarball on the "Additional Aircraft Download" page on flightgear.org. Are all those additional aircraft built from the main CVS? I'd assumed they were maintained by their original authors. Whatever, there's still a bit of minor finishing off to do before the Colditz Glider is ready for such a showcase. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Wrong coordinates with airport LICP?
On Mon, 2005-06-20 at 16:29, Roberto Inzerillo wrote: > Hi, > I have an aerial picture of airport LICP (Boccadifalco, Italy) with UTM33N > coordinates [...] as soon as I overlap it to the scenery data in FGSD, I have > it displaced by by approximately 550m. > 550m? That's a big error! FlightGear uses WGS84 coordinates, but I'd not expect such a big deviation between WGS84 and any other geodesic system. Proving FlightGear's dataset is easy if you have a GPS receiver. Go stand on some part of the airport that has a reference point in FlightGear's data file. (The touchdown point on the main runway for instance... :-)) See what your GPS receiver says the coordinates are. The GPS reading should not be out by more than a few metres if you've got a good signal. Then, scrape yourself off the wheels of the Jumbo Jet that just landed on your head, and tell everyone if the FlightGear data is good or not. If UTM33N really is 550m displaced from WGS84 at that location, you can probably still use the UTM33N data if you offset it by the right amount. You may have to rotate it a bit too. Over such a small area, any ground distances you measure will be the same in both systems after simple correction. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Wrong coordinates with airport LICP?
On Mon, 2005-06-20 at 18:06, Roberto Inzerillo wrote: > > If UTM33N really is 550m displaced from WGS84 at that location, you can > > probably still use the UTM33N data if you offset it by the right amount. > > You may have to rotate it a bit too. Over such a small area, any ground > > distances you measure will be the same in both systems after simple > > correction. > > Sorry, I really don't understand you here. UTM33N and WGS-84 cannot be > displaced in any locations; one is the coordinate system and the second is > the datum. What do you mean with that? UTM33N is indeed a coordinate system, probably the system of choice for use in Italy, most of the country being in the 33rd 6-degree wide strip of the planet, and in the northern hemisphere: http://www.cnr.colostate.edu/class_info/nr502/lg3/datums_coordinates/utm.html WGS84 is also a coordinate system - the "native" system used by GPS and (unless I'm mistaken) the system used by FlightGear. http://www.gmat.unsw.edu.au/snap/gps/gps_survey/chap2/214.htm The difference is that UTM33N (or any of the other UTMs) are intended merely as map projections and only work over a small strip of the world's surface. WGS84 works over the whole planet. You can convert between projections obviously. One of the "complete" ways of doing it is called the Molodensky transform: http://www.colorado.edu/geography/gcraft/notes/datum/datum_f.html ( In practice, for small areas, you can assume that just applying an X and Y correction factor and a small rotation about that point will do it. ) > > > Anyway, do you think is possible that apt.dat is that wrong (550m)? Scenery > files for Europe are not precise at all. Are airport locations affected by > the same kind of errors? Maybe because of not enough precise source > informations? > Someone else pointed out that airport data comes from published figures, but it is possible that some airports published their coordinates in a non WGS84 system but someone forgot to do the Molodensky transformation on them before adding them to the apt.dat files. I have noticed though that *scenery* features can be off by a few hundred metres. They are derived in many cases from radar mappings made from space. I live on the coast, and one of these radar maps(*) I once tried to use for a mapping project had the coastline wrong by a hundred metres or more. Steve (*) IIRC, I derived it from FG scenery files from the then-current FlightGear 0.5.6 or similar vintage code. I've not checked the more recent maps of my area for absolute accuracy of the coastline Note to self: must do that sometime. :-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Wrong coordinates with airport LICP?
On Wed, 2005-06-22 at 17:05, Roberto Inzerillo wrote: > Hi Steve, > > > UTM33N is indeed a coordinate system, probably the system of choice for > > use in Italy, most of the country being in the 33rd 6-degree wide strip > > of the planet, and in the northern hemisphere: > > I agree. > > > WGS84 is also a coordinate system - the "native" system used by GPS and > > (unless I'm mistaken) the system used by FlightGear. > > Sorry, but I thought WGS84 is a Datum, one of the possible geometric > ellipsoid to choose from for describing the earth surface. True. > It's not a > coordinate system by it's own. Right? No - it is a coordinate system as well. "WGS84" is in some ways a bit confusing as it defines two things: a spheroid (known as the WGS84 spheroid, apparently) and a reference system on top of that (i.e an equator and a prime meridian). The reference system doesn't seem to have a name other than maybe "the WGS84 reference system :-)). But WGS84 is only any use for describing points on a spheroid. If you want to make paper maps of any area of the world you need a projection system. Italy (evidently) uses UTM33N. > This decision changes the way the > normal in a point is defined as well as the point considered to be the > center of the earth, so the latitude value depends on this choice too. > What am I missing? > Nothing! Read on > I visited www.atlanteitaliano.it (a Government web site); there I find a > complete map system of Italy. It's a ECW driven interactive site. I can pick > a point and have the coordinates back. www.atlanteitaliano.it says (for the > region where LICP lays) Datum is WGS84 and Projection is NUTM33 (UTM, region > 33, North). This is interesting. It implies that the data points coming from that web site are originally WGS84 already. If the site gave you lat/long then you could forget the UTM33 knowledge - lat/long would be the same on both. However, your comments below show that the coords given on the site are in UTM33 Eastings and Northings, and you'll have to convert them. > Airport LICP start and end points of the runway are: >Coordinates(1) > - Point A > X: 352091.5 Y: 4220579.4 > - Point B > X: 352213.2 Y: 4219364.1 > Knowing Datum, Projection and Coordinates is enough for determining the > point in the space, right? > Yes I think so. Looks like point A is 353.0915km east and 4220.5794km north of the UTM33N reference point. > - Second step (optional): coordinate conversion > I make use of "Geographic Translator Version 2.2.5" for getting the > conversion, which is usefull for further data verification. > The source data are the above ones; I specify that Datum is "WGE: World > Geodetic System 1984" (Ellipsoid is "WE: WGS84"), "Universal Transverse > Mercator (UTM)", Zone is 33, Hemisphere is North. >Coordinates(1) > - Point A > Easting/X(m): 352091.5 Northing/Y(m): 4220579.4 > - Point B > Easting/X(m): 352213.2 Northing/Y(m): 4219364.1 > I asked Geographic Translator to give me the output so that Datum is "WGE: > World Geodetic System 1984" (Ellipsoid is "WE: WGS84"), Geodetic. > I get the following output: >Coordinates(2) > - Point A > Longitude: 13 18 45.5E Latitude: 38 7 15.4N > - Point B > Longitude: 13 18 51.4E Latitude: 38 6 36.1N > These should be the coordinate values of the two points in FG Scenery, > right? Well these are not! > OK, so either "Geographic Translator Version 2.2.5" is buggy, or the published UTM33N eastings and northings are wrong. > > - Third step: aerial picture of LICP overlap to FGFS scenery LICP > I make use of FlightGear Scenery Designer for importing the aerial picture > and overlap it to the scenery so to complete it with surrounding buildings, > roads and so on. I make use of the tool called "Map Fragments". Here I can > import a picture of the terrain, fixing the coordinates of three known > points. > www.atlanteitaliano.it gives me those three points (two of them being the > two above described, and choosing a third usefull point). > Well, here FGSD asks me which kind of coordinates I am importing. I set > "System: Universal Transverse Mercator", "Zone: 33", North, "Datum: WGS-84". > For the two points, I use the Coordinates(1). > Well, the problem is when I import this "MAP Fragment" into the scenery. The > result is the picture of the airport being translate by almost 500m north to > the position of the airport of the scenery. > > The scenery airport coordinates, as viewed into FGSD, are: > Coordinates(3) > - Point A: > E 013:18'50.4 N 38:06'18.0 > - Point B: > E 013:18'45.8 N 38:06'57.6 > > > > The error is that (Coordinates(3)A.N)!=(Coordinates(2)A.N) . > I get the same error for PointB too, of course. > Yeah, I see that. So potentially FGSD is doing a dud conversion too. At least we have the source code for FGFS and can check it > The two runways are perfectly parallel to each other. There seems not to be > any rotation erro
Re: [Flightgear-devel] CVS for OpenAL
On Tue, 2005-06-28 at 08:23, bass pumped wrote: > > > > > > cvs -d:pserver:[EMAIL PROTECTED]:/usr/local/cvs-repository co openal > > > I tried this command too!! nothing happened. it just sits. Didn't > even ask me for a password. I am using Fedora Core 2. Does this have > anything to do with it? > It's not Fedora Core 2 per se. I checked out OpenAl a while back with no trouble on FC2. Not tried updating recently, but last time I did, that happened just fine too. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fedora Core 4
On Tue, 2005-07-12 at 03:14, Paul Kahler wrote: > I'm looking to build FGFS on FC4-x86_64. I looked at the instructions > at: http://www.flightgear.org/cvsResources/anoncvs.html It sounds > reasonable, but I can't just "yum install plib". Is there a repository > with a suitable package? A link to instructions on using non-standard > repositories would also be helpful ;-) > > Rinse and repeat the question for SimGear. There's a complete set of SRPMs for stock Flightgear 0.9.8 (plus plib,Simgear and the rest) on ftp://tallyho.bc.nu/~steve/flightgear/SRPMS ...feel free to build those for FC4. The same site already has RPMs built for FC2, but they might not agree with the version of glibc that comes with FC4. You'll also find RPMs for Flightgear scenery for the UK and Faroe Islands (France coming next, then Benelux, Germany, Switzerland, Spain etc). Sorry the scenery SRPMs aren't available yet - no space on the server! Also, they need reworking to make them 'noarch' anyway. Sometime, I'll start on RPMs for addon aircraft too. So much to do, and no time in which to do it Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fedora Core 4
On Tue, 2005-07-12 at 09:50, Steve Hosgood wrote: > There's a complete set of SRPMs for stock Flightgear 0.9.8 (plus > plib,Simgear and the rest) on > ftp://tallyho.bc.nu/~steve/flightgear/SRPMS > Sorry: make that ftp://tallyho.bc.nu/pub/steve/flightgear/SRPMS Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Fri, 2005-07-22 at 15:15, Andy Ross wrote: > We should probably fix this, I guess. Maybe the easiest way to do it > would be to contact the author; is XEarth or descendents still an > active project? > I've just been looking for xearth, and just about all the links I can find are dead. However, xearth spawned Xglobe and Xplanet, both of which claim to be GPL, and Xplanet is most certainly a live project. Xearth also spawned my own hack "xmars", but since Xplanet does everything in the solar system, I now consider xmars defunct. Xplanet claims that it pinched its moon position code from xearth, and Xglobe claims that it pinched its sun position code from xearth too. If xearth isn't GPL, that might compromise Xplanet and or Xglobe's claims to be GPL. However, Xplanet would seem like a good place to go looking for GPL sun-position code. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Fri, 2005-07-22 at 17:56, Erik Hofman wrote: > Andy Ross wrote: > > Erik Hofman wrote: > > > >>Since you are already familiar with this stuff, I need the function to > >>calculate the sun position (in degrees or radians) above the horizon > >>at a certain time/lat/lon. What is this normally called: > >>RightAscension, Declination, Magnitude or something else? > > > > None of the above. :) > > Not even "something else"? > :-) > Erik: The position of any astronomical object relative to a viewer standing on the planet's surface is usually given as "altitude" and "azimuth" - with the true horizon and true "North" used as the references. Normally, an object is said to "set" when it crosses the visible horizon. Simple rise/set programs assume that the visible horizon and true horizon are the same. It gets a bit more tricky in a flight sim because the visible horizon will be significantly below the "true" mathematical one, and thus the sun might well be visible even though it is below the true horizon. For orbit simulators, it gets even more extreme. Additional entertainment will be provided by the fact that and code for FG needs to work with a WGS84 spheroid, meaning that the distance to the earth's centre will vary with lat and long, but for *sun* rise and set, that's probably not significant. There's a great program called "ephem" which will yield all the routines you could ever want, though the pointers to "sunriset.c" that someone else posted here will likely do it too. Not sure of the licence for 'ephem' though. Somewhere I've got source for my own home-written version of a sun rise/set program that I wrote a very long time ago (1979 I believe). I'll see if I can find what I did with it. It started life in Fortran, but was converted to C ages ago, and will probably do the job just fine. I'd be quite happy to GPL any such source if it isn't already. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Mon, 2005-07-25 at 10:35, Erik Hofman wrote: > Steve Hosgood wrote: > > > Erik: > > The position of any astronomical object relative to a viewer standing on > > the planet's surface is usually given as "altitude" and "azimuth" - with > > the true horizon and true "North" used as the references. Normally, an > > object is said to "set" when it crosses the visible horizon. Simple > > rise/set programs assume that the visible horizon and true horizon are > > the same. > > Flightgear being one of them ... > > > It gets a bit more tricky in a flight sim because the visible horizon > > will be significantly below the "true" mathematical one, and thus the > > sun might well be visible even though it is below the true horizon. For > > orbit simulators, it gets even more extreme. > > Yes, I've wanted to fix that for some time, but never gotten to it. I've been thinking a bit more on this, and reckon that probably the horizon business is misleading. You only have to worry about it when you're trying to calculate a sunrise or sunset time. In flightgear, you just want to know the sun's true position at a given time, which is a single one-off calculation. You're only wanting to know the answer so as to set the lighting model. For any value of sun's altitude, you have to do object-intersection work to see if the sun itself is actually visible. One of the "objects" in that list is the planet itself (or, in simpler terms a flat obstruction representing the true horizon-line). Maybe you get the graphics card to do the intersection calculation anyway? Presumably flightgear's sky lighting models do need to know how far the sun is below the true horizon in order to change the sky colour from pale blue through all the shades of purple to black. > > Additional entertainment will be provided by the fact that and code for > > FG needs to work with a WGS84 spheroid, meaning that the distance to the > > earth's centre will vary with lat and long, but for *sun* rise and set, > > that's probably not significant. > > > > There's a great program called "ephem" which will yield all the routines > > you could ever want, though the pointers to "sunriset.c" that someone > > else posted here will likely do it too. Not sure of the licence for > > 'ephem' though. > > > > Somewhere I've got source for my own home-written version of a sun > > rise/set program that I wrote a very long time ago (1979 I believe). > > I'll see if I can find what I did with it. It started life in Fortran, > > but was converted to C ages ago, and will probably do the job just fine. > > I'd be quite happy to GPL any such source if it isn't already. > > I thought we could do it with the current code, but there is a chicken > and egg problem; To change the time, it is first calculated and then > set. The time setting code (or rather ephemeris update code) relies on > the time setting code. I was hoping to get the data from the ephemeris > code but it can get me the right data only after it has been set based > on the same settings ... > I'm a bit lost here! When calculation sunrise or sunset, you do have to do several iterations. First you find the sun's position in the sky for (say) 18:00 hrs locally. Then you guess a sunset time based on how far the sun is away from the true horizon. Then you recalculate the sun's position in the sky (its right ascension and declination) for that guessed sunset time, and convert to altitude and azimuth. Then you probably have to do at least one more loop, because you'll find that in the time between 18:00 and the first guess at sunset-time, the sun's position in the sky moved enough to change the results. Or more to the point, that the earth moved around the sun enough to change the results, but you know what I mean). However, none of this should be necessary for flightgear. You're not calculating the set time, you just want to put the sun in the sky correctly and illuminate the scenery accordingly. That should be a one-shot calculation. My code is on my home machine - I'll check tonight. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Mon, 2005-07-25 at 15:17, Andy Ross wrote: > I humbly submit that this is yet another area where an Euler (angle) > representation is a bug, not a feature. We have a sane cartesian > coordinate system for the earth. All that's needed is to define one > for the solar system* and then do reasonably trivial conversion. To be frank, that's close to what's happening anyway. The earth orbits the sun in an ellipse and it is considered to be a 2D system. Trouble is that the earth's orbital velocity isn't constant (as Johann Kepler and Tycho Brahe discovered in the 15th century - or was it the 14th?). Solving where the planet is in its orbit for any given calendar time is tricky. Once you've got that, you then do exactly what Andy says and do a "reasonably trivial conversion" to get the sun's position as seen from the POV of an observer on the planet (or over it) at that calendar time. The hard part is finding the calendar time given a phenomenum (like, say 'sunset'). I outlined that one in my previous post. > The > moon should be even easier, presuming that the moon's orbit passes > through the equatorial plane (it does, doesn't it?). > No. None of the planets share the earth's orbital plane either, but the moon is quite well offset. 18 degrees I think, and its orbital plane precesses w.r.t the earth's quite quickly too. The ancients deserve serious respect for managing to predict the moon's movements and eclipses at all. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Mon, 2005-07-25 at 17:13, Andy Ross wrote: > Steve Hosgood wrote: > > Solving where the planet is in its orbit for any given calendar time > > is tricky. > > This is just the equal area thing, right? Yes. > If nothing else, we can > certainly solve it by brute-force integrating it for +/- a few hundred > years and storing the table. > :-) It's not *that* tricky! Tricky for pre-computer-era people to solve with log tables and slide-rules maybe, but it's just an iterative algorithm where you plug a suggested value of 'x' into a formula and it gives you a better approximation. Repeat until the new approximate 'x' is within an allowable tolerance of the original. Trivial on any modern computer. > > The hard part is finding the calendar time given a phenomenum (like, > > say 'sunset'). I outlined that one in my previous post. > > Right, but the point was we don't give a hoot about "sunset". That's > a derived quantity specified in euler space... Yeah, quite right. I think the discussion just went off a bit sideways there. So we're just down to the problem that the sun position code is possibly not GPL-able. I've dug out my own code that I'm quite happy to donate. Only part of 'src/Time/sunpos.cxx' seems to be derived from Kirk Johnson's 'xearth' anyway, and even he attributes it all to the legendary "Practical Astronomy with your Pocket Calculator" book by Peter Duffett-Smith. I think the interface routines to FlightGear (all starting with 'fg') are not Johnson's anyway, but I'm not totally sure. Durk Talsma may know better - his name is on some of the comments in those 'fg' routines. If it's just a case of changing ecliptic_to_equatorial(), julian_date(), and GST() then I'm up for it. Can someone confirm that doing this will fix the issue, or is there more? Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Tue, 2005-07-26 at 10:37, Erik Hofman wrote: > To prevent any problems in the future I would like to see that file > removed and the functions added to tmp.[ch]xx > Remove sunpos.[ch]xx completely? OK. > But what is really needed is a way to get sun_angle() working in > sunsolver.cxx which is done by replacing fgSunPositionGST() with a new > version (or by writing a new function that can calculate the sun_angle > any time of day at any location) Funnily enough, I was just having a cup of tea and reading that very file just as your email came in (you're in Europe I presume?). fgSunPositionGST seems to be derived from Johnson's 'xearth' code, but it calculates where on earth the sun is directly overhead. That makes sense for 'xearth' where one of the options is to display the planet from the sun's point of view (so to speak). I can't work out what that routine is doing in FlightGear! It's only used in 'sunsolver.cxx' which was written by Curtis anyway, and is GPL of course. But why is called at all? The rest of Curtis's code does what I'd expect - which is to find the time of day when the sun is at a given angle (so you can specify flying at dusk, or noon or whatever). Give me a bit longer to disentangle it all! I can't work on it right now, (I'm at work) but I can take a quick look at lunchtime, and do more this evening. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Tue, 2005-07-26 at 17:34, Erik Hofman wrote: > that's all [fgSunPositionGST] does, give an angle to display the pretty > colors > properly. > Doh! That's a silly way to do it (see below). > > Give me a bit longer to disentangle it all! I can't work on it right > > now, (I'm at work) but I can take a quick look at lunchtime, and do more > > this evening. > > I can imagine, I had trouble finding out what's going on also :-\ > Tell me about it! Here's a basic audit: The julian_date() routine is pretty much word for word the same as Johnson's original, but it's 'static' and only used by the GST() routine. The GST() routine is also word for word identical with Johnson's. It is 'static' and only used by fgSunPosition(). fgSunPosition() isn't used anywhere! So we could ditch all three of these routines immediately with no possible ill effect. FlightGear's 'ecliptic_to_equatorial()' routine is a modified version of Johnson's and it might be said that his copyright in it is no longer relevant. It is, after all just an implementation of the algorithm in Duffett-Smith's book (I've got a copy in front of me). The only novel thing is that my (first edition) copy of the book uses 'atan' and has to sort out the ambiguities caused by that afterwards, but Johnson's and FlightGear's version (sensibly) uses 'atan2()' to avoid the ambiguity in the first place. This is a pretty obvious implementation issue, but who thought of it? Johnson? Or is like that in the third edition of Duffett-Smith?. The 'ecliptic_to_equatorial()' routine gets used by fgSunPosition (not used) and fgSunPositionGST only. Both these routines are rewrites of Johnson's sun_position() routine, and are probably similar enough to be a problem. As stated at the start of the audit, we could lose 'fgSunPosition()' immediately since it isn't actually used anywhere. FlightGear's 'fgUpdateSunPos()' routine seems to have no obvious connection to Johnson's code, though it does call fgSunPositionGST(). I'm not convinced that FlightGear even wants to do this anyway. Surely it should have done a conversion from sun's equatorial coordinates (right ascension and declination) to horizon coordinates (altitude and azimuth) since, as Erik says above, all FlightGear wants to know is the bearing of the sun below the horizon so that it can get the dusk lighting correct! Altitude and azimuth would seem to be the ideal data for that. The only other call to 'fgSunPositionGST()' is in sunsolver.cxx and that's for finding sunrise or sunset time as mentioned before. Again, knowing solar alt/az from the location of the viewer would have been more useful I think. Looks like binning 'sunpos.cxx' will be relatively trivial. Still working on it though. Gotta be careful not to break some cunning interdependency... Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Wed, 2005-07-27 at 12:29, Steve Hosgood (that's me) wrote: > The julian_date() routine is pretty much word for word the same as > Johnson's original, but it's 'static' and only used by the GST() > routine. > > The GST() routine is also word for word identical with Johnson's. It is > 'static' and only used by fgSunPosition(). > > fgSunPosition() isn't used anywhere! So we could ditch all three of > these routines immediately with no possible ill effect. > Just tried it. Also removed the 'extern' reference to 'fgSunPosition()' in sunpos.hxx and it all compiles just fine as expected. Much the same thing applies to moonpos.cxx too. There's a 'julian_date()', 'GST()' and 'fgMoonPosition()' set of defunct routines in there which can be deleted with no ill effect. Remove the 'extern' reference to 'fgMoonPosition()' from moonpos.hxx too. Still working on the remaining issues. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Sun Azimuth [Was: licensing problems in SUSE Linux]
On Mon, 2005-08-08 at 06:31, Durk Talsma wrote: > On Sunday 07 August 2005 15:54, Erik Hofman wrote: > > Erik Hofman wrote: > > > Is this correct or am I missing something? > > > > I just realized that you also need to adjust for day-of-year to > > compensate for the out-of-center rotation that causes long days (and > > nights) for both polar areas. > > > Just looking through your mails quickly, it looks like you also need to > compensate for the fact the the earth's rotation axis is tilted by about 23 > degrees, [plus] the earth's orbit around the sun > is not a perfect sphere, but an ellipse. Durk is quite right. It's non-trivial, but dealing with all these issues is not really a problem. I'm in the middle of doing it myself, but have just only just got back from a week on vacation. My main interest is in removing the use of Xearth's "find the point on the planet where the sun is overhead" routine and replacing it with the more obvious "what is the current altitude and azimuth of the sun seen from a given location". Doing that will make all the solar (and lunar) astronomy code use standard algorithms from Peter Duffett-Smith's books and thus make sure there can be no problems with Xearth's non-GPL code causing trouble for FlightGear. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Sun Azimuth [Was: licensing problems in SUSE Linux]
On Mon, 2005-08-08 at 10:35, Erik Hofman wrote: > But if you don't mind I'm still working on my own solution, I already > have the code to compensate for lon and daylight saving time. > Let's see what comes out of it ;-) > Don't mind? Of course I don't mind! FG is a great big GPL-ed OSS project and this is exactly how development should work. Chances are that you'll be finished before me anyway, as I can only get odd moments to work on it. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Does FlightGear model eclipse?
On Mon, 2005-10-03 at 09:01, Erik Hofman wrote: > Speaking of which, is anybody still working on replacing the non-GPL > sun/moon azimuth calculations to properly model the color of them? > I've done some of it. Not sure about the 'color' bit, I'm just working on taking out the xearth astronomy routines (which are largely inappropriate anyway) and replacing with straight boring math from the likes of Peter Duffett-Smith's book. I've just been overworked for the last month and haven't made any recent headway, that's all. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
On Tue, 2005-11-08 at 08:39, Erik Hofman wrote: > Josh Babcock wrote: > > > possibly the Colditz glider to follow it. BTW, how come the Colditz > > never made it into CVS, IIRC it's GPL, and I personally thought it was a > > pretty neat little project. Anyway... > > The last message I saw about this subject indicated it wasn't ready for > inclusion. After that it became silent. > That's because I (the FDM writer) suddenly had to learn how to write Windoze device drivers and ran out of free time! Josh did a great job of the 3D model. The whole thing looks good and flies OK. I wasn't totally sure about the alignment of the 3D model with the reference points for the FDM, but hey, it may not be perfect but it's perfectly usable. I'll be quite happy for the Colditz Glider to be part of 0.9.9 It will benefit from a catapult launch system (apparently the aircraft carriers have such a thing now?). I tried using a short-duration low-powered rocket in the FDM to achieve a similar effect, but never managed to get the coefficients right. Help yourselves at ftp://tallyho.bc.nu/pub/steve/flightgear/colditz_20050908.tgz I can't put in CVS myself: (no permission). If it does go into CVS (or anywhere else) please delete the subdirectories 'Docs/' and 'Images/' because they contain all the research materials I pulled together in order to build the thing in the first place and are not GPL. Similarly, "thumbnail.jpg" in the top directory isn't mine either. Everything else is by me or Josh Babcock and we're both happy that it's GPL. FYI: The 'Images/' directory is every photo of Colditz Castle that I could find on the web. I was wondering if there was enough information there to do a reasonable 3D scenery mockup of the castle to be added to the default FGFS scenery of that corner of Saxony. Never got past the first stages though. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz glider (Was: AI Aircraft Models)
On Tue, 2005-11-08 at 17:40, Erik Hofman wrote: > Steve Hosgood wrote: > > > I'll be quite happy for the Colditz Glider to be part of 0.9.9 > > > > Ok it's committed to CVS. It won't be part of 0.9.9 directly but it will > be downloadable from the aircraft page after that. > That's great. Glad to be of assistance. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.9-pre2
On Wed, 2005-11-09 at 19:46, Curtis L. Olson wrote:
> FlightGear v0.9.9-pre2 (second prerelease for v0.9.9) is now available
> for downloading and testing from the FlightGear web site
> (http://www.flightgear.org)
>
> It would be great if as many people as possible could download the
> tarballs for this release and build and test it on as many platforms as
> possible. Also note you will need the corresponding SimGear-0.3.9-pre2
> (from http://www.simgear.org)
>
Folks:
I just built 0.9.9.pre2 as an RPM for Fedora Core on i386 class
machines. I did this months ago with 0.9.8 too, and it worked fine.
However, I'm getting a core dump off fgfs almost immediately at
start-up. It won't even get as far as "fgfs --help".
The latter few lines of "strace fgfs" look like this:
open("/usr/share/FlightGear/data/preferences.xml", O_RDONLY) = 3
open("/usr/share/FlightGear/data/Translations/locale.xml",
O_RDONLY) = 4close(4)= 0
open("/usr/share/FlightGear/data/gui/menubar.xml", O_RDONLY) = 4
close(4)= 0
open("/usr/share/FlightGear/data/gui/styles/default.xml",
O_RDONLY) = 4
close(4)= 0
open("/usr/share/FlightGear/data/gui/styles/anthrax.xml",
O_RDONLY) = 4
close(4)= 0
open("/usr/share/FlightGear/data/cloudlayers.xml", O_RDONLY) =
-1 ENOENT (No such file or directory)
open("/usr/share/FlightGear/data/keyboard.xml", O_RDONLY) = 4
close(4)= 0
open("/usr/share/FlightGear/data/mice.xml", O_RDONLY) = 4
close(4)= 0
close(3)= 0
munmap(0xb0913000, 4096)= 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
( I indented it by hand to make it a bit more obvious what 'close'
belongs with which 'open' )
Seems like the program closes /usr/share/FlightGear/data/preferences.xml
and immediately crashes.
I've not got any scenery loaded apart from the default couple of tiles
around KSFO. I removed my 0.9.8 .rc files and anything else I could find
that looked like hangovers from 0.9.8 just in case. No effect.
This was compiled on Fedora Core 2 with the gcc 3.3.3-7 standard
compiler. All worked fine for 0.9.8 as I said.
Steve
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.0.9-pre3
On Fri, 2005-11-11 at 09:09, Erik Hofman wrote: > Curtis L. Olson wrote: > > Just a quick announcement that I rolled up v0.9.9-pre3 tonight. I had > > screwed up and missed a file in the base package, and then some other > > changes got snuck into simgear/flightgear so I figured I might as well > > roll out another try. > Hot damn! I haven't even got pre2 to run yet! Curt: if you've not done it yourself yet, the file "data/Huds/Instruments/Default/runwayinstr.xml" has duff permissions. > There's one thing I really like to see solved preferably before 0.9.9 > (but it is a must for 1.0) and that's the sun/moon azimuth calculation > code to be replaced. > That's certainly not getting in before 0.9.9! Turns out to be wy more tricky than it looked. It would seem that the entire handling of sun/moon azimuth/altitude as it's done now in flightgear needs replacing, with the alt/az calculations themselves done in Simgear. Everything else to do with the ephemeris happens in Simgear. To some extent, I'd argue that the whole ephemeris thing needs splitting out from Simgear into "Ephemlib" or something. After all, there are quite a few planetarium programs out there, each with its own unique ephemeris calculations. It would make sense to try and draw them together. There's little incentive for anyone writing an astronomical program to want to use Simgear for the ephemeris calculations because it comes with so much flightsim-related baggage. But that's for another day, another year. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.0.9-pre3 xglobe licence issue
On Fri, 2005-11-11 at 13:07, Erik Hofman wrote: > Ladislav Michnovic( wrote: > > 2005/11/11, Erik Hofman <[EMAIL PROTECTED]>: > >> There's one thing I really like to see solved preferably before 0.9.9 > >> (but it is a must for 1.0) and that's the sun/moon azimuth calculation > >> code to be replaced. > > > > If you are talking about code from xglobe ( src/Time/sunpos.cxx, > > moonpos.cxx) , which licence is quite problematic, I hope it would be > > solved as soon as possible. > > Yes, that's the code. > I now have a fully working version without any of the affected code, > just a routine which was written by Curtis anyhow. > Well, Erik, you've done *far* better than I did in less time. I got lost in the mass of 3D vector stuff that was working out how to light the scene and shift the skyglobe based on knowledge (from Xearth) of what point on earth had the sun directly overhead! I got as far as replacing the Xearth stuff with a simple "get the sun's alt and azim for a given place on earth" routine, but couldn't untangle the rest. I shall go hang my head in shame somewhere quiet Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.0.9-pre3
On Fri, 2005-11-11 at 12:29, Jon Stockill wrote: > Steve Hosgood wrote: > > > Curt: if you've not done it yourself yet, the file > > "data/Huds/Instruments/Default/runwayinstr.xml" has duff permissions. > > The following files probably *shouldn't* be there: > And the following file probably should (considering that otherwise you get a complaint message on the screen when using the default aircraft): data/Aircraft/c172r/Models/c172-dpm.ac Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.9-pre2
On Thu, 2005-11-10 at 19:05, Dave Culp wrote: > Aside from the already mentioned glitch about the missing cloudlayers.xml > file, I was able to build 0.9.9-pre2 without any problems on my linux box. I just moved on to 0.9.9.pre3 No (real) problems now. Thanks to all who looked at my 'strace' listing. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Fedora Core RPMs for 0.9.9-pre3
If anyone wants to test 0.9.9-pre3 on Fedora Core 2,3 or 4 but can't compile it for themselves, please help yourselves to my RPMs: ftp://tallyho.bc.nu/pub/steve/flightgear/0.9.9-pre3/RPMS/i386/FlightGear-0.9.9.pre3-0.FC.i386.rpm ftp://tallyho.bc.nu/pub/steve/flightgear/0.9.9-pre3/RPMS/i386/openal-20050209-0.FC2.i386.rpm Ignore the 'FC2' suffix on the openal package: it should be fine for FC2 onwards. You don't need the 'devel' RPMs unless you plan building the SRPMS for flightgear. If you do, they are in the directory: ftp://tallyho.bc.nu/pub/steve/flightgear/0.9.9-pre3/SRPMS/ (of course). Scenery RPMs (for the UK, Ireland and Faroe Islands) coming soon using the scheme I used for 0.9.8. Not to everyone's taste I know, but convenient if you like keeping your software under RPM's control. Steve. PS: If pre4 isn't coming out tomorrow morning :-), could someone mirror these RPMs somewhere please. They're currently hosted on rather a puny machine on a slow WAN. Thanks in advance. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 0.9.9 scenery?
The main fgfs website only lists scenery for 0.9.8 Is world scenery for 0.9.9 waiting for a stable, offical 0.9.9 release first? Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 0.9.9 scenery?
On Fri, 2005-11-11 at 15:14, Curtis L. Olson wrote: > There is a current world scenery rebuild in progress. We are currently > hung up on a data processing glitch that is being worked on. The > scenery and the source release can and will happen independently. I'll just wait then. Thanks Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Flightgear 0.9.9 RPMs for Fedora Core 2, 3, 4 on i386
Please help yourselves to my RPMs: ftp://tallyho.bc.nu/pub/steve/flightgear/0.9.9/RPMS/i386/FlightGear-0.9.9-0.FC.i386.rpm ftp://tallyho.bc.nu/pub/steve/flightgear/0.9.9/RPMS/i386/openal-20050209-0.FC2.i386.rpm Ignore the 'FC2' suffix on the openal package: it should be fine for FC2 onwards. For the convenience of non-techie users (not that there are any using Fedora Core!) the Flightgear RPM adds a launcher to the 'Games' category of the Red Hat "Start" tool (bottom left of the screen). Yes, it probably should create a category called 'Simulators' and put the icon and launcher in there instead. However, I couldn't work out how to do that - if anyone knows how, please post and tell me. --- You don't need the 'devel' RPMs unless you plan building the SRPMs for flightgear. If you do want the SRPMs, they are in the directory: ftp://tallyho.bc.nu/pub/steve/flightgear/0.9.9/SRPMS/ (of course). Scenery RPMs (for the UK, Ireland and Faroe Islands) coming soon using the scheme I used for 0.9.8. Not to everyone's taste I know, but convenient if you like keeping your software under RPM's control. Steve. PS: Could someone mirror these RPMs somewhere please. They're currently hosted on rather a puny machine on a slow WAN. Thanks in advance. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Re] Buildings?????
On Wed, 2005-11-23 at 18:01, Martin Spott wrote: > Robicd wrote: > > Martin Spott wrote: > >> "Roberto Inzerillo" wrote: > > >>>FGSD is very helpfull in modelling the terrain too. > > >> but you should note that there is no way to feed this terrain back > >> into the 'official' FlightGear Scenery, > > > I have real fun with that, my area (which is Palermo - Italy) has really > > awfull release scenery tiles. I guess I will need more time to spend on > > learning GRASS and maybe in the near future we will have the tools to > > easily integrate private enhancements to the scenery base. > > I'm pretty sure we will have tools in the near future to merge certain > landcover enhancements into the main scenery. We may have tools to > merge elevation data into the main scenery but I fear we will almost > _never_, as we already said in an earlier discussion, never have the > tools to merge those enhancements that people created with FGSD. > I know this topic comes up from time to time, but it strikes me that the only way you can ever hope to handle the custom terrain & scenery question is to cater for a two-layer approach: 1) Flightgear has a world-coverage terrain dataset available (as now). It's stored in tiles and goes in .../Data/Terrain. It contains elevation and approximate land-usage texturing clues (as now). 2) Flightgear has a limited set of 3D world scenery objects (as now), such as airports and famous landmarks. This gets superimposed on the terrain (as now). It's stored in tiles in .../Data/Scenery 3) Flightgear should support a secondary terrain dataset available in (say) .../Data/Terrain/Custom. If FG needs a tile, it looks there first. If it finds a match, then that tile is used in preference to the default one. 4) Flightgear should support a secondary scenery objects dataset in (say) .../Data/Scenery/Custom. Managing this gets a bit more complex, but it's probably best that each scenery item be considered separately. If a custom scenery object is in view, display it. If a default scenery object is in view, display it too unless it's been trumped by a custom object occupying the same coordinates. 4a) You need to cater for the idea of a custom null-object whose only job is to trump a default scenery object that's considered to be wrong. I believe someone said that the Eiffel Tower in Paris is an example of this (being around 500m misplaced)? Doing all of this ought to allow the Flightgear main project people to just get on with the sim, but allow individual enthusiasts to improve the look of their own localities. Plus it would allow anyone to download peoples' local improved scenery and have it plug in seamlessly. Some of this has been talked about before. Folks were asking recently about what had to be done for 1.0.0. My vote would be to sort this one out. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Re] Buildings?????
On Thu, 2005-11-24 at 12:20, Ralf Gerlich wrote: > Hi, > > Buchanan, Stuart schrieb: > > Hi Steve, > > > > Apologies if I've misunderstood your answer, but I think we can already do > > this by setting the FG_SCENERY environmental variable appropriately. > > This is actually the way I'm using the Lake Constance scenery and it's > the way proposed on the Lake Constance Scenery Download site. It works. > OK, so what was the original poster bothered about again? Sounds like it's all working as expected. I suppose I could complain that maybe the reliance on an environment variable to point to the scenery may be great for scenery developers, but isn't so great for package maintainers who might like to try and make (say) FlightGear-LakeConstance-Scenery-0.9.9-0.rpm Rather difficult for the post-install script in a package to make sure that the users' environment gets updated to know about the new scenery. Even more difficult to remove it cleanly and correctly afterwards when they uninstall the package. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Newbie-friendly Aircraft downloads
To follow on (loosely) from the recent topic about a "browser" for aircraft to make it easier for newbies: The other way (at least with linux) to accommodate newbies(*) is to package the sim, its various terrain and scenery, and its aircraft in RPMs or a similar system. I just did this with the Colditz Escape Glider - it dovetails in nicely with the Fedora Core RPMs that I've already made available on: ftp://tallyho.bc.nu/pub/steve/flightgear/0.9.9 look in the RPMS/noarch directory for the glider package, or the RPMS/i386 directory for the sim itself. If a set of packages like these are put on a 'yum' server, it all becomes pretty trivial for a newbie(*) to obtain what he/she wants complete will all the prerequisites in a single operation. (*) More likely, experts who just want to try out the sim and not to have to understand all the vagaries of FlightGear before doing so. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] No 0.9.9 scenery yet?
Folks: I keep hearing comments to the effect that though 0.9.9 scenery *will* appear RSN, 0.9.8 scenery works fine with 0.9.9. Is that true? There doesn't seem to be any info on the FlightGear project pages to guide users around this issue. Might it be easier to issue scenery under its own numbering system, making it clear that a given version of FlightGear needs scenery version x.y.z (or maybe >= version x.y.z)? This might be an important consideration as FG goes to 1.0.0 and beyond. Steve PS: Is it planned that after 1.0.0, there will be a 'development' tree of 1.1.x, with the next "proper" release becoming 1.2.x? Opinions differ on whether or not this scheme is good or bad, but the FG project gods probably need to think it through pretty soon. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] No 0.9.9 scenery yet?
On Tue, 2005-11-29 at 16:52, Curtis L. Olson wrote: > Steve Hosgood wrote: > >Is it planned that after 1.0.0, there will be a 'development' tree of > >1.1.x, with the next "proper" release becoming 1.2.x? > For what it's worth, we did use this version numbering > scheme for a while. Officially 0.8.0 is our 'stable' release. However, > as soon as we released 0.8.0 and made 0.9.0 available, *everyone* > ignored 0.8.0 and ran with 0.9.x. > It may not be universally true, but quite a few projects only start the "even/odd" numbering scheme *after* they've got as far as 1.0.0 All the way through the 0.x.y numbering era I think the usual idea is that there *is* no "stable release" as such. I can quite understand why everyone forgot about 0.8 of FlightGear once 0.9.x came out! *So* much new stuff had appeared since 0.8 no one wanted to run it any more. But you could consider that after 1.0.0 things will change - if you make it so. Have a rule that the only tarballs and other packages on the FlightGear website are of the even subtree. Anyone wanting odd subtree stuff must go to the CVS for it. Make sure that the even subtree doesn't get covered in cobwebs (so to speak) such that no-one wants to run it because it lacks all the cool new features (the 0.8 mistake). Don't start 1.1.x until at least 1.0.5 or 1.0.6 have come out so that immediately post 1.0.0 the development team's efforts are aimed at making dead sure 1.0.x will run properly. Linux kernel people rarely start the odd subtree until at least ".10" of the even subtree is out. Just my thoughts - other opinions may differ. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] No 0.9.9 scenery yet?
On Wed, 2005-11-30 at 12:46, Curtis L. Olson wrote: > Stefan Seifert wrote: > > > Why the need for an odd subtree then? > > Normal end users use the released packages on the webpage (currently > > 0.9.9). Everyone else, including developers and bleeding edge people > > already check out from CVS. > > Right now I suspect that most users of FG are either developers or bleeding edge people. But the idea is that that should start changing as of 1.0.0. Indeed - that's *why* there's a 1.0.0, surely? >From then on you need to try and accommodate the "mere users" at the same time as allowing the developers to take the project forwards. But Stefan is right. You can do that with just a 1.1.x release sequence some time after 1.0.x. Trouble is that the developers get robbed of a way of referring to milestones in their own efforts. All they can do is say "this was broken some time after 20060510" referring to the CVS date of a commit. The linux kernel people do at least have the advantage of having "development builds" on the odd-number trees which they can use as absolute references to their progress. That's the only distinction I can see between Stefan's argument and the odd/even numbering system. > > Normally pretty everyone should > > want future updates as soon as they are stable enough for end users. The trick is *not* to do that. Wait a while until you have a set of nice stable goodies for the end-users *then* call a flag day, shift from 1.0.x to 1.2.0 and bring in all the new stuff from 1.1.x in one go. It makes for a better news story on Slashdot/SourceForge/wherever and is more likely to generate column-centimetres in the glossy magazines on real news-stands. > > Linux Kernel versioning has change a _lot_ since 2.6. There is not > > even a real development branch anymore. > They just haven't started 2.7.x yet. They're close to the point where they will though. Linux kernels usually get to .10 on the even tree before the odd tree appears. They're at, what .13 now on the even tree? The odd tree is late, but not massively so. Yet. > I think as flightgear develops and matures, there argument for an > even-stable/odd-devel release system will grow a lot stronger, but for > the moment, development has been moving so quickly with so many new > important features being added, that our attempts at a stable release > have largely been ignored, simply because the devel releases ahead of it > were so much better. > The users up to now have been the developers (see above). > It is interesting to have this discussion though. At the start of this > project, the big focus was to get anyone interested. I was very focused > on generating enough forward progress to keep people from giving up and > moving on to other stuff. At that point I felt like I largely carried > the project on my back and if I would have dropped it, the whole thing > would have quickly died. > Which is why, quite frankly, whatever you say about version numbers is what will happen. That's fine with me, but the fact that we talked about it at all is good. > Now as we look forward, we are talking less about a mad scramble to add > basic features (although there are a few important things left to add) > and more about stability and content (aircraft, scenery, etc.) > It's a bit worse than that though. It was suggested here just a couple of days back that we'd need a way to implement changing aircraft whilst running the program (because everyone else does). That'll likely need a lot of rip-up and replace in the low-level architecture. We might want to change the GUI in a big way. We might want to allow new FDMs to be added, etc etc. You seriously don't want side effects of stuff like that leaking into the users' version of the program until it is very well established amongst the developers that it's all working again and all the loose ends have been tied up. Look what happened to linux kernel around 2.4.9 when someone changed the deep underlying magic in the virtual machine system(*) on the *even* tree and broke the even tree totally for weeks, maybe months. It wasn't until 2.4.14 or thereabouts that the mess got sorted out. > So this discussion of odd/even releases may be a bit premature at the > moment, but it is something we should possibly consider again sometime > after our 1.0 release. > > Curt. Curt - you're the "Linus" of this project. What you say goes. If we people wish to see a given thing done or not done, it's up to us to convince you. And that's what this list is for. Stefan makes valid points above, I think I do too - as will others. There's no right answer, but at least if we've discussed it, we can understand the resulting action or inaction. And change our minds later :-) (*) OK, maybe that wasn't quite what happened, please don't flame me about what *really* happened on this list!!! It's supposed to be just an illustration of how developer stuff got done on the wrong tree(**) and inconvenien
[Flightgear-devel] Autopilot
Folks, was there a bug in the autopilot on the c172 default airplane in 0.9.8? I fill in the fields and tick the boxes on the "Autopilot" dialog box, take my hands off the stick and the bloody thing wanders all over the sky. 1) Maybe this is an accurate model of the c172 autopilot? :-) or 2) Maybe the c172 doesn't have an autopilot. If the latter, then surely the dialog box ought not to be available (i.e be greyed out in the relevant menu). or (I suppose) 3) It was broken in 0.9.8 but is fixed now. I *think* I may have tried it in 0.9.9 with the same results. Not sure. Can't check right now. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot
On Wed, 2005-11-30 at 16:55, Jon Stockill wrote: > Steve Hosgood wrote: > > > 3) It was broken in 0.9.8 but is fixed now. I *think* I may have tried > > it in 0.9.9 with the same results. Not sure. Can't check right now. > > It'll still be the same. The C172 doesn't use the generic autopilot code > - it has a KAP140 autopilot model - which is controlled by clicking the > buttons on the device in the cockpit. Others wrote with much the same info. Guys, this is a 1.0.0 killer. I knew there was an autopilot on the cockpit display, but on my monitor at home (1024x768) it was a bit difficult to read. So, like any random punter would, I figured that the (fully functioning) autopilot dialog box would be an alternative interface to the *same bloody autopilot*. Not so, it appears. If we want to have FG 1.0.0 laughed at by one and all on release day, this is the way to go. Pleeese fix it? Can anyone else point out instances where a non-greyed-out menu item or dialog box offers what looks like an alternative UI for a cockpit instrument, but actually does nothing of the sort? Any other related inconsistencies? Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
On Wed, 2005-11-30 at 20:25, Steve Knoblock wrote: > >It'll still be the same. The C172 doesn't use the generic autopilot code > >- it has a KAP140 autopilot model - which is controlled by clicking the > >buttons on the device in the cockpit. > > This confusion will raise its head every time a person comes to > FlightGear for the first time. They will start with the Cessna and > reach for the Autopilot dialog on the toolbar and wonder why it does > not work. How could they know it is not hooked up for the particular > aircraft Steve Knoblock is replying to my query about bizarre inconsistent autopilot behaviour on the default Cessna. Makes me wonder whether there's an excuse for some new thinking on the subject of UI design, regardless of whether a cockpit is 3D or 2D. Here's what I propose - please be kind with your comments, I'm not trying to dictate terms or tread on anyone's toes: Flightgear (and any other flight sim) is trying to reproduce the experience of flying, both in terms of the flight dynamics and (to a limited extent) "the whole experience". As such, many of the instruments in the virtual cockpit can be configured with mouse-clicks on the instruments themselves. Some can also be configured through dialog boxes. If FG wants to try and model the "flight experience", these alternative dialog-box UIs must go. There are no pull-down menus on a real plane, and no dialog-boxes. Providing them therefore breaks the "flight experience". I'm not saying get rid of the menu-bar as such, because the menu bar has a valid raison d'etre in that it allows you to control aspects of the world outside that are not part of the flying experience. For instance, setting the weather, time of day, type of plane, lat, long and altitude of the plane. That sort of thing has to stay on the menus. Everything else (autopilot, comms and navigation radio settings etc) must go. Trouble is, as Steve comments above (and as caused me to get messed over by the Cessna autopilot fake dialog-box bug in the first place), you can't always read the virtual instruments on the 2D/3D cockpit on smaller screens. For instance I can't read the compass on my screen - the numbers are too small. I propose then that every single instrument on the cockpit has the ability to be double-clicked, and if so then a separate draggable window appears containing a magnified view of that same instrument. Obviously, it will be a *lot* easier to click on buttons and knobs on this magnified instrument, though some people with colossal screens won't need to bother and can carry on with the normal-size instruments. Being able to double-click the comms radio, click on the buttons to tune it and set it up will remove the need for the dialog-box option for setting it. Likewise the autopilot. The user will be able to choose to declutter his/her screen by dismissing the magnified instrument once they're done with it, The smaller version on the instrument panel will of course reflect the same information. Any time you want a closer look, you double-click again. In my case, I'd probably double-click the magnetic compass at takeoff time, drag it to a convenient corner and leave it here for the flight. At least I'd know where I was going! In my case, I'd expect to double-click the altimeter at takeoff time to adjust it for QNH, then dismiss it (I can read the altimeter OK on my screen anyway). The user would have the option to double-click *every* instrument on the panel of course - they'd end up with an awful lot of draggable windows and probably nowhere to put them all, but that's their choice. Users of 'gimp' will know what I mean by this sort of idea. Just my $0.04 Now just off to don fireproof suit Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Possible new thinking for 2D/3D cockpitinstruments
On Thu, 2005-12-01 at 11:52, Norman Vine wrote: > I agree that it would be nice to have all instruments etc have interactive > interfaces ala a mouse click, if that is at all realistic, but this does not > necessarily > mean that the dialog boxes should go. > [Flightgear has] a much broader vision then a first person experience of > flight !! > > So if you don't want to use the menu or dialog box interface don't > and they won't spoil your experience :-) > Agreed, but if we've got a better scheme, why keep the dialog boxes? Every disjoint aspect to the GUI is just another thing waiting to go wrong, as with the Cessna autopilot where the dialog box is invisibly disconnected from the real autopilot. Now, maybe if the autopilot dialog box was part of the "autopilot object" so to speak, then such a mistake couldn't happen, and I'd retract my complaint on those grounds at least. It would be neat if the instruments were objects in that way (I suspect they're not currently). If your airplane uses one, its instantiation code would to hook any dialog box interface that it may have into the list of things on a given menu, to start feeding polygons and textures reflecting its state to the OpenGL engine. Later, if that object sees a double-click on itself, it pops open a draggable, scalable window containing a photorealistic image of its front panel, maybe allowing clicks on that window to set its parameters. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
On Thu, 2005-12-01 at 11:56, Buchanan, Stuart wrote: > > I propose then that every single instrument on the cockpit has the > > ability to be double-clicked, and if so then a separate draggable window > > appears containing a magnified view of that same instrument. > Personally I think this is a fine idea, and indeed gets around the > challenge of having generic dialog boxes that don't match specific > instruments. I'm not sure whether it would need to be magnified, it would > be sufficient just to display them at "normal" resolution (e.g. 128X128 > for most round gauges, 256x60 (ish) for radio stacks). > On my screen I can just about read the round gauges and radios and can't read the compass (on the 3D Cessna). The 2D cockpit is much more legible. Hence the comment about magnification. > However, I don't know whether we can easily display the gauges in windows > by themselves - I'm not familiar with the graphics routines we have, but I > suspect that we are stuck with a single rendered window (as opposed to > dialogs created using GUI widgets), unless we want to take huge perf hits. > I was thinking of using the machine's underlying windows system for these popup per-instrument displays. So that would be GTK or similar on X-Windows and native MS Windows API on M$Windows machines. Alternatively, FlightGear could standardise on GTK for writing the things, and use the fact that there already are "GTK-on-M$Windows" and "GTK-on-MacOS" libraries out there that would take care of the platform-dependencies. > I think the main issue here is with the radios, GPS and autopilot. One > simple solution would be to create a "radio" panel for the plane > containing these components, the visibility of which could be toggled > either from the menu, or from a keypress. > I would leave the OpenGL engine to display the panel as it does now, but some instruments (at the users' discretion) may get duplicated in their draggable, scalable windows. > - The panel couldn't be dragged and dropped - though it could be shifted > using the normal controls. It could, if it was written to employ the ordinary windows-system windows, not be part of the OpenGL main display window. > - I don't think we'd be able to use the double-click idea, as that > normally causes two increments/decrements. > Double-click is normally detected as such really low down and doesn't normally get confused with two single-clicks. > - You can bind the key normally used for the radio dialog to displaying > this specific panel. > Indeed. And there's another possible plus side. There was a thread here a few weeks back about the serious flightsim-heads who like to build physical cockpits and have "real" instruments. Apparently, one way to get the effect of real instruments on a budget is to fit an LCD panel behind cutouts in a fascia plate and display the instruments on that LCD panel. Well, doing this gets a load easier if we've already written the code for every instrument to be able to render itself (magnified) in photo-realistic style in individual windows. The builder of a fake cockpit can then drag all the magnified instruments to wherever they're needed behind the cutouts in the fascia, and hey presto! Job done (pretty much). FlightGear would need to be able to remember at start-up how the user wants to display any instruments that have to start in this "windowed" mode: i.e their magnification (or window-size) and window location (X and Y coords on which physical screen). Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
On Thu, 2005-12-01 at 14:15, Josh Babcock wrote: > Just as a note, this functionality already exists. You can use the mouse > to look around and zoom in. Zoom in, click, zoom out. I do it all the time. > That's a very good trick (just tried it). Never thought of that one, and yes, I can even read the buttons on the autopilot by doing that. The only trouble with that approach is that you can't both look out of the window *and* read the autopilot without quite a few mouse-clicks and some x/X keypresses. I'll grant you that it does allow you read small buttons and things, it's a great workaround for my main gripe. > I also recognize that > there are a lot of people out there (myself included) that would much > rather use the keyboard, dialog box or pulldown menu. > > In short, It's all well and good to add a functionality, but talking > about taking away a functionality that someone wanted enough to go to > the trouble of creating is not productive. Yeah, OK. Several people have said the same thing now, so obviously the dialog-box option is regarded as a must-have. As you say, let's not throw out something that works. However, can the implementation be changed so that repeats of the autopilot snafu "can't happen"? I suggested in a different reply that maybe the "instrument object" should be in charge of all its related displays - whether that's the OpenGL one, the dialog box or (if it was accepted as a good idea) my separate pop-up window alternate-view idea. > If you don't like it, don't > use it. I get the message! (And I have no problems with that.) Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3Dcockpit instruments
On Thu, 2005-12-01 at 17:29, Curtis L. Olson wrote: > Norman Vine wrote: > >FlightGear is more then just a first person sim > >These other uses may have reasons to want > >dialog box displays. > > > >Again if you don't ike the dialog boxes don't use them > >but please do not advocate taking them away. > > > Norman isn't saying blindly keep dumb or broken stuff. What he is > saying is entirely compatible with a discussion about fixing bugs or > making the gui work better or be more intuitive or less confusing. > There is ample room for this sort of thing. Whoa! I get the message! The flameproof suit is burning through in places! I back off! Scrub the idea of getting rid of the dialog boxes, as you say they often are easier to use than the simulated "real instrument". Indeed, I was using the autopilot dialog partly for that reason when I tripped over the bug that started me off on this rant. See elsewhere for the "object orientated" instrument suggestions that should avoid repeats of the Cessna autopilot mess. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
On Thu, 2005-12-01 at 22:47, Josh Babcock wrote: > Steve Hosgood wrote: > Also, have you considered looking into OpenGC? It won't give you the > MSFS like functionality of dragable sub windows, but I think it would > allow you to make arbitrary windows to display instruments in cutouts. > I was deliberately thinking that you **don't** want to use OpenGL for that sort of thing. The GPU has enough work to do rendering the view out of the windows, it would be a waste of its time rendering instruments for the fascia - they're always going to be displayed "straight on" with flat lighting. It's just a simple animation job for a normal window. I see that a "cockpit building" discussion has kicked off in a parallel part of this thread... Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
On Thu, 2005-12-01 at 20:23, Curtis L. Olson wrote: > This is why all those oddball home/hobby cockpit builders aren't as far > off their rockers as it might first appear. They are taking a huge step > towards a more realistic simulation environment. Dead right. I'd never knock them - more like admire their enthusiasm. And as you say, an open source sim like FlightGear is much more likely to be able to interface to all these home-made instruments. > And I'm sure all these > people have spouses who understand the importance of a realistic flying > experience. > Yeah, right! :-) > having the flight model right exactly on, is less > important than having a full scale cockpit with controls that have the > right amount of force feedback at the right times. An enclosure is a > huge addition... Not sure about whether FlightGear currently allows for force feedback, but of course, if anyone's flight sim could do it, FlightGear could. Does FlightGear provide output data that would allow you to tip a cockpit on hydraulic rams (or any other system) to try and model changing G forces for the pilot? I've mentioned the possibility in other mails on this thread for a revamped future FlightGear instrument model to cater for separate windows (maybe on other display heads of course) which would help implement fascias using LCD panels behind cutouts. I'd have thought that the cockpit-builder types would be clamouring for such an addition, yet no-one's apparently all that enthusiastic. Do the current crop of cockpit builders happen to use real simulated physical instruments wired to USB or something? I read elsewhere that the 747 guys were simulating a glass cockpit, so maybe they didn't have any "physical instrument" scenarios to cope with. Hasn't anyone tried a cockpit-build for a WWII plane with FlightGear yet? Steve. BTW, nearly unrelated - one of the Discovery channels in the UK recently ran a documentary on recreating the Dambusters raid on the Ruhr in 1943. They had a (rather crude looking) mockup of a Lancaster bomber and a crew of modern RAF types who tried to simulate reproducing the raid. Whose flightsim was that? Unlikely to be FlightGear, unless the TV people commissioned their own Lancaster FDM. Did anyone apart from me see it? It looked like the instruments panel for the Lancaster was simulated with the old "lcd panel behind holes cut in plywood" trick. Actually, I'm not even sure they bothered with the plywood. They certainly didn't appear to bother with putting a skin on the fuselage of the fake plane - they just ran it in a darkened warehouse. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Autopilot (and more)
On Wed, 2005-11-30 at 20:25, Steve Knoblock wrote: > If an aircraft has its own autopilot, the default dialog > does not come up, but if it does not specify an autopilot, the default > dialog comes up. > Not quite. I've just discovered that the autopilot works(*) with the Colditz Glider! Let's see: a WWII escape glider built from floorboards and bedsheets and lacking *any* instruments apart from a yaw-string, does feature a fully-functioning autopilot! You've gotta take your hat off to those POW dudes On second thoughts, just possibly there's a bug here! We seriously need an item in the 'instruments' XML where a 'plane can request the default autopilot be available if: 1) The plane actually *has* an autopilot (**) and 2) The author doesn't want to bother with writing their own (yet). In the long term we could argue that the second case above isn't required - the dialog should only be available if the plane actually has an autopilot. In the case of the Cessna (and maybe others) where a "real" autopilot has been modelled, the dialog should be there, but set values in the "real" autopilot simulation. However, I'd suggest that the two-part test above be put in to sort out the most gratuitous ill effects in the current code *before* 1.0.0 comes out. Something similar should probably also be done for things like comms and nav radios (again, the Wright Flyer and Colditz Glider don't have them), in fact the *entire* "Equipment" menu item ought to be grayed-out for those two planes. All the gliders would want to disable the "Fuel Settings" dialog in that menu item. All historic craft would want to disable "GPS settings". Sheesh: there's a good bit of work to be done around here. The "systems failures" dialog box should only have boxes for systems that the plane in question actually has! The "altimeter settings" dialog should be greyed out on any plane that doesn't have an altimeter (Wright Flyer, Colditz Glider and the Hang Glider I suppose). Steve (*) "Velocity control using pitch" oscillates badly. Heading control is fine. (**) I suspect the FlightGear "1903 Wright Flyer" has autopilot too... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
On Fri, 2005-12-02 at 14:28, Josh Babcock wrote: > No, OpenGC > ^ > http://www.opengc.org/ > Oops. Sorry. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Autopilot (and more)
On Sat, 2005-12-03 at 20:32, Ampere K. Hardraade wrote: > How about disabling avionic functions by default unless the aircraft-set.xml > specifically demands them? > > Ampere > Sounds fine. Don't limit the control just to be true/false though: As you suggest, the avionics dialog boxes would be "enable=false" by default. Tthe aircraft's XML can enable the FG default dialog by selecting "enable=default". Later (in 1.2.x maybe) allow for "enable=custom" so that (amongst other things) the Cessna's KAP140 autopilot simulator can be extended to allow it to be controlled by dialog-box instead of clicking on the buttons. But that's for later. To fix this in time for 1.0.0, just the "false" and "default" options would be fine. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
