Re: [Flightgear-devel] status of aircraft carrier
On Mittwoch 20 Oktober 2004 09:49, Vivian Meazza wrote: We calculated the output in geodetic terms (lat/long/alt) for submodels so that they could be displayed, and it's no problem to output in x,y,z aircraft terms. It didn't seem to be expensive computationally. Further, lat/long/alt was the easiest to get at for the aircraft location. I think that I'll need some help here with the necessary conversion factors. I'll look into it further. The problem is that those values are in geodetic lat/lon. The underlying transform to an elliptical coordinate space is done in sgCartToGeod in SimGear/simgear/math/sg_geodesy.cxx. There is also a paper about this stuff floating around. But it is sufficient to know that this transform is significantly more expensive than doing a scalar times vector. Do we need ground reactions as an intrinsic part of this code? Although I can see that it might represent an opportunity to improve the current situation. I think so. I cannot see a way to model the earths surface with different properties like runnway/grass/water with load factor. Moving and rotating triangles for the ac carriers deck, and special elements like the wires/catapults. Ok, this can be put into the property tree as we have a structure broken out into scalar values. But I guess that this provides a huge overhead for that stuff. If you do serious computatiions with those values you will need to transform them back into structs/classes/whatever. Good, let's go for it. Ok, yesterday evening I did that hierarchical boundingbox stuff. It looks very hackish at the moment and I first need to seperate out some stuff also in that experimental tree before I can send you what I have. I hope to get that done today evening ... I can taxi on slopes and get all surfaces/lines in an ball aroung the aircraft. So If you can think about, how we can inject our preliminary wire area into the scenegraph, we will be some step ahead. :) I thought about using normal ssgLeafs for such a thing with some special information that this is a wire area stored in the UserData field of ssgBase. Really, modelling individual wires with lines is also not a big deal. So If we could inject individual wires every 5 meters on the whole KSFO runway (I am not a good pilot for testing ... :) we can start with that. A word for testing if a wire is caught: The hook (think of it as a line) has a position before the integration step. Past integration, it has a new position. The rectangle spanned by those two lines is the area where the hook was during that integration step. If a wire line intersects this rectangle, we have cought that wire (when we assume for now and testing, that we catch every wire we touch). I'll get on with seeing if I can provide hook position - we would be well under way with that. I think this would be a worthwhile activity since we seem to have most of the bits almost in place. Yep this hook position is also something we will need. As I told, best in (double valued) cartesian coordinates relative to the earth's center. greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] status of aircraft carrier
On Mittwoch 20 Oktober 2004 18:11, Vivian Meazza wrote: It would be easy to convert to X,Y,Z coordinates, if I knew the equations (I have suitable equations for ft to degrees lat/long) or, better, I could start in X,Y,Z. Start with X/Y/Z ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
On Wed, 20 Oct 2004 11:12:11 +0100 David Luff [EMAIL PROTECTED] wrote: On 10/19/04 at 11:57 AM Chris Metzler wrote: Well, I guess we'll find out eventually. Converters are easy to write, if somewhat tedious. The current X-Plane format contains a flag indicating whether to include runway distance remaining signs or not, so the change to it should be good for you in that respect. Yeah, I'd read his specification before, and I don't know how I didn't notice that in there before you pointed it out. I can be pretty oblivious sometimes. It'd be really nice if info was provided on the *method* used to place the signs (there are three FAA standards for how to lay them out; I presume things are similar to one or more of them elsewhere than the U.S., but really have no idea). I think that your idea to put a taxiway designator in the 'xxx' (bet this message gets flagged as spam now!) HA. part of the record is an excellent one. The downside of course is that it would require X-Plane itself to understand it before it could be applied to the master dataset. Well, yes and no. We could collect this data, but not include it in the upstream updates until they do have the ability either to understand it or to at least ignore it when it's present (that is, they could consider anything other than xxx as xxx). On the other hand, genapts could be made to understand it as an extension to the default format. And in the short term, similar to above, genapts could be made to simply ignore that field -- it shouldn't need it now anyway since the T identifier in the first column of the record in runways.dat identifies the record as referring to a taxiway. The xxx isn't used for anything, is it? So it should be harmless to put info there; if genapts really does care about what's in that field, I'd naively think it wouldn't be too hard to just have it ignore that field for now. Then we could collect this data as we get it. And if as you say the X-Plane format is likely to contain it soon then that's excellent. Well, I dunno what soon is; you know how this can go. Robin Peel says: } Enhancements to the X-Plane airport and nav-aid data that are currently } under development (and to be available in X-Plane 7.x or 8.x) include: } [ snip ] } } * Completely revised airport data file (apt.dat) that will allow many } new features, such as smoothly-curved taxiways, polygonal aprons, } airport boundary fences, enhanced taxiway markings (centre lines and } lights, edge lines), taxiway signs, and many other goodies. . . .which suggests the taxiway idenfication info will be in there in some form, either as labels on the records or as fixed signs (like the beacons or windsocks). In the latter case, it'd be possible to infer taxiway identifiers, albeit with some work. What I suggest is that the TaxiDraw project file be allowed to keep extra information such as this, perhaps in xml format. Then, when exporting one can simply export the information relevant at the time for the format exported to. One could possible generate the airport signage directly from the TaxiDraw project files, or maybe by exporting the extra data into the X-Plane data as an extension that genapts understands. Once X-Plane format officially includes it, it can be exported from the TaxiDraw project files into whatever format it uses to understand it. I think this all sounds really good. Some of the other issues you bring up in the archived post you mention are similar to those that Paul Surgeon brings up in this thread - I'll think about it and reply again. Cool. I have one other request that's specifically TaxiDraw related; I'll put it in another thread just to keep things straight. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgp9wULF26nKW.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Mathias Fröhlich wrote: Sent: 21 October 2004 07:36 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] status of aircraft carrier On Mittwoch 20 Oktober 2004 18:11, Vivian Meazza wrote: It would be easy to convert to X,Y,Z coordinates, if I knew the equations (I have suitable equations for ft to degrees lat/long) or, better, I could start in X,Y,Z. Start with X/Y/Z ... Yesterday I put together some code which outputs the Lat/Lon/Alt of the hook tip when extended. Norman Vine kindly pointed me at the SG conversion function, so I now have output in X,Y,Z. I'm using great chunks of submodel code, much of which is redundant in this context, so I need to tighten this up. However, I've added the function to the Seafire as a demonstrator. I still have to adjust the hook tip for compression when it's in contact with the ground. I'll have a first cut of all this code ready after the weekend, I hope. So far so good V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Mathias Fröhlich wrote: Sent: 21 October 2004 07:31 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] status of aircraft carrier On Mittwoch 20 Oktober 2004 09:49, Vivian Meazza wrote: We calculated the output in geodetic terms (lat/long/alt) for submodels so that they could be displayed, and it's no problem to output in x,y,z aircraft terms. It didn't seem to be expensive computationally. Further, lat/long/alt was the easiest to get at for the aircraft location. I think that I'll need some help here with the necessary conversion factors. I'll look into it further. The problem is that those values are in geodetic lat/lon. The underlying transform to an elliptical coordinate space is done in sgCartToGeod in SimGear/simgear/math/sg_geodesy.cxx. There is also a paper about this stuff floating around. But it is sufficient to know that this transform is significantly more expensive than doing a scalar times vector. Unless I can find a way to get at the XYZ positions we're stuck with it. However, my initial impression, admittedly on a pretty powerful machine is that the computation effort is not significant. Do we need ground reactions as an intrinsic part of this code? Although I can see that it might represent an opportunity to improve the current situation. I think so. I cannot see a way to model the earths surface with different properties like runnway/grass/water with load factor. In principle you need to tell the fdm what static and dynamic coefficients of friction to apply for each type of surface - I think I've seen suitable figures around on the net. Did you mean water lying on runway/grass or the sea? Thats just another coefficient of friction. I think the hydrodynamics of floats are a whole new ballpark. We shouldn't tackle that, but we need to recognize that we now have a float plane in the inventory, so someone might like to do it some time. Moving and rotating triangles for the ac carriers deck, and special elements like the wires/catapults. This is a similar problem to the position of the hook tip relative to the origin of the aircraft. We should be able to adapt the (soon to be) existing code. Ok, this can be put into the property tree as we have a structure broken out into scalar values. But I guess that this provides a huge overhead for that stuff. If you do serious computatiions with those values you will need to transform them back into structs/classes/whatever. Good, let's go for it. Ok, yesterday evening I did that hierarchical boundingbox stuff. It looks very hackish at the moment and I first need to seperate out some stuff also in that experimental tree before I can send you what I have. I hope to get that done today evening ... I can taxi on slopes and get all surfaces/lines in an ball aroung the aircraft. So If you can think about, how we can inject our preliminary wire area into the scenegraph, we will be some step ahead. :) I thought about using normal ssgLeafs for such a thing with some special information that this is a wire area stored in the UserData field of ssgBase. I was thinking on similar lines. Let's start with that and see how we evolve. Really, modelling individual wires with lines is also not a big deal. So If we could inject individual wires every 5 meters on the whole KSFO runway (I am not a good pilot for testing ... :) we can start with that. A word for testing if a wire is caught: The hook (think of it as a line) has a position before the integration step. Past integration, it has a new position. The rectangle spanned by those two lines is the area where the hook was during that integration step. If a wire line intersects this rectangle, we have cought that wire (when we assume for now and testing, that we catch every wire we touch). Yes, good, I hadn't thought that far. This should work I'll get on with seeing if I can provide hook position - we would be well under way with that. I think this would be a worthwhile activity since we seem to have most of the bits almost in place. Yep this hook position is also something we will need. As I told, best in (double valued) cartesian coordinates relative to the earth's center. The only common output from the fdms that I can get hold of right now seems to be LLZ. Not to worry for now, my code will only need a small change to cope with XYZ. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VBOs - performance test results
Ampere K. Hardraade wrote: First of all, I'm not saying let's switch to OpenRT now. I am saying that if FlightGear's scenegraph ever requires a large restructure, it will be a good time to look at the feasibility of using OpenRT. Off course not. We will lose more than 50% of our current users because their setup isn't powerful enough to run it. I mean, rendering is just a *part* of what FlightGear does. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Mathias Fröhlich writes: I cannot see a way to model the earths surface with different properties like runnway/grass/water with load factor. Moving and rotating triangles for the ac carriers deck, and special elements like the wires/catapults. Easiest way is to add surface property is to use the ssgBase user_data field in the leafs and then use the a modified FGHitList::get_entity() method to return the touched leaf user_data. This could just be the pointer to the ssgTexture. Probably easiest to derive a fgTexture object from ssgTexture and add a surface property field This would require adding a field to the HitList that was set to the fgHitRec used note: I believe that this will always be the same as last_hit() but I haven't tested this and adding and maintaining an extra field won't hurt performance The actual call to do this would then be something like ((fgTexture *)(myHitList-get_entity(myHitList-get_active_entity())-get_user_data()-get_surface_property(); Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw and choice of images from terraserver-usa
Chris Metzler wrote: [...] The Urban Areas/T=4 dataset is fabulous, btw -- it goes down to 25cm resolution (TaxiDraw fetches 1 meter resolution images, it appears). I'd recommend just changing fetch.cpp to T=4, and getting the highest resolution images available; but not all areas are covered by the better dataset. That's why I'm recommending tests -- try to fetch from the higher resolution dataset, and drop down to the lower-res one if the first fetch fails. LOL, sounds as if Chris has hacked terraserver.com to provide him with their payware imagery for free ;-) After all your attempts, it's now certainly VERY interesting to have a look at their logs ! Did you also try numbers greater than 4 ? :-) And I don't even mention what their logs are going to look like if Chris adds your brute force method of trying to look for available images :-) What a creative way to organize a distributed denial of service attack against a Microsoft server, really Chris, awesome !! ;-) Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] TaxiDraw and choice of imagesfrom terraserver-usa
Boris Koenig writes: Chris Metzler wrote: What a creative way to organize a distributed denial of service attack against a Microsoft server, really Chris, awesome !! ;-) Better running something like http://learn.arc.nasa.gov/worldwind/ against rhese advertised services http://terraserver.microsoft.com/ogccapabilities.ashx?version=1.1.1request=getcapabilitiesservice=wms AFAICT TerraServer has a FAT pipe:-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Trans.: Re: [PATCH] segfault in AI code
I repost this to the list because Dave Culp raised the problem -Fred Erik Hofman wrote: Frederic Bouvier wrote: Hi Erik, David Culp wrote : Just downloaded a fresh CVS FlightGear and found that the AI code is causing segfaults now. I'll recompile and run it through gdb. In the mean time beware that some aircraft that set up AI scenarios by default, like the T-38 or the hunter-2tanks, are crashing the sim. I think I found the problem in props.hxx. I have an exception when copying properties. An alias to a property that has no value trigger this exception. I've commented out the offending line for now. I think the problem is that GRawValueMethods doesn't expose it's type to the tie() function. We don't lose much with this line disabled and it give some more time to look at the problem. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Trajectory show when replay?
Thanks Arnt. Responses inline. Other gents, have time to look into my questions in my previous email and help me out? One question, if I have already know one point's (lat, lon, alt), how can I calculate a right position to draw it? I know it needs to be updated as the scenery center is being changed...I did some investigation but I have to say I messed up something. Can anyone give me a clarification on what procedures I should call...is the way I showed in my previous email correct? Hi, I am trying to show the trajectory the aircraft just flied when start replaying. Is there anybody who had ever done that? ..like Klog? ' apt-get install klog ', if you use debian sid, otherwise see http://kflog.org . Or could you give me some ideas about the solution? ..preliminary idea: Ethy Brito asked for help investigating a helicopter crash using FG, if you _are_ doing what I think you are doing, chk out http://baron.flightgear.org/pipermail/flightgear-users/2004-October/009104.html and help us qualify FlightGear as an air crash investigation tool, your trajectory code ideas are spot on what we need, if they are anywhere near what I think they are. :-) ..updated protocol handler for FG: http://www.a1.nl/~ehofman/fgfs/downloads/j3cub [QingRou] I saw Erik's email. Sounds like in the coming release we can have such functionality: save your flight to a file with the data need to be stored in FGReplayData (Sim_time, FDM and Ctrls). Then read this file back and replay the flight. This is useful especially for the instructors to show the students how a successful/bad flight is. Also it can be used to save students' flight and give scores. ..ca 2 hours Dolphin SA365 real life flight data for FG calibration: http://www.inexo.com.br/SA365/SA365-flight007-aero-data.tar.gz http://www.inexo.com.br/SA365/SA365-flight007-engine-data.tar.gz ..bonus extensions could be placing choppers or airplanes rather your lines or dots along the trajectory trail, [QingRou] Yes with my point (spot) solution, you can change the loading 3D model to anything you want and then you can see the model showed along the trajectory. I had ever done that to show a rocket along the flight path! maybe showing red wireframe orientations etc according to the black box recordings, and green, blue, yellow etc wireframe orientations according to the black box recordings filtered thru the yasim, JSBSim, UIUC etc flight dynamics models to help understand the recordings and say, help identify instrument errors disturbing the black box recordings. [QingRou] Yeah...actually what I am doing is, read the record data from Flight Data Recorder (black box), and refine the data to some format, then input into the replay system of FlightGear. All the flight recorded by the FDR can be replayed. In a flight school, this can be used for the instructors to review the flight with the student and give some comments to his operation. ..Ethy? You're still around? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d _ MSN Explorer: http://explorer.msn.com/lccn/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New JSBSim Newsletter Issue
The Fall issue of the JSBSim newsletter, Back of the Envelope is online at the JSBSim web site, www.jsbsim.org. Click on the newsletter link in the sidebar at left, or select one of the newsletters at the top of the main page. The Fall 2004 issue features contributions by Mathias Fröhlich, Bill Galbraith, and Roy Vegard Ovesen, as well as myself, with articles: - JSBSim Presented at the 2004 AIAA Modeling and Simulation Conference - DATCOM+ - The PID Controller - JSBSim Reference Frames I hope you enjoy the newsletter, a mix of lightweight reading and overviews on various technologies and items related to the use of JSBSim, a flight dynamics model that is used by FlightGear. As always, suggestions for future article topics, contributions of writing, corrections, etc. are welcome. Jon Berndt -- Project Coordinator JSBSim Flight Dynamics Model http://www.jsbsim.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] new version 0.9.6, always bugs
On my home win98se the game crashes (as at the previous version) but in a different point: after the splash screen. On my office XP Professional with s.p. 2 the game not crash but: a) the Save / Load NOT WORK!!! b) pressing the V key the plane is in the FOG, nothing other is visibile The first point, expecially, is very important. The previous version also was bugged in this manner. At the next i have reported the FGFS.SAV file, hoping someone may help me Sorry for my bad english. -- ?xml version=1.0? PropertyList position longitude-deg type=double9.279957/longitude-deg latitude-deg type=double45.431902/latitude-deg altitude-ft type=double1255.229819/altitude-ft /position orientation heading-deg type=double137.245697/heading-deg roll-deg type=double-10.543338/roll-deg pitch-deg type=double-6.766211/pitch-deg /orientation velocities uBody-fps type=double396.935351/uBody-fps vBody-fps type=double4.599903/vBody-fps wBody-fps type=double17.692969/wBody-fps /velocities sim presets speed-set type=stringUVW/speed-set onground type=boolfalse/onground trim type=boolfalse/trim /presets panel visibility type=booltrue/visibility jitter type=boolfalse/jitter /panel current-view heading-offset-deg type=double0.00/heading- offset-deg field-of-view type=double55.00/field-of-view goal-heading-offset-deg type=double0.00/goal- heading-offset-deg goal-pitch-offset-deg type=double-8.00/goal- pitch-offset-deg goal-roll-offset-deg type=double0.00/goal-roll- offset-deg pitch-offset-deg type=double-8.00/pitch-offset- deg roll-offset-deg type=double0.00/roll-offset-deg axes long type=double0.00/long lat type=double0.00/lat /axes ground-level-nearplane-m type=double0.50/ground- level-nearplane-m /current-view time gmt type=string2004-10-20T11:06:16/gmt /time view internal type=booltrue/internal config x-offset-m-0.38/x-offset-m y-offset-m2.26/y-offset-m z-offset-m-12.16/z-offset-m pitch-offset-deg type=double-8.00/pitch- offset-deg /config /view view n=1 config z-offset-m alias=/sim[0]/chase-distance-m[0]/ z-offset-m /z-offset-m /config /view /sim environment clouds layer coverage type=stringscattered/coverage elevation-ft type=double5000.00/elevation-ft thickness-ft type=double600.16/thickness-ft transition-ft type=double150.04/transition-ft span-m type=double4.00/span-m /layer layer n=1 coverage type=stringcirrus/coverage elevation-ft type=double19500.000320/elevation-ft thickness-ft type=double65.01/thickness-ft transition-ft type=double25.00/transition-ft span-m type=double59436.00/span-m /layer layer n=2 coverage type=stringclear/coverage span-m type=double4.00/span-m elevation-ft type=double0.00/elevation-ft thickness-ft type=double0.00/thickness-ft transition-ft type=double0.00/transition-ft /layer layer n=3 coverage type=stringclear/coverage span-m type=double4.00/span-m elevation-ft type=double0.00/elevation-ft thickness-ft type=double0.00/thickness-ft transition-ft type=double0.00/transition-ft /layer layer n=4 span-m type=double4.00/span-m elevation-ft type=double0.00/elevation-ft thickness-ft type=double0.00/thickness-ft transition-ft type=double0.00/transition-ft coverage type=stringclear/coverage /layer /clouds turbulence magnitude-norm type=double0.011825/magnitude-norm rate-hz type=double1.00/rate-hz /turbulence wind-from-north-fps type=double18.396213/wind-from- north-fps wind-from-east-fps type=double-24.904275/wind-from- east-fps wind-from-down-fps type=double0.00/wind-from-down- fps visibility-m type=double16093.44/visibility-m temperature-sea-level-degc type=double15.00/temperature-sea-level-degc dewpoint-sea-level-degc type=double5.255940/dewpoint- sea-level-degc pressure-sea-level-inhg type=double29.92/pressure- sea-level-inhg /environment controls flight aileron type=double0.20/aileron aileron-trim type=double0.00/aileron-trim elevator type=double-0.15/elevator elevator-trim type=double0.00/elevator-trim rudder type=double-0.10/rudder rudder-trim type=double0.00/rudder-trim flaps type=double0.00/flaps slats type=double0.00/slats BLC type=boolfalse/BLC spoilers
Re: [Flightgear-devel] Re: DeHavilland Beaver
Melchior FRANZ wrote: Ohh, and don't start it from 28R! $ fgfs --aircraft=dhc2F --lon=-122.43695 --lat=37.60588 --heading=155 I've got a suggestion which I consider an excellent companion to the beaver model: Vancouver Coal Harbour airpor. References: http://www.world-airport-codes.com/canada/vancouver-harbour-sp-7367.html http://www.2747.com/2747/world/airport/vancouver.htm Been there, seen that - a _marvellous_ place with lots of Beavers, Single- and Twin-Otthers in the air and on the sea. Nice pictures at: http://www.airliners.net/search/photo.search?placesearch=Vancouver%20Harbour%20%28CXH%29distinct_entry=true Apparently they have a heli platform as well Vancouver International is called YVR, ICAO code CYVR. So I presume one could take CCXH for Vancouver Harbour, but I didn't find a valid proof, except from this one :-)) http://apple.cs.umbc.edu/cache/swoogle/ORIGINAL/56873_cache I'd say it's easy to add this airport to FlightGear because you don't have to deal with the terrain - you'd simply need to put it onto the list, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw and choice of images from terraserver-usa
On Thu, 21 Oct 2004 10:24:45 +0200 Boris Koenig [EMAIL PROTECTED] wrote: Chris Metzler wrote: [...] The Urban Areas/T=4 dataset is fabulous, btw -- it goes down to 25cm resolution (TaxiDraw fetches 1 meter resolution images, it appears). I'd recommend just changing fetch.cpp to T=4, and getting the highest resolution images available; but not all areas are covered by the better dataset. That's why I'm recommending tests -- try to fetch from the higher resolution dataset, and drop down to the lower-res one if the first fetch fails. LOL, sounds as if Chris has hacked terraserver.com to provide him with their payware imagery for free ;-) Oh man, I don't know if I explained this well enough. The stuff on terraserver-usa.com (as opposed to terraserver.com -- same company, different website), including the images I fetched, are all free through the web interface. Try it out with the browser of your choice; you'll see it all just by clicking on links. Before, terraserer-usa only had one dataset of free aerial images. Now they have a second, which improves coverage in U.S. urban areas. Did you also try numbers greater than 4 ? :-) And I don't even mention what their logs are going to look like if Chris adds your brute force method of trying to look for available images :-) Heh. But again, I wasn't fishing for available images by tweaking the URL Dave uses in TaxiDraw. These images are available normally, through normal use. There was no detective work on my part in finding the images, because they provide them to you with nice informative links. The only thing I did was figure out how to get fetch.cpp to draw from the new dataset instead of the old one-- something that would have been trivial for anyone who knows c++ (but I don't). -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpNmgN3Kj8B6.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] segfault in AI code
Just downloaded a fresh CVS FlightGear and found that the AI code is causing segfaults now. I'll recompile and run it through gdb. In the mean time beware that some aircraft that set up AI scenarios by default, like the T-38 or the hunter-2tanks, are crashing the sim. I've run it through gdb and didn't get any useful output. After a few hours of detective work with cout's I'm getting this: [EMAIL PROTECTED] bin]$ ./t38 FGPropertyManager::GetNode() No node found for fcs/throttle-cmd-norm[0] Creating new property FGPropertyManager::GetNode() No node found for fcs/throttle-cmd-norm[1] Creating new property Starting FGAIManager::bind() Finished FGAIManager::bind() Creating new scenario: refueling_demo Creating an AIAircraft Created an AIAircraft Scenario has been processed. ./t38: line 24: 662 Aborted /home/dave/bin/fgfs $cmdline The sim is crashing before the first call to FGAIManager::update(), however the init() is working fine, and the scenario gets processed and an AI aircraft is created properly. AFAIK the AI subsystem doesn't do anything else between bind() and update(), so the property system (as pointed out by Fred) might be a good place to look. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw and choice of images from terraserver-usa
On 10/21/04 at 9:26 AM Chris Metzler wrote: On Thu, 21 Oct 2004 10:24:45 +0200 Boris Koenig [EMAIL PROTECTED] wrote: Chris Metzler wrote: [...] The Urban Areas/T=4 dataset is fabulous, btw -- it goes down to 25cm resolution (TaxiDraw fetches 1 meter resolution images, it appears). I'd recommend just changing fetch.cpp to T=4, and getting the highest resolution images available; but not all areas are covered by the better dataset. That's why I'm recommending tests -- try to fetch from the higher resolution dataset, and drop down to the lower-res one if the first fetch fails. LOL, sounds as if Chris has hacked terraserver.com to provide him with their payware imagery for free ;-) Oh man, I don't know if I explained this well enough. The stuff on terraserver-usa.com (as opposed to terraserver.com -- same company, different website), including the images I fetched, are all free through the web interface. Try it out with the browser of your choice; you'll see it all just by clicking on links. Before, terraserer-usa only had one dataset of free aerial images. Now they have a second, which improves coverage in U.S. urban areas. Yes, to clarify, terraserver-usa.com IS NOT THE SAME SITE as terraserver.com. terraserver-usa.com includes the following copyright statement: The U.S. Geological Survey (USGS) provides the Microsoft® TerraServer site with images and maps of the United States. The images are in the public domain, and are freely available for you to download, use and re-distribute. If you download and use any images, the TerraServer team and the USGS appreciate a reference to our work on this project. The TaxiDraw website includes a thank-you to both USGS and Microsoft Research, so we're following both the letter and the spirit of the law here. Terraserver-usa.com even includes a reference to a programming api to interface to the site (but it's dot-net so I didn't use it), and at least one other site has had an alternative front end to their images up for several years now with no apparent problems. TaxiDraw has absolutely nothing whatsoever to do with terraserver.com, only terraserver-usa.com. This is directed at others, not Chris, who obviously knows the score. As Chris says, terraserver-usa.com now includes free colour USGS images to many (I haven't checked this, just going on Chris' post) urban areas, which include many airports. These are presumably easier to work against and more up-to-date than the b/w images. When I coded TaxiDraw they only had Seattle in colour, so I didn't bother adding support. I will eventually add support for these, but my current priority for the image code is to use the cross-platform cURL library and work with the images in pieces as downloaded (instead of tiling them with ImageMagick) so that Windows users can also benefit from this. Working with tiles should improve program response when zoomed in on a small portion of the image as well. I won't be including any support whatsoever for downloading images that don't have an unequivocal copyright statement allowing unrestricted use of the images similar to the above, have no fear of that. I probably will put some safeguards in the program to avoid downloading excessively large areas, but for now I trust that users will use it responsibly! Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Other segfaults -- the same? (was Re: segfault in AI code)
On Thu, 21 Oct 2004 09:06:14 -0500 David Culp [EMAIL PROTECTED] wrote: Just downloaded a fresh CVS FlightGear and found that the AI code is causing segfaults now. I'll recompile and run it through gdb. In the mean time beware that some aircraft that set up AI scenarios by default, like the T-38 or the hunter-2tanks, are crashing the sim. I've run it through gdb and didn't get any useful output. After a few hours of detective work with cout's I'm getting this: [EMAIL PROTECTED] bin]$ ./t38 FGPropertyManager::GetNode() No node found for fcs/throttle-cmd-norm[0] Creating new property FGPropertyManager::GetNode() No node found for fcs/throttle-cmd-norm[1] Creating new property Starting FGAIManager::bind() Finished FGAIManager::bind() Creating new scenario: refueling_demo Creating an AIAircraft Created an AIAircraft Scenario has been processed. ./t38: line 24: 662 Aborted /home/dave/bin/fgfs $cmdline The sim is crashing before the first call to FGAIManager::update(), however the init() is working fine, and the scenario gets processed and an AI aircraft is created properly. AFAIK the AI subsystem doesn't do anything else between bind() and update(), so the property system (as pointed out by Fred) might be a good place to look. Hmmm. I was having a problem that I was starting to write up the night before last, until I saw your post. I thought it was the same problem, and you'd reported it. But now I'm beginning to wonder if they *were* the same problem. I get the impression from the above that your segfaults are occuring promptly, at the beginning of the scenario. I'm getting segfaults that seem related to the AI subsystem. They occur when I turn AI traffic on through the menu. They seem more frequent as I turn the AI traffic density up from 1 to 3. But they don't occur promptly upon start; instead, they almost always occur when I'm on final for a landing. --log-level=debug shows no useful messages -- there's just an abrupt end. But if I don't enable the AI traffic, I don't get the segfaults. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpzeOeBaGdJt.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Other segfaults -- the same? (was Re: segfault in AI code)
I'm getting segfaults that seem related to the AI subsystem. They occur when I turn AI traffic on through the menu. They seem more frequent as I turn the AI traffic density up from 1 to 3. But they don't occur promptly upon start; instead, they almost always occur when I'm on final for a landing. --log-level=debug shows no useful messages -- there's just an abrupt end. But if I don't enable the AI traffic, I don't get the segfaults. That's strange because the AI subsystem and the AI Traffic subsystem are two different and completely seperate systems. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Other segfaults -- the same? (was Re: segfault in AI code)
On 10/21/04 at 9:52 AM David Culp wrote: I'm getting segfaults that seem related to the AI subsystem. They occur when I turn AI traffic on through the menu. They seem more frequent as I turn the AI traffic density up from 1 to 3. But they don't occur promptly upon start; instead, they almost always occur when I'm on final for a landing. --log-level=debug shows no useful messages -- there's just an abrupt end. But if I don't enable the AI traffic, I don't get the segfaults. That's strange because the AI subsystem and the AI Traffic subsystem are two different and completely seperate systems. Uggh, that's me in the firing line then! I haven't added any features or code to the AI-traffic system for quite a while, probably pre-0.9.5. I thought I had all the bugs worked out, but it seems not :-( It's been switched off by default for the last couple of versions so I guess that's why it hasn't been generating complaints before. Can you get a backtrace? Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New airport data available
I've put a new set of data up at the TaxiDraw website for TaxiDraw users and FlightGear scenery builders. This is based on the last released X-Plane data (as is Flightgear's runways.dat). Changes are: 175 airports that we split up in the master database (and therefore broken in Flightgear's scenery) have been reassembled with a script. (For example KMIC). This does not include any airports with codes ending in ZZ in the database, since it is impossible to tell if these are duplicates. 60 airports have had user-submitted additions or alterations, from Jon Stockill, Erik Hofman and Doug Robertson, and a few by myself to test the program during development. This data is in X-Plane format - the latest Terragear cvs only builds from this format now (Curt's change, not mine BTW). I recommend that TaxiDraw users work from this latest dataset to avoid duplicating work, or to avoid manually fixing the 175 split-up airports (a lot of them don't have taxiways though). If you don't use TaxiDraw or generate FlightGear scenery yourself there is no point in downloading this dataset - it cannot be used by Flightgear itself independently of a scenery rebuild. Please report any problems with the data - it's possible my merge scripts could have introduced corruptions, which I'd like to get ironed out before Curts's next world scenery rebuild. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New airport data available - url
I guess the url would help ;-) It's http://www.nottingham.ac.uk/~eazdluf/taxidraw/airportdata.html Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [OT] Aviation weblog: Land and Hold Short
On Thu, 21 Oct 2004 02:15:07 +0200, Boris Koenig [EMAIL PROTECTED] wrote: ...how would you then call the following: http://www.megginson.com/blogs/lahso/medicals.html ? A brief lapse of judgement. BTW: talking of healthy presidents: Pres. Bush Senior did even do a parachute jump on his birthday this year, he talked about that on Larry King Live, whereas Larry King himself wasn't allowed to jump because of his health condition... Yes, I heard about that. It was a tandem jump, but still. I am sure you could attract some readers here by talking about the time when _you_ were a teenager ;-) All my friends listened to the early Queen albums, jammed jazz and blues, and (I'm ashamed to report) hoped that Ronald Reagan would be assassinated because we thought he was going to start WW III. Not much there to keep a blog going; certainly not much of a social life until university. I've noticed that you've provided this kind of tutorial on your webpage, too - how about also recommending one or two decent RSS feed- readers ? :-) I've tried Straw and Liferea in Linux, and prefer Liferea. There are some plugins for Mozilla/Firefox, but Firefox also has a simple RSS reader built into its bookmarks now. Under Windows, there are FeedDemon ($$, standalone), NewsGator ($$, Outlook), and FeedReader (open source, standalone), along with the Mozilla/Firefox options and dozens of other programs. Under MacOS X, people seem to prefer NetNewsWire, but I think there's also one called AmphetaDesk. After all that, though, a lot of people use an online aggregator rather than installing software on their computers. http://www.megginson.com/blogs/lahso/thumb60.html So, if you intend to maintain that type of contents you could certainly attract some interested readers, I think. Thanks. I'm going to try for some variety -- today, I posted about an NDB fansite, for people who log NDBs they manage to tune in the same way plane spotters log tail numbers: http://www.megginson.com/blogs/lahso/ndb-fans.html I'll probably do another more technical topic soon, maybe more of the rules of thumb. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw and choice of images from terraserver-usa
On 10/21/04 at 3:16 PM David Luff wrote: On 10/21/04 at 9:26 AM Chris Metzler wrote: something about changing to colour images I will eventually add support for these, but my current priority for the image code is to use the cross-platform cURL library and work with the images in pieces as downloaded (instead of tiling them with ImageMagick) so that Windows users can also benefit from this. Working with tiles should improve program response when zoomed in on a small portion of the image as well. Having read what you changed to get these in more detail (T1 - T4), it seems it shouldn't be too difficult at all to check for a valid jpeg returned with T4, and then default to T1 if not. I'll try and knock something up. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Legal file references in aircraft definitions
I'm trying to write a script to determine the interdependencies of aircraft, as a start on trying to figure out a way of splitting the aircraft into different packages. I'm dealing with searching through the files in the \Aircraft\ subdir for references to other files, and while I could take each token that could be a filename and check it against the list of filenames, I'd rather only take those that are filenames, so I'm wondering how another file can legitimately be included. ATM, I've found three places: In a path environment In a background environment As an include= argument to an instrument tag Does anybody know of any others? Giles Robertson ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Other segfaults -- the same? (was Re: segfault in AI code)
On Thu, 21 Oct 2004 15:55:24 +0100
David Luff [EMAIL PROTECTED] wrote:
Uggh, that's me in the firing line then! I haven't added any features
or code to the AI-traffic system for quite a while, probably pre-0.9.5.
I thought I had all the bugs worked out, but it seems not :-( It's been
switched off by default for the last couple of versions so I guess
that's why it hasn't been generating complaints before. Can you get a
backtrace?
Here's what I see from gdb . . .
(gdb) run
Starting program: /home/cmetzler/Projects/FlightGear-0.9/source/src/Main/fgfs
--enable-fullscreen --prop:/environment/params/real-world-weather-fetch=true
--airport=KDCA --offset-azimuth=45 --offset-distance=7.0 --altitude=4000 --vc=100
--heading=0
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 3690)]
Failed to find runway 28R at airport KDCA
[New Thread 32769 (LWP 3693)]
[New Thread 16386 (LWP 3694)]
Object PanelInstruments not found
Object ControlsGroup not found
[New Thread 32771 (LWP 3696)]
[New Thread 49156 (LWP 3697)]
Altitude = 74
Temp at alt (C) = 11
Temp sea level (C) = 11.1425
Altitude = 74
Dewpoint at alt (C) = 11
Dewpoint at sea level (C) = 11.0148
Trim Results:
Angle of Attack: 0.44 wdot: 9.13e-06 Tolerance: 1e-03 Passed
Throttle: 0.75 udot: 8.47e-02 Tolerance: 1e-03 Failed
Pitch Trim: 0.22 qdot: 4.09e-03 Tolerance: 1e-04 Failed
Trim Statistics:
Total Iterations: 61
Sub-iterations:
wdot: 126 average: 2.07 successful: 57 stability: 3.96
udot: 1148 average: 18.82 successful: 1 stability: 14.47
qdot: 121 average: 1.98 successful: 61 stability: 4.26
Run Count: 22370
Altitude = 15
Temp at alt (C) = 12
Temp sea level (C) = 12.029
Altitude = 15
Dewpoint at alt (C) = 11
Dewpoint at sea level (C) = 11.003
Error: base = 0,858.14 course = 0.881677 dist = 8.88574e+06
Error: base = 0,-1099.45 course = 4.56981 dist = 8.88574e+06
Error: base = 0,857.26 course = 0.881679 dist = 8.88573e+06
Error: base = 0,-1099.45 course = 4.56981 dist = 8.88573e+06
Error: base = 0,857.261 course = 0.881681 dist = 8.88572e+06
Error: base = 0,-1098.97 course = 4.56898 dist = 8.88294e+06
Error: base = 0,855.813 course = 0.880004 dist = 8.88294e+06
Error: base = 0,-1098.97 course = 4.56898 dist = 8.88294e+06
Error: base = 0,855.808 course = 0.880004 dist = 8.88294e+06
Error: base = 0,-1099.38 course = 4.56978 dist = 8.88522e+06
Altitude = 74
Temp at alt (C) = 11
Temp sea level (C) = 11.1425
Altitude = 74
Dewpoint at alt (C) = 11
Dewpoint at sea level (C) = 11.0148
Altitude = 15
Temp at alt (C) = 12
Temp sea level (C) = 12.029
Altitude = 15
Dewpoint at alt (C) = 11
Dewpoint at sea level (C) = 11.003
Altitude = 280
Temp at alt (C) = 11
Temp sea level (C) = 11.5399
Altitude = 280
Dewpoint at alt (C) = 11
Dewpoint at sea level (C) = 11.056
Altitude = 15
Temp at alt (C) = 12
Temp sea level (C) = 12.029
Altitude = 15
Dewpoint at alt (C) = 11
Dewpoint at sea level (C) = 11.003
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 3690)]
0x080b0705 in FGTower::ProcessDownwindReport (this=0xd041ee8, t=0xd87d8c8)
at AIPlane.hxx:80
80 inline PatternLeg GetLeg() {return leg;}
(gdb) backtrace
#0 0x080b0705 in FGTower::ProcessDownwindReport (this=0xd041ee8, t=0xd87d8c8)
at AIPlane.hxx:80
#1 0x080af97c in FGTower::Respond (this=0xd041ee8) at tower.cxx:520
#2 0x080aee7d in FGTower::Update (this=0xd041ee8, dt=0.17272)
at tower.cxx:356
#3 0x0808d428 in FGATCMgr::update (this=0x98727e0, dt=0.034546)
at stl_list.h:167
#4 0x08052e20 in fgMainLoop () at globals.hxx:278
#5 0x08083dc5 in GLUTidle () at fg_os.cxx:114
#6 0x400a9c67 in glutMainLoop () from /usr/lib/libglut.so.3
#7 0x08054bd5 in fgMainInit (argc=9, argv=0xb570) at main.cxx:943
#8 0x0805166d in main (argc=0, argv=0x0) at bootstrap.cxx:185
HTH.
-c
--
Chris Metzler [EMAIL PROTECTED]
(remove snip-me. to email)
As a child I understood how to give; I have forgotten this grace since I
have become civilized. - Chief Luther Standing Bear
pgpkRWhsT03So.pgp
Description: PGP signature
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
Has anybody got TaxiDraw 0.2 to compile? I got problems compiling it with gcc 3.3 (IRIX and Linux) and MIPSpro (IRIX). For some off reason I could probably get MIPSpro to compile it if I was able to get wxwindows to (later than version 2.3.3) to compile, but gcc gives me all kinds of errors (both IRIX and Linux). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
Erik Hofman wrote: Has anybody got TaxiDraw 0.2 to compile? I got problems compiling it with gcc 3.3 (IRIX and Linux) and MIPSpro (IRIX). For some off reason I could probably get MIPSpro to compile it if I was able to get wxwindows to (later than version 2.3.3) to compile, but gcc gives me all kinds of errors (both IRIX and Linux). Works fine for me on slackware 10.0 (which uses gcc 3.3.4) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
On Thu, 21 Oct 2004 18:26:15 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Has anybody got TaxiDraw 0.2 to compile? I got problems compiling it with gcc 3.3 (IRIX and Linux) and MIPSpro (IRIX). For some off reason I could probably get MIPSpro to compile it if I was able to get wxwindows to (later than version 2.3.3) to compile, but gcc gives me all kinds of errors (both IRIX and Linux). I compiled the most recent one (0.2.2) under Linux just fine. With gcc-3.3, it looks like. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpytfM8J4Bkh.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
Jon Stockill wrote: Erik Hofman wrote: Has anybody got TaxiDraw 0.2 to compile? I got problems compiling it with gcc 3.3 (IRIX and Linux) and MIPSpro (IRIX). For some off reason I could probably get MIPSpro to compile it if I was able to get wxwindows to (later than version 2.3.3) to compile, but gcc gives me all kinds of errors (both IRIX and Linux). Works fine for me on slackware 10.0 (which uses gcc 3.3.4) I guess it boils down to getting the proper version of WxWindows then. What version is recommended? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
David Luff wrote: 60 airports have had user-submitted additions or alterations, from Jon Stockill, Erik Hofman and Doug Robertson, and a few by myself to test the program during development. I presume (from reminding past threads on this list) that several of these user-submitted airports are supposed to represent disused airfields on the British territory. Are these submissions consistent with the following table ? http://dss.ucar.edu/datasets/ds900.0/data/pre73 I asking simply because I'm trying to gather evidence that the data on that page is really valid. Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
Erik Hofman writes: Jon Stockill wrote: Erik Hofman wrote: Has anybody got TaxiDraw 0.2 to compile? I got problems compiling it with gcc 3.3 (IRIX and Linux) and MIPSpro (IRIX). For some off reason I could probably get MIPSpro to compile it if I was able to get wxwindows to (later than version 2.3.3) to compile, but gcc gives me all kinds of errors (both IRIX and Linux). Works fine for me on slackware 10.0 (which uses gcc 3.3.4) I guess it boils down to getting the proper version of WxWindows then. What version is recommended? Hi Erik, You need either 2.4.x (the latest stable version) or 2.5.x (2.5.2 definately works), the latest unstable version. 2.2.x doesn't work unfortunately, I think I use parts of the api that weren't present then. Since 2.3.3 is an out-of-date unstable version (wxWindows uses the Linux kernal numbering convention) I wouldn't recommend it. I've never had any problem compiling wxGTK-2.4.x on Linux with either 2.95 or 3.3. It you can't sort it out then I'll see if I can get it to work on earlier versions. I've compiled it (TaxiDraw) on Linux with both g++-2.95 and g++-3.3 by the way. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Trajectory show when replay?
On Thursday 21 October 2004 11:31, Yu QingRou wrote: Thanks Arnt. Responses inline. Other gents, have time to look into my questions in my previous email and help me out? One question, if I have already know one point's (lat, lon, alt), how can I calculate a right position to draw it? I know it needs to be updated as the scenery center is being changed...I did some investigation but I have to say I messed up something. Can anyone give me a clarification on what procedures I should call...is the way I showed in my previous email correct? Hi, I am trying to show the trajectory the aircraft just flied when start replaying. Is there anybody who had ever done that? ..like Klog? ' apt-get install klog ', if you use debian sid, otherwise see http://kflog.org . Or could you give me some ideas about the solution? ..preliminary idea: Ethy Brito asked for help investigating a helicopter crash using FG, if you _are_ doing what I think you are doing, chk out http://baron.flightgear.org/pipermail/flightgear-users/2004- October/009104.html and help us qualify FlightGear as an air crash investigation tool, your trajectory code ideas are spot on what we need, if they are anywhere near what I think they are. :-) ..updated protocol handler for FG: http://www.a1.nl/~ehofman/fgfs/downloads/j3cub [QingRou] I saw Erik's email. Sounds like in the coming release we can have such functionality: save your flight to a file with the data need to be stored in FGReplayData (Sim_time, FDM and Ctrls). Then read this file back and replay the flight. This is useful especially for the instructors to show the students how a successful/bad flight is. Also it can be used to save students' flight and give scores. ..ca 2 hours Dolphin SA365 real life flight data for FG calibration: http://www.inexo.com.br/SA365/SA365-flight007-aero-data.tar. gz http://www.inexo.com.br/SA365/SA365-flight007-engine-data.ta r.gz ..bonus extensions could be placing choppers or airplanes rather your lines or dots along the trajectory trail, [QingRou] Yes with my point (spot) solution, you can change the loading 3D model to anything you want and then you can see the model showed along the trajectory. I had ever done that to show a rocket along the flight path! maybe showing red wireframe orientations etc according to the black box recordings, and green, blue, yellow etc wireframe orientations according to the black box recordings filtered thru the yasim, JSBSim, UIUC etc flight dynamics models to help understand the recordings and say, help identify instrument errors disturbing the black box recordings. [QingRou] Yeah...actually what I am doing is, read the record data from Flight Data Recorder (black box), and refine the data to some format, then input into the replay system of FlightGear. All the flight recorded by the FDR can be replayed. In a flight school, this can be used for the instructors to review the flight with the student and give some comments to his operation. ..Ethy? You're still around? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. Sorry - a bit late on this one - but if AIballistic submodels are used without the --enable-ai-models parameter the submodels stay at their release point, giving a very good trajectory indicator:) Vivian - would it be tricky to implement this? While we were trying to figure out what I was doing wrong on the Canberra I actually did use this 'feature' to look at trajectories - I especially found it interesting to be able to study the course of the a/c on the glideslope and touch-down. If people thought such a feature might have wider uses it would be easy to make a simple generic marker object that could be used by all a/c. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
David Luff wrote: You need either 2.4.x (the latest stable version) or 2.5.x (2.5.2 definately works), the latest unstable version. 2.2.x doesn't work unfortunately, I think I use parts of the api that weren't present then. Since 2.3.3 is an out-of-date unstable version (wxWindows uses the Linux kernal numbering convention) I wouldn't recommend it. Unfortunately 2.3.3 is the only one that's available as freeware- package for IRIX Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Trajectory show when replay?
If people thought such a feature might have wider uses it would be easy to make a simple generic marker object that could be used by all a/c. Stunt smoke like they use at airshows. g. -- I'm not crazy, I'm plausibly off-nominal! Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
Martin Spott wrote: http://dss.ucar.edu/datasets/ds900.0/data/pre73 I asking simply because I'm trying to gather evidence that the data on that page is really valid. I mean: Consistent with other people's source of information on disused airfields ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
David Luff wrote: Hi Erik, You need either 2.4.x (the latest stable version) or 2.5.x (2.5.2 definately works), the latest unstable version. 2.2.x doesn't work unfortunately, I think I use parts of the api that weren't present then. Since 2.3.3 is an out-of-date unstable version (wxWindows uses the Linux kernal numbering convention) I wouldn't recommend it. I've never had any problem compiling wxGTK-2.4.x on Linux with either 2.95 or 3.3. It you can't sort it out then I'll see if I can get it to work on earlier versions. I've compiled it (TaxiDraw) on Linux with both g++-2.95 and g++-3.3 by the way. Never mind , I gave up on WxWindows. If it ain't GTK I won't use it. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] SGPropertyNodes are making fun of me ! (fgcommands)
Hi ! Having added a couple of new fgcommands recently I was now going to refine some of the acceptable parameters, to allow more functionality. And since Erik said that there could only be ONE parameter of type SGPropertyNode be passed to a fgcommand, I was going to pass all other parameters as additional subnodes/values of that particular SGPropertyNode. However, somehow I'm screwing things up now - because this works only for a certain amount of nodes/values so far. Without splitting parameters up, the whole things works, but it's then of course a rather static solution - so I assume I simply didn't take the right approach to deal with (=get) the subnodes, basically I'm using constructs of the global pointer, like: globals-get_props()-getNode(...) as well as the hasValue/hasChild methods in order to obtain the values/childs of the SGPropertyNode pointer. (Erik mentioned already some time ago that using the global pointer wouldn't be the preferable way in most cases, but rather one should use helpfer function) But running the mentioned fgcommand directly via a simple commandmycommand/command binding in menubar.xml works fine, however as soon as I either start providing several parameters within one property node, OR as soon as I try to run the very same fgcommand using Nasal, the whole thing doesn't work anymore, the Nasal problem seems to be related to the calling format: fgcommand(mycommand,/path/within/proptree/); So, what's the correct way (method/function) to deal with the passed SGPropertyNode pointer in order to obtain the values of several (kown) subnodes within that pointer ? As I said: it works sporadically :-/ Let's say I have half a dozen of parameters, all stored as values or subnodes within the passed SGPropertyNode pointer, how do I actually obtain the contents reliably - so that it doesn't matter whether the fgcommand is executed directly via a command tag or using the Nasal interpreter ? Thanks - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Trajectory show when replay?
Lee Elliott wrote: Sent: 21 October 2004 19:25 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Trajectory show when replay? On Thursday 21 October 2004 11:31, Yu QingRou wrote: Thanks Arnt. Responses inline. Other gents, have time to look into my questions in my previous email and help me out? One question, if I have already know one point's (lat, lon, alt), how can I calculate a right position to draw it? I know it needs to be updated as the scenery center is being changed...I did some investigation but I have to say I messed up something. Can anyone give me a clarification on what procedures I should call...is the way I showed in my previous email correct? Hi, I am trying to show the trajectory the aircraft just flied when start replaying. Is there anybody who had ever done that? ..like Klog? ' apt-get install klog ', if you use debian sid, otherwise see http://kflog.org . Or could you give me some ideas about the solution? ..preliminary idea: Ethy Brito asked for help investigating a helicopter crash using FG, if you _are_ doing what I think you are doing, chk out http://baron.flightgear.org/pipermail/flightgear-users/2004- October/009104.html and help us qualify FlightGear as an air crash investigation tool, your trajectory code ideas are spot on what we need, if they are anywhere near what I think they are. :-) ..updated protocol handler for FG: http://www.a1.nl/~ehofman/fgfs/downloads/j3cub [QingRou] I saw Erik's email. Sounds like in the coming release we can have such functionality: save your flight to a file with the data need to be stored in FGReplayData (Sim_time, FDM and Ctrls). Then read this file back and replay the flight. This is useful especially for the instructors to show the students how a successful/bad flight is. Also it can be used to save students' flight and give scores. ..ca 2 hours Dolphin SA365 real life flight data for FG calibration: http://www.inexo.com.br/SA365/SA365-flight007-aero-data.tar. gz http://www.inexo.com.br/SA365/SA365-flight007-engine-data.ta r.gz ..bonus extensions could be placing choppers or airplanes rather your lines or dots along the trajectory trail, [QingRou] Yes with my point (spot) solution, you can change the loading 3D model to anything you want and then you can see the model showed along the trajectory. I had ever done that to show a rocket along the flight path! maybe showing red wireframe orientations etc according to the black box recordings, and green, blue, yellow etc wireframe orientations according to the black box recordings filtered thru the yasim, JSBSim, UIUC etc flight dynamics models to help understand the recordings and say, help identify instrument errors disturbing the black box recordings. [QingRou] Yeah...actually what I am doing is, read the record data from Flight Data Recorder (black box), and refine the data to some format, then input into the replay system of FlightGear. All the flight recorded by the FDR can be replayed. In a flight school, this can be used for the instructors to review the flight with the student and give some comments to his operation. ..Ethy? You're still around? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. Sorry - a bit late on this one - but if AIballistic submodels are used without the --enable-ai-models parameter the submodels stay at their release point, giving a very good trajectory indicator:) Vivian - would it be tricky to implement this? While we were trying to figure out what I was doing wrong on the Canberra I actually did use this 'feature' to look at trajectories - I especially found it interesting to be able to study the course of the a/c on the glideslope and touch-down. If people thought such a feature might have wider uses it would be easy to make a simple generic marker object that could be used by all a/c. You can do it right now by setting the velocity to zero, buoyancy to 32 and wind to false. Then you need to create a suitable marker in /models/geometry (use puff.ac to prove the principle), and put the path in the submodel.xml file. Oh, and set the delay to a smallish number and the count to -1 life should be longish. Pick some suitable offset - CofG good be a good choice. And there you have it - a stream of stationary markers dropped off behind your aircraft. No problem, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Trajectory show when replay?
Gene Buckle wrote: Sent: 21 October 2004 20:21 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Trajectory show when replay? If people thought such a feature might have wider uses it would be easy to make a simple generic marker object that could be used by all a/c. Stunt smoke like they use at airshows. Submodels can do a fair imitation of this. The F16 has/had an experimental version. Erik? Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Trim quotes
Would it be grumpy of me to suggest that we try a little harder to trim quotes when replying with quotes? I've noticed that there are several emails today with 100 to 200 lines of quoted material, followed by anywhere from a few lines to ten or so. Over time, this stuff builds up... Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
Erik Hofman writes: David Luff wrote: Hi Erik, You need either 2.4.x (the latest stable version) or 2.5.x (2.5.2 definately works), the latest unstable version. 2.2.x doesn't work unfortunately, I think I use parts of the api that weren't present then. Since 2.3.3 is an out-of-date unstable version (wxWindows uses the Linux kernal numbering convention) I wouldn't recommend it. I've never had any problem compiling wxGTK-2.4.x on Linux with either 2.95 or 3.3. It you can't sort it out then I'll see if I can get it to work on earlier versions. I've compiled it (TaxiDraw) on Linux with both g++-2.95 and g++-3.3 by the way. Never mind , I gave up on WxWindows. If it ain't GTK I won't use it. As far as I know, wxGTK uses native GTK behind the scenes on Linux / Unix. According to http://www.wxwindows.org/platform.htm versions 2.2 and 2.5 have been compiled on IRIX 6.5 with the MIPSPro 7.3 compiler. I'm somewhat dissapointed that you're having such problems - I was hoping it would be a genuinely cross platform toolkit in practice as well as theory. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Trim quotes
Jon S Berndt wrote: Would it be grumpy of me to suggest that we try a little harder to trim quotes when replying with quotes? I've noticed that there are several emails today with 100 to 200 lines of quoted material, followed by anywhere from a few lines to ten or so. Over time, this stuff builds up... I noticed that too, on the other hand it's still easier to cope with that than with those postings that quote without quote signs ... ;-) Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Ray Tracing (was: OpenRT)
And I thought joining this mailing list would get me into something different. ;-) Ray tracing is not ready for real-time flight simulation. I'm speaking from experience here. I used to be on the same mailing list as those OpenRT guys. I also wrote the renderer behind rtChess: http://www.newimage.com/~rhk/rtchess/ Which BTW, is available for download (the game) and comes with docs. Be sure you right-click to drag the board around. Use the Space-bar for options menu. Unlike most chess games, you can probably beat this one. I've been working the realtime ray tracing (RTRT) stuff for years, and it's always been real soon now for gaming performance. My library can easily render as many polygons as you can fit in RAM at a couple FPS (requires undersampling) on my 700MHz AMD. It's about 40% faster now than when we wrote rtChess. As with many things, there is one tiny piece of code that consumes 90% of the time and I've worked really hard on that. When I get around to releasing it (probably GPL) some assembly guru *might* get a bit more performance out of it. Because RT is point sampled, the render time is mostly a function of the number of pixels rather than the number of polygons. The time complexity is very good WRT scene size (think log n). A few objects can be handled really really fast on a modern processor. Unfortunately, using 1000s of objects brings log(n) up to where things are rather slow. Going to millions of objects just cuts it in half again. GPUs are not currently able to handle the data structures and recursive algorithms required to get scene scalability, nor do they use double precision. Eric Haines once asked me to estimate when RTRT will be really feasible - I estimated 2012 and so did he. That doesn't take into account the brick wall we see now with power density and no 4GHz pentiums and all that... Multi-core is great for RT. Multi-threading is one of the features I need to add (done before but removed) because it scales nearly optimally with more CPUs. I could probably (openRT too) load the entire FGFS scenery database and render it at 1FPS given enough RAM. Unfortunately that doesn't mean you'll be flying in a ray traced plane any time soon. -Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw and choice of images from terraserver-usa
Wouldn't it be better if FAA Airport Diagrams are used instead of aero photos? There can always be an option to translate the airport to the proper location afterwards. Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new version 0.9.6, always bugs
On October 21, 2004 08:46 am, Antonio Pennino wrote: On my home win98se the game crashes (as at the previous version) but in a different point: after the splash screen. On my office XP Professional with s.p. 2 the game not crash but: a) the Save / Load NOT WORK!!! It has been broken since 0.9.5. Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Trim quotes
Yeah I noticed that too - it makes for some hard reading. Does this become a bandwidth issue on the mailing list server by any chance? I've got a couple of basic rules that I try stick to. Maybe they will help others a bit. 1. Try to only quote what the last guy said - remove all the 2nd hand and older quotes 2. Strip all the quoting out that you are not replying to and just leave the basic sentence or paragraph you are responding to. 3. Remove all personal and mailing list signatures Paul On Thursday, 21 October 2004 23:47, Jon S Berndt wrote: Would it be grumpy of me to suggest that we try a little harder to trim quotes when replying with quotes? I've noticed that there are several emails today with 100 to 200 lines of quoted material, followed by anywhere from a few lines to ten or so. Over time, this stuff builds up... Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Ray Tracing (was: OpenRT)
On October 21, 2004 07:57 pm, Paul Kahler wrote: And I thought joining this mailing list would get me into something different. ;-) Ray tracing is not ready for real-time flight simulation. I'm speaking from experience here. I used to be on the same mailing list as those OpenRT guys. I also wrote the renderer behind rtChess: http://www.newimage.com/~rhk/rtchess/ Which BTW, is available for download (the game) and comes with docs. Be sure you right-click to drag the board around. Use the Space-bar for options menu. Unlike most chess games, you can probably beat this one. SDL isn't the only thing that is needed. I've got the following error: error while loading shared libraries: libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory I apt-get the libstdc++6 package, but the error is still there. Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] status of aircraft carrier
On Donnerstag 21 Oktober 2004 09:11, Vivian Meazza wrote: Yesterday I put together some code which outputs the Lat/Lon/Alt of the hook tip when extended. Norman Vine kindly pointed me at the SG conversion function, so I now have output in X,Y,Z. I'm using great chunks of submodel code, much of which is redundant in this context, so I need to tighten this up. However, I've added the function to the Seafire as a demonstrator. I still have to adjust the hook tip for compression when it's in contact with the ground. I'll have a first cut of all this code ready after the weekend, I hope. You, do YASim for the hunter? For the *first* *proof* *of* *concept*, you can also let the hook hang below ground. That is what I actually try to do at the moment with JSBSim. I want to have something where I can test if I can see the wires I have now injected in my scene. The Aircraft I use for that is a private one with a 4-th gear at its tail. This 4th gear has a tiny spring constant and a well defined name. A gear named 'HOOK' interacts with a line called 'Wire'. This is the preliminary test to find all that stuff ;) I hope to send you a version of that stuff today evening ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
