Re: [Flightgear-devel] TaxiDraw-0.2.2 released
Curtis Olson wrote: Dale E. Edmons wrote: Yes, I'm trying to use Terragear to bring some life back into an old SPX-200 system. (ie flat runways) Other than polygon count this is the biggest problem I have. Oh, well. You should be able to hack terragear to limit the max runway grade to 0% and/or limit the overall elevation change allowed to 0 meters. I should have said, "I'm using TerraGear Scenery." I've actually hacked FlightGear Scenery Designer to do most of the work (with lots of help from Fred). The runways are a mixed blessing. In the future we may be required to match the actual slope of runways so I'm leaving this alone until the last minute when I can display scenes on the simulator (right now only the modeling station will display my autogenerated models). Thanks for the info though, as this may be something that I may be forced to do. (I'm just starting to look into the TerraGear code to see if I can generate whole chunks at a time. I haven't figured out a good way to adapt the offset UTM conversion I do to convert to flat map type xy coordinates like I do under FGSD.) Thanks. Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
Chris Metzler wrote: On Tue, 26 Oct 2004 19:08:23 -0700 Curtis Olson <[EMAIL PROTECTED]> wrote: Chris Metzler wrote I'm wondering whether we know what the X-Plane format really *is*. Robin does a pretty good job of documenting his format on his website. Sorry, I wasn't clear. I knew that; I know/knew what the format is now. What I was trying (apparently poorly) to say was that I was getting the impression that that formatting was about to change. The changes are usually very subtle ... often things like XP vN-1 only supports 200 airports within a 1x1 degree area whereass XP vN+1 will support 250 airports within that same area. Robin then tweaks his scripts to export more of the airports, but still live within the upper limit. The data file might crash (or at least not work with) XP vN-1. Occasionally there are more substantial changes, but often it's related to built in static table limits of x-plane. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
On Tue, 26 Oct 2004 19:08:23 -0700 Curtis Olson <[EMAIL PROTECTED]> wrote: > Chris Metzler wrote >> >>I'm wondering whether we know what the X-Plane format really *is*. >> > > Robin does a pretty good job of documenting his format on his website. Sorry, I wasn't clear. I knew that; I know/knew what the format is now. What I was trying (apparently poorly) to say was that I was getting the impression that that formatting was about to change. -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 pgpp4QCHNPs8S.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
Dale E. Edmons wrote: Yes, I'm trying to use Terragear to bring some life back into an old SPX-200 system. (ie flat runways) Other than polygon count this is the biggest problem I have. Oh, well. You should be able to hack terragear to limit the max runway grade to 0% and/or limit the overall elevation change allowed to 0 meters. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
Chris Metzler wrote I'm wondering whether we know what the X-Plane format really *is*. Robin does a pretty good job of documenting his format on his website. Since the beginning of September, Robin Peel has been saying that a new set of files are coming out "next weekend, September 18." He's busy like all of us, new data supposedly has now been released. On a related note, since the X-Plane files are apparently going to support this soon, is there any possibility of being able to "label" taxiways with identifiers (e.g. "taxiway A")? The fileformat already has a placeholder for taxiway labels. Right now they are all listed as "xxx". Finally, I'm wondering how you're going to handle conflicts between future X-Plane data releases, and changes that people have sent to you. For example, suppose an FG user sends some changes to an airport to you; and suppose some X-Plane user sends some changes to the same airport to Robin Peel (or the DAFIF changes for that airport). The next X-Plane dataset contains the changes that Robin Peel received, which are different from the ones you have. How would that get resolved? Go with theirs? Go with ours? Contact the person who sent you changes to review the situation and update? The plan is to submit our local changes to Robin for inclusion in his next release. But the exact details of integrating our changes with his next release are a little bit open for discussion. Clearly some clever scripts could help the process tremendously, but there would need to be some human oversight. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ 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] TaxiDraw-0.2.2 released
David Luff wrote: On 10/19/04 at 11:57 AM Chris Metzler wrote: > I think that your idea to put a taxiway designator in the 'xxx' (bet this message gets flagged as spam now!) 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. I am not sure whether there's much communication ongoing between the two projects, anyway: David, as you might remember I recently also had some talks with the X-Plane folks because of the IVAO/VATSIM thing, Ben (the developer of XSquawkBox) also functions as a contractor for general X-Plane development, I am not sure whether I forwarded that particular eMail to you where he explicitly mentioned how grateful the X-Plane community is about various opensource tools that can (and are) also be used for X-Plane. So, based on that and on the mail exchanges I've had with him so far I am inclined to bet that he would probably not mind forwarding your request/recommendation to Austin Meyers (the X-Plane author). My impression is that the odds are looking good for such an inquiry ;-) - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
On October 20, 2004 06:12 am, David Luff wrote: > >I'm wondering whether we know what the X-Plane format really *is*. > >Since the beginning of September, Robin Peel has been saying that a > >new set of files are coming out "next weekend, September 18." But he > >also says that these files won't work at all with earlier versions > >of X-Plane. That may simply be because of the new information content > >in fields that were basically dummy (see below) choking reads that > >don't know how to handle them; but it made me wonder if there's a file > >format change coming up. At the very least, his comments about being > >able to declare aprons separate from taxiways suggest a new record type. > > 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. May be it is time FlightGear should have its own file format? Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
On 10/19/04 at 11:57 AM Chris Metzler wrote: > >I'm wondering whether we know what the X-Plane format really *is*. >Since the beginning of September, Robin Peel has been saying that a >new set of files are coming out "next weekend, September 18." But he >also says that these files won't work at all with earlier versions >of X-Plane. That may simply be because of the new information content >in fields that were basically dummy (see below) choking reads that >don't know how to handle them; but it made me wonder if there's a file >format change coming up. At the very least, his comments about being >able to declare aprons separate from taxiways suggest a new record type. > 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. >On a related note, since the X-Plane files are apparently going to support >this soon, is there any possibility of being able to "label" taxiways with >identifiers (e.g. "taxiway A")? I know that right now, we don't do >anything with that information; but we might in the future, with sign >placement or ground control instructions or whatever, and if people have >that information and the opportunity to add it to the database, we might >as well, rather than having to go back and add it later. Something >along these lines (re: taxiways and aprons): > >http://baron.flightgear.org/pipermail/flightgear-devel/2004-July/029106.htm l > I think that your idea to put a taxiway designator in the 'xxx' (bet this message gets flagged as spam now!) 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. On the other hand, genapts could be made to understand it as an extension to the default format. And if as you say the X-Plane format is likely to contain it soon then that's excellent. 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. 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. 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] TaxiDraw-0.2.2 released
On 10/19/04 at 11:57 AM Chris Metzler wrote: >Finally, I'm wondering how you're going to handle conflicts between future >X-Plane data releases, and changes that people have sent to you. For >example, suppose an FG user sends some changes to an airport to you; and >suppose some X-Plane user sends some changes to the same airport to Robin >Peel (or the DAFIF changes for that airport). The next X-Plane dataset >contains the changes that Robin Peel received, which are different from >the ones you have. How would that get resolved? Go with theirs? Go with >ours? Contact the person who sent you changes to review the situation and >update? > Well, in a way this is no different from before, in that several folk could have separately sent Robin submissions for the same airport during the same data cycle. There's really no way round this - at least the airport in question should end up with some taxiways at the end of the day. I shall endeavour to get them sent on to him as soon as possible once he's back in communication in order to minimise the chance of this. FWIW, don't bother doing KOXR, KGYY, KDPA or KCPU or you'll be duplicating my work. At the end of the day, I figured that maintaining some sort of diff to the master database was the only way that TaxiDraw users would get to see their stuff in FlightGear in the near future, especially given that regenerating the scenery oneself is somewhat non-trivial, and requires some extremely large downloads. I guess we'll see how it works out in time. 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] TaxiDraw-0.2.2 released
On 10/19/04 at 8:41 PM Paul Surgeon wrote: >I suggest that changes made override the "official" data until someone has >a >chance to review the problem airport. We can't have people spending hours >building nice taxiways and then having the runways dancing around the >place >every time there is an update. >I know I would be a little upset if I've spent 100 hours building taxiways >and >10% of them no longer line up with the runways 6 months down the line. > I don't think that this should be a big problem anymore. I believe that most of the runway shifting occured when he (Robin) moved over to the DAFIF as the base data, and a lot of incorrectly user-positioned runways got moved. Of course, some correctly user positioned runways got moved to incorrect DAFIF positions (like at Nottingham!). However, if a shift of all runways at a given airport does now occur, it's very easy to simply drag or rotate the taxiways en-masse to the new position in TaxiDraw. Simply draw a selection box round them all and do it. If some of the runways shift with respect to others then it implies that they weren't layed out correctly to begin with, and that sort of thing really needs sorting before starting on a Taxiway layout. If using the USGS photos as a backdrop then keep in mind that a number of runways have been built or extended since the photos were taken. 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] TaxiDraw-0.2.2 released
Paul Surgeon wrote: I'm not complaining about the sloping runways - I absolutely love it! Me too. In fact that was the number one feature that stood out to me when I first tried FlightGear. Whoever did the coding (Curt?) did a great job. It's just a pain from a programming point of view to work with "real values". Yes, I'm trying to use Terragear to bring some life back into an old SPX-200 system. (ie flat runways) Other than polygon count this is the biggest problem I have. Oh, well. Paul On Tuesday, 19 October 2004 23:34, Dale E. Edmons wrote: The big guys are moving to *non-flat* runways. Flat runways cause many problems with landing altitude, G/S, touchdown point, and most of all, *realizism*. In a word, "don't do flat runway modeling"! This may become a point with FAA certification in the near future as well. Flat=bad, correctly modeled = good. Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
I'm not complaining about the sloping runways - I absolutely love it! In fact that was the number one feature that stood out to me when I first tried FlightGear. Whoever did the coding (Curt?) did a great job. It's just a pain from a programming point of view to work with "real values". Paul On Tuesday, 19 October 2004 23:34, Dale E. Edmons wrote: > The big guys are moving to *non-flat* runways. Flat runways cause many > problems > with landing altitude, G/S, touchdown point, and most of all, > *realizism*. In a word, > "don't do flat runway modeling"! This may become a point with FAA > certification in > the near future as well. Flat=bad, correctly modeled = good. > Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
Paul Surgeon wrote: While we're on the taxiway topic ... I've been toying around with some taxiway ideas over the last couple of days after having played with David's TaxiDraw app. TaxiDraw is an excellent piece of work but I really don't like the way TerraGear/FlightGear create and handle taxiways. Yes, they are simple and were probably done in a hurry just to get something working quickly but they don't come close to being "correct". The biggest things I would like to see implemented with regards to taxiways are : 1. Proper use of directional textures 2. Proper taxiway markings and lighting (from runway to parking ramp) I realize that these are no small changes! It will require : 1. A new drawing tool (Similar to the way it was done in Fly! but more user friendly) 2. A change in the way TerraGear builds taxiways 3. A new airport/taxiway database to store the tons of taxiway and apron data into The new drawing tool will be responsible for building the taxiways at the polygon level (including texturing) because unique cases will require manual tweaking and drawing. TerraGear will be responsible for merging the DEM data with the raw polygon and texture data. Later on we can get the AI to taxi around the airport correctly according to ATC instructions. ;-) Of course someone has to do all this hard work so I've started playing with some code to do the taxiway drawing and rendering. I just hope I can keep focused - so many distractions and so little time. :) One thing that is a real pain to deal with is the issue that airports are not flat in FlightGear. Of course non-flat airports and runways look so cool but when you get down to the polygon level you quickly realize why "the big guys" stick with flat airports. It makes texturing and layering polygons 10 times more complex. The big guys are moving to *non-flat* runways. Flat runways cause many problems with landing altitude, G/S, touchdown point, and most of all, *realizism*. In a word, "don't do flat runway modeling"! This may become a point with FAA certification in the near future as well. Flat=bad, correctly modeled = good. Curt ... why oh why?! :P If you guys have any suggestions please add them. I've taken note of Chris Metzler's suggestion of labeling taxiways so that we can automatically place taxiway signs later on. That's a great idea! Paul Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
On Tuesday, 19 October 2004 17:57, Chris Metzler wrote: > I'm wondering whether we know what the X-Plane format really *is*. > Since the beginning of September, Robin Peel has been saying that a > new set of files are coming out "next weekend, September 18." But he > ... If we start doing some major enhancements to taxiways we are going to have to store them in another file and format anyway. > On a related note, since the X-Plane files are apparently going to support > this soon, is there any possibility of being able to "label" taxiways with > identifiers (e.g. "taxiway A")? That is a good feature that I'll keep in mind when I'm playing around with some ideas I have. > Finally, I'm wondering how you're going to handle conflicts between future > X-Plane data releases, and changes that people have sent to you. For I suggest that changes made override the "official" data until someone has a chance to review the problem airport. We can't have people spending hours building nice taxiways and then having the runways dancing around the place every time there is an update. I know I would be a little upset if I've spent 100 hours building taxiways and 10% of them no longer line up with the runways 6 months down the line. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
While we're on the taxiway topic ... I've been toying around with some taxiway ideas over the last couple of days after having played with David's TaxiDraw app. TaxiDraw is an excellent piece of work but I really don't like the way TerraGear/FlightGear create and handle taxiways. Yes, they are simple and were probably done in a hurry just to get something working quickly but they don't come close to being "correct". The biggest things I would like to see implemented with regards to taxiways are : 1. Proper use of directional textures 2. Proper taxiway markings and lighting (from runway to parking ramp) I realize that these are no small changes! It will require : 1. A new drawing tool (Similar to the way it was done in Fly! but more user friendly) 2. A change in the way TerraGear builds taxiways 3. A new airport/taxiway database to store the tons of taxiway and apron data into The new drawing tool will be responsible for building the taxiways at the polygon level (including texturing) because unique cases will require manual tweaking and drawing. TerraGear will be responsible for merging the DEM data with the raw polygon and texture data. Later on we can get the AI to taxi around the airport correctly according to ATC instructions. ;-) Of course someone has to do all this hard work so I've started playing with some code to do the taxiway drawing and rendering. I just hope I can keep focused - so many distractions and so little time. :) One thing that is a real pain to deal with is the issue that airports are not flat in FlightGear. Of course non-flat airports and runways look so cool but when you get down to the polygon level you quickly realize why "the big guys" stick with flat airports. It makes texturing and layering polygons 10 times more complex. Curt ... why oh why?! :P If you guys have any suggestions please add them. I've taken note of Chris Metzler's suggestion of labeling taxiways so that we can automatically place taxiway signs later on. That's a great idea! Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
Hi Dave. This is great work. Seriously, it's a fabulous contribution, and I'm pumped to get started using it. I have a couple of quick questions: > Version 0.2.2 fixes several serious bugs in the X-Plane format writer > present in 0.2.0 and 0.2.1. All users should upgrade, since X-Plane > format is becoming the default format for FlightGear in the very near > future. I'm wondering whether we know what the X-Plane format really *is*. Since the beginning of September, Robin Peel has been saying that a new set of files are coming out "next weekend, September 18." But he also says that these files won't work at all with earlier versions of X-Plane. That may simply be because of the new information content in fields that were basically dummy (see below) choking reads that don't know how to handle them; but it made me wonder if there's a file format change coming up. At the very least, his comments about being able to declare aprons separate from taxiways suggest a new record type. On a related note, since the X-Plane files are apparently going to support this soon, is there any possibility of being able to "label" taxiways with identifiers (e.g. "taxiway A")? I know that right now, we don't do anything with that information; but we might in the future, with sign placement or ground control instructions or whatever, and if people have that information and the opportunity to add it to the database, we might as well, rather than having to go back and add it later. Something along these lines (re: taxiways and aprons): http://baron.flightgear.org/pipermail/flightgear-devel/2004-July/029106.html Finally, I'm wondering how you're going to handle conflicts between future X-Plane data releases, and changes that people have sent to you. For example, suppose an FG user sends some changes to an airport to you; and suppose some X-Plane user sends some changes to the same airport to Robin Peel (or the DAFIF changes for that airport). The next X-Plane dataset contains the changes that Robin Peel received, which are different from the ones you have. How would that get resolved? Go with theirs? Go with ours? Contact the person who sent you changes to review the situation and update? Thanks muchly. And thanks again for TaxiDraw! -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 pgpUU2HyF4GW3.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] TaxiDraw-0.2.2 released
TaxiDraw-0.2.2 is now released. Versions 0.2.2 and 0.2.1 fix several serious bugs in v0.2.0 - all users should upgrade. TaxiDraw is available from http://www.nottingham.ac.uk/~eazdluf/taxidraw.html Changes are as below: * 0.2.2 *** Version 0.2.2 fixes several serious bugs in the X-Plane format writer present in 0.2.0 and 0.2.1. All users should upgrade, since X-Plane format is becoming the default format for FlightGear in the very near future. * 0.2.1 *** Version 0.2.1 fixes several serious bugs in 0.2.0, and adds some feature refinements. All users should upgrade. Changes from 0.2.0: * Removed an undocumented option left over from early development testing where pressing 'Y' would silently move the selected taxiway to position 3 in the list. Ouch - how did that get left in? * Fixed a nasty bug where repeately viewing the properties of one taxiway could reduce either the length or width by one foot each time. This seems to have only occured on Linux, not Windows. * Improved the taxiway selection criteria where more than one taxiway is under the mouse-click location. Previously the highest taxiway in the list was selected. Now the criteria is that if one taxiway under the click point is already selected that will be selected again, otherwise that the smallest taxiway under the click point will be selected. This makes operations on small taxiway segments that are largly obscured by larger ones much easier. Additionally, taxiways are now selected preferentially to runways where an overlap occurs at the selection point. * Fixed the grid corruption bug which occured at certain projections and zoom values. * Moving runways and beacons can now be un-done, and will set the dirty flag. * Cancel now works for the runway and taxiway dialogs (previously data was transferred even if cancel was pressed). * Changing taxiway or runway properties through the properties dialog can now be un-done, and will set the dirty flag. * Constrained move now works for runways (when unlocked!). Pressing shift whilst dragging with the mouse will constrain a runway or taxiway to move only in the direction of its longitudinal axis - this was already implemented for taxiways but not runways. * The default editing units can now be set to meters if desired. This setting will be remembered between sessions. This is not recommended, since the data is saved between sessions in integer feet (as in the master databases), but since the foot has a significantly smaller resolution than meters this should work OK for those who really want to work in meters. * Runways can now be locked and unlocked from the edit menu, and the shortcut key to toggle the runway lock has been changed from 'U' to 'Ctrl+Shift+U' to make accidental unlocking harder. * Lighting preview can now be accessed from the View menu. * Fixed a gcc-2.95 compile error. 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
