Re: [Flightgear-devel] collision avoidance
On Monday 12 June 2006 07:15, Mick - wrote: Through observation, I found that my calculated agl value (as discussed in my previous post) was close to that of /position/ground-elev-ft when using the current lat/lon values instead of those from Point3D calc_gc_lon_lat( const Point3D orig, double course, double dist ). I did this in an attempt to compare against the /position/ground-elev-ft value. The resulting value was close but not the same. Having converted between feet and meters, and degrees and radians for the purpose of the calculations, would this have resulted in the slight difference in value? Ok, what is 'slight' in that case? With my limited avionics knowledge, I assumed that: (altitude-ft - ground-elev-ft) = altitude-agl-ft. Again, this is something I want to verify instead of assuming. So is it (somewhat) correct to assume that subtracting the current altitude from my calculated agl would give me the the altitude-agl-ft? That should be ok. Anyway, I have attached the quick hack that I used to test that and the past material changes. That might serve as a starting point for you. It takes the aircraft's position (not the view position!) does an additional ground query at that location and computes an additional location 10 meters away in the direction of your view. There is also an additional ground query. Both are printed to stdout ... Hope that helps Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ? src/FDM/OpenFDM Index: configure.ac === RCS file: /var/cvs/FlightGear-0.9/source/configure.ac,v retrieving revision 1.116 diff -u -r1.116 configure.ac --- configure.ac 5 Apr 2006 19:52:52 - 1.116 +++ configure.ac 12 Jun 2006 06:13:18 - @@ -439,6 +439,14 @@ fi AM_CONDITIONAL(ENABLE_JPEG_SERVER, test x$ac_cv_header_simgear_screen_jpgfactory_hxx = xyes) +dnl Check for installed OpenFDM +AC_CHECK_HEADER(OpenFDM/OpenFDMConfig.h) +AM_CONDITIONAL(ENABLE_OpenFDM_FDM, \ + [ test x$ac_cv_header_OpenFDM_OpenFDMConfig_h = xyes ] ) +if test x$ac_cv_header_OpenFDM_OpenFDMConfig_h = xyes ; then +AC_DEFINE([FG_ENABLE_OPENFDM_FDM], 1, [Define for no logging output]) +fi + AC_LANG_POP dnl Check for system installed zlib @@ -519,6 +527,7 @@ src/FDM/JSBSim/models/atmosphere/Makefile \ src/FDM/JSBSim/models/propulsion/Makefile \ src/FDM/LaRCsim/Makefile \ + src/FDM/OpenFDM/Makefile \ src/FDM/SP/Makefile \ src/FDM/UIUCModel/Makefile \ src/FDM/YASim/Makefile \ Index: src/FDM/Makefile.am === RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/Makefile.am,v retrieving revision 1.7 diff -u -r1.7 Makefile.am --- src/FDM/Makefile.am 22 Nov 2004 10:10:33 - 1.7 +++ src/FDM/Makefile.am 12 Jun 2006 06:13:18 - @@ -4,8 +4,14 @@ SP_DIR = endif +if ENABLE_OpenFDM_FDM +OpenFDM_DIR = OpenFDM +else +OpenFDM_DIR = +endif + SUBDIRS = Balloon JSBSim LaRCsim UIUCModel YASim \ - $(SP_DIR) ExternalNet ExternalPipe + $(SP_DIR) $(OpenFDM_DIR) ExternalNet ExternalPipe noinst_LIBRARIES = libFlight.a Index: src/FDM/flight.hxx === RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/flight.hxx,v retrieving revision 1.13 diff -u -r1.13 flight.hxx --- src/FDM/flight.hxx 11 Jun 2006 13:34:19 - 1.13 +++ src/FDM/flight.hxx 12 Jun 2006 06:13:20 - @@ -433,7 +433,10 @@ FG_PARACHUTE = 9, // Driven externally via a serial port, net, file, etc. - FG_EXTERNAL = 10 + FG_EXTERNAL = 10, + + // OpenFDM. Reads JSBSim legacy and new files. + FG_OPENFDM = 11 }; // initialization Index: src/Main/Makefile.am === RCS file: /var/cvs/FlightGear-0.9/source/src/Main/Makefile.am,v retrieving revision 1.68 diff -u -r1.68 Makefile.am --- src/Main/Makefile.am 14 May 2006 12:22:53 - 1.68 +++ src/Main/Makefile.am 12 Jun 2006 06:13:20 - @@ -9,6 +9,13 @@ SP_FDM_LIBS = endif +if ENABLE_OpenFDM_FDM +OpenFDM_LIBS = $(top_builddir)/src/FDM/OpenFDM/libFGOpenFDM.a \ + -lOpenFDMJSBReader -lOpenFDMeasyxmlXML -lOpenFDMXML -lOpenFDM +else +OpenFDM_LIBS = +endif + if WITH_THREADS THREAD_LIBS = -lsgthreads $(thread_LIBS) else @@ -74,6 +81,7 @@ $(top_builddir)/src/FDM/LaRCsim/libLaRCsim.a \ $(top_builddir)/src/FDM/UIUCModel/libUIUCModel.a \ $(SP_FDM_LIBS) \ + $(OpenFDM_LIBS) \ $(top_builddir)/src/GUI/libGUI.a \ $(top_builddir)/src/Autopilot/libAutopilot.a \ $(top_builddir)/src/Input/libInput.a \ Index: src/Main/fg_init.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_init.cxx,v retrieving revision 1.165 diff -u -r1.165 fg_init.cxx --- src/Main/fg_init.cxx 10 Jun 2006 22:24:05 - 1.165 +++ src/Main/fg_init.cxx 12 Jun 2006 06:13:20 - @@ -88,6 +88,9 @@
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
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 ?
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 flightgear-devel@lists.sourceforge.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net 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 ?
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 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] 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 fg:runway id=03L fg:runwaypart material=concrete svg:polygon /fg:runwaypart fg:runwaypart material=asphalt svg:polygon ... /fg:runwaypart /fg:runway (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 ?
On 12/06/2006, at 9:37 PM, Thomas Förster wrote: snip 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 ?
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 fg:runway id=03L fg:runwaypart material=concrete svg:polygon /fg:runwaypart fg:runwaypart material=asphalt svg:polygon ... /fg:runwaypart /fg:runway (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 ?
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, 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 ?
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 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 ?
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:
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 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, 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 ?
* 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 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 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 ?
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 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] 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 ?
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] 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 ?
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
[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] 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
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] 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] 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] 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
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
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 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 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] 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
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
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
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] 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
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] 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] 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] 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 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] 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] 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
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] 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 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] 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 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] 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 ?
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] 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 ?
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 ?
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 flightgear-devel@lists.sourceforge.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net 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 ?
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] 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
