Re: [Flightgear-devel] FlightGear/PLIB/CVS: Enabling 3D Clouds results in Floating point interrupt (SIGFPE)
syd sandy wrote: View-Render Options-Enable 3D Clouds I'm getting a repeated printout saying: Floating point interrupt (SIGFPE), and FlightGear freezes. I've installed Simgear-plib (CVS as of yesterday), and FlightGear-Plib source, CVS as of yesterday. System is Linux, Suse 10.2, gcc (GCC) 4.1.2 20061115 (prerelease) Cheers, Durk Hi Durk , make sure the cloud cache and resolution aren't zero before enabling them Please (before 0.9.11-pre2), could someone slip in some code to the effect: if (cloud_cache == 0 || resolution == 0) grey_out_menu_item(View-Render Options-Enable3DClouds); :-) This is basic, basic GUI design stuff. We don't want FlightGear to appear on the interface hall of shame page now, do we? GUI design rule 1: If it doesn't work or is temporarily unavailable, grey it out. If rule 1 turns out to be confusing (not obvious to the user how to enable the greyed-out item, try the following: GUI design rule 1A: If it doesn't work and you can't or won't grey out the button, have the button pop up an explanation-dialog. I recall a similar situation months ago with the autopilot menu for the c172 that used to pop up a dialog but didn't do anything because that 'plane has its own autopilot controlled via the 3D cockpit. The latest c172 (and quite a few other 'planes) grey out the 'autopilot' menu with a bit of Nasal as I recall. Much better. Steve - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] youtube video
Stefan Seifert wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis Olson wrote: I've discovered that I really love the AN-2 and the new fly-by view mode! I've posted a youtube video of the FlightGear AN-2 landing at Ranger Creek, WA (taken with a cheesy digital camera pointed at my computer screen ...): But the jiggling and motion blur somehow adds to the realism of the video. Maybe we should integrate them in FG ;) Actually, I agree with that! I noticed the same thing and thought how much it added to the realism! Especially the last shot as the plane comes to a halt. Curtis, you really ought to pump the tires on that AN-2. They looked totally flat to me :-) Something I do notice though - if you do what Curtis did there and compose a video out of fly-by shots and nothing else, it gets *really* repetitive. Had a movie director shot that sequence with a real plane, he/she'd have intercut the fly-by shots with a few out of the pilot's window shots, a couple of closeups of the pilot's fact (OK, so we can't reasonably do that), and maybe some chase-plane shots. It's too late to go fiddling with it in time for 0.9.11, but maybe an idea for the future might be to rework fly-by as an option to a sort-of movie director playback mode which would allow a much more convincing (and less repetitive) move to be made. The current system certainly shows the possibilities of such a thing, and we've got out of the window and chase plane options already. It's just putting them together that's missing. Nice work by the fly-by author though. BTW - What happens if you fly a plane directly over the fly-by camera? - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] announcing star trek runabout shuttle and
Martin Spott wrote: Hi Stewart, Stewart Andreason wrote: I thought I was done, but you know how it goes. I thought of several ideas for improvements, and managed to write the code to do it. How would you define non-profit commercial use. Does your intention meet the demands of the GPLv2 ? Ignoring GPL issues for a moment (important though they may be), the entire concept of the Star Trek® Danube-Class® Landing Craft® is copyright© by Paramount Pictures® until about the year 2845 (assuming the US government manage to keep extending the terms as they have for the last 50 or so years). Is it safe for FG to include such a likely target for Paramount Pictures'® Copyright© Lawyers® (*)? It looks like a great model (from the screenshots) and probably would be nice eye candy and publicity for the FG project, but it could be a ticking bomb for us. I'm rather uneasy about it all Steve (*) Yes, I'm overdoing the ®'s and ©'s for effect :-) Have you ever read the blurb on offical ST merchandise? It's plastered with them - and tm too (which I don't seem to have a symbol for, otherwise I'd have abused that too!). - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT]: Range of radios
Just a resend of a failed posting from earlier: I (Steve Hosgood) wrote: Anders Gidenstam wrote: On Tue, 13 Feb 2007, Holger Wirtz wrote: I know that exact range answers are depending from more parameters than only the output power... What I need is a simple number which should describe the maximum range og a COM1. For example 5 km? oder 20 km??? Hi, I think VHF transmissions are mostly limited to line of sight unless something unusual is going on.. You're right, Anders though the tricky bit is modeling the interactions between radios fitted in different classes of 'plane. Which is what I believe Holger is trying to do here. I'm not an expert either - expect at least three more people to pounce on my maths below :-) Here goes anyway It might be easiest to use an analog of real world parameters to get this sort of thing working right. Transmitters are typically rated in watts, receiver sensitivity is typically given in uV. The power received by a receiver is proportional to the power of the transmitter and inversely proportional to the square of the distance. The *voltage* received (which is what you want to know) is proportional to the square-root of that, i.e proportional to the square root of the transmitter power and inversely proportional to the distance itself. I think. So, Holger, if you arrange that all radio transmission packets in FG/MP carry the transmitter's wattage and the location of the source, you can work out the straight-line distance from yourself (call it 'd'), and then do something like: pkt = get_packet(); d = sqrt(sqr(my_x - pkt-x) + sqr(my_y - pkt-y) + sqr(my_alt - pkt-alt)); if (sqrt(pkt-transmitter_power)/d my_receiver_sensitivity) /* I can't hear this guy */ chuck_packet(pkt); else decode_packet(pkt); This sort of thing would maybe allow ATC (who might have more sensitive radios) to hear people that the local Cessna pilots can't hear. And that might be quite realistic. To improve things, you might like to make sure that the straight-line distance 'd' between yourself and the transmitter does not get close to ground. You'd have to factor in curvature of the earth and any mountains if you wanted to get it right. If the straight line gets within a couple of wavelengths of ground, you start getting attenuation and multipath distortion and all sorts of stuff(*). For a first cut, ignore all that and just use 'd'! Notice also how you could arrange to degrade packets if they get received very close to your receiver's sensitivity (you could add noise, distortion etc) which again would add to realism. My code suggestion above just models an unrealistic sharp cutoff when the signal gets too weak, but IIRC aviation radio is AM deliberately because that's *not* how AM radio behaves as it nears the sensitivity limit. Steve. (*) The BBC (amongst others) have done a load of work in this area to do with predicting service-areas of radio and TV transmitters. Some of it is on the net. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release. Any timetable?
Heiko Schulz wrote: I mean not to stop the work on OSG - far from it! But if we want FlightGear and OSG to get better we need users - and we get them only with a next release. With OSG in the state it's in, we can't go testing it on the users. If we did, we won't *have* any users before too long! The currently version is a good one with very few bugs. There are much improvements done since april. For me important: framerates are stable, the helicopter fdm is more realistic than MSFS's, nice route manager (could be the cutting edge for a FMS)- every day I'm flying with FG I got more fun. I would vote for a next release - a pre-OSG release! ;-) Agreed, a release of all the things that are working, but for now at least, no OSG. I don't know what Curt uses as a metric for deciding if a new release should happen, but the time delay between the current 'stable' and the previous one was about two years - too long I'm sure. People out there start assuming that a project is *dead* if it doesn't release new versions within living memory! Having said that, getting a release together is hard work for the team. It shouldn't be done unless there's a good reason. Steve - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Small Bug in COM1 (Cessna C-172)?
Torsten Dreyer wrote: There seems to be a float/rounding issue somewhere in the property system. I noticed this too, when modeling the Seneca. I did some debugging and found that some values - probably 911.00 is one of these - are converted to a float of 910.9 so the display shows 910.99. Same with 700 (shows 699.99) 710 (shows 709.99) etc. Hmm - that's interesting. If the value had been stored as a float (or double) and printed with (say) %6.2f it should have been rounded off correctly. I suspect therefore that the radio display code has converted this value to an integer in 10Hz steps and failed to do its own rounding. So it's doing something like intfreq = (int)real_kHz * 100; or intfreq = (int)(real_kHz * 100.0); If real_kHz had been 910.99 as suggested, this would give 91099 as intfreq and yield the reported effect. What *should* have been done would be more like intfreq = (int)(real_kHz + 0.005) * 100; You can work around this issue by entering 911.001. But I think this is a bug that should be fixed. I try to look into this again in the next week. Torsten Hopefully, there's a clue or two above! I'd look for it myself, but don't have a set of sources on this machine. Steve. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terrain surface types...
Martin Spott wrote: You know, some people do it the other way round. Just a reminder, I guess this strip has already been mentioned elsewhere: http://foxtrot.mgras.net/bitmap/Wasserlandung_mit_Salto.mpeg Martin. That looks like a really expensive mistake! Just for interest - I know nothing much about seaplanes. What did the pilot do wrong? I'm guessing that the wheels should have been retracted really high (or inside the floats) and out of the way. Is that it? Steve - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Small Bug in COM1 (Cessna C-172)?
Steve Hosgood wrote: So it's doing something like intfreq = (int)real_kHz * 100; or intfreq = (int)(real_kHz * 100.0); Let's just catch my own bug before everyone else does :-) It's the second of those options of course. Steve - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Sailing Ships and Submarines (was Re: Tides in FlightGear?)
Oliver wrote: Maybe we could integrate code from the submarine simulation Danger of the Deep. They have allready very nice eye candy water effects. [...] If we think about this a little further perhaps they might be interested in a merge of both projects. Because even a submarine simulation needs airplanes in the air and nice coast lines with hills and buildings on the land that is visible from the sea. :) All of this applies to my earlier comments about tallships too. I'd not heard of Danger from the Deep before, it does indeed like a much better seascape simulator than FG currently offers. I suppose from FG's (and its users') POV, you have to ask is it worth having a better sea simulation? The argument for tides has been done, and is probably valid, plus it can be done with only a small change to the existing flat blue parking lot sea in FG. I suspect that another very small change to FG would stop ordinary aircraft landing on the water - it just becomes an automatic crash to come within a few metres of any body of water unless your landing gear includes floats. (Of course, FG currently doesn't have much of a concept of crashing...) Would incorporating a more realistic looking ocean contribute much to FG's flying experience considering it surely will reduce the achievable display frame rate? I can certainly understand the reverse idea - that DftD might like to adopt FG's world scenery to make its coastline approaches look more realistic (assuming they have a problem with that currently?). Steve. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sailing Ships (was Re: Tides in FlightGear?)
Martin Doege wrote: Hi Steve! Naval simulations are great, but if integrating tides into the present-day ocean in FG is such a big technical challenge as it seems to be, I would not think that a "real" ocean with rolling waves, reefs, bathymetry, etc. is right around the corner. I think you would want to have something like in Virtual Sailor or Silent Hunter III and that is simply far removed from the blue plane that is currently the sea in FG. Hi Martin. I'm not sure the tides issue is likely to be a "big technical challenge" actually. In the space of about 4 postings here, a workable scheme was proposed of colouring certain triangles "sea" or "mud" according to their datum heights as compared with a local simplified tideheight generator. I can provide the maths for a tideheight generator, the only "problem" is providing a suitable set of triangles (tagged with datum heights) in a known tidal area. Also, on a tile-by-tile basis, a set of (probably four) tidal vectors has to be given. The graphics engine needs to know how to do the colouring on-the-fly, but compared with the magic that the 3D experts on this project have already acheived, that'll be done in an evening as soon as someone sets out to do it! But in general naval simulations don't always need flashy graphics to be fun, so finding a good graphics engine is probably not so important at this point. I ws intimating that I don't have to find one - I've found it! Right here. :-) As with all simulations, what really makes them absorbing is the feeling of "being there", and while good graphics don't hurt, good gameplay matters more. For example, the submarine sim Red Storm Rising mostly had only tactical displays to look at that look about as boring as it gets, and yet it was an engaging game and the suspension of disbelief worked well. That's about what the current "surprise" program (windoze or linux) has. It's really just a wrapper around the "FDM" to let the "FDM" be used for something. So instead of hoping for great seascapes from FG/SimGear in the near (or not so near) future, I would first improve your existing "FDM", add the ocean, include navigation aids, etc. Stars, sun and a stopwatch. That's all you get! Ok. Ok, I'm joking of course. That's all you get in the 18th century, but if sailing ships worm their way into the FG world, they'll be usable in any timeframe. After all, tall ships are still with us in the 21st century. Cannons and a damage model should also be added since you are mentioning Hornblower. As in Sid Meier's Pirates!, the crew should also be simulated, [giant snip] Funny, you've just written almost exactly what I wrote to "The Admiral" (Peter Davis) last year. His comments were that he never planned to make a game of the sim - his sentiments in fact matched closely to those we hear all the time here on the FlightGear discussions group. It's to be an accurate sim first and foremost, but if people want to add guns/missiles etc then that's up to them. I talked about crew, crew morale etc. (I've been a penpaper RPG-er for a long time.) Same sort of response - basically, he (Davis) is only really interested in getting the sim to work well and would be disappointed to see the project "degenerate" into "just a game". Of course, done well then there's no reason why any of the additions you mention would degenerate the project - they should be seen as enhancements. Graphics could initially be fairly minimal, perhaps isometric view or 2D. Dovetailing into FG would allow 3D models from the start. I really don't want to have to build a custom isometric or 2D graphics engine just for "surprise". This would also give you time to develop a good interface. All your points are very valid - especially this one. Unlike aircraft, saling ships don't have a single "point of control". The nearest (in 18th century parlance) is "the quarterdeck" where the master or captain issues the orders, which then have to be relayed through several layers of middlemen to the grunts who pull the ropes. There is of course a "ship's wheel" but it's not a single point of control to compare with (say) an aircraft control column. Try it with "suprise". The ship's wheel does precious little unless the ship is moving at quite a lick. It's the set of the sails (especially the spanker) that really steers the thing. I would also use a higher-level language for faster development and improved flexibility. Python comes to mind and has the advantage that the existing BASIC code should be easily converted to it and that there is Libglade and pyGlade. It is also nicely modular and its sane implementation of object orientation as well as its use of generators are definite boons for simulations. At a later point, 3D graphics could be added if desired, e.g. via PyOpenGL or using code in C/C++. The existing code isn't BASIC, it's 'C' that looks like BASIC :-) As I stated before - Davis wrote the original in BASIC and ported it to 'C' many years
Re: [Flightgear-devel] Sailing Ships (was Re: Tides in FlightGear?)
Jim A wrote: All very good, and a great technical challenge. But, maybe a branch called FloatGear would be in order? ;-) I love it! Thanks - that made me smile first thing in the morning. then there are land vehicles -- for transportation, sport, and defenseDriveGear? Or TopGear (or IntoGear) :-) It would be cool to have the Nimitz (and others) respond to sea state, and the visual eye candy of the water to look appropriate to the sea state condition. These thoughts all seem daunting, but seeing what this community has accomplished thus far, it could very well happen. Indeed - however my suggestion would be that should the world-system of FG get used for things other than flight simulation, that it doesn't get branched. Branching just makes maintainance more difficult and breeds flamewars. It is probably best that people wanting to use FlightGear as a world engine for other things (like ship sims) just get on with it using the code as is, but keep talking on this list so that mainline code developers can try and avoid doing things that deliberately break those side-projects. Should something like a ship-sim become popular (and people have asked about ship sims on here before) then maybe its code might enter FG's CVS repository, just like a new flight-sim engine might. (There are at least three flight-sim engines in there already.) It might even happen that FlightGear code becomes three or more conceptual lumps, rather than the two is is now (SimGear FlightGear). SimGear is already starting to look like a great load of astronomy stuff could be broken out into - er - EphemGear? :-) I shall keep an interested eye on whatever improvements are suggested (and made) to the oceans in FG. The development people will probably already want to allow for things like aircraft carriers to behave more naturally - if they keep that in mind, hooking in a sailing ship later should be straightforward. Steve. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tides in FlightGear?
Durk Talsma wrote: Curtis L. Olson wrote: Martin Spott wrote: The triangles don't have to be changed at all because in our Scenery the tidal area is part of the ocean. The idea was about changing nothing but the colour, Ok, so you are only talking about areas that are marked explicitly as tidal areas in our land use/land cover data base, and then they would be either at full tide or no tide ... that's probably simpler to manage. Curt. I like the idea. Having some real-life experience flying over the wadden area that Martin (Doege) referred to, I can tell that the low tide areas can be very scenic. A change in texture would indeed suffice, because the elevation differences are almost negligable. Basically, you could model a tidal area as a triangle mesh (as detailed as you like) where the triangle type is tidal and each triangle also carries a parameter X which is the local tide-height at which that triangle is covered by water. A tide-calculator finds local tide-height in a slow-running background loop, and every iteration of that loop, all triangles where X tide-height are textured as water, otherwise as sand (or mud). What's nice about that approach is that you can model tidal reaches with whatever detail you want. It could just be tide in/tide out as suggested by Curt (above) or vastly complex, handling the water flows of mudflats like the wadden area or Mont St. Michel. I've been interested in tides for years, and although 'Xtide' has now appeared (which outdoes my efforts), I've been offering a tide calculator program on my website for years: see http://tallyho.bc.nu/~steve/tides.html The underlying maths is very much simplified compared with Xtide, but would be fine for Flightgear. Help yourselves if you want it! Steve. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Sailing Ships (was Re: Tides in FlightGear?)
Martin Doege wrote: By having the water as a separated mesh, we could finally simulate the plane-water interaction properly. I feel that this method would move us into the right direction. And since one of the major selling points of "Flight Simulator X" will be, at least according to the screenshots and trailers, the more realistic depiction of water in all its pixel shader-rendered glory, it would be great if the water in FG would also be a little more than just the big blue parking lot it is right now. :-) Martin D. If there's an interest in improving FG's handling of water, might it be good to take in the idea that maybe one day the FG engine could be used for sailing ship simulation too? After all, FG's already got the 3D graphics engine, world scenery and a weather engine. Add in a sailing ship simulator "FDM", and a proper concept of water (tides, currents, depths, waves, 50-ft sea monsters etc) and you'd have it. Last year, I discovered Peter Davis's Tallship simulator "surprise.exe" and made a partial port to linux. Davis's website (for the original windoze program) is: http://home.wxs.nl/~pdavis My RPMs of the linux port are here: ftp://tallyho.bc.nu/pub/steve/surprise/surprise-20030924-2.i386.rpm My port is nowhere near complete in terms of options and eye-candy, but it does run. Mine only simulates the three-masted frigate (the original does that plus a two-masted brig). Mine doesn't have the "map" display nor any concept of land. The original modelled some "islands" to provide some entertainment trying to navigate. Mine doesn't yet show the "thrusts" diagram which tells you what forces are being provided by which sails. Mine doesn't yet have configurable weather, the original does. Porting it required me to tease out the "FDM" for Davis's ship simulator - it had been somewhat intertwined with the calls to the windoze API needed for his GUI. My version uses his "FDM" but with the GUI implemented with "Glade", the GTK+ GUI writer. I was actually using the project to teach myself Glade. Funnily enough, Peter Davis taught himself Visual Basic (and later Visual C) in order to write his ship-sim in the first place. His inexperience with computer programming does show in the code (along with its rather BASIC-like layout due to its heritage), but it does at least work. I've seen various people post queries about ship simulators on this list before, all to no avail. See here for a (commercial) 3D model of an 18th century frigate: http://www.turbosquid.com/FullPreview/Index.cfm/ID/240860/Action/FullPreview FG can't use this (obviously) but the FG project's got quite a few excellent 3D modeller experts in need of a challenge :-) If you get the "The Making of Hornblower" book that went with the UK's "Carlton TV" dramatisation of Forrester's books, then on the inner cover flysheets and the centre-spread there's a reproduction of a set of technical drawings for the "Grand Turk" (the ship used in the TV series, and used in the BBC's "Longitude" TV programme). To answer one obvious comment before it happens: yes, Peter Davis's source code (and my existing work on a linux port) are all GPL! I asked Davis last year if he would consider some sort of formal licence for his work, and he GPL-ed it last August. Steve ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tides in FlightGear?
Martin Doege wrote: Of course the tide calculations would not be required to be extremely accurate à la xtide -- the hour angle of the Moon would probably be quite sufficient as a broad indication of tide. It would have to be slightly more than just that. At the very least, you'd need a delay-factor for the local hour-angle of the moon. Also an amplitude-factor. Even then, you'd sometimes get the tide happening about an hour displaced from reality due to the loss of the solar tide. If you added a simple solar tide (i.e a delay factor for the local solar hour-angle and a solar-tide amplitude-factor) then you'd probably be getting a pretty good rough approximation for a given area. Good enough for a flight-sim, certainly. It would also better model those areas of the world where the solar tide dominates and there's only one significant tide per day. Steve --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid7521bid$8729dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frames of Reference in jsbsim
Dave Culp wrote: But it doesn't. Seems like an oversight to me. I'm trying to model a 'plane with almost no dihedral AFAICS and I'm not sure what to twiddle in the .xml file to get that effect. My advice is don't worry about it. Is there something about the way the Colditz Glider is flying that doesn't seem right? Yeah - it flies too well! It's got almost no dihedral, so I'd expect it to be pretty unstable in roll. Having said that, and though I've never flown anything other than a hang-glider for real, I find the c172 to be rather *too* unstable in roll for my liking. It's not obvious to me (yet) how the effects of dihedral are handled in jsbsim, so it's not easy to experiment with changes in those values. Steve.
Re: [Flightgear-devel] FGLive 0.1 alpha available for testing
Martin Spott wrote: Stefan Seifert wrote: That may be a problem, that could affect FGLive, too: http://trends.newsforge.com/article.pl?sid=06/05/15/1451229from=rss Well, you never know which intention sits behind the mentioned EMail, you don't even know the author. Bear in mind that Bill Gates or Steve Ballmer would be credible candidates for authorship of something like this. Look what it's done already - closed down a potential competitor to M$... Maybe it's just a 'symptom', a side-effect of the fight about the Right Way (TM) on how to use OpenGL for desktop eye candy, probably driven by jealousy ?!? There's been a Slashdot thread covering this at: http://linux.slashdot.org/article.pl?sid=06/05/14/2059242 I suggest you read at +2 or better to filter out the worst of the loonies, but opinions on Slashdot are clearly divided between the "linux must never be distributed on the same medium as any non-GPL code" camp versus the "nothing wrong - binary drivers aren't part of the kernel itself, they just use it" camp. My opinion sides with the latter. Steve.
Re: [Flightgear-devel] Frames of Reference in jsbsim
Dave Culp wrote: On Thursday 11 May 2006 11:08 am, Steve Hosgood wrote: Deriving the parameters like "yaw moment due to beta" and other such magic numbers from physical parameters is going to be pretty non-trivial. You can use "common numbers" from some hard to find sources. To get fancy you can use DATCOM+ to calculate them. Hence the existance of Aeromatic I presume. Yes, that takes the pain out of getting a good first cut at a config file. You can tweak stuff afterwards. Tell you what: a "tweaker's guide" would be a useful document! For instance, how do you tweak the output of Aeromatic to model the fact that your aircraft (Colditz Glider in my case) has almost no dihedral on the main wing. Look at it this way. The process of getting an FDM to model a particular aircraft can be broken down into 3 steps: 1) define the airplane parts 2) define the effects of the airplane parts 3) render the airplane state during simulation Using YASim you do step 1, and YASim does steps 2 and 3. Using JSBSim you do steps 1 and 2, and JSBSim does step 3. The two methods each have their own advantages. Now that you've pointed it out, I can see the relative merits of both routes. I have no argument with jsbsim's methodology, just a slight misunderstanding to do with just how much the physical model is "missing" from jsbsim's .xml files! However, it doesn't seem possible to specify the things I was griping about to Aeromatic (wing incidence, dihedral, vertical dispacement of rudder w.r.t centerline etc). You don't specify the measurements, you specify the effects. (Except wing incidence). What I meant was, regardless that most of the physical measurements are missing from jsbsim's .xml files, **Aeromatic** should have a way of specifying them so that it can produce the right "magic" coefficients. Yet it doesn't. Aeromatic is good at what it does, but would be nice it it handled some of the other possible physical parameters of a basic aircraft. Dihedral and wing incidence would seem obvious ones. Steve. Steve.
Re: [Flightgear-devel] FGLive 0.1 alpha available for testing
Arnt Karlsen wrote: ..we do have the right to distribute the GPL ati and radeon drivers under the GPL. Yeah, but they suck in comparison with the binary drivers. There's no 3D acceleration. This is a very strong reason Nvidea would consider honoring our question to distribute their proprietary binary drivers favorably, or watch ATI get all the FGLive business on GPL drivers. ..we need only ask them, and then ATI, and in that sequence. ;o) I don't think the problem was ever with Nvidia or ATI. Specifically asking their permission might be polite but other people package those binary drivers in convenient ways (like in RPMs) and don't run into trouble. The trouble is that some random troller emailed Kororaa (who also do a LiveCD thing) claiming that GPL prohibits distributing proprietary binary drivers with a linux kernel. Opinions are (to say the least) divided. Kororaa has, temporarily, withdrawn their LiveCD. The scare is that FGLive would run into the same problem with the GPL. Reading slashdot, you get the impression that the you can't distribute camp are arguing from a purely idealistic point of view in which they claim that all software should be free and that free software cannot co-exist with proprietary software on the same planet. The other camp is actually reading the words of the GPL which don't seem to prohibit anything being proprietary, just that it can't be *linked in* to GPL software. Drivers aren't linked in, they're dynamically loaded when needed, and in the case of the 3D drivers, the shim that interfaces to the kernel calls to let that happen *is* GPL and sourcecode is distributed for it. Seems like a no-brainer to me, but IANAL. Steve. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGLive 0.1 alpha available for testing
Martin Spott wrote: Steve Hosgood wrote: Martin Spott wrote: Maybe it's just a 'symptom', a side-effect of the fight about the Right Way (TM) on how to use OpenGL for desktop eye candy, probably driven by jealousy ?!? There's been a Slashdot thread covering this at: http://linux.slashdot.org/article.pl?sid=06/05/14/2059242 Well, I didn't find anything new in this thread... Sorry - I didn't say it contained anything new, just that it existed. actually it consists of statements that are being repeated for months or years now Yeah - it isn't like this hasn't happened before, but I must admit I'd thought the situation had been resolved ages ago. I.e. it is OK to have a proprietary plug-in to GPL-ed software as long as it is indeed a plug-in, not compiled in. Loadable device drivers would count as a "plug-in". Obviously. Look at things like Xine and Mplayer, the DVD and media players. They use plugins all the time (many of them intended to work on M$ Windows), and there's never been a fuss about distributing Xine or Mplayer. There has been a fuss about acquiring some of the plugins that were intended for use with M$ Windows, but that was down to copyright and licencing issues from the authors of the plugins. The FGLive CD doesn't have that problem because the copyright holders of the 3D drivers are OK about redistribution. - and finally the thread doesn't give any insight into the motivation behind this EMail that has been cited. Ah yes, trouble is you'll probably never know that bit. It could be M$ themselves spreading FUD (wouldn't be the first time) and it could just be some loser 15 yr old idealist doing some trolling. Steve.
Re: [Flightgear-devel] Frames of Reference in jsbsim
Jon S. Berndt wrote: I just *know* I'm going to get totally flamed for this, but can someone please tell me how the CG, Eyepoint, AERORP and VRP are interconnected? Yeah, I know - RTFM. I'd say that, but there really isn't much of one, yet! :-( You won't get flamed. It's not the easiest concept to figure out. Before I say anything, I'd like to commend you Jon, along with Dave Culp and Erik Hofman for your three replies to my original question. *None* of you flamed me or anyone else, and answered pretty much all my questions really neatly. As you say, Jon, there isn't much of a manual (yet) and discussions like this in the archives are often the next best thing. Maybe you (as prime author of jsbsim) and the other guys could clear up one or two associated questions for me please? Issue 1, Vol1 of the Quarterly Newsletter states that the sim tracks an aircraft by its CG. >From the replies I've read so far then it would appear that Issue 1, Vol 1 meant to say "jsbsim tracks the stated CG of the empty airframe". That makes a lot more sense as the article then goes on to say that the actual flying CG of a plane isn't a useful reference because it moves. Do you confirm that the "AERORP" is the point from which the "tail arm" and "rudder arm" are referenced? Since it doesn't seem possible to specify a "wing arm", do I assume that the "AERORP" must be sited at the 0.25 chord point of the main wing? Since it is largely the relative positions of various points on the aircraft which matter most, it's somewhat arbitrary how the "base" coordinate system is defined. The XYZ points in the JSBSim config file are specified relative to a coordinate system that has its X axis pointing backwards, the Y axis pointing out the right side of the aircraft, and the Z axis pointing upwards. The origin of the coordinate frame could be anywhere, but it is usually out ahead of the aircraft, and often the X axis is coincident with the aircraft centerline. This is the "structural frame" as defined by some aircraft manufacturers. It is fixed in the aircraft for all time. OK. One thing I've noticed about the aircraft.xml file (both the new version and the old) is that the "metrics" section (describing the physical layout of the plane) is rather "lightweight" compared with the vast other parts of the file that can provide lift and drag and stall characteristics of the airfoil. However (and you're probably going to prove me wrong pretty quick here) it seems that the metrics section merely lists the span and width (or area) of the main wing and the same things for the horizontal stabilizer on the tail, along with the "tail arm" length. Also the rudder dimensions and "rudder arm". There doesn't seem to be any way to specify dihedral (of the wing or of the horizontal stabilizer), or that the horizontal stabilizer airfoil isn't necessarily the same as the main wing airfoil. There doesn't seem to be any way to specify the angle of the wing chord w.r.t the aircraft centerline, or the angle of the horizontal stabilizer chord w.r.t the aircraft centerline. This comes back to my original question about orientation of the X axis. I know it runs "nose to tail" but without a way so specify the wing chord you could end up with a plane that flies rather nose up or nose down. Similarly, there doesn't seem to be a way to specify where the centre of lift of the rudder is placed vertically off the aircraft centerline. Most planes have the rudder above the centerline, and surely that generates a rolling moment on the plane when the rudder is moved? You'd seem to need some concept of "rudder vertical arm" to deal with that, but if there is one then I (for one) don't know about it. Don't feel bad about "interrogating". If you have questions, please feel free to ask either here or in the JSBSim list. Let us know if the above does not answer your question. Best regards, Jon Jsbsim is a fine bit of work, Jon. Just trying to make up for a slight lack of definitive manuals, that's all! Steve.
[Flightgear-devel] Frames of Reference in jsbsim
I just *know* I'm going to get totally flamed for this, but can someone please tell me how the CG, Eyepoint, AERORP and VRP are interconnected? Yeah, I know - RTFM. Trouble is, I think I did R the FM (there was an article by Jon S. Berndt himself in Issue 1, Vol1 of the Quarterly Newsletter) but it didn't seem to answer the following questions. For that matter ISTR that this same issue came up here a while back, but I can't find it in the mailiing-list archives. Here goes. Issue 1, Vol1 of the Quarterly Newsletter states that the sim tracks an aircraft by its CG. However, it then goes on to state that CG isn't a useful datum for a frame of reference because it can move (as, for instance, when fuel is used up). Indeed, CG gets specified in the aircraft .xml file as having an [X,Y,Z] location, and evidently this [X,Y,Z] is using some other point on the aircraft as datum. Where is this other point? Just some arbitrary convenient point? Presumably not the aerodynamic reference point, since it looks like that also gets specified with an [X,Y,Z] coordinate in the setting of AERORP. Is the AERORP the point about which the tail arm is referenced? Where should the AERORP be placed w.r.t the wing? Is there a concept of wing arm to match the concept of tail arm? I think I know what the eyepoint is :-). It is specified with an [X,Y,Z] too, but in what coordinate frame? Likewise the VRP. This is the location of the reference point of the 3D model isn't it? Again, from what point is the VRP's [X,Y,Z] measured from? Then there's the semi-unrelated question of the X axis. Increasing aftwards it says, but along what axis of aftwards are we speaking? Is it parallel (say) to the chord of the main wing or what? Finally, back to CG again. Do I assume the the CG that is specified with an [X,Y,Z] coordinate refers just to the CG of the airframe itself? Issue 1, Vol1 of the Quarterly Newsletter states (quite rightly) that the actual CG of a plane moves during flight duration as the fuel is used up, but I assume that this is why you can specify tank locations and fuel weights and rates of fuel usage. So the actual flying CG of a plane isn't where you set CG? Sorry about the interrogation, but I've realised that I seriously don't know what I'm doing in the .xml file department here! Thanks in advance for any insights. Steve. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flightgear/FlightGearSDL-0.9.10-0.FC.i386.rpm failing on FC5
Some time back, andy wrote: Hi I posted earlier today a msg on the user list about issues with running fgfs on FC5 (c enclosed copy) . After a little more research I found the development list thread about FC5 and the freeglut 2.4. So I tried the following rpm flightgear/FlightGearSDL-0.9.10-0.FC.i386.rpm ftp://tallyho.bc.nu/pub/steve/flightgear/FlightGearSDL-0.9.10-0.FC.i386.rpm This FlightGearSDL RPM *still* hasn't managed to get on the mirrors. If there's no worry about it working (apparently it does) could someone copy the above link off my rather slow machine onto the mirrors for everyone's benefit please? Thanks in advance. Steve. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Colditz Glider woes
I've just been reworking the FDM of my Colditz Escape Glider to get it to work with 0.9.10 and the new JSBSim .xml format. So far so good, but 1) How do I get the 'autopilot' menu item to grey out and go away please? I've tried studying the c172p and conclude that it does it by specifying its own autopilot which automagically greys out the default one. I don't want one at all. How to do that please? 2) If I dive the colditz glider vertically down it manages to hold this vertical flight until it hits the ground. Two problems ... 2a) I reckon it ought to try and pull out of the dive as the lift over the wings increases. I assume that the JSBsim applies a torque due to wing lift about the claimed CG of the 'plane, and if so then I need to have my CG behind the wing root somewhere. Presumably I've not got it far enough behind. Does this sound like a likely cause of excessively easy vertical dive? Needless to say, without a real Colditz Glider to measure, I'm having to estimate the position of CG. 2b) The Colditz Glider in vertical dive mode (see above) manages to achieve about mach 6 (:-)). I tried fiddling with drag due to mach in the .xml file to try and limit the terminal velocity, but it doesn't seem to do much. A human being in freefall manages about 120mph (190km/h) apparently, and I'm not sure I'd expect a crude wood and fabric airplane to do much more than that. What's the right way to model drag due to velocity? Thanks in advance for any clues. Steve --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flightgear/FlightGearSDL-0.9.10-0.FC.i386.rpm failing on FC5
Curtis L. Olson wrote: It should start propogating now. Sorry for the delay. I've had zero spare time to devote to FG in the last couple weeks due to my job situation. Hopefully this will begin to return to normal by the end of May. Curt. Thanks, Curt. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: FlightGear RPMs (was Re: [Flightgear-devel] FC2 .rpm)
Steve Hosgood wrote: Curtis L. Olson wrote: My vote is to build it with sdl. For 99.9% of the people out there, sdl will work just fine and they won't be able to tell the difference, and for the other 0.1%, freeglut won't work anyways because they never actually implimented glut's game mode. Curt. SDL is indeed shipped with FC5, but punters would have to load their own from http://www.libsdl.org/ if they want to run FlightGear with SDL on a Fedora Core earlier than that. I have now got a Fedora Core 4 RPM of FlightGear compiled with SDL rather than freeglut. It will run on FC5 too (I think). I'd appreciate if anyone out there with FC5 would load it and give it a test. It's called FlightGearSDL and is on the same FTP site as my other 0.9.10 offerings: ftp://tallyho.bc.nu/pub/steve/flightgear/FlightGearSDL-0.9.10-0.FC.i386.rpm Please would all the mirror-site operators grab a copy? It would be useful if the FlightGear website download page points out that: FC2 people have to run the freeglut version. FC3 people have to run the freeglut version. FC4 people can run either (but will have to get a copy of the SDL RPM from the FC4 updates site if they want to run the SDL version). FC5 people can only run the SDL version due to trouble with freeglut 2.4 SRPMs coming soon. Thanks in Advance. Steve --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
FlightGear RPMs (was Re: [Flightgear-devel] FC2 .rpm)
Folks: There is a 0.9.10 version of FlightGear and SimGear in RPM form suitable for Fedora Core 2,3,4 on: ftp://tallyho.bc.nu/pub/steve/flightgear/ Would the main FlightGear site maintainers (and mirror-site managers) please grab these and throw them in the existing "RPMs for Fedora Core" directory ASAP? You could replace the 0.9.9 versions or keep them "just in case". These RPMs require the openal-* and plib-* RPMs that are already on the download site. Please hand-delete "simgear-0.3.7-1grk.i386.rpm" that is *still* lying around and probably confusing everyone! Please also flag the fact that we've still got an issue with Fedora Core 5. This is because FC5 ships with freeglut 2.4 and there's a bug in that version that kills FlightGear. I'm working on it, but I'm either going to have to compile with the SDL option to replace freeglut for FC5 or make the RPM specifically require freeglut version 2.2, and ship a special "freeglut22" RPM to provide such a thing on FC5. Trouble is, I'm not running FC5 (yet). Decisions, decisions. I'm just snowed under right at the moment. Steve
Re: FlightGear RPMs (was Re: [Flightgear-devel] FC2 .rpm)
Curtis L. Olson wrote: My vote is to build it with sdl. For 99.9% of the people out there, sdl will work just fine and they won't be able to tell the difference, and for the other 0.1%, freeglut won't work anyways because they never actually implimented glut's game mode. Curt. SDL is indeed shipped with FC5, but punters would have to load their own from http://www.libsdl.org/ if they want to run FlightGear with SDL on a Fedora Core earlier than that. Currently I'm working on the idea of having the RPM as you see it for FC2,3,4 and a different one for FC5. I'll have to compile on FC4 though, so I suppose that will leave FC4 people able to load and run either. Please mirror the existing compiled-with-freeglut RPMs for now, and I'll attack the SDL variant as soon as I can. BTW, I guess you'll be wanting the source RPMs for 0.9.10 on the website too - I'll stick them on my FTP server probably about the same time I announce the SDL binary RPM. Steve --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Me262
Martin Spott wrote: I just recieved these photographs from a collague at Eurocopter. Subject of his EMail was: today the First Flight in Manching / Germany http://document.ihg.uni-duisburg.de/bitmap/FGFS/Me_20262-1.jpg http://document.ihg.uni-duisburg.de/bitmap/FGFS/Me_20262-2.jpg http://document.ihg.uni-duisburg.de/bitmap/FGFS/Me_20262-3.jpg http://document.ihg.uni-duisburg.de/bitmap/FGFS/Me_20262-4.jpg Enjoy, Martin. Amazing isn't it? You forget just how good Agfacolor was, even in the 1940's. I take it the photos must have been color corrected or something because there's no scratches or fading or anything. Those photos could have been taken yesterday if it wasn't for the fact that there - are --- no --- ME262's -- still -- flying. D'Oh! Steve --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Use of old maps
David Luff wrote: Steve Hosgood writes: My only comment is just that 1937 maps will certainly be before the National Grid was adopted, and will be based on the "old triangulation" done between the late 1700's to mid 1800's. I don't know the details, but it wasn't metric (possibly surveyed in "survey chains" or thousands of yards or royal Babylonian cubits). The first OS maps based on the "new triangulation" (which was metric), and with the now-familiar National Grid didn't appear to the public until after WWII. Whether or not you can get an "old survey" map to line up with a "new survey" map (or even with reality!) is not obvious. I'm not even sure if the mapping projection of the pre WWII maps is the same as today's (i.e Transverse Mercator based on the "Airy 1830" spheroid). It certainly isn't WGS84 which IIRC is what FG's terrain is based on. Hmm, I've got a feeling that the 36 in OSGB36 might refer to 1936, in which case you are probably right - post-war maps should be OK - I've got no problem converting to and from WGS84 == OSGB36. It seems that 1" maps from the 7th series in the mid fifties to early sixties are fairly widely available - I guess that these are probably the best to go for at the moment. I will look out for one to a hilly area to try as a proof-of-concept. Check out: http://en.wikipedia.org/wiki/OSGB36 You are right: the "36" refers to 1936, the date that they created the "OSGB36" datum, but the underlying spheroid is still the 1830 Airy Spheroid, used by the earlier survey. However, the 1936 resurvey was done with technology 100 years advanced from the original survey, and was way more accurate. They brought in the trig points, still familiar to hill walkers today, and introduced the National Grid and had the foresight to do it all in metric - still regarded as rather an alien concept back then. Regarding the rest of the thread - yes, the OS jealously guards copyright in the UK. Other agencies are just as bad - it was very difficult to find online tide tables for dates in the future last time I looked. Try "xtide". There is (allegedly) a port called "wxtide32" for windoze people.
Re: [Flightgear-devel] Use of old maps
David Luff wrote: Hi folks, I happened to come across the following ebay item whilst looking for a map which caught my eye: http://cgi.ebay.co.uk/1937-Ordnance-Survey-Map-42-Llandudno-and-Denbigh_W0QQitemZ8403614581QQcategoryZ121824QQrdZ1QQcmdZViewItem It's a 1937 OS map to a reasonably hilly area of the UK, and appears to have quite detailed contours. All the information I can find suggests that Crown Copyright persists in OS products for 50 years from the date of publication, suggesting that it might be possible to extract freely usable elevation data from such maps, admittedly not up-to-date but likely to be much denser than the 3-arcsec SRTM. Does anyone see any major flaws in this line of thought? Cheers - Dave My only comment is just that 1937 maps will certainly be before the National Grid was adopted, and will be based on the old triangulation done between the late 1700's to mid 1800's. I don't know the details, but it wasn't metric (possibly surveyed in survey chains or thousands of yards or royal Babylonian cubits). The first OS maps based on the new triangulation (which was metric), and with the now-familiar National Grid didn't appear to the public until after WWII. Whether or not you can get an old survey map to line up with a new survey map (or even with reality!) is not obvious. I'm not even sure if the mapping projection of the pre WWII maps is the same as today's (i.e Transverse Mercator based on the Airy 1830 spheroid). It certainly isn't WGS84 which IIRC is what FG's terrain is based on. Steve. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FC2 .rpm on FlightGear website being distributed with freeglut 2.4!
Chris Metzler wrote: Hi. We had a Fedora Core user come into the IRC channel tonight, unable to get FG to run without crashing. He'd downloaded the 0.9.9 rpm from the links provided on the FlightGear website. It turns out that that .rpm is built against, and distributes, freeglut 2.4; so it crashes with the usual freeglut (fgfs) : Failed to create cursor freeglut ERROR: Function glutSetCursor called without first calling 'glutinit' errors. If we're imminently releasing 0.9.10, it'd be good to avoid the same issue with the new release. -c Thanks for the comment Chris. I wrote the RPMs for the 0.9.8 and 0.9.9 linux releases on the main server (and am therefore the de facto maintainer of them :-( ). I was planning on doing 0.9.10 as soon as I can. I hadn't been aware of any troubles with the existing 0.9.9 though. I tested 0.9.9 on FC2 and FC4 before releasing and it all seemed OK then. I tend to run FG at home on my FC2 machine - my work machine doesn't currently have the Nvidia drivers installed for its antique Quadra card. Freeglut is not distributed by the Flightgear RPMs, though Flightgear RPMs obviously requires it. I've got bog standard FC4 and freeglut 2.2.0-16 on my work machine for instance, no sign of freeglut 2.4... Flightgear RPM doesn't insist on any particular version of freeglut BTW, just whatever is available. What's the fix? Insist on only a certain version of Freeglut? Thanks in advance. Steve Hosgood. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FC2 .rpm on FlightGear website being distributed with freeglut 2.4!
Chris Metzler wrote: I've got bog standard FC4 and freeglut 2.2.0-16 on my work machine for instance, no sign of freeglut 2.4... He was on FC5; maybe they're distributing freeglut 2.4 at this point. Quite right, they are. Annoyingly, they don't seem to be distributing "freeglut22" which would be the specific version 2.2 freeglut. Some other RPMs are done this sort of way, just to allow certain programs to continue using an old version of a library. Flightgear RPM doesn't insist on any particular version of freeglut BTW, just whatever is available. What's the fix? Insist on only a certain version of Freeglut? Yeah. Or go the SDL route. I take it we can't just fix FG to call freeglut's 'init()' routine as requested? The problem is that when people try it and it crashes in this fashion, the majority aren't going to react with "oh wow, freeglut must be buggy." They're going to think the problem is with FG. It sucks, but that's reality. Agreed. The advantage of the SDL route, I guess, is that if you demand freeglut 2.4, there's a chance of a conflict if they have something else installed which requires freeglut = 2.4. As I indicated earlier, the "right way" to do this sort of thing on RPM-ed machines is usually to have a special package called (say) 'freeglut22' providing such a thing. Then it doesn't conflict with 'freeglut' which may also be installed. Such a thing doesn't seem to be available on FC5 currently. We could provide one I suppose, or like you say, use SDL instead. Steve
Re: [Flightgear-devel] Version 9.9 improvements
On Fri, 2006-01-06 at 19:53, Drew wrote: Also, what are the major differences between the scenery of 0.9.8 and 0.9.9? Will the 0.9.9 scenery work with version 0.9.8 of FlightGear? I asked this same question before Christmas and got no answer. So I tried it to see what happened. It works just fine. Curt is working on some proper 0.9.9 scenery, but evidently 0.9.8 is still compatible. Steve --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
