Re: [Flightgear-devel] configurable HUD colors [breaks backward compatibility]
* Melchior FRANZ -- Thursday 08 June 2006 20:07: Here's a screeshot (for the lazy bums): http://members.aon.at/mfranz/hud.jpg [81 kB] I've now fixed the alpha problem and made the f16-hud transparent. This addresses Isao's valid complaints. The colors depend now on the background and look rather white-ish against light background, but saturated green against dark ones. This should be quite realistic now. Also, the HUD can now really be faded out, and doesn't turn to black by that. Here's a new screenshot: http://members.aon.at/mfranz/hud2.jpg [60 kB] BTW: I also commented out the time/date line. This can't be added to every HUD -- it needs to be requested by HUDs that want it. (This isn't solved yet, though.) m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Is there anybody on this list who is (or will be) following this discussion? There is one thing I would like to see added to this; It becomes pretty common for (former) Military airports over here to have an asphalt runway with two concrete touchdown zones giving best of both worlds, low friction and high (touch down) strength. I don't think this can be specified in the new format. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Valid point Erik, I have run into a situation where a KOSH runway is 1/2 asphalt and 1/2 concrete...taking this to the nth degree a single runway might need to be divided into n segments each of different function...as you say an asphalt runway with two concrete touchdown zones or the KOSH situation above. What can be done to accomodate these situations and is it realistic to hope to get them into the next update I'm unsure as to the status of the apt850 doc, is it a proposal for comment or a statement of what the next version WILL be? regards :-D ene From: Erik Hofman [EMAIL PROTECTED] Reply-To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] apt.dat changes ? Date: Sat, 10 Jun 2006 10:16:25 +0200 Is there anybody on this list who is (or will be) following this discussion? There is one thing I would like to see added to this; It becomes pretty common for (former) Military airports over here to have an asphalt runway with two concrete touchdown zones giving best of both worlds, low friction and high (touch down) strength. I don't think this can be specified in the new format. Erik -- http://www.ehtw.info (Dutch) Future of Enschede Airport Twente http://www.ehofman.com/fgfsFlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Discover fun and games at @ http://xtramsn.co.nz/kids ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Fri, 9 Jun 2006 22:35:02 -0400, Tony wrote in message [EMAIL PROTECTED]: not sure if folks on this list care, or are aware ... but Ben Supnik has made a couple of RFC type posts to one of the x-plane lists, talking about a new design for the airport data coming from Robin Peel. This is apparently the spec that is emerging from those conversations. http://www.x-plane.org/home/robinp/Apt850.htm ..this proposal may improve things, but will not work for KOSH: http://80.239.32.252/notams/notam06.pdf and http://airventure.org/atc/ ..the above changes can be done in several ways, but all of these ways require a time or date header, and headers for _temporary_ or _recurring_ changes to the airport. E.G. KOSH effectively ceases to exist during AirVenture, and KOSH-SOUTH and KOSH-NORTH or somesuch replaces it. ..given timed headers, Robin's apt850 could last 5 years with no change for KOSH, the AirVenture dates has been set for the next 5 years. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Arnt, If you mean time and date headers that correspond to Real-Time for project teams developing Live like CD's they may cause problems..you and I and the rest of the project team want KOSH to be in the AirVenture configuration at the moment... but now doesn't fall within the time/date header parameters... would a Special Events check list be more flexible? Similair to selecting a starup RWY, you select a/or series of Special Event configurations... This could cater for AirVenture, WarBirds over Wanaka, Farnham or any other event that causes changes to an airport. I know from my experience with FGTools, FGFS and TaxiDraw that parsing the APT file is not trivial ...the downside is of course the need for a SpecialAPT.DAT to cater for this and the inherent support and maintenance needed. Mind you your say does mean that if I fly over the area( quite randomly) and it happens to fall within the 24 July-30 July timeframe the AI scenarios may also be active and the sky would be filled with planes... ;-) Cheers :-D ene not sure if folks on this list care, or are aware ... but Ben Supnik has made a couple of RFC type posts to one of the x-plane lists, talking about a new design for the airport data coming from Robin Peel. This is apparently the spec that is emerging from those conversations. http://www.x-plane.org/home/robinp/Apt850.htm ..this proposal may improve things, but will not work for KOSH: http://80.239.32.252/notams/notam06.pdf and http://airventure.org/atc/ ..the above changes can be done in several ways, but all of these ways require a time or date header, and headers for _temporary_ or _recurring_ changes to the airport. E.G. KOSH effectively ceases to exist during AirVenture, and KOSH-SOUTH and KOSH-NORTH or somesuch replaces it. ..given timed headers, Robin's apt850 could last 5 years with no change for KOSH, the AirVenture dates has been set for the next 5 years. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Find the coolest online games @ http://xtramsn.co.nz/gaming ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Sat, 10 Jun 2006 22:01:37 +1200, dene wrote in message [EMAIL PROTECTED]: Hi Arnt, If you mean time and date headers that correspond to Real-Time for project teams developing Live like CD's they may cause problems..you and I and the rest of the project team want KOSH to be in the AirVenture configuration at the moment... ..yup. ;o) but now doesn't fall within the time/date header parameters... would a Special Events check list be more flexible? ..you mean as an FG start-up menu entry? That and airventure.apt.gz and other.special.events.apt.gz's etc will work ok for us (FG) but not for xplane so they have to do a similar hack. Similair to selecting a starup RWY, you select a/or series of Special Event configurations... This could cater for AirVenture, WarBirds over Wanaka, Farnham or any other event that causes changes to an airport. ..aye. I know from my experience with FGTools, FGFS and TaxiDraw that parsing the APT file is not trivial ...the downside is of course the need for a SpecialAPT.DAT to cater for this and the inherent support and maintenance needed. Mind you your say does mean that if I fly over the area( quite randomly) and it happens to fall within the 24 July-30 July timeframe the AI scenarios may also be active and the sky would be filled with planes... ;-) ..like in RL, that's the idea, yes. Cheers :-D ene not sure if folks on this list care, or are aware ... but Ben Supnik has made a couple of RFC type posts to one of the x-plane lists, talking about a new design for the airport data coming from Robin Peel. This is apparently the spec that is emerging from those conversations. http://www.x-plane.org/home/robinp/Apt850.htm ..this proposal may improve things, but will not work for KOSH: http://80.239.32.252/notams/notam06.pdf and http://airventure.org/atc/ ..the above changes can be done in several ways, but all of these ways require a time or date header, and headers for _temporary_ or _recurring_ changes to the airport. E.G. KOSH effectively ceases to exist during AirVenture, and KOSH-SOUTH and KOSH-NORTH or somesuch replaces it. ..given timed headers, Robin's apt850 could last 5 years with no change for KOSH, the AirVenture dates has been set for the next 5 years. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configurable HUD colors [breaks backward compatibility]
Melchior FRANZ wrote: * Melchior FRANZ -- Thursday 08 June 2006 20:07: Here's a screeshot (for the lazy bums): http://members.aon.at/mfranz/hud.jpg [81 kB] I've now fixed the alpha problem and made the f16-hud transparent. This addresses Isao's valid complaints. The colors depend now on the background and look rather white-ish against light background, but saturated green against dark ones. This should be quite realistic now. Also, the HUD can now really be faded out, and doesn't turn to black by that. Here's a new screenshot: http://members.aon.at/mfranz/hud2.jpg [60 kB] BTW: I also commented out the time/date line. This can't be added to every HUD -- it needs to be requested by HUDs that want it. (This isn't solved yet, though.) m. That last pic looks fantastic. You know what would be really useful for the HUD is to be able to define the plane that it is mapped onto as well as aspect ratio. Too bad render to texture isn't working. That is ultimately the way to do it, IMO. Define the name of the texture in the hud.xml file, then map it onto the HUD glass directly in Blender or AC3D. Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configurable HUD colors [breaks backward compatibility]
* Erik Hofman -- Saturday 10 June 2006 15:30: Josh Babcock wrote: Too bad render to texture isn't working. It isn't? If you got working 3d clouds then render-to-texture is supported. Or look into src/Instrumentation/od_gauge.[ch]xx and .../wxradar.[ch]xx. It's used there, too. m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] remove me from discussion list
I think i may have accidentally become a part of a discussion list that is overflowing my in box please help me to be free of this inconvenience [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] remove me from discussion list
Dustin Hilderley wrote: I think i may have accidentally become a part of a discussion list that is overflowing my in box please help me to be free of this inconvenience [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Much nicer than the usual HELP HELP UNSUBSCRIBE NOW!!!. There's a link in the footer of each e-mail: https://lists.sourceforge.net/lists/listinfo/flightgear-devel Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On 6/10/06, dene maxwell [EMAIL PROTECTED] wrote: I know from my experience with FGTools, FGFS and TaxiDraw that parsing the APT file is not trivial ...the downside is of course the need for a SpecialAPT.DAT to cater for this and the inherent support and maintenance needed. it's interesting that you would say this. i had the same experience when i was doing some work for an x-plane plugin, that parsing those files was tedious and so ... 1980's ... when Ben put the word out about changes to apt.data, as an RFC to the x-plane scenery list, i tried to advocate for an XML solution. i was shot down immediately, and _one_ of the reasons was that it was deemed that the current format is simple, and an XML format is more difficult, which i found to be the oppossite of my own thinking. it's nice to hear someone else say the current format is a pain too. Tony -- X-SA user ? 0.5.1 is out ! XData 0.1 for X-SA is out ! http://x-plane.dsrts.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi, Tony Pelton schrieb: On 6/10/06, dene maxwell [EMAIL PROTECTED] wrote: I know from my experience with FGTools, FGFS and TaxiDraw that parsing the APT file is not trivial ...the downside is of course the need for a SpecialAPT.DAT to cater for this and the inherent support and maintenance needed. it's interesting that you would say this. i had the same experience when i was doing some work for an x-plane plugin, that parsing those files was tedious and so ... 1980's ... [SNIP] it's nice to hear someone else say the current format is a pain too. Writing a parser is always work we rather wouldn't be doing as we'd rather devote ourselves to working with the data than to reading or writing it from or to file. What makes XML easier to parse is the presence of generic parser libraries that physically parse the XML entities. You still don't have your data cleanly fetched out of that. The property tree probably is one of the obligatory exceptions. The reason why parsing apt.dat is a PITA is the lots of data to be parsed and interpreted for runways and taxiways (lighting, material, stopways, etc.). This data doesn't get less with XML and it certainly won't get less with the new format. Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On 6/10/06, Ralf Gerlich [EMAIL PROTECTED] wrote: Writing a parser is always work we rather wouldn't be doing as we'd rather devote ourselves to working with the data than to reading or writing it from or to file. yes. using XML, any number of parsers are available, AND they can do well formedness checks for you, AND XML is inherently more self documenting than record/delimeter based formats. The reason why parsing apt.dat is a PITA is the lots of data to be parsed and interpreted for runways and taxiways (lighting, material, stopways, etc.). This data doesn't get less with XML and it certainly won't get less with the new format. well, for me, it had nothing to do with the volume. it had to do with having to write lots of brittle code to parse the data. i mean seriously, a format that relies on having to understand the first field for any given record, as defining its type ... and having to do stuff like skip the first N lines ... and having an end of file record ? and to be advocating for expanding it ... in 2006 ? i was trying to advocate for XML, as i could have then brought XSLT and XPath tools to the table, in addition to having the parsing done for free, which would have made the data easier to use. i was also trying to point out that, ime, XML formats are much easier to mutate and keep compatible over the longer term, and XSLT is a great way for migrating older formats to newer formats. ultimately though, it looks like the decision will be more of the same ... Cheers, Ralf Tony -- X-SA user ? 0.5.1 is out ! XData 0.1 for X-SA is out ! http://x-plane.dsrts.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Tony Pelton wrote: well, if austin wrote it, besides being amused by the thought, you'd have to question his sanity, given the code base of parsers already available in the wild. I'm sure that XML would also end up with a few new features, like extend DTD while in flight and each element and tag now has it's Cl, Cm and Cd calculated individually, giving unprecedented flight realism. Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Sat, 10 Jun 2006 11:40:23 -0500 Curtis L. Olson wrote: That's the big argument that Ben Supnik gave me. He converted a single airport to an xml represenation and it was about 2Mb just for the one airport. Of course he used the most verbose xml variant he could devise, but it is true that the data size would expand, and for this particular amount of data, it would likely be a substantial expansion. So you break the file up? -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 signature.asc Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Saturday 10 June 2006 20:34, Ralf Gerlich wrote: BTW: We still have some issues regarding the FlightGear graphics engine to solve if we want curved taxiways and generalised markings (stopbars, etc.), don't we? Yes, TerrorGear won't do anything with the new data. Who's up for some hairy 3D maths? Paul ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] cvs commit e-mail
hi all, i'm new around here. is there a list i can join, or someone i can ask, such that i could get e-mail from the CVS server when someone commits to the codebase ? i'm slowly trying to get up to speed on the codebase, and seeing what things people are working on, by seeing what code they are committing would really help i think. any help for me ? tia, Tony -- X-SA user ? 0.5.1 is out ! XData 0.1 for X-SA is out ! http://x-plane.dsrts.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cvs commit e-mail
Tony Pelton wrote: is there a list i can join, or someone i can ask, such that i could get e-mail from the CVS server when someone commits to the codebase ? FlightGear-CVSLogs http://www.flightgear.org/mail.html Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] remove me from discussion list
Dustin Hilderley wrote: I think i may have accidentally become a part of a discussion list that is overflowing my in box please help me to be free of this inconvenience [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Dustin, Done. -- Bill Earnest [EMAIL PROTECTED] Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] collision avoidance
Hi Gonzalo, I've managed to get Mathias' suggestion of using get_elevation_m but with strange AGL values. I used calc_gc_lon_lat from simgear/math/polar3d.hxx for getting the latitude/longitude from x-meters away, then feeding the resulting lat/lon values into get_elevation_m, but it seems this might not be correct (result is not wgs84?). When flying over the ocean, I get an varying AGL value of 10-20ft. With this said, could you suggest an alternative? Additionally, could you please suggest how I could use the bounding box method? thanks, Michael. From: Gonzalo Aguilar Delgado [EMAIL PROTECTED] Reply-To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] collision avoidance Date: Fri, 02 Jun 2006 13:58:18 +0200 Hi all! Best thing to do would be bounding boxes. It's fast to calculate and relative accurate. You can calculate bounding box for each object one time and use every time! On Friday 02 June 2006 01:44, Mick - wrote: I'm trying to create a type of collision avoidance capability, and would need AGL data from in front of the aircraft. Could someone suggest where (in the code) I could get projected elevation information, for example, AGL data 10 meters in front. My understanding is that AGL is taken from the nose of the aircraft. In C++ code src/Scenery/scenery.hxx one of: FGScenery::get_elevation_m; FGScenery::get_cart_elevation_m; should do what you need. Dependent on how often you need to compute that and how far away from the actual aircraft you need to know that the groundcache accessible from FGInterface might be faster. That provides you with the same information in a small area around the aircraft (usually only the bonunding sphere of the aircraft model plus a few meters) in a more performant way. Greetings Mathias -- Gonzalo Aguilar Delgado - Ingeniero en Informática [ Seguridad Medios de pago ] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
