Re: [Flightgear-devel] apt.dat changes ?
Thank you Martin, my last download was jan 2006 and it's been updated june 2006 I stand corrected :-} cheers :-D ene >From: Martin Spott <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED],FlightGear developers discussions > >To: flightgear-devel@lists.sourceforge.net >Subject: Re: [Flightgear-devel] apt.dat changes ? >Date: Tue, 13 Jun 2006 05:02:24 + (UTC) > >"dene maxwell" wrote: > > > What was ths source URL for that ..? > >French AIP VFR is on: > > http://www.sia.aviation-civile.gouv.fr/aip/enligne/UK/home.htm > >Martin. >-- > Unix _IS_ user friendly - it's just selective about who its friends are ! >-- > > >___ >Flightgear-devel mailing list >Flightgear-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Check out the latest video @ http://xtra.co.nz/streaming ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
Hi Ben, bsupnik wrote: > On the other hand, it's a lot less work to write a client for FG than to > write a client, server, ATC client, possibly write clients for other > flight sims to get higher user numbers, write the protocols, find a VoIP > lib, and also get the servers and donated bandwidth and then convince a > few thousand people to use the service on a regular basis. Just for your information: FlightGear actually _has_ a working multiplayer interface, including a protocol that probably outperforms the VATSIM protocol, there are multiplayer servers and even a 'moving map' based on Gogle Maps, there is a choice of suitable OpenSource VoIP client libraries as well as servers that would do the job. But you're right, we currently don't have an ATC client (well, there _are_ OpenSource ATC clients which probably could be modified to work with our multiplayer servers) and, this argument really strikes: We won't be able to build a community that large in a reasonable time. As we experience several thousand downloads of FlightGear binary packages per month, apparently only a few users at ready for this level of fidelity. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] UAV Heli and Matlab
Josh Babcock wrote: > For instance: translational lift, ground effect, retreating blade stall, > and VRS. I don't think that there is any kind of realism regarding the > energy model for the blades. (AFAIK, all they do is spool up to the > specified rpm when the engines are turned on and then back down again > when they turn off) This is what nowadays is done even on many model helicopters: They spool up the whole thing, activate the governor, which typically part of a FADEC in large helicopters, and have the rotor running at fixed speed for the whole trip. Regarding retreating blade stall, at least there's an effect that comes close when you cruise at high speed. I _do_ agree that the BO is able to reach much higher speed than I'd expect from the real helicopter I don't claim the helicopter FDM in FlightGear is perfect, but turning it down just because a few details are missing, whereas most of the actual in-flight behaviour is pretty well done, is unjustified, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
"dene maxwell" wrote: > What was ths source URL for that ..? French AIP VFR is on: http://www.sia.aviation-civile.gouv.fr/aip/enligne/UK/home.htm Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
What was ths source URL for that ..? ...it certainly provides that data needed I would like to add it to my AIP database Cheers :-D ene >From: "Ampere K. Hardraade" <[EMAIL PROTECTED]> >Reply-To: FlightGear developers discussions > >To: FlightGear developers discussions > >Subject: Re: [Flightgear-devel] apt.dat changes ? >Date: Tue, 13 Jun 2006 00:37:50 -0400 > >On Tuesday 13 June 2006 00:32, Ampere K. Hardraade wrote: > > > > > IIRC the French > > > > > CAA diagrams don't even have lat/long references apart from the > > > > > various navaid locations. > > > > > > > >Yes they do. > > > > > > Not Toulouse > > > http://airventure2006.blogspot.com/2006/06/toulouse-aip.html > > > > You are on the wrong page! :P > > > > Ampere > >Haha, wrong document to begin with. > >Page 3, in http://www.cs.yorku.ca/~cs233144/Toulouse.pdf > >Ampere > > >___ >Flightgear-devel mailing list >Flightgear-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Need more speed? Get Xtra Broadband @ http://jetstream.xtra.co.nz/chm/0,,202853-1000,00.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Tuesday 13 June 2006 00:32, Ampere K. Hardraade wrote: > > > > IIRC the French > > > > CAA diagrams don't even have lat/long references apart from the > > > > various navaid locations. > > > > > >Yes they do. > > > > Not Toulouse > > http://airventure2006.blogspot.com/2006/06/toulouse-aip.html > > You are on the wrong page! :P > > Ampere Haha, wrong document to begin with. Page 3, in http://www.cs.yorku.ca/~cs233144/Toulouse.pdf Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Tuesday 13 June 2006 00:06, dene maxwell wrote: > but I don't want to "prove you wrong" ... can we agree that TaxiDraw > provides certain functionality at the moment that works with the current > format of apt.dat... any replacement should provide the same functionality > OR a mechanism whereby that functionality is not needed? Sure. > > > IIRC the French > > > CAA diagrams don't even have lat/long references apart from the various > > > navaid locations. > > > >Yes they do. > > Not Toulouse > http://airventure2006.blogspot.com/2006/06/toulouse-aip.html You are on the wrong page! :P Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Ampere, I really don't want to pursue an arguement about right and wrong... the approaches are different and each has it's merits .. I would have really liked to have your tools available to me when I started converting the current FAA diagram >On Monday 12 June 2006 19:47, dene maxwell wrote: > > Unfortunately the data kept by FAA/CAA or what ever the local > > administration is called is often out-of-date or just plain wrong. > > Experience of the last month has taught me that. Poring over aerial >photos > > and current third-party documentation has shown significant >discrepencies. >Keep in mind that those FAA/CAA diagrams are being used in real aviation >right >now, not the aerial photos or third-party documentation. While I would not >rule out that that those airport diagrams may contain errors, I am more >certain that the aerial photos and third-party documentation you mentioned >are the ones that are wrong. refer; http://airventure2006.blogspot.com/2006/06/kosh-apt-810-layout.html this is the data out of the apt-810 file represented in TaxiDraw and also appears in FGFS Scenery 09.10 http://airventure2006.blogspot.com/2006/06/faa-representation-of-kosh.html this is the current FAA representation of KOSH, note is does have taxiway "Alpha" and taxiway "Papa" is connected to the end of rwy22. http://airventure2006.blogspot.com/2006/06/aerial-photo-photo-only-2-years-old.html this is a 2-year old aerial photo notice the additional grass taxiways to the right and left of runway 36/18, the surarface types on runways 22 & 31 I have heaps more evidence of the various anomalies between the various documention sources and RL but I don't want to "prove you wrong" ... can we agree that TaxiDraw provides certain functionality at the moment that works with the current format of apt.dat... any replacement should provide the same functionality OR a mechanism whereby that functionality is not needed? is there away to convert svg format to btg to avoid TerrorGear? > > > IIRC the French > > CAA diagrams don't even have lat/long references apart from the various > > navaid locations. >Yes they do. Not Toulouse http://airventure2006.blogspot.com/2006/06/toulouse-aip.html > >Ampere > > Mate, I am really interested in the work you're doing and see real benefit it in as I said before right/wrong is not on my agenda ...how do we achieve the best given a starting point and a goal is. best regards :-D ene _ Become a fitness fanatic @ http://xtramsn.co.nz/health ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] UAV Heli and Matlab
Martin Spott wrote: > "Correu PelDavid" wrote: > >> Isn't the FDM much good? >> I thought it would be. What fidelity lacks? > > I find the helicopter FDM quite reasonable. I've been flying a model > helicopter about the time when I finished school but this is > already 20 years ago, so my memory might play tricks with me. Still the > BO-105 behaves very much as how I'd expect it from knowledge of the > aerodynamical effects. > > In my opinion the biggest drawback is the lack of appropriate > helicopter controls. A joystick and pedals for 200 Euro each will never > replace a real stick, collective and pedals. Successfull helicopter > flight is achieved by small and highly precise movement of all the > controls you have in such a beast - and I've personally never met > simulator controls that really meet the requirements. > > Cheers, > Martin. Though I have never flown a helo, I have a friend who has and I agree with you on the lack of good controls. Also, don't get me wrong, I think that YASim is a good helo sim, though not as good as X-Plane in many respects. I also feel, however, that there are some important things missing from the FDM. For instance: translational lift, ground effect, retreating blade stall, and VRS. I don't think that there is any kind of realism regarding the energy model for the blades. (AFAIK, all they do is spool up to the specified rpm when the engines are turned on and then back down again when they turn off) There's no coupling at all between blade energy and vertical acceleration and speed. You can't affect rotor or engine RPM with the collective at all. Try autorotating some time. Other less important missing features include: effect of rotor wash on other rotors and wings export of data regarding rotor disc coning and orientation (for animations) support for multiple engines support for engine throttles (PCLs, FADECs or manual throttles) 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 Mon, 12 Jun 2006 18:56:02 -0400, Ampere wrote in message <[EMAIL PROTECTED]>: > On Monday 12 June 2006 03:50, Thomas F�rster wrote: > > The logical layout (taxiway names, aprons, tower locations etc.) is > > then put on top of that (i.e. extra tags and attributes). > > You can group objects into different layers that you can named. You > can also name an object, such as a polyline, as "Taxiway X" or > "Runway ##". > > The above SVG examples have the buildings, runways, and taxiways > separated into different layers. These layers are named "buildings", > "runways", and "taxiways" respectively. ..I like this scheme, will allow the 3 RL KOSH'es, KOSH-normal, and KOSH-North and KOSH-South during AirVenture, each in its own set of layers. :o) -- ..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] vatsim
On Mon, 12 Jun 2006 19:47:10 -0400, bsupnik wrote in message <[EMAIL PROTECTED]>: > Hi Y'all, > > GWMobile wrote: > > Why not just duplicate vatsim with independent GPL programming? > > I think the point of VATSIM (and IVAO) is that they are existing > communities with user bases that show up on a regular basis. If you > wrote a pilot client for FG you could then go fly online on any given > night and be pretty sure you'd have live ATC, without convincing > anyone else to get involved, because you'd be joining an existing > community. ..or shanghaiing it with a better deal. ;o) > That's a double-edged sword...if you don't like VATSIM's > admin/moderator policy or its management or dev policy, well, it > already exists so you wouldn't have the kind of influence that you > get from starting things on the ground floor. ..there _are_ other independent server communities out there. ;o) > On the other hand, it's a lot less work to write a client for FG than > to write a client, server, ATC client, possibly write clients for > other flight sims to get higher user numbers, write the protocols, > find a VoIP lib, and also get the servers and donated bandwidth and > then convince a few thousand people to use the service on a regular > basis. ..in the short term, agreed. The long term is a different matter and will be decided on its own merits, like it or not. Ethics is "just" one such important merit. ;o) > So I think you guys have to decide your goals before you can evaluate > an approach! ..one of the fun things here, is how trial and error works in these meritocracies, chk out which license the successful and major "open source" projects use and see if it matches our. ;o) -- ..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 ?
On Monday 12 June 2006 19:47, dene maxwell wrote: > Unfortunately the data kept by FAA/CAA or what ever the local > administration is called is often out-of-date or just plain wrong. > Experience of the last month has taught me that. Poring over aerial photos > and current third-party documentation has shown significant discrepencies. Keep in mind that those FAA/CAA diagrams are being used in real aviation right now, not the aerial photos or third-party documentation. While I would not rule out that that those airport diagrams may contain errors, I am more certain that the aerial photos and third-party documentation you mentioned are the ones that are wrong. > Dumb is a very subjective assessment, agreed it is time-comsuming, but is > sometimes necessary to get not only positioning correct but also surface > type. The positioning would be correct as long as the lat/lon information on the aerial photo is correct. If those lat/lon information is incorrect, then all those time spent on positioning would be wasted. > I seem to remember a while ago I provided examples of CAA airport > documentation for conversion into SVG format and it couldn't be done > because the color scheme used was not what the automated process needed. I > am not aware of any numerical description available that would solve this. > It is really great that you have managed to get this working for FAA > diagrams ... It will be even better when it can be applied globally. It could be done. It just that I "hardcoded" the color information into my script, and was too lazy to alter it just to prove that it would work for CAA airport diagrams. > >2) Lat/Long information is in the diagram itself. > > Generally the lat/long information in the FAA/CAA diagrams is too coarse > for some uses. I am currently doing AI flightplans and need to get Lat/long > for touch-down points, braking points, and taxi-ing points. TaxiDraw > provides this 6 decimal places. The FAA diagram doesn't. So what? Users like you and I generate those 6 decimal places, from aerial photos and third-party documentations that have incorrect lat/lon information. Who have better access to those information? Us or the authorities? > IIRC the French > CAA diagrams don't even have lat/long references apart from the various > navaid locations. Yes they do. Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Monday 12 June 2006 05:55, Hugo Vincent wrote: > In the case of Inkscape (I don't know about any of the other SVG > editors), a reasonably simple plugin should suffice for editing the > non-graphical aspects of the airport layout. There should be no need for a plugin. Just create a new layer, name it as "no-render", then put those non-graphical assets into it. Simple. Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
>On Monday 12 June 2006 04:22, dene maxwell wrote: > > Hi > > Having edited airports there are a few things that tools like TaxiDraw > > provide that are invaluable; > > > > 1) super-imposing the airport layout on top of a scaled background >image > > to allow placement of taxiways etc in proportion to the RL layout. > > 2) providing lat/long readout for any point on the layout. > > 3) showing centre lines for runways/taxiways. > > 4) catering for such things as edge lighting and centre line lighting >etc. > > 5) exporting the beacon information to stg files > > > > not to mention; layering info, (even biezer curves will need layering at > > the interfaces), surface types etc. > > > > If a program like Inkscape can duplicate this and is multiplatform then >by > > all means. > >Let see... > >1) Tracing taxiway outlines is time consuming and plain dumb. It takes >hours >just to create one airport. The SVG files on the other hand, are converted >from FAA Airport Diagrams, and it only took one command. Separating all >the >info in a SVG files took me less than ten minute. > Unfortunately the data kept by FAA/CAA or what ever the local administration is called is often out-of-date or just plain wrong. Experience of the last month has taught me that. Poring over aerial photos and current third-party documentation has shown significant discrepencies. Dumb is a very subjective assessment, agreed it is time-comsuming, but is sometimes necessary to get not only positioning correct but also surface type. I seem to remember a while ago I provided examples of CAA airport documentation for conversion into SVG format and it couldn't be done because the color scheme used was not what the automated process needed. I am not aware of any numerical description available that would solve this. It is really great that you have managed to get this working for FAA diagrams ... It will be even better when it can be applied globally. >2) Lat/Long information is in the diagram itself. > Generally the lat/long information in the FAA/CAA diagrams is too coarse for some uses. I am currently doing AI flightplans and need to get Lat/long for touch-down points, braking points, and taxi-ing points. TaxiDraw provides this 6 decimal places. The FAA diagram doesn't. IIRC the French CAA diagrams don't even have lat/long references apart from the various navaid locations. >3) You can create a new layer in inkscape and draw the center lines >wherever >you want. This degree of freedom would be extremely valuable when creating >centerlines on the apron. > >4) The lights could be automatically generated a long the edge of a >taxiway, >no big deal. > >5) This functionality could be added to the bash script. > >Ampere > Please don't get me wrong, I am not running down your efforts or approach. All I'm saying is that this is what TaxiDraw has at the moment and was asking the question. I look forward to an automated tool. As you rightly pointed out, in certain circumstances it can be a very time consuming process at the moment. Regards :-D ene _ 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] vatsim
Hi Y'all, GWMobile wrote: > Why not just duplicate vatsim with independent GPL programming? I think the point of VATSIM (and IVAO) is that they are existing communities with user bases that show up on a regular basis. If you wrote a pilot client for FG you could then go fly online on any given night and be pretty sure you'd have live ATC, without convincing anyone else to get involved, because you'd be joining an existing community. That's a double-edged sword...if you don't like VATSIM's admin/moderator policy or its management or dev policy, well, it already exists so you wouldn't have the kind of influence that you get from starting things on the ground floor. On the other hand, it's a lot less work to write a client for FG than to write a client, server, ATC client, possibly write clients for other flight sims to get higher user numbers, write the protocols, find a VoIP lib, and also get the servers and donated bandwidth and then convince a few thousand people to use the service on a regular basis. So I think you guys have to decide your goals before you can evaluate an approach! *Cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
On Monday 12 June 2006 15:22, Martin Spott wrote: > Ok, in theory having a closed source interface _might_ serve the > licensing issues, _but_: > - Who likes to have to use a closed source module in order to connect > their OpenSource flight simulation to VATSIM ? > - More important, who of the OpenSource developers likes to maintain a > closed source module, compile it at least for half a dozend > different platforms and play the lonesome cowboy to whom bug reports > will be adressed - without having any chance to share the load with > someone else ? > - Most important, who of the OpenSource developers likes to take the > risk of getting sued for license infringement because VATSIM > might claim he could have transferred source code from the closed > source interface to FlightGear ? > > Anyone ? > > Cheers, > Martin. I see another issue here. Even if the licensing issue is solved, there would still be problems. For example, planes hovering/submerging on taxiways and runways, because both us and MSFS have different scenery. To avoid this problem, we would have to force MSFS to use our better scenery. Who's up for that task? Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
Why not just duplicate vatsim with independent GPL programming? On Mon, 12 Jun 2006 5:52 pm, Arnt Karlsen wrote: > On Mon, 12 Jun 2006 14:39:40 -0500, Curtis wrote in message > <[EMAIL PROTECTED]>: > >> Martin Spott wrote: >> >> >Ok, in theory having a closed source interface _might_ serve the >> >licensing issues, _but_: >> > - Who likes to have to use a closed source module in order to >> > connect their OpenSource flight simulation to VATSIM ? >> > >> >> Does the bridge module between flightgear and vatsim need to be closed >> source? Or just non-GPL? My assumption is that all the closed source >> vatsim magic happens in a proprietary library? > > ..this is the story we are being told, AFAIUI. > >> We would link our application to this library. Am I wrong on this? >> Our application may not then be licensable under the gpl, but we could >> still make our portion of the code open and available. > > ..only one problem: Would any of us need to sign their NDA and > risk litigation? They may be nice now, but bad guys can easily grind > them flat in court, to get at us. At Groklaw, we have seen at least 2 > Canopy people die in suspect "suicidings", I'm guessing because they > learned something important. Just how powerful the GPL and copyright > law is, is best shown in how the GPL moots such "suicide" schemes for > people like us, Samba.org, Red Hat, IBM, who all hides under the GPL. > >> > - More important, who of the OpenSource developers likes to maintain >> > a closed source module, compile it at least for half a dozend >> > different platforms and play the lonesome cowboy to whom bug >> > reports will be adressed - without having any chance to share the >> > load with someone else ? > > ..maybe Vatsim staff? If they hire somebody to write it under the GPL, > they will own it too, and get "street" credibility here, talk is cheap, > but action talks loud. Either way. > >> Hmmm, this is dependent on the answer to your first point. Does the >> vatsim app have to be closed source, or is the vatsim app that >> we/someone creates simply an app that has to link to a non-gpl, >> proprietary library? > > ..neither. Let's go dance the good old proven Samba way. > >> > - Most important, who of the OpenSource developers likes to take the >> > risk of getting sued for license infringement because VATSIM >> > might claim he could have transferred source code from the closed >> > source interface to FlightGear ? >> >> Well I think it's clear that the vatsim folks are more than happy to > > ..sure. Let's make it beneficial for both parties. > >> work with us if we are willing to meet them on their terms. > > ..these are negotiable. Let's see if we can talk them into GPL it > all, > both Red Hat and IBM makes good money on their GPL business. > > ..I see _no_ reason why Vatsim, the X-plane guys etc should'nt be able > to do likewise. > >> If we develop a friendly cooperative relationship with them instead of >> an adversarial relationship, and if we follow their procedures and >> guidelines, why would there be a risk of being sued? > > ..in the ideal world, there isn't. IRL, there is, and the easiest way > to get at us (FG), is thru allegations of "IP" infringement, and the > best way is thru people like Vatsim, who are _much_ easier to screw > by litigation or by buying their debts and hike their loan etc expenses > up really high, etc, "if they don't wanna play ballmer games." > > ..you basically needs to be Microsoft, the SCO Group or North Korea to > not be able to profit from the GPL. > > -- > ..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 Bush's family and their Saudi partners make higher profits by preventing Saddam's huge Iraqi oil reserves from ever being sold. They'll Enron the world - George Watson 2001 For Hurricanes www.globalboiling.com For solar wind and earthquakes www.electricquakes.com Typos caused by two inch mobile phone keyboard ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Monday 12 June 2006 04:22, dene maxwell wrote: > Hi > Having edited airports there are a few things that tools like TaxiDraw > provide that are invaluable; > > 1) super-imposing the airport layout on top of a scaled background image > to allow placement of taxiways etc in proportion to the RL layout. > 2) providing lat/long readout for any point on the layout. > 3) showing centre lines for runways/taxiways. > 4) catering for such things as edge lighting and centre line lighting etc. > 5) exporting the beacon information to stg files > > not to mention; layering info, (even biezer curves will need layering at > the interfaces), surface types etc. > > If a program like Inkscape can duplicate this and is multiplatform then by > all means. Let see... 1) Tracing taxiway outlines is time consuming and plain dumb. It takes hours just to create one airport. The SVG files on the other hand, are converted from FAA Airport Diagrams, and it only took one command. Separating all the info in a SVG files took me less than ten minute. 2) Lat/Long information is in the diagram itself. 3) You can create a new layer in inkscape and draw the center lines wherever you want. This degree of freedom would be extremely valuable when creating centerlines on the apron. 4) The lights could be automatically generated a long the edge of a taxiway, no big deal. 5) This functionality could be added to the bash script. Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] UAV Heli and Matlab
"Correu PelDavid" wrote: > Isn't the FDM much good? > I thought it would be. What fidelity lacks? I find the helicopter FDM quite reasonable. I've been flying a model helicopter about the time when I finished school but this is already 20 years ago, so my memory might play tricks with me. Still the BO-105 behaves very much as how I'd expect it from knowledge of the aerodynamical effects. In my opinion the biggest drawback is the lack of appropriate helicopter controls. A joystick and pedals for 200 Euro each will never replace a real stick, collective and pedals. Successfull helicopter flight is achieved by small and highly precise movement of all the controls you have in such a beast - and I've personally never met simulator controls that really meet the requirements. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Monday 12 June 2006 03:50, Thomas Förster wrote: > The logical layout (taxiway names, aprons, tower locations etc.) is then > put on top of that (i.e. extra tags and attributes). You can group objects into different layers that you can named. You can also name an object, such as a polyline, as "Taxiway X" or "Runway ##". The above SVG examples have the buildings, runways, and taxiways separated into different layers. These layers are named "buildings", "runways", and "taxiways" respectively. Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] UAV Heli and Matlab
On Tue, 13 Jun 2006 07:51:46 +1200, dene wrote in message <[EMAIL PROTECTED]>: > I agree and that's why I still fly helicopters even though I > can't even follow Rule #5. That's the nice thing about a Sim... > crashes don't hurt :-) ...the bad habits might, mightily too. ;o) -- ..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] vatsim
On Mon, 12 Jun 2006 14:39:40 -0500, Curtis wrote in message <[EMAIL PROTECTED]>: > Martin Spott wrote: > > >Ok, in theory having a closed source interface _might_ serve the > >licensing issues, _but_: > > - Who likes to have to use a closed source module in order to > > connect their OpenSource flight simulation to VATSIM ? > > > > Does the bridge module between flightgear and vatsim need to be closed > source? Or just non-GPL? My assumption is that all the closed source > vatsim magic happens in a proprietary library? ..this is the story we are being told, AFAIUI. > We would link our application to this library. Am I wrong on this? > Our application may not then be licensable under the gpl, but we could > still make our portion of the code open and available. ..only one problem: Would any of us need to sign their NDA and risk litigation? They may be nice now, but bad guys can easily grind them flat in court, to get at us. At Groklaw, we have seen at least 2 Canopy people die in suspect "suicidings", I'm guessing because they learned something important. Just how powerful the GPL and copyright law is, is best shown in how the GPL moots such "suicide" schemes for people like us, Samba.org, Red Hat, IBM, who all hides under the GPL. > > - More important, who of the OpenSource developers likes to maintain > > a closed source module, compile it at least for half a dozend > > different platforms and play the lonesome cowboy to whom bug > > reports will be adressed - without having any chance to share the > > load with someone else ? ..maybe Vatsim staff? If they hire somebody to write it under the GPL, they will own it too, and get "street" credibility here, talk is cheap, but action talks loud. Either way. > Hmmm, this is dependent on the answer to your first point. Does the > vatsim app have to be closed source, or is the vatsim app that > we/someone creates simply an app that has to link to a non-gpl, > proprietary library? ..neither. Let's go dance the good old proven Samba way. > > - Most important, who of the OpenSource developers likes to take the > > risk of getting sued for license infringement because VATSIM > > might claim he could have transferred source code from the closed > > source interface to FlightGear ? > > Well I think it's clear that the vatsim folks are more than happy to ..sure. Let's make it beneficial for both parties. > work with us if we are willing to meet them on their terms. ..these are negotiable. Let's see if we can talk them into GPL it all, both Red Hat and IBM makes good money on their GPL business. ..I see _no_ reason why Vatsim, the X-plane guys etc should'nt be able to do likewise. > If we develop a friendly cooperative relationship with them instead of > an adversarial relationship, and if we follow their procedures and > guidelines, why would there be a risk of being sued? ..in the ideal world, there isn't. IRL, there is, and the easiest way to get at us (FG), is thru allegations of "IP" infringement, and the best way is thru people like Vatsim, who are _much_ easier to screw by litigation or by buying their debts and hike their loan etc expenses up really high, etc, "if they don't wanna play ballmer games." ..you basically needs to be Microsoft, the SCO Group or North Korea to not be able to profit from the GPL. -- ..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] UAV Heli and Matlab
> Question #4: Has anybody tried the Matlab-FlightGear connection without > perishing on the try? If so, is there any documentation? > I don't know if there is any documentation. I kind of remember that Jon had asked someone to come up with a paper or something... but there is ofcourse the protocol documentation you can find with flightgear to find out what the udp packets look like. There also is a small toolbox you can download from the mathworks website which will help in sending and reading udp data in simulink. You can find that here http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=345 best of luck!! ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
"Curtis L. Olson" wrote: > Martin Spott wrote: >> - More important, who of the OpenSource developers likes to maintain >> a closed source module, compile it at least for half a dozend >> different platforms and play the lonesome cowboy to whom bug >> reports will be adressed - without having any chance to share the >> load with someone else ? >> > Hmmm, this is dependent on the answer to your first point. Does the > vatsim app have to be closed source, or is the vatsim app that > we/someone creates simply an app that has to link to a non-gpl, > proprietary library? To my understanding the library is closed source and you can attach anything you like to it - just let us assume the best scenario we can get. Still somebody who signed the NDA has to port the library to and debug on different platform/compiler-setups - most of which he won't have access to! This definitely will be a tough ride in the world of portable OpenSource flight simulation ;-)) > Well I think it's clear that the vatsim folks are more than happy to > work with us if we are willing to meet them on their terms. If we > develop a friendly cooperative relationship with them instead of an > adversarial relationship, and if we follow their procedures and > guidelines, why would there be a risk of being sued? Who kows ? These guys expect you to sign an NDA just to use an interface library at no cost. As long as this situation stands I personally would be pretty sceptical because I fear they have something to hide or I have to fear that they might react in a senseless way. Well, I don't _have_ to use this library :-) Have a nice day, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ 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: > * Josh Babcock -- Saturday 10 June 2006 15:27: >> Define the name of the texture in the hud.xml file, then map it onto the >> HUD glass directly in Blender or AC3D. > > Yeah. Done. Wasn't even difficult. :-) > > m. > > > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > Sweet. Where can I find example code? Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] UAV Heli and Matlab
Isn't the FDM much good? I thought it would be. What fidelity lacks?Does anybody pilot R/C helicopters to compare?What is the best FDM in FG for helis?And about the 5th rule... We ought to share a multiplayer sessions someday and take a look at the hover capabilities of the helis users. David2006/6/12, dene maxwell <[EMAIL PROTECTED]>: >"dene maxwell" wrote:>> > Rule #5 Until you can hover indefinitely over the same point on the>ground> > and and climb and descend without moving from that point, don't try >anything> > fancier...ie practice hovering.> > Rule #6 When you can hover, practice pulling up from level flight to a> > stationary hover.>>I don't agree. It's still much fun slowly flying around known terrain >in the helicopter even if you're not a skilled helicopter pilot - you>just won't manage to land the beast without crashing :-)>>Martin.>--I agree and that's why I still fly helicopters even though I can't even follow Rule #5. That's the nice thing about a Sim... crashes don't hurt :-):-D ene_Discover fun and games at @ http://xtramsn.co.nz/kids___Flightgear-devel mailing listFlightgear-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
Re: [Flightgear-devel] UAV Heli and Matlab
>"dene maxwell" wrote: > > > Rule #5 Until you can hover indefinitely over the same point on the >ground > > and and climb and descend without moving from that point, don't try >anything > > fancier...ie practice hovering. > > Rule #6 When you can hover, practice pulling up from level flight to a > > stationary hover. > >I don't agree. It's still much fun slowly flying around known terrain >in the helicopter even if you're not a skilled helicopter pilot - you >just won't manage to land the beast without crashing :-) > >Martin. >-- I agree and that's why I still fly helicopters even though I can't even follow Rule #5. That's the nice thing about a Sim... crashes don't hurt :-) :-D ene _ 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] vatsim
Martin Spott wrote: >Ok, in theory having a closed source interface _might_ serve the >licensing issues, _but_: > - Who likes to have to use a closed source module in order to connect > their OpenSource flight simulation to VATSIM ? > > Does the bridge module between flightgear and vatsim need to be closed source? Or just non-GPL? My assumption is that all the closed source vatsim magic happens in a proprietary library? We would link our application to this library. Am I wrong on this? Our application may not then be licensable under the gpl, but we could still make our portion of the code open and available. > - More important, who of the OpenSource developers likes to maintain a > closed source module, compile it at least for half a dozend > different platforms and play the lonesome cowboy to whom bug reports > will be adressed - without having any chance to share the load with > someone else ? > > Hmmm, this is dependent on the answer to your first point. Does the vatsim app have to be closed source, or is the vatsim app that we/someone creates simply an app that has to link to a non-gpl, proprietary library? > - Most important, who of the OpenSource developers likes to take the > risk of getting sued for license infringement because VATSIM > might claim he could have transferred source code from the closed > source interface to FlightGear ? > > Well I think it's clear that the vatsim folks are more than happy to work with us if we are willing to meet them on their terms. If we develop a friendly cooperative relationship with them instead of an adversarial relationship, and if we follow their procedures and guidelines, why would there be a risk of being sued? 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
"Curtis L. Olson" wrote: > If people don't like Vatsim's approach or their licensing terms, you are > welcome to your opinion, but maybe you should take it up with the vatsim > folks rather than firing random shots in the air around here. But if > you do take it up with vatsim directly, please make it clear that you > aren't speaking on behalf of the flightgear project as a whole. Ok, in theory having a closed source interface _might_ serve the licensing issues, _but_: - Who likes to have to use a closed source module in order to connect their OpenSource flight simulation to VATSIM ? - More important, who of the OpenSource developers likes to maintain a closed source module, compile it at least for half a dozend different platforms and play the lonesome cowboy to whom bug reports will be adressed - without having any chance to share the load with someone else ? - Most important, who of the OpenSource developers likes to take the risk of getting sued for license infringement because VATSIM might claim he could have transferred source code from the closed source interface to FlightGear ? Anyone ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
Justin Smithies wrote: >How about we just use our own system based on data from the FG prop tree. >We already have the google map servers , so all we would need to do is get >other people to host their own too and become controllers for different >areas. >For voip / text we could use a secondary app which would run on Win , Linux & >Mac or develop our own. > >It would save heaps of legal issues . > >Ok it would maybe need some fine tuning but we're all good at that here :) > > Well and we'd need to find qualified ATC controllers, etc. Honestly though, I don't think we need to have any animosity towards commercial/proprietary groups in all of this. Vatsim is what it is. We can participate on their terms, or we can do something ourselves, and because this is FlightGear, we can do both. Maybe some day far in the future our in-house system will rule the world, but that's no reason to exclude the potential for a lot of fun in the mean time. If we build an independent vatsim bridge module we can satisfy the licensing terms of vatsim and the licensing of FlightGear at the same time. Seems like a pretty reasonable route to me. If people don't like Vatsim's approach or their licensing terms, you are welcome to your opinion, but maybe you should take it up with the vatsim folks rather than firing random shots in the air around here. But if you do take it up with vatsim directly, please make it clear that you aren't speaking on behalf of the flightgear project as a whole. 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
On Monday 12 June 2006 20:06, Martin Spott wrote:
> Honestly, I'm really curious to know what the _real_ driving force is
> behind this protectionism.
> Is this stupid arrogance ("if they want to participate, they'll have to
> follow our rules - not matter if it makes sense"), simply incompetence
> ("one of these bad guys out there might compromise our servers if the
> protocol gets published") or do they really have to fear something if
> some third party implements their protocol ?
I think it's just a case of lazy developers thinking that "security via
obscurity" is a viable route. It's a Micro$oft mentality that rubs off on
people.
Writing a secure protocol requires lots of work - it's easier to just do
what's required and try hide the security holes.
The open source mentality is very foreign concept to most Windows users.
Paul
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
How about we just use our own system based on data from the FG prop tree.
We already have the google map servers , so all we would need to do is get
other people to host their own too and become controllers for different
areas.
For voip / text we could use a secondary app which would run on Win , Linux &
Mac or develop our own.
It would save heaps of legal issues .
Ok it would maybe need some fine tuning but we're all good at that here :)
Justin Smithies
On Monday 12 June 2006 19:06, Martin Spott wrote:
> Hi Ben,
>
> bsupnik wrote:
> > - VATSIM could require a FG-client to use their libs (under some terms)
> > as conditions for network approval. I thikn that VASTIM users are
> > required as part of their membership agreement with the network to only
> > use "approved" clients.
>
> Honestly, I'm really curious to know what the _real_ driving force is
> behind this protectionism.
> Is this stupid arrogance ("if they want to participate, they'll have to
> follow our rules - not matter if it makes sense"), simply incompetence
> ("one of these bad guys out there might compromise our servers if the
> protocol gets published") or do they really have to fear something if
> some third party implements their protocol ?
>
> Anyway, if they don't want FlightGear users to participate does
> anyone have an idea if the "FlightProject" network still is supported
> by an active community ?
>
> http://www.flightproject.net/
>
> Cheers,
> Martin.
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
Hi Ben,
bsupnik wrote:
> - VATSIM could require a FG-client to use their libs (under some terms)
> as conditions for network approval. I thikn that VASTIM users are
> required as part of their membership agreement with the network to only
> use "approved" clients.
Honestly, I'm really curious to know what the _real_ driving force is
behind this protectionism.
Is this stupid arrogance ("if they want to participate, they'll have to
follow our rules - not matter if it makes sense"), simply incompetence
("one of these bad guys out there might compromise our servers if the
protocol gets published") or do they really have to fear something if
some third party implements their protocol ?
Anyway, if they don't want FlightGear users to participate does
anyone have an idea if the "FlightProject" network still is supported
by an active community ?
http://www.flightproject.net/
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] Issues with the website?
Solved the mystery of the bounced email, but the FTP problem still remains. JD Fenech wrote: >I can't tell if this is just me, or everyone, but ftp.flightgear.org >seems to be having a major problem right now. >This one is serious because it seems to lock up firefox. MSIE doesn't >seem to choke on it, but neither it or my FTP client can log into it >anonymous. > >They all seem to get the same error (Firefox also mentions not >understanding "500", before it becomes improperly responsive and has to >be killed manually). > >Everything seems to be in order on my side of things. A "log" follows. > >Connected to 128.101.142.113:21 in 0.070100 seconds, Waiting for Server >Response >220 FTP Server ready. >Host type (1): Automatic detect >USER anonymous >500 not understood > >I'm at a loss to explain this, since I'm not an FTP expert. >Not sure if there's a related problem with the list flightgear-devel at >flightgear.org, but I'm getting bounced mail before it gets there. > >JD > > >___ >Flightgear-users mailing list >Flightgear-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/flightgear-users > > > ___ 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]
* Josh Babcock -- Saturday 10 June 2006 15:27: > Define the name of the texture in the hud.xml file, then map it onto the > HUD glass directly in Blender or AC3D. Yeah. Done. Wasn't even difficult. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
Hi, Ralf Gerlich schrieb: > When they switched to the new radar client, I tried to keep up, but with > the team at that time (not their head, Julian Smart, but instead those Kudos to the right people...somehow I managed to mix up Julian Smart and Jason Grooms. I should get an appointment at my local neurologist...first posting wrong URLs twice, now mixing up names, not recognising having worked with Ben on ProController ports (Ben: Mac, me: KDE)...%-) Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
On Mon, 12 Jun 2006 12:05:28 -0400, Tony wrote in message <[EMAIL PROTECTED]>: > On 6/12/06, Martin Spott <[EMAIL PROTECTED]> wrote: > > Justin Smithies wrote: > > On the other hand I was told that certain people didn't care about > > licensing and hacked the VATSIM authentication protocol > > for reference ... > > http://news.com.com/Blizzard+wins+lawsuit+on+video+game+hacking/2100-1047_3-5845905.html > > is VATSIM gonna sue flightgear.org for reverse engineeing a > *protocol*? ..with the usual GrokLaw disclaimers: This here is legal: "The defendants in the case, Ross Combs and Rob Crittenden, reverse-engineered the Blizzard protocol using tools like "tcpdump" to listen to the software's communications with a game server. Eventually, their "bnetd" project let Blizzard games connect with unofficial servers, yielding benefits like faster response times. " ..if you do _not_ pull idiot stunts like this one here: "The 8th Circuit also cited a contractual agreement that Combs and Crittenden OK'd when installing Blizzard software. That agreement prohibits reverse-engineering." > > in this case, it certainly isn't an issue of "preventing piracy". ..correct, this case was about enforcing a contract, "that agreement." -- ..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] vatsim
Hi Martin, Martin Spott wrote: > Well, at least in theory FlightGear would 'only' need to make use of > the communication protocol, not of any third-party library that you > mention (which apparently implements the protocol). In theory, yes. In practice there could be additional issues: - VATSIM could require a FG-client to use their libs (under some terms) as conditions for network approval. I thikn that VASTIM users are required as part of their membership agreement with the network to only use "approved" clients. I don't know the legal mechanism behind this. - No one has coded their own VoIP among existing clients yet, so in practice everyone's chosen to go for the libs. Doesn't mean it can't be done. I'm not saying any of this makes sense - not my place to judge VATSIM, it's their show, not mine. I mention this only to give situational awareness given some of the things I've been through with them. *Cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
Hi Ben, bsupnik wrote: > The authentication protocol has been overhauled, and if you were offered > an NDA more than months ago, the NDA is overhauled too. But > there is still an NDA and there is still restrictions on the licensing > of the lib. (It's not just the NDA that would be a restriction on > clients - the lib itself has a licensing agreement too.) Well, at least in theory FlightGear would 'only' need to make use of the communication protocol, not of any third-party library that you mention (which apparently implements the protocol). Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
Hi, Martin Spott schrieb: > The story _I_ was told reads like this: > > They have severe difficulties with their user authentication because > the protocol they use is considered to be "braindead" (TM). So they try > to hide the drawbacks of their authentication protocol by forcing > people to sign an NDA - which therefore gives them a handle to control > who'll implement the protocol. Heh! Given that they didn't change their protocol over the years, I know what is meant by braindead. Once upon a time I worked on a KDE port of ProController, their radar application at that time. I got the protocol specs _without_ signing an NDA. Their network chief was not amused - to say the least - as he found out about our (we were already two at the time) client being used on their network. At least that's what he said. They seemed to have "structural" problems at the time and it might not have fit his plan to see an open-sourced tool implementing the protocol. BTW: Their server-software used to be open-source as well and as far as I can see, it has vanished... When they switched to the new radar client, I tried to keep up, but with the team at that time (not their head, Julian Smart, but instead those who wanted to work at it then) no cooperation was possible and my time is valuable. Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
On Mon, 12 Jun 2006 10:25:58 -0500, Curtis wrote in message <[EMAIL PROTECTED]>: > Justin Smithies wrote: > > >Just got a reply from Vatsim ive pasted it it below. > > > >: it's certainly viable to start such a client. However, in order to > > connect to the VATSIM network, it needs to be using libraries ..really??? Didn't Microsoft tell the world a similar story before http://samba.org/ emerged? ;o) > > whose source code is proprietary to VATSIM (i.e. its source code is > > under Non Disclosure Agreement). > > > > If that's OK with you, let me know. ..I'd settle for doing it the Samba way, Samba is GPL too, instead of inviting lawsuits for copyright infringement. Sniffing black box wiring is legal. You wanna check out Samba.org's track record, also in litigation. ;o) > Vatsim would be a "competitor" to our native multiplayer system, > right? ..and they are entitled to it, and to _anything_ from their NDA signatories, under their NDA. ;o) > Would it be possible to develop the vatsim interface as a separate > utility that runs in the background. It could exchange data with FG > through our multiplayer interface configured to talk to the local > vatsim daemon and then the vatsim daemon could talk to the vatsim > world. ..and it could be in a black box too, and under the GPL. > It goes against the windows philosophy of cramming everything into a > big monolithic application, but I would be ok with breaking that rule > just this once. :-) ..uhuh. ;o) -- ..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] vatsim
On 6/12/06, Martin Spott <[EMAIL PROTECTED]> wrote: > Justin Smithies wrote: > On the other hand I was told that certain people didn't care about > licensing and hacked the VATSIM authentication protocol for reference ... http://news.com.com/Blizzard+wins+lawsuit+on+video+game+hacking/2100-1047_3-5845905.html is VATSIM gonna sue flightgear.org for reverse engineeing a *protocol* ? in this case, it certainly isn't an issue of "preventing piracy". 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] vatsim
"Curtis L. Olson" wrote: > Vatsim would be a "competitor" to our native multiplayer system, right? Well, we might need some more users of our own system to really compete with VATSIM :-) > It goes against the windows philosophy of cramming everything into a big > monolithic application, [...] The VATSIM interface to M$F$, at least as far I've seen it, consists of a set of multiple small utilities, I think there are at least three of them: One that connects to M$F$, one that connects the MP channel to VATSIM, one that connects the voice channel to VASTIM. The problem with these tools: There are different versions each, version/communication incompatibilities are likely to happen, you have to start them in the right order and if it doesn't work it's not necessarily your fault :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
Hi Martin, The authentication protocol has been overhauled, and if you were offered an NDA more than months ago, the NDA is overhauled too. But there is still an NDA and there is still restrictions on the licensing of the lib. (It's not just the NDA that would be a restriction on clients - the lib itself has a licensing agreement too.) So the specifics you saw may have changed completely, but not enough to make a difference. That depends on what you consider acceptable. *cheers* ben Martin Spott wrote: > Justin Smithies wrote: > >>Just got a reply from Vatsim ive pasted it it below. > > >>>it's certainly viable to start such a client. However, in order to >>>connect to the VATSIM network, it needs to be using libraries whose >>>source code is proprietary to VATSIM (i.e. its source code is under Non >>>Disclosure Agreement). > > > The same story all the years. I did some investigations in this > direction as well and someone suggested to me to contact Lefteris if I > want to have at least a slight chance to get a reply that differs from > this NDA-cretinism. The reply you got is definitely discouraging. > > > The story _I_ was told reads like this: > > They have severe difficulties with their user authentication because > the protocol they use is considered to be "braindead" (TM). So they try > to hide the drawbacks of their authentication protocol by forcing > people to sign an NDA - which therefore gives them a handle to control > who'll implement the protocol. > > On the other hand I was told that certain people didn't care about > licensing and hacked the VATSIM authentication protocol - and these > people actually _did_ initiate some trouble as well. The whole thing > obviously is no surprise because trying to use an NDA in order to guard > a broken protocol is as "braindead" as the protocol itself. So some > people at VATSIM, as I was told, were planning to overhaul the > authentication protocol by creating one that works - and this > [c,sh]ould be the point where FlightGear comes into play. > > Too little time, too many tasks Could anyone confirm the story ? > > Martin. -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Mon, 12 Jun 2006 15:13:49 + (UTC), Martin wrote in message <[EMAIL PROTECTED]>: > Arnt Karlsen wrote: > > > ..any chance these _timed_ entries versions of KOSH can replace > > your current version of KOSH? > > Wrong thread, please don't always hijack threads that deal with a > totally different topic. This thread is about the structure, not about > the content, ..which still needs a structure. -- ..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] vatsim
Justin Smithies wrote: > Just got a reply from Vatsim ive pasted it it below. > > it's certainly viable to start such a client. However, in order to > > connect to the VATSIM network, it needs to be using libraries whose > > source code is proprietary to VATSIM (i.e. its source code is under Non > > Disclosure Agreement). The same story all the years. I did some investigations in this direction as well and someone suggested to me to contact Lefteris if I want to have at least a slight chance to get a reply that differs from this NDA-cretinism. The reply you got is definitely discouraging. The story _I_ was told reads like this: They have severe difficulties with their user authentication because the protocol they use is considered to be "braindead" (TM). So they try to hide the drawbacks of their authentication protocol by forcing people to sign an NDA - which therefore gives them a handle to control who'll implement the protocol. On the other hand I was told that certain people didn't care about licensing and hacked the VATSIM authentication protocol - and these people actually _did_ initiate some trouble as well. The whole thing obviously is no surprise because trying to use an NDA in order to guard a broken protocol is as "braindead" as the protocol itself. So some people at VATSIM, as I was told, were planning to overhaul the authentication protocol by creating one that works - and this [c,sh]ould be the point where FlightGear comes into play. Too little time, too many tasks Could anyone confirm the story ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
Justin Smithies wrote: >Just got a reply from Vatsim ive pasted it it below. > >: > >it's certainly viable to start such a client. However, in order to >connect to the VATSIM network, it needs to be using libraries whose >source code is proprietary to VATSIM (i.e. its source code is under Non >Disclosure Agreement). > >If that's OK with you, let me know. > > Vatsim would be a "competitor" to our native multiplayer system, right? Would it be possible to develop the vatsim interface as a separate utility that runs in the background. It could exchange data with FG through our multiplayer interface configured to talk to the local vatsim daemon and then the vatsim daemon could talk to the vatsim world. It goes against the windows philosophy of cramming everything into a big monolithic application, but I would be ok with breaking that rule just this once. :-) 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
Just got a reply from Vatsim ive pasted it it below. : it's certainly viable to start such a client. However, in order to connect to the VATSIM network, it needs to be using libraries whose source code is proprietary to VATSIM (i.e. its source code is under Non Disclosure Agreement). If that's OK with you, let me know. Best regards, Lefteris Kalamaras : Regards, Justin Smithies On Monday 12 June 2006 15:49, bsupnik wrote: > Hi, > > Sorry to barge in again, but I work with the VATSIM guys and can tell > you: you may have licensing issues...email Lefteris to find out about > such a thing, but you may want to find out up-front if the licensing on > the VATSIM VoIP stuff is compatible with FG (either legally or > philosophically). > > *CHeers* > Ben > > Justin Smithies wrote: > > Is anyone working on a plugin / client to enable us FG users to use the > > vatsim network with voice too ? > > I myself can't find anything at all , maybe some of us could get together > > and start such a project ? > > > > Regards, > > Justin Smithies > > > > > > ___ > > 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
Re: [Flightgear-devel] apt.dat changes ?
Arnt Karlsen wrote: > ..any chance these _timed_ entries versions of KOSH can replace > your current version of KOSH? Wrong thread, please don't always hijack threads that deal with a totally different topic. This thread is about the structure, not about the content, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Melchior FRANZ wrote: > * Melchior FRANZ -- Monday 12 June 2006 13:53: > >> Of course, this is a bad example, as those extensions make the format >> basically useless for any other purpose than for the AI subsystem. No >> other subsystem in fgfs can load them, which is why I would rather get >> rid of this sooner than later [...] >> > > Again, this would much less apply to an apt.dat extension. But for the > AI/Traffic system it's an artificial barrier for future improvements, > and a violation of the FlightGear Way[TM]. It's beyond me how this > could be accepted into cvs. > > The XML format in FlightGear has been chosen such that tag attributes > are only used to describe the node properties (data-type, read-only, > etc.). They are deliberately *not* used for *information*, because this > couldn't be cleanly mapped to the property system. > > I was about to add a feature to the UFO editor that would have allowed > to load AI files, to visualize the waypoints, to edit them, to assign > vehicles etc. One would have been able to create paths by clicking on > the tarmac, defining curve radii, etc. Finally, one could have saved the > result into a ready-to-use AI file again. But all this doesn't work, > because of this braindead decision. > > Melchior, I've tossed around various ideas with different people, and made a decision that seemed to be right at the time. I'm open to any constructive suggestion. Note that most people working on flightgear are doing this in their spare time and for personal reasons. Keep in mind that everybody writing code is inclined to do things in the best way possible in the best interest of the project. At times this involves the need to make decisions on the basis of limited information and even more limited feedback. Therefore, calling the decisions related to the AI traffic xml files braindead is just plain offensive, and has nothing to do with criticism. As other people have observed, criticizing other people's work is not you're strongest point, so please let me offer you some advice. If you follow the guidelines below, chances are you're still getting your message across, but without running the risk of accidentally or purposefully pissing somebody off. In the long run, I'll guarantee that that will not only be more beneficial to the project, but that it will also help in keeping this fine bunch of people motivated to work on the project: 1) Stick to the facts, leave out you're emotional appraisal of the problem. 2) Give explicit and objective reasons why something is wrong 3) If possible, propose an alternative solution. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
Hi, Sorry to barge in again, but I work with the VATSIM guys and can tell you: you may have licensing issues...email Lefteris to find out about such a thing, but you may want to find out up-front if the licensing on the VATSIM VoIP stuff is compatible with FG (either legally or philosophically). *CHeers* Ben Justin Smithies wrote: > Is anyone working on a plugin / client to enable us FG users to use the > vatsim > network with voice too ? > I myself can't find anything at all , maybe some of us could get together and > start such a project ? > > Regards, > Justin Smithies > > > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] vatsim
Is anyone working on a plugin / client to enable us FG users to use the vatsim network with voice too ? I myself can't find anything at all , maybe some of us could get together and start such a project ? Regards, Justin Smithies ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Mon, 12 Jun 2006 09:24:05 -0400, bsupnik wrote in message <[EMAIL PROTECTED]>: > Martin Spott wrote: > > > It would be extremely nice to have at least one single, completely > > working example that really matches the proposed spec. This would > > significantly help to understand the schema by having a means to > > cross-check what I've grasped from the idea behind the new spec. > > Until then it's really difficult to tell if the new schema actually > > delivers what I'd expect from it or not - or at least to tell if the > > schema is comprehensive enough to derive missing information. > > Agreed...and as soon as we have such a thing, we will post it! (I > would find such a thing useful too.) This stuff is still very very > new. ..a proposal: Timed entries: I see 5 (6, 7, 8) versions of KOSH (Oshkosh, Wi), yours (_do_ check it out ;o)), the 3 RL ones (KOSH outside AirVenture, KOSH-North and KOSH-South) and Dene's version of the latter 3 that I (and maybe Pigeon) will put on one or more FGLiveCD's. ;o) ..during this and the next 4 AirVenture's, KOSH loses the 2 RWYs crossing RWY09/27 and dies, the carcass is chopped into KOSH-North which gains these 2 RWYs as taxiways while KOSH-South trades taxiway Alpha for RWY 18L/36R, details at AirVenture.org/atc/ . ..any chance these _timed_ entries versions of KOSH can replace your current version of KOSH? -- ..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] UAV Heli and Matlab
"dene maxwell" wrote: > Rule #5 Until you can hover indefinitely over the same point on the ground > and and climb and descend without moving from that point, don't try anything > fancier...ie practice hovering. > Rule #6 When you can hover, practice pulling up from level flight to a > stationary hover. I don't agree. It's still much fun slowly flying around known terrain in the helicopter even if you're not a skilled helicopter pilot - you just won't manage to land the beast without crashing :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Martin, Martin Spott wrote: > It would be extremely nice to have at least one single, completely > working example that really matches the proposed spec. This would > significantly help to understand the schema by having a means to > cross-check what I've grasped from the idea behind the new spec. > Until then it's really difficult to tell if the new schema actually > delivers what I'd expect from it or not - or at least to tell if the > schema is comprehensive enough to derive missing information. Agreed...and as soon as we have such a thing, we will post it! (I would find such a thing useful too.) This stuff is still very very new. *Cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hello Ben, bsupnik wrote: > Martin Spott wrote: >> 100 08x 49 02 2 0.25 1 2 1 35.04420900 -106.59855700 300 200 3 2 1 1 2 \ >> 2 3.00 35.04420900 -106.59855700 0300 3 2 0 1 1 2 3.50 >> >> How is this gonna work when the thresholds of the opposing runway ends >> are situated at the same location ? Shouldn't the meaning of the cited >> text be "The following _columns " ? > > This appears to be a zero-meters-long runway. :-) I think this is > simply a bad example in Robin's spec. The lat/lon pairs for the runway > ends really should (must?) be different. It would be extremely nice to have at least one single, completely working example that really matches the proposed spec. This would significantly help to understand the schema by having a means to cross-check what I've grasped from the idea behind the new spec. Until then it's really difficult to tell if the new schema actually delivers what I'd expect from it or not - or at least to tell if the schema is comprehensive enough to derive missing information. Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Impact of texturing objects on performance?
On Sun, 11 Jun 2006 14:53:13 -0400, Ampere wrote in message <[EMAIL PROTECTED]>: > On Friday 09 June 2006 21:50, Arnt Karlsen wrote: > > ..Roberto _ is_ stretching understatement as concept, last years > > AirVenture put over 10 000 planes on KOSH. My initial idea > > was "paint parked planes" with copies of one texture. Textures is > > what we "see out the window" in FG and it works on my old junk. > > > > ..you're saying "using 20 different a few hundred times each > > is gonna work better than textures??? "Bring it on!" 8o) > > Textures would work if all those planes are of one type and have the > same livery, which is an unrealistic scenario. ..or if the textures covers a row bit of planes. > A more realistic scene that a user would see (hopefully) in FG is a > dozen different types of planes belonging to a dozen different > airlines. Using textures for details would require huge textures per > aircraft-type per airline, and would result in performance cost going > through the roof; and that's excluding the textures that would be > already presented in the airports. ..ok, we're talking "grass with rows of parked planes as seen from the pattern", nothing fancy. > Performance would still degrade if all those aircraft and buildings > have high geometric details, but geometries wouldn't eat up memory as > quick as textures would. Beside, one could always turn off a portion > of the geometries when they aren't needed. > > Anyway, I think we are getting a bit ahead of ourselves here. > FlightGear starts to struggle/struggles with merely 10 aircraft on > the scene. I don't think users would be able to see 100 planes in > the same scene anytime soon. :P ..hmmm. -- ..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 ?
* Melchior FRANZ -- Monday 12 June 2006 13:53: > Of course, this is a bad example, as those extensions make the format > basically useless for any other purpose than for the AI subsystem. No > other subsystem in fgfs can load them, which is why I would rather get > rid of this sooner than later [...] Again, this would much less apply to an apt.dat extension. But for the AI/Traffic system it's an artificial barrier for future improvements, and a violation of the FlightGear Way[TM]. It's beyond me how this could be accepted into cvs. The XML format in FlightGear has been chosen such that tag attributes are only used to describe the node properties (data-type, read-only, etc.). They are deliberately *not* used for *information*, because this couldn't be cleanly mapped to the property system. I was about to add a feature to the UFO editor that would have allowed to load AI files, to visualize the waypoints, to edit them, to assign vehicles etc. One would have been able to create paths by clicking on the tarmac, defining curve radii, etc. Finally, one could have saved the result into a ready-to-use AI file again. But all this doesn't work, because of this braindead decision. m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Martin, Martin Spott wrote: > FlightGear uses this compilation aproach for ages and we're currently > working on improving the process - this is why a foresighted airport > description format would come very handy right now ;-) Well, I think you need both things...you need a high level format that is powerful enough to generate what you want and _if_ you don't do 100% of the compilation in the sim, you need a container format for the results that is adequately expressive and efficient. I am proposing the second but not the first, and if you do not need such a container format, well, it's nto very useful. :-) > But scenery generation actually is not the whole story. Think of > placing your aircraft at the beginning of runway 05R at EDDL at runtime > - the simulation somehow needs to have access to the runway locations > and the FlightGear simulation runtime uses the 'apt.dat' for this > purpose as well. Which pint is the simulation supposed to pick for this > purpose ? Given how little runways have changed in the spec 'the point you pick now' is probably still fine. I don't think that we've removed any of the existing high level info from 850 that would have been useful, we just haven't brought the level up. (If we have dropped stuff you need, please shout at me!!) > 100 08x 49 02 2 0.25 1 2 1 35.04420900 -106.59855700 300 200 3 2 1 1 2 \ > 2 3.00 35.04420900 -106.59855700 0300 3 2 0 1 1 2 3.50 > > How is this gonna work when the thresholds of the opposing runway ends > are situated at the same location ? Shouldn't the meaning of the cited > text be "The following _columns " ? This appears to be a zero-meters-long runway. :-) I think this is simply a bad example in Robin's spec. The lat/lon pairs for the runway ends really should (must?) be different. Those two points should be the intersection of the extended runway centerline with the threshhold (not displaced threshhold) of the runway. > I'm not trying to torpedo your work on the new schema, I'm simply > trying to understand it _before_ I point my gun at you ;-) It's a good question - I'll try to answer any q's I can. The docs are still in a pretty raw state - Robin only did the first spec on Friday! *Cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Ralf, Ralf Gerlich wrote: >>Well, there is the problem: if you want to database the highest level >>layout info, you need to standardize the high level model. > Then that's where we need to work with you and Robin Peel regarding the > next generation database ;-) Just to play devil's advocate: 1. How hard would it be to reconstruct a layout from the low-level apt.dat layout? I'm imagining a layout started in WorldEditor and then modified in TaxiDraw. Would you and I have to agree on a high-level interchange format, or could we reconstitute the info we need from the low level format? (I suppose this is a question about the editors - for an editor that truly built layouts from centerlines, there would I think be no way to reconstitute a layout. Because WED will be area-focused, it could probably rebuild a layout from its export, with the risk that some layouts would be invalid within WED.) 2. What if we databased the last author of a layout...the implication being that if you want to edit a layout in the DB and cannot work with the final apt.dat data, you contact the author and resolve the problem directly? Without this, it becomes necessary for all editors to agree on a high level format that is in the DB and thus is involved in lockstep. So I'm looking for a practical solution that would decouple this dependency. *cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hello Ben, bsupnik wrote: > X-Plane has ended up more and more using a 'compiler' approach to our > scenery, where we view the process of making scenery as a series of > transformations on data. FlightGear uses this compilation aproach for ages and we're currently working on improving the process - this is why a foresighted airport description format would come very handy right now ;-) But scenery generation actually is not the whole story. Think of placing your aircraft at the beginning of runway 05R at EDDL at runtime - the simulation somehow needs to have access to the runway locations and the FlightGear simulation runtime uses the 'apt.dat' for this purpose as well. Which pint is the simulation supposed to pick for this purpose ? I still failed to understand the logic in the description on: http://www.x-plane.org/home/robinp/Apt850.htm to my current impression the description is a bit inconsistent. The explanation for type '100' contains the following text: The following rows are repeated for each end of the runway: 35.04420900 Latitude (in decimal degrees) of runway threshold at centreline -106.59855700 Longitude (in decimal degrees) of runway threshold at centreline The example for KABQ reads: 100 08x 49 02 2 0.25 1 2 1 35.04420900 -106.59855700 300 200 3 2 1 1 2 \ 2 3.00 35.04420900 -106.59855700 0300 3 2 0 1 1 2 3.50 How is this gonna work when the thresholds of the opposing runway ends are situated at the same location ? Shouldn't the meaning of the cited text be "The following _columns " ? I'm not trying to torpedo your work on the new schema, I'm simply trying to understand it _before_ I point my gun at you ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Ben, bsupnik schrieb: > Ralf Gerlich wrote: >>There was criticism of the physical storage model of apt.dat, as it has >>been and probably will continue to be in version 850. I just wanted to >>say that, if the FlightGear project were to "invent" its own format - >>let's call it FGAPT for simplicity - and would then not be able to >>convert from APT to FGAPT _and_ backwards, we would lose the possibility >>of properly interchanging data with X-Plane and Robin Peel's database. >>We might not lose the possibility in total, but at least in part. > > > Ah...well, it's that translatability that's most important I think ... > there's really no reason why FG should be stuck with an X-Plane > container model. Exactly. [SNIP] > Well, there is the problem: if you want to database the highest level > layout info, you need to standardize the high level model. Then that's where we need to work with you and Robin Peel regarding the next generation database ;-) 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 ?
Hi Ralf, Ralf Gerlich wrote: > There was criticism of the physical storage model of apt.dat, as it has > been and probably will continue to be in version 850. I just wanted to > say that, if the FlightGear project were to "invent" its own format - > let's call it FGAPT for simplicity - and would then not be able to > convert from APT to FGAPT _and_ backwards, we would lose the possibility > of properly interchanging data with X-Plane and Robin Peel's database. > We might not lose the possibility in total, but at least in part. Ah...well, it's that translatability that's most important I think ... there's really no reason why FG should be stuck with an X-Plane container model. > Some time ago (it might be already a year ago) I had a discussion with > Dave Luff on the topic of making TaxiDraw a bit more useable. At that > time I had started customising scenery for my local area and found the > way of working with single rectangles in TaxiDraw very awkward and > time-consuming, in contrast to, e.g., just clicking along the centerline > of a taxiway and having TaxiDraw generate the rectangles from that. This is where the compiler model works...it doesn't dictate a higher level abstraction, so it leaves authors like you and David to make the best internal model for TaxiDraw that you can come up with, one that plays to TaxiDraw's strengths and doesn't saddle you with implementing things you don't need. We had Christian Franz trying to take X-plane's final modeling format (OBJ) and stick extensions into it to make it into an editing format...this ended in repeated failure; by comparison, exporting from Blender works well. > I also like the mindset of interpreting apt.dat as some kind of > intermediate format of a compiler. However, as decompilation into a > higher-level format is not possible, apt.dat even in its new form does > not seem to be a good format for keeping in a central database based on > which updates to the airport layouts are made. Such a format needs to > keep the top-level information modellers see in their editor, so that > the next one can simply import that top-level model from the database > and go on where his/her predecessor left. This is exactly the reason why > we have sourcecode in our CVS and not the intermediate register transfer > language (RTL) of the GNU C/C++ compiler suite ;-) Well, there is the problem: if you want to database the highest level layout info, you need to standardize the high level model. I'm not against doing that...but to some extent it's beyond the scope of apt.dat 850...to some extent apt.dat 850 says what data x-plane will eat, but nothing about where it comes from. The intention is that the programs that create that data will have a more descriptive format that makes editing practical. *Cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Ben, bsupnik wrote: > Ralf Gerlich wrote: >>As it seems, the X-Plane authors are not keen to go away from the >>apt.dat format, so if FlightGear would go away from bidirectional >>compatibility with apt.dat, this would result in a clear split of the >>databases and in ceasing the up to now fruitful exchange of data between >>FlightGear and X-Plane. Keep this in mind when assessing the advantages >>of a new, totally different format. > > > I'm not 100% what you mean by this...we are supporting older apt.dat > formats in x-plane ... we have to - in X-plane apt.dat can be embedded > in custom scenery packas, so users can add old-format data to the sim > in-field. So X-Plane will continue to read and show old-format data but > without any new features. There was criticism of the physical storage model of apt.dat, as it has been and probably will continue to be in version 850. I just wanted to say that, if the FlightGear project were to "invent" its own format - let's call it FGAPT for simplicity - and would then not be able to convert from APT to FGAPT _and_ backwards, we would lose the possibility of properly interchanging data with X-Plane and Robin Peel's database. We might not lose the possibility in total, but at least in part. I like the idea of essentially having the userbases of two flight simulators work on the airport database. This is something both projects gain from. In consequence, I don't like the idea of losing this possibility by not being able to transfer updates in both directions. Some time ago (it might be already a year ago) I had a discussion with Dave Luff on the topic of making TaxiDraw a bit more useable. At that time I had started customising scenery for my local area and found the way of working with single rectangles in TaxiDraw very awkward and time-consuming, in contrast to, e.g., just clicking along the centerline of a taxiway and having TaxiDraw generate the rectangles from that. It all boiled down to the question how we could preserve our basic information - the polylines - in apt.dat. We could - as Curt told us - have our own codes in apt.dat, but then we would have to store the same information twice, once as polyline and once as rectangle list, practically calling for them to go out of sync. In that aspect, the new intended version 850 of apt.dat solves that problem at least in my mind. I also like the mindset of interpreting apt.dat as some kind of intermediate format of a compiler. However, as decompilation into a higher-level format is not possible, apt.dat even in its new form does not seem to be a good format for keeping in a central database based on which updates to the airport layouts are made. Such a format needs to keep the top-level information modellers see in their editor, so that the next one can simply import that top-level model from the database and go on where his/her predecessor left. This is exactly the reason why we have sourcecode in our CVS and not the intermediate register transfer language (RTL) of the GNU C/C++ compiler suite ;-) People in FlightGear have already come up with external solutions, such as Durk Talsma's XML-based logical AI-network, but as Melchior said, this is nothing we should wish to do with any upcoming extension in the future. 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 ?
* Ralf Gerlich -- Monday 12 June 2006 13:42: > BTW: Durk Talsma's AI-extension using external XML-files shows us that > we _can_ extend the format without changing apt.dat at all. Of course, this is a bad example, as those extensions make the format basically useless for any other purpose than for the AI subsystem. No other subsystem in fgfs can load them, which is why I would rather get rid of this sooner than later and keep further such nonsense from being added to FlightGear. In the apt case an extension would surely be less evil. m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi, BTW: Durk Talsma's AI-extension using external XML-files shows us that we _can_ extend the format without changing apt.dat at all. However, we still have the problem of keeping extensions like that in sync with changes from Robin Peel's database. 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 ?
Hi Ralf, Ralf Gerlich wrote: > As it seems, the X-Plane authors are not keen to go away from the > apt.dat format, so if FlightGear would go away from bidirectional > compatibility with apt.dat, this would result in a clear split of the > databases and in ceasing the up to now fruitful exchange of data between > FlightGear and X-Plane. Keep this in mind when assessing the advantages > of a new, totally different format. I'm not 100% what you mean by this...we are supporting older apt.dat formats in x-plane ... we have to - in X-plane apt.dat can be embedded in custom scenery packas, so users can add old-format data to the sim in-field. So X-Plane will continue to read and show old-format data but without any new features. > ...and that's why that is to change in the new apt.dat-format. They have > both polygonal pavement sections, but also polyline sections, by which > rows of lights, markings, etc., can be placed accurately. Accurately and arbitrarily! And this is one of our design choices. Given a choice between "come up with a logical model that explains every possible combination of pavement and taxiway line markings" and "let the user put the paint where it is in real life" we ended up at the second, after trying some schemes for the first and just spiraling totally out of control. We considered 'total realism' to be the goal, e.g. it would be unacceptable to have the "wrong" pavement markings (by real life standings) because the algorithm to generate them couldn't be expressed by our logic model. Of course, such an expressive logic model would be valuable for a number of things, so it might make sense to develop one for FG...in the case of X-Plane it didn't fit with our development roadmap. > However, given proper tools - which is what TaxiDraw is going for - we > can make the tool support the user, by, e.g., automatically placing > lines of borderlights around any new pavement polygon and allow the user > to edit them or remove them as they wish. The 850 format also supports the tagging of the bezier edges with light codes, so to some extent the procedure of wrapping lights around pavement is made a little bit simpler, or at least the data file a little smaller. *Cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi, Thomas Förster schrieb: >>Ralf Gerlich schrieb: >>Erm...I just wanted to add, that I don't mean that TaxiDraw isn't a >>proper tool right now %-) The intention was to express the direction of >>TaxiDraw towards a more flexible tool with the possibility for more >>high-level support in airport editing. > > > Neither do I. Taxidraw is an amazing tool right now. I was just thinking of > ways to decrease your programming burden. :-) Heh! You don't need to decrease my programming burden by (mentally) replacing TaxiDraw with an SVG-tool. I'd like to keep TaxiDraw, if only for the fun of working on it ;-) (of course, there's parts of that job that are a PITA, but gladly, it's only parts) 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 ?
Hi Guys, First I must say I have not read the past FG-dev discussion on this ... if someone can point me to a thread title name or date range I will catch up. The 850 apt.dat format came out of about 3 years of banging our head on the problem inside LR, but I suspect that the things we've struggled with are similar to some of the approaches described here. To try to answer some questions: X-Plane has ended up more and more using a 'compiler' approach to our scenery, where we view the process of making scenery as a series of transformations on data. The final transformation is into some kind of "distribution" format, the assembly code of our scenery, where the format is meant to be fast to read, compact, and things the sim doesn't care about but tools do have been thrown out. Overall this has worked well for us, and I think is appearing a bit in apt.dat 850. In particular, really the apt.dat 850 taxiway layouts should be thought of as a planar map of bezier curves, but X-plane doesn't care, so 850 apt.dat is more of a derivative product of which a planar map is one of multiple possible sources. A topological network that has been 'extruded' into a taxiway set could also be the source. One of the advantages of a compiler approach is that different tools can create simcompatible layout without accepting the same abstractions. With that in mind, apt.dat 850 is low level...if you guys can get an SVG editor to output the kind of format you need, then that's great ! I just recommend that you consider the process a transform and not insist that the intermediate and final formats be the same...the design needs of the sim and the editing tools may be very different. (I should also say, for us they are different because X-plane is a commercial sim, so it's possible that FG can use the editing format as the distribution format where other sims can't. But I think having the two decoupled is useful for backward compatibility, if this is a goal.) ATC and Logical Layout: apt.dat 850 is a total punt - it makes no attempt to provide logical layout, machine-ready analysis of the layout, or things an ATC or AI implementation would need. This came out of pragmatism...we couldn't find a format that enforced these high level constructs, was still expressive enough to do all of the special-case things that authors would want to model real life, and would still be practical to implement. Based on the "compiler" model, a logical layout could be compiled into an apt.dat layout, but an apt.dat 850 layout might not be decompilable. Our assumption was that given higher level layouts, we would separately compile ATC/AI data if/when we need it. I see comments that something is better than nothing and also that this isn't a step in the right long-term direction. I will only say: right now we have _no_ higher level metadata defined in layouts and frankly the way that even the outline of the layout is expressed is a bit kludgy. So to me going to bezier curves is a step away from the wrong direction, even if it isn't a step in the right direction. (Did that make any sense?) I guess what I'm trying to say is: I wouldn't suggest sticking with overlapping quads because bezier curves don't have logical layout. If you can make a logical layout system work, then that's great, but at LR we saw that as out of our current scope. Border Lights: two thoughts...the apt.dat 850 spec specifically defines layouts as made entirely of old or new records...one of the things this implies is that FG or X-plane or any sim only has to generate 'clipped' taxiway lights for an old layout. That code can be skipped for a new layout, where all lights are explicitly placed. The problem of inset/non-inset lights is a tricky one...we're still going up and back on how much of these kinds of effects should be automatic vs explicit. For example, it seemed logical that x-plane would choose inset vs non-inset approach lights by looking at the presence of crossing taxiways, displaced threshholds, etc. On the other hand, we didn't think we could change a taxi line to have/not-have a black stripe based on the underlying terrain pavement. So I'm not sure what's best here...basically anything that could have a logical ruling but is considered too much of a PITA for the sim ends up pushed off to the tools...for our current code base the tools do a lot of work to make scenery pre-digestible and by choosing a similar strategy for airports we risk the same thing happening. But then it's all code that has to get written, whether it's in a tool or the sim's code base. In the end of the day I suppose it's a question of whether inset taxi lights are fundamentally different from non-inset ones or whether they represent two variations of the same concept. *Cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox
Re: [Flightgear-devel] apt.dat changes ?
Hi Ralf Hi, dene maxwell wrote: > it's not just layout that is important, there have been instances where > people have wanted uni-directional runways... this could just as equally > apply to taxiways (I haven't come across any examples of this YET!)... > defining taxi-ways as unirdirection or bidirectional could cater for > specifically styled runway signs (if indeed this was the case in RL)... > taking it a step further... apron markings could be layered over this. With > the proprietry APT format this would be hard to implement...a more generic > "tree" structure would be more extensible (I think this has been mentioned > before as an advantage) As it seems, the X-Plane authors are not keen to go away from the apt.dat format, so if FlightGear would go away from bidirectional compatibility with apt.dat, this would result in a clear split of the databases and in ceasing the up to now fruitful exchange of data between FlightGear and X-Plane. Keep this in mind when assessing the advantages of a new, totally different format. I have made this point before, IMHO it is preferrable that we both (FG & Xplane) stay with the same format if only for the reason that the more people that are working on getting airport layouts correct the better both the end results are going to be no matter how we process the data in each application. My flights (pardon the pun) of fancy are only a way of sharing some ideas on where the furture will lead us. They are certainly not a proposal we go our(FGFS) own way independantly. The more discussion and more ideas that are proposed then any final choice can only be more informed (even the most ridiculous idea might have some merit even if to discount it). Thomas Förster wrote: >>Example case: I've seen taxi lights standing besides the asphalt and on the >>other hand others buried within the taxiway concrete. Just specifying that >>there is taxiway lighting is not enough in my opinion. ...and that's why that is to change in the new apt.dat-format. They have both polygonal pavement sections, but also polyline sections, by which rows of lights, markings, etc., can be placed accurately. Which brings us to the point where we have to draw our borderlights, etc., ourselves _in addition_ to the pavement, where in the past we "simply" placed a rectangle and activated lighting. However, given proper tools - which is what TaxiDraw is going for - we can make the tool support the user, by, e.g., automatically placing lines of borderlights around any new pavement polygon and allow the user to edit them or remove them as they wish. as mentioned, "a certain amount of logic" can be enforced at a data structure level or at a tool level, I believe it should be done at the tool level at this stage of the discussion as it leaves the data structure more open and able to cater for unforseen developments. Whether or not the APT data format is most suitable now is largely irrelevant...without a universal agreement that it should be discarded and a clean start should be made it is the legacy format and the 850 proposal is a definite step forward... who knows what ingenious changes are possible in the apt format to accomodate some of the "flights of fancy" that have been expressed. Cheers, Ralf regards :-D ene _ 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 ?
Am Montag, 12. Juni 2006 12:28 schrieb Ralf Gerlich: > Hi, > > Ralf Gerlich schrieb: > > However, given proper tools - which is what TaxiDraw is going for - we > > can make the tool support the user, by, e.g., automatically placing > > lines of borderlights around any new pavement polygon and allow the user > > to edit them or remove them as they wish. > > Erm...I just wanted to add, that I don't mean that TaxiDraw isn't a > proper tool right now %-) The intention was to express the direction of > TaxiDraw towards a more flexible tool with the possibility for more > high-level support in airport editing. Neither do I. Taxidraw is an amazing tool right now. I was just thinking of ways to decrease your programming burden. :-) Thomas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi, Ralf Gerlich schrieb: > However, given proper tools - which is what TaxiDraw is going for - we > can make the tool support the user, by, e.g., automatically placing > lines of borderlights around any new pavement polygon and allow the user > to edit them or remove them as they wish. Erm...I just wanted to add, that I don't mean that TaxiDraw isn't a proper tool right now %-) The intention was to express the direction of TaxiDraw towards a more flexible tool with the possibility for more high-level support in airport editing. At least that is my vision, and it seems that TaxiDraw-master Dave Luff seems to like that vision. Am I wrong, Dave? ;-) 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 ?
Hi, dene maxwell wrote: > it's not just layout that is important, there have been instances where > people have wanted uni-directional runways... this could just as equally > apply to taxiways (I haven't come across any examples of this YET!)... > defining taxi-ways as unirdirection or bidirectional could cater for > specifically styled runway signs (if indeed this was the case in RL)... > taking it a step further... apron markings could be layered over this. With > the proprietry APT format this would be hard to implement...a more generic > "tree" structure would be more extensible (I think this has been mentioned > before as an advantage) As it seems, the X-Plane authors are not keen to go away from the apt.dat format, so if FlightGear would go away from bidirectional compatibility with apt.dat, this would result in a clear split of the databases and in ceasing the up to now fruitful exchange of data between FlightGear and X-Plane. Keep this in mind when assessing the advantages of a new, totally different format. Thomas Förster wrote: >>Example case: I've seen taxi lights standing besides the asphalt and on the >>other hand others buried within the taxiway concrete. Just specifying that >>there is taxiway lighting is not enough in my opinion. ...and that's why that is to change in the new apt.dat-format. They have both polygonal pavement sections, but also polyline sections, by which rows of lights, markings, etc., can be placed accurately. Which brings us to the point where we have to draw our borderlights, etc., ourselves _in addition_ to the pavement, where in the past we "simply" placed a rectangle and activated lighting. However, given proper tools - which is what TaxiDraw is going for - we can make the tool support the user, by, e.g., automatically placing lines of borderlights around any new pavement polygon and allow the user to edit them or remove them as they wish. 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 ?
Hi > > This idea actually _does_ have appeal - hey, I'm right now busy with > > creating an SVG drawing - but I see one drawback here: > > Airport-creators or -maintainers are not _forced_ to think of the > > logical layout. Let's assume some flight simulation does not honour the > > logical layout at all and we'll experience people submitting airports > > without _any_ logic, not even the direction of the taxiway centerline, > > just consisting of the outlines of taxiways and runways. > >Better have just the outlines than having nothing at all. People more >experienced in airport layout could take over and add the missing parts. >Welcome to the power of open source. I for myself would volunteer for this >since I don't like redrawing runway borders from an aerial. Its all about >collaboration :-) > it's not just layout that is important, there have been instances where people have wanted uni-directional runways... this could just as equally apply to taxiways (I haven't come across any examples of this YET!)... defining taxi-ways as unirdirection or bidirectional could cater for specifically styled runway signs (if indeed this was the case in RL)... taking it a step further... apron markings could be layered over this. With the proprietry APT format this would be hard to implement...a more generic "tree" structure would be more extensible (I think this has been mentioned before as an advantage) > > In order to do it 'right' (TM, yes, I know ;-) I'd prefer to have an > > airport description language that consists of nothing but the logical > > layout at least for those objects, that relate to the core airport > > operations (runway, taxiway, apron, tower location), forcing the user > > to create a logical sense behind _every_ object. > >This is exactly what I have in mind. It just contains 'embedded' svg >descriptions of the physical layout of the parts that make up the logical >model. Something like this > > > > > > > > >(NOTE I dont know svg syntax :-)) > >Of course this also means that only an svg editor is not enough to fully >specify an airport. > Just as a text editor will edit a dat file... TaxiDraw does a much better job because it enforces a set of rules. > > Yes, I feel that this > > path might be a bit steep in the beginning but I believe it's the only > > one that saves us from major trouble once we expect every airfield to > > contain a certain amount of logic and realizing that noting's there. > > Opinions ? > >I think this is a quality control issue. So it should be solved in the >process >rather than in the data format. > Agreed, the tool enforces the quality control and the data format stores that information such that the result of the rules is also stored for other editing sessions. > > I must admit that from reading some explanations on the 8.50 format I > > still didn't understand which route this new format is heading for - I > > simply failed to find the logic in the description > >ASFIU they only want to provide the high-level description and leave >everything else to the sim. That makes it easy for airport modellers since >there are less options but I can see issues arising regarding flexibility. >Example case: I've seen taxi lights standing besides the asphalt and on the >other hand others buried within the taxiway concrete. Just specifying that >there is taxiway lighting is not enough in my opinion. > >Thomas :-D ene _ Need more speed? Get Xtra Broadband @ http://jetstream.xtra.co.nz/chm/0,,202853-1000,00.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On 12/06/2006, at 9:37 PM, Thomas Förster wrote: > > Of course this also means that only an svg editor is not enough to > fully > specify an airport. In the case of Inkscape (I don't know about any of the other SVG editors), a reasonably simple plugin should suffice for editing the non-graphical aspects of the airport layout. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
> This idea actually _does_ have appeal - hey, I'm right now busy with > creating an SVG drawing - but I see one drawback here: > Airport-creators or -maintainers are not _forced_ to think of the > logical layout. Let's assume some flight simulation does not honour the > logical layout at all and we'll experience people submitting airports > without _any_ logic, not even the direction of the taxiway centerline, > just consisting of the outlines of taxiways and runways. Better have just the outlines than having nothing at all. People more experienced in airport layout could take over and add the missing parts. Welcome to the power of open source. I for myself would volunteer for this since I don't like redrawing runway borders from an aerial. Its all about collaboration :-) > In order to do it 'right' (TM, yes, I know ;-) I'd prefer to have an > airport description language that consists of nothing but the logical > layout at least for those objects, that relate to the core airport > operations (runway, taxiway, apron, tower location), forcing the user > to create a logical sense behind _every_ object. This is exactly what I have in mind. It just contains 'embedded' svg descriptions of the physical layout of the parts that make up the logical model. Something like this (NOTE I dont know svg syntax :-)) Of course this also means that only an svg editor is not enough to fully specify an airport. > Yes, I feel that this > path might be a bit steep in the beginning but I believe it's the only > one that saves us from major trouble once we expect every airfield to > contain a certain amount of logic and realizing that noting's there. > Opinions ? I think this is a quality control issue. So it should be solved in the process rather than in the data format. > I must admit that from reading some explanations on the 8.50 format I > still didn't understand which route this new format is heading for - I > simply failed to find the logic in the description ASFIU they only want to provide the high-level description and leave everything else to the sim. That makes it easy for airport modellers since there are less options but I can see issues arising regarding flexibility. Example case: I've seen taxi lights standing besides the asphalt and on the other hand others buried within the taxiway concrete. Just specifying that there is taxiway lighting is not enough in my opinion. Thomas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Hallo Thomas ! Thomas Förster wrote: > Which brings me to an idea. What if the airport format is enriched svg. That > way the physical airport layout is in svg and might be viewed with a standard > svg viever/editor. Converting electronic airport charts to svg works already. > The logical layout (taxiway names, aprons, tower locations etc.) is then put > on top of that (i.e. extra tags and attributes). This idea actually _does_ have appeal - hey, I'm right now busy with creating an SVG drawing - but I see one drawback here: Airport-creators or -maintainers are not _forced_ to think of the logical layout. Let's assume some flight simulation does not honour the logical layout at all and we'll experience people submitting airports without _any_ logic, not even the direction of the taxiway centerline, just consisting of the outlines of taxiways and runways. In order to do it 'right' (TM, yes, I know ;-) I'd prefer to have an airport description language that consists of nothing but the logical layout at least for those objects, that relate to the core airport operations (runway, taxiway, apron, tower location), forcing the user to create a logical sense behind _every_ object. Yes, I feel that this path might be a bit steep in the beginning but I believe it's the only one that saves us from major trouble once we expect every airfield to contain a certain amount of logic and realizing that noting's there. Opinions ? I must admit that from reading some explanations on the 8.50 format I still didn't understand which route this new format is heading for - I simply failed to find the logic in the description Regards, Martin. -- Agreed if I understand you placing "blobs" on a layout just to get the outline right is not productive in the long run it might solve an immediate problem but doesn't contribute to the maintenance of that data hence curves are going to be necessary to allows whatever tools to enforce the "certain amount of logic" ideal ...as mentioned I believe there will be a degree of resistance if it is perceived that current tools (that people are familiar with) won't be "valid"... I don't believe this is a reason not to pursue the "certain amount of logic" ideal, but a reason to mitigate a migration path that everyone involved, understands. :-D ene _ Shop til you drop at XtraMSN Shopping http://shopping.xtramsn.co.nz/home/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New apt.dat format, X-Plane and Flight Gear
Hi Ben, bsupnik wrote: > I just wanted to make a few comments on how this format has evolved that > might be of bearing to future FG development: Do you follow the "apt.dat changes" thread on this list ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hallo Thomas ! Thomas Förster wrote: > Which brings me to an idea. What if the airport format is enriched svg. That > way the physical airport layout is in svg and might be viewed with a standard > svg viever/editor. Converting electronic airport charts to svg works already. > The logical layout (taxiway names, aprons, tower locations etc.) is then put > on top of that (i.e. extra tags and attributes). This idea actually _does_ have appeal - hey, I'm right now busy with creating an SVG drawing - but I see one drawback here: Airport-creators or -maintainers are not _forced_ to think of the logical layout. Let's assume some flight simulation does not honour the logical layout at all and we'll experience people submitting airports without _any_ logic, not even the direction of the taxiway centerline, just consisting of the outlines of taxiways and runways. In order to do it 'right' (TM, yes, I know ;-) I'd prefer to have an airport description language that consists of nothing but the logical layout at least for those objects, that relate to the core airport operations (runway, taxiway, apron, tower location), forcing the user to create a logical sense behind _every_ object. Yes, I feel that this path might be a bit steep in the beginning but I believe it's the only one that saves us from major trouble once we expect every airfield to contain a certain amount of logic and realizing that noting's there. Opinions ? I must admit that from reading some explanations on the 8.50 format I still didn't understand which route this new format is heading for - I simply failed to find the logic in the description Regards, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Having edited airports there are a few things that tools like TaxiDraw provide that are invaluable; 1) super-imposing the airport layout on top of a scaled background image to allow placement of taxiways etc in proportion to the RL layout. 2) providing lat/long readout for any point on the layout. 3) showing centre lines for runways/taxiways. 4) catering for such things as edge lighting and centre line lighting etc. 5) exporting the beacon information to stg files not to mention; layering info, (even biezer curves will need layering at the interfaces), surface types etc. If a program like Inkscape can duplicate this and is multiplatform then by all means. As you might have gathered, I have no experience with Inkscape and am looking for comments and affirmations rather than flame-wars... I believe a more generic and structured approach to the apt format is desirable as long as there isn't a re-adjustment period that means we are left devoid of current capabilities. I also see merit in maintaining a commonality between x-plane ad fgfs as it increases the resources available for further development albeit on a cooperative basis. We also need to keep in mind that a number of people have devoted a large amount of time and effort to interfacing with the apt.dat format, I feel their voices should be most prominent when any change like this is considered. :-D ene From: Thomas Förster <[EMAIL PROTECTED]> Reply-To: FlightGear developers discussions To: FlightGear developers discussions Subject: Re: [Flightgear-devel] apt.dat changes ? Date: Mon, 12 Jun 2006 09:50:12 +0200 Am Montag 12 Juni 2006 01:10 schrieb Ampere K. Hardraade: > On Saturday 10 June 2006 13:15, Tony Pelton wrote: > > heck, even taking the records, and stuffing those records, as they are > > now, into XML would be a start. > > Already in XML format... > > http://www.cs.yorku.ca/~cs233144/export_cyyz.svg > http://www.cs.yorku.ca/~cs233144/export_eddf.svg > http://www.cs.yorku.ca/~cs233144/export_eddh.svg > http://www.cs.yorku.ca/~cs233144/export_etou.svg > http://www.cs.yorku.ca/~cs233144/export_ksfo.svg Which brings me to an idea. What if the airport format is enriched svg. That way the physical airport layout is in svg and might be viewed with a standard svg viever/editor. Converting electronic airport charts to svg works already. The logical layout (taxiway names, aprons, tower locations etc.) is then put on top of that (i.e. extra tags and attributes). Don't know wether svg editors will preserve unknown tags and attributes. If they do, the physical airport layout can then be changed with a standard svg drawing program (e.g. inkscape). Thomas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Need more speed? Get Xtra Broadband @ http://jetstream.xtra.co.nz/chm/0,,202853-1000,00.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Thomas Förster wrote: > Don't know wether svg editors will preserve unknown tags and attributes. If > they do, the physical airport layout can then be changed with a standard svg > drawing program (e.g. inkscape). > That's the nice thing about XML: you just have to put your own tags and attributes in your own namespace, include that namespace and then tools should at least preserve them, even if they don't understand their meaning. Nine ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Am Montag 12 Juni 2006 01:10 schrieb Ampere K. Hardraade: > On Saturday 10 June 2006 13:15, Tony Pelton wrote: > > heck, even taking the records, and stuffing those records, as they are > > now, into XML would be a start. > > Already in XML format... > > http://www.cs.yorku.ca/~cs233144/export_cyyz.svg > http://www.cs.yorku.ca/~cs233144/export_eddf.svg > http://www.cs.yorku.ca/~cs233144/export_eddh.svg > http://www.cs.yorku.ca/~cs233144/export_etou.svg > http://www.cs.yorku.ca/~cs233144/export_ksfo.svg Which brings me to an idea. What if the airport format is enriched svg. That way the physical airport layout is in svg and might be viewed with a standard svg viever/editor. Converting electronic airport charts to svg works already. The logical layout (taxiway names, aprons, tower locations etc.) is then put on top of that (i.e. extra tags and attributes). Don't know wether svg editors will preserve unknown tags and attributes. If they do, the physical airport layout can then be changed with a standard svg drawing program (e.g. inkscape). Thomas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
