Re: [Flightgear-devel] A question regarding accurate taxiways
Martin Spott wrote: On the other hand it might be worthwhile to spend this effort once we have a means to reliably convert airport layouts back and forth between vector layout and X-Plane format. To my opinion the X-Plane format isn't qualified for accurate runway and taxiway layout. It's way too course by using the centerlines only approach. I'd much rather see a polygon (or even quad) based approach. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: A revised README.Joystick.html
First let me say that I find it great if you and others look through old documents and submit updates. And I'm sorry to say that I have a little problem with this particular version, or two: * Dick Maurer -- Thursday 13 October 2005 23:58: I've updated and Attached Readme.joystick.html. Huh? That's almost the original file from CVS! You only added a title, changed two version numbers, and removed John as the author and made you the New Author: | version 0.9.8.1 13/10/2005 Former Author John Check New Author Dick Maurer That's not how copyright works. Editing someone's work doesn't make me the New Author, and him the Former Author. That's more like Original author vs. edited by But maybe I'm just too picky. | This document is written with versions of FlightGear 0.9.8 and greater in mind. And that's a problem. It does exactly describe versions 0.8.SOMETHING to 0.9.8. But we are going to release 0.9.9, which has seen quite some changes in the joystick area: no more joysticks.xml file (at least until 0.9.10), nasal init block, common nasal namespace, diagnose properties). Fortunately, all is not lost: I had started with describing the new features already months ago. I even fixed the numerous bugs and typos, and I'll finish my version later today or tomorrow. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Andy Ross wrote: Hardware mixing is, of course, the best solution, but note also that OpenAL can be built with any of a zillion back ends, among them the various sounds servers (esd, arts) which do their own mixing. In fact they *all* get included and an option in ~/.openalrc can define which one to use: ; Contains user settings for OpenAL ; Goes in ~/.openalrc ; Which backend? Tried in order of appearance (define devices '(native alsa sdl esd arts null)) ; Four speaker surround with ALSA (define speaker-num 4) (define alsa-out-device surround40:0,0) ; Some drivers do not support select (define native-use-select ;t) Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A revised README.Joystick.html
Ah oke I'll explain better what my intention was with this document. I indeed only inserted a title, a new author, new version numbers and deleted some old text. Explanation: Title, well I just thought it was nice to insert a title. Version number and deletion of link: I'm always a bit frustrated when I open a document and read that it has last been updated 4 years ago, with a link in the document that don't work anymore. That's why I changed it. Author: Interesting discussion :) I'll explain why I did this, and I gave it 15 minutes thought and also thought about it when I went to sleep if it was the right step. At the company where I work as an IT guy if we update someone's work we add ourselves as the author so that people can see who are the authors and ask questions about the document to the new author also. So It was not my intention to dusrupt the copyright or do it wrong but I just did what I thought was right. Maybe I was wrong I'm sorry. How do you guys do this? Then I'll adapt to that. Cheers, Dick Citeren Melchior FRANZ [EMAIL PROTECTED]: First let me say that I find it great if you and others look through old documents and submit updates. And I'm sorry to say that I have a little problem with this particular version, or two: * Dick Maurer -- Thursday 13 October 2005 23:58: I've updated and Attached Readme.joystick.html. Huh? That's almost the original file from CVS! You only added a title, changed two version numbers, and removed John as the author and made you the New Author: | version 0.9.8.1 13/10/2005 Former Author John Check New Author Dick Maurer That's not how copyright works. Editing someone's work doesn't make me the New Author, and him the Former Author. That's more like Original author vs. edited by But maybe I'm just too picky. | This document is written with versions of FlightGear 0.9.8 and greater in mind. And that's a problem. It does exactly describe versions 0.8.SOMETHING to 0.9.8. But we are going to release 0.9.9, which has seen quite some changes in the joystick area: no more joysticks.xml file (at least until 0.9.10), nasal init block, common nasal namespace, diagnose properties). Fortunately, all is not lost: I had started with describing the new features already months ago. I even fixed the numerous bugs and typos, and I'll finish my version later today or tomorrow. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A revised README.Joystick.html
Am Friday 14 October 2005 10:23 schrieb [EMAIL PROTECTED]: At the company where I work as an IT guy if we update someone's work we add ourselves as the author so that people can see who are the authors and ask questions about the document to the new author also. So It was not my intention to dusrupt the copyright or do it wrong but I just did what I thought was right. Maybe I was wrong I'm sorry. How do you guys do this? Then I'll adapt to that. The correct way is to leave copyright and author statements untouched and simply add a line with edited by John Doe, 11/10/2005. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On 14 Oct 2005, at 08:33, Oliver Schroeder wrote:Finding the "right" port isn't easy, since we have about 32 thousand (64 thousand on newer OSes) to choose from ;) However, I decided to use port 5000 on the server-side (and 5001 for telnet), both ports are configurable but these are the defaults. Both ports are only used by the free internet chess server (fics), which uses tcp. The udp ports are not used, yet. (AFAIK) Although a client can choose any incoming port he prefers, my personal predilection is to use the same port as used for outgoing. (=5000) It would be better to pick a port range that is entirely unused, for two reasons:- I think there's an implicit assumption that if the TCP port is well-known, the UDP port is reserved for your use- This stops FG providing a TCP alternative to UDP on the same port, which is something I think should be done anyway. Requiring people to update their firewall NAT tables is not a long term approach, even assuming the user is permittd to do such a thing; a much better approach is to have a 'try UDP, fall back to TCP approach', since TCP traversal from inside the firewall to out 'just works' with most NAT boxes. (One solution to using UDP is to implement Microsoft's UPnP system for asking the firewall to set up a dynamic port forward, but we looked at doing that for WorldForge and it's horrible. Really big spec. Nasty.)- As a side issue to the second point, unless you want to implement your own reliable layer on top of UDP (boring, fiddly), it makes sense to have a TCP channel open anyway for reliable transfer of critical information. Textual ATC might fit into this category, and I'm sure there is other meta-info that should be reliably delivered.HHJames-- Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A revised README.Joystick.html
[EMAIL PROTECTED] wrote: How do you guys do this? Then I'll adapt to that. Just add an extra copyright statement below the others. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: A revised README.Joystick.html
* [EMAIL PROTECTED] -- Friday 14 October 2005 10:23: Then I'll adapt to that. I've committed already. Your name is in the log. I think that this is sufficient for that case. Thanks! m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A revised README.Joystick.html
Oke I understood all the comments. I'll adapt them. Thanks for the explanations. Cheers, Dick Citeren Melchior FRANZ [EMAIL PROTECTED]: * [EMAIL PROTECTED] -- Friday 14 October 2005 10:23: Title, well I just thought it was nice to insert a title. Agreed. :-) Version number and deletion of link: I'm always a bit frustrated when I open a document and read that it has last been updated 4 years ago, with a link in the document that don't work anymore. Removing the link was a good idea. But changing the version number was just cosmetics, and actually a lie: it doesn't magically make the document describe 0.9.8 or greater. I find this actually more frustrating. From an old date/version number I can at least see *why* the contents are all wrong. ;-) At the company where I work as an IT guy if we update someone's work we add ourselves as the author so that people can see who are the authors and ask questions about the document to the new author also. I would still not call that author. Just editor. And I know this only as adding a copyright line with appropriate date, and mostly in source code. This isn't normally done in fgfs documents AFAIK. There's ususally only one -- the real -- author named in the documents. All fgfs developers that edit the file can be found in the cvs log and are of no interest to the reader. m. -- Faust, New Author: Melchior FRANZ (Former Author: Johann W. von GOETHE :-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
Am Friday 14 October 2005 10:37 schrieb James Turner: It would be better to pick a port range that is entirely unused, for two reasons: There is no unused range of ports, but see below. - I think there's an implicit assumption that if the TCP port is well- known, the UDP port is reserved for your use I take well known as a well defined term, refering to ports 1-1024, assigned by the IANA. In that case your assumption is wrong. It is either defined or not used. All other ports (1024) are free for use for any application. All we have to take care about is, that these ports are unlikely used by other applications at the same time. A good example of what will _not_ work is using port 6000+ for incoming connections, since it is used by X-Servers. - This stops FG providing a TCP alternative to UDP on the same port, which is something I think should be done anyway. Requiring people to update their firewall NAT tables is not a long term approach, even assuming the user is permittd to do such a thing; a much better approach is to have a 'try UDP, fall back to TCP approach', since TCP traversal from inside the firewall to out 'just works' with most NAT boxes. In case of multiplayer, there is no alternative to UDP. Well, there is of course, but you definatly don't want TCP for MP-data. If a user is not permitted to alter the NAT tables, he is probably not permitted to fire up flightgear as well. But I do admit, that it might be a huge barrier for a user to alter firewall rules as needed. But anyway, using a fallback mechanism leads to everyone using tcp connections, as they would simply work. And I repeat, you don't want tcp in multiplayer environments. - As a side issue to the second point, unless you want to implement your own reliable layer on top of UDP (boring, fiddly), it makes sense to have a TCP channel open anyway for reliable transfer of critical information. Textual ATC might fit into this category, and I'm sure there is other meta-info that should be reliably delivered. In case you really need a reliable transmission, there is no alternative to TCP. But there are simple ways to ensure that UDP data arrives its target. But that is out of scope here. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DME range
Does anyone know if the DME calculation to a VORTAC is based on slant range? Noticed when flying over a fix say at FL350, the range goes down to zero at station passage. It should be the AGLvalue of the aircraft over the station. OTH a waypoint based on radial intersections or GPS would go to zero. With VOR-DME it is definitely the slant range. I don't know about VORTACs, never flew a TACAN-equipped aircraft in the real life... v ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On Fri, 14 Oct 2005, George Patterson wrote: [snip] Gawd, I don't belive that I am commenting on a patch. Thanks for your comments! (I'm having similar feelings every time I am sending a patch, esp. to a minor thing like the docs...) I'm fairly certain that the selective positioin forwarding based on the players' position is already in the logic of the FG server. This was fixed in 0.0.6 of FG server. Here is an addition against the current CVS (I also threw in the GPL-ness): Index: ../data/Docs/README.multiplayer === RCS file: /var/cvs/FlightGear-0.9/data/Docs/README.multiplayer,v retrieving revision 1.2 diff -u -p -r1.2 README.multiplayer --- ../data/Docs/README.multiplayer 13 Oct 2005 13:42:35 - 1.2 +++ ../data/Docs/README.multiplayer 14 Oct 2005 10:31:32 - @@ -58,13 +58,13 @@ For use with a server: -- Oliver Schroeder has created a server for multiplayer flightgear use. The server acts as a packet forwarding mechanism. When it -receives a packet, it sends it to all other active players. -Future versions might be more scalable, only forwarding information -on the planes in the receiving player's vicinity. +receives a packet, it sends it to all other active players +in the vicinity (the server is configured to use 100nm by default). Check out the server homepage http://www.o-schroeder.de/fg_server/ for the current status. You can either download the server for -some local use, or join the developers on the existing servers. +some local use, or join the developers flying at the existing servers. +As with flightgear, the server is free software, released under GPL. Pigeon http://pigeond.net has created a web page monitoring two such servers, showing the traffic in a Google map environment. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On 14 Oct 2005, at 10:27, Oliver Schroeder wrote:But I do admit, that it might be a huge barrier for a user to alter firewall rules as needed. But anyway, using a fallback mechanism leads to everyone using tcp connections, as they would simply work. And I repeat, you don't want tcp in multiplayer environments. I simply don't agree with that statement - many Windows games offer both options, for this exact reason. The notion that using TCP for multiplayer games is inadvisable is simply unfounded in my experience. It is certainly 'conventional wisdom' that TCP is evil / bad / slow, and for sure it offers a performance and overhead cost, but TCP works perfectly acceptably providing you have a faster-than-modem connection and low packet loss rates, which is the case for virtually everyone with a DSL or cable connection these days.Back in the days of QuakeWorld and Tribes 1, for sure this was more critical, but we've using nothing but plain TCP in WorldForge for years, in a interactive environment, and the response is pretty good. For sure we will move the 'lossy' position update data to UDP in the future to get smoother updates, but it's purely an optimisation, and we will always keep TCP as a fallback, since so many people are NATed.So my perspective is that amount of code added is trivial, the usability benefit is high, the people who can make UDP work see no change, and a large group of people who previously would be completely unable to use MP can give it a go. Anyway, I'll resume lurking now.James -- Java is, in many ways, C++-- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
All other ports (1024) are free for use for any application. All we have to take care about is, that these ports are unlikely used by other applications at the same time. A good example of what will _not_ work is using port 6000+ for incoming connections, since it is used by X-Servers. Why are we talking about 6000 anyway? The README.multiplayer never talked about anything except 5000-5002 and 5500-5501 AFAIK. In case of multiplayer, there is no alternative to UDP. Well, there is of course, but you definatly don't want TCP for MP-data. If a user is not permitted to alter the NAT tables, he is probably not permitted to fire up flightgear as well. Hear, hear. If a user is behind a firewall and can't have it configured the way he wants for the UDP traffic to come through, it's a problem of the user's relations with the local admin and/or the ISP. But I do admit, that it might be a huge barrier for a user to alter firewall rules as needed. But anyway, using a fallback mechanism leads to everyone using tcp connections, as they would simply work. And I repeat, you don't want tcp in multiplayer environments. - As a side issue to the second point, unless you want to implement your own reliable layer on top of UDP (boring, fiddly), it makes sense to have a TCP channel open anyway for reliable transfer of critical information. Textual ATC might fit into this category, and Are you talking about the textual ATC datalinks in the modern cockpits? V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
Oliver Schroeder wrote: Am Friday 14 October 2005 10:37 schrieb James Turner: - I think there's an implicit assumption that if the TCP port is well- known, the UDP port is reserved for your use I take well known as a well defined term, refering to ports 1-1024, assigned by the IANA. In that case your assumption is wrong. It is either defined or not used. There are what I'd call two types of well-known port numbers. Think of common database servers for example. Nobody would chose port 5432 for their application although it's not below 1024. A fine explanation and a set of the respective files is collected here: http://www.sethwklein.net/projects/iana-etc/ Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
Am Friday 14 October 2005 13:54 schrieb Martin Spott: There are what I'd call two types of well-known port numbers. Think of common database servers for example. Nobody would chose port 5432 for their application although it's not below 1024. A fine explanation and a set of the respective files is collected here: Actually, there are 3 port ranges defined by IANA: 1) The Well Known Ports are those from 0 through 1023. - these are assigned by IANA 2) The Registered Ports are those from 1024 through 49151 - they are not assigned by IANA, the IANA lists these ports only as a convenience to the community. 3) The Dynamic and/or Private Ports are those from 49152 through 65535 - they are not assigned by IANA, and they are meant for temporary use only But anyway. It's up to the server operator to decide which port to use. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
Am Friday 14 October 2005 12:54 schrieb James Turner: I simply don't agree with that statement - many Windows games offer both options, for this exact reason. The notion that using TCP for multiplayer games is inadvisable is simply unfounded in my experience. It is certainly 'conventional wisdom' that TCP is evil / bad / slow, and for sure it offers a performance and overhead cost, I don't call TCP evil / bad / slow. I just think that TCP is not usable for out purpose. Please note that I'm talking _only_ about the transmission of multiplayer data (position, actions, etc). but TCP works perfectly acceptably providing you have a faster-than- modem connection and low packet loss rates, which is the case for virtually everyone with a DSL or cable connection these days. It's a bit snooty to think that no one is using a modem connection anymore. But anyway, the discussion about TCP vs. UDP in multiplayer environments is very old (and still ongoing), and nobody can give a (serious) answer, which is valid for all environments. It simply depends on the needs of the application. A turn-based game is for sure better served with TCP. As for roleplaying games, some use TCP and others UDP. For action based games there is almost no way around UDP (well, depends on the number of users, too). In a real-time scenario TCP is a no-go. TCP is a good, solid protocol, however it simply isn't up to the task of real-time games. With TCP, even if you have received a packet, the kernel/stack will witthold that packet until all previous packets have arrived - this means that while more up to date information is available, your code may never see it until the TCP stacks decides you can. This may include a 3-second retransmit timer in the case of lost packets. Back in the days of QuakeWorld and Tribes 1, for sure this was more critical, but we've using nothing but plain TCP in WorldForge for years, in a interactive environment, and the response is pretty good. For sure we will move the 'lossy' position update data to UDP in the future to get smoother updates, but it's purely an optimisation, and we will always keep TCP as a fallback, since so many people are NATed. I hope you don't plan to mix UDP/TCP transmission. It sounds tempting to send updates via UDP and use TCP for serious data. But you will end up with frustrating timing problems and funny effects within your virtual world. So my perspective is that amount of code added is trivial, the usability benefit is high, the people who can make UDP work see no change, and a large group of people who previously would be completely unable to use MP can give it a go. The only real argument against UDP is the firewall configuration issue (at least in our case). Btw, good reading on the subject is the source code of Quake3 and John Carmacks comments on it (especially the network part of course). Have fun, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A question regarding accurate taxiways
Martin Spott wrote: Erik Hofman wrote: To my opinion the X-Plane format isn't qualified for accurate runway and taxiway layout. This is Harald's opinion as well as mine ! _But_: Our opinion on this format actually does not change it. Right ? And as long as FG sticks to rely on this X-Plane data it makes little sense to generate airports in a different format - as long as we are unable to convert back and forth. For example it would be a nice feature to automagically create outlines and a centerline from X-Plane data and create a set of overrides from FAA/SIA/whoever data. I can see two kind of airports in the Robin database : - those with detailed taxiways and apron : they have no more any taxiway description because the mass of little pseudo-apron used to make details and curves have replaced the one or two default taxiways ; - those without detaild taxiways; they have one or two taxiways paralel to the runways. So I have the feeling that we can not extract any meaningfull information from the runways data from this database, the side effect is that there is no need to convert from one format to another hypothetical format. Probably we are going to merge this data into a single set of airport descriptions in vector format for FlightGear. What are we going to do if something is being changed in Robin's database ? Are we going to maintain a parallel database ? Regards, Martin. We have 20.000+ airports in Robin base, we want to change 50 or 500 of them. I think we should keep Robin's database and use it as we use it today, and use a new database for the few airports we want to upgrade with a new format. Durk Taslma is using a network to describe the ground traffic pattern, we are no more talking about polygons. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On Freitag 14 Oktober 2005 15:20, Oliver Schroeder wrote: I don't call TCP evil / bad / slow. I just think that TCP is not usable for out purpose. Please note that I'm talking _only_ about the transmission of multiplayer data (position, actions, etc). Well, UDP is just aprioriate for realtime applications. Professional simulation codes I know combining real hardware together with simulations together in a single loop, use udp or udp like protocols. Where with 'udp like', I think of protocols just pushing the data onto the wire and not waiting for an ack of the other side. Whatever you may experience with tcp in *your* special case, the only way to *guarantee* that you will not block or hang the simulation because of lost ethernet frames which will past a timeout be retransmitted and block the stream for that whole time, is *not* using tcp. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
James Turner wrote: This stops FG providing a TCP alternative to UDP on the same port, which is something I think should be done anyway. Requiring people to update their firewall NAT tables is not a long term approach, even assuming the user is permittd to do such a thing This is a mischaracterisation. All consumer NAT routers of which I am aware do automatic port forwarding of UDP connections. The problem you are having is a misfeature in the MP server. It should be replying to the source port address, and not to a hard-coded standard UDP port on the client (which may have been munged by intervening routers). Properly done, UDP works just like TCP -- the client connects to a well-known port on the server and the server replies to the same connection. No client port needs to be specified. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] rain model on windsheild
i have seen som time ago, a post on this list, from some one who wanted to model rain dromps over windsheild and asking for pictures/video with that from real world. A few weeks ago i had flown in verry bad weather with a cessna 172 and i took some pictures and videos... if any body whaant them, ask me! IS ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems compiling latest CVS snapshot (2005-10-11)
Hi Andy,
thanks for the hint and patch. I should have searched in the mail archive.
With the patch it compiles fine.
Thanks
Matthias
This is a known bug when compiling on a 64 bit system. I fix it in my
tree by double casting:
--- AIBase.cxx 5 Sep 2005 13:25:09 - 1.41
+++ AIBase.cxx 10 Oct 2005 23:39:47 -
@@ -398,7 +398,7 @@
}
int FGAIBase::_getID() const {
-return (int)(this);
+return (int)(long)this;
}
This fix can't be checked in though, because it isn't correct*. The
generated ID is not guaranteed to be unique. The right solution would
be to either change the type of the ID to a long long or uint64_t,
or generate an identifier from something other than the pointer value.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A question regarding accurate taxiways
On Fri, 14 Oct 2005 18:54:47 +0200, Harald wrote in message [EMAIL PROTECTED]: Martin Spott wrote: Erik Hofman wrote: To my opinion the X-Plane format isn't qualified for accurate runway and taxiway layout. This is Harald's opinion as well as mine ! _But_: Our opinion on this format actually does not change it. Right ? And as long as FG sticks to rely on this X-Plane data it makes little sense to generate airports in a different format - as long as we are unable to convert back and forth. For example it would be a nice feature to automagically create outlines and a centerline from X-Plane data and create a set of overrides from FAA/SIA/whoever data. I can see two kind of airports in the Robin database : - those with detailed taxiways and apron : they have no more any taxiway description because the mass of little pseudo-apron used to make details and curves have replaced the one or two default taxiways ; - those without detaild taxiways; they have one or two taxiways paralel to the runways. So I have the feeling that we can not extract any meaningfull information from the runways data from this database, the side effect is that there is no need to convert from one format to another hypothetical format. Probably we are going to merge this data into a single set of airport descriptions in vector format for FlightGear. What are we going to do if something is being changed in Robin's database ? Are we going to maintain a parallel database ? We have 20.000+ airports in Robin base, we want to change 50 or 500 of them. I think we should keep Robin's database and use it as we use it today, and use a new database for the few airports we want to upgrade with a new format. Durk Taslma is using a network to describe the ground traffic pattern, we are no more talking about polygons. ..IMHO, the wise thing to do is extend Robin's database format to do our thing the way we wanna do it, and use that to win him over our way exporting to his format, and ship him both. Robin's user's corrections remains useful to us, even if they stick with their current format. ..and, we can reel them in pretty nicely our way setting up a web site taxi way editor app for user input of their database corrections, to output the corrected data on the spot, and in both formats. -- ..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@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] ..picky preach to the choir, was: A revised README.Joystick.html
On Fri, 14 Oct 2005 10:58:51 +0200, Melchior wrote in message [EMAIL PROTECTED]: * [EMAIL PROTECTED] -- Friday 14 October 2005 10:23: At the company where I work as an IT guy if we update someone's work we add ourselves as the author so that people can see who are the authors and ask questions about the document to the new author also. I would still not call that author. Just editor. ..say maintainer, if you mean the guy who updates old docs and answers questions etc. ..adding new content to something old, you become an author. Too. But not the original author to the document. Only to whatever you add to it. Also when that add word means remove old stuff. ;o) And I know this only as adding a copyright line with appropriate date, and mostly in source code. This isn't normally done in fgfs documents AFAIK. There's ususally only one -- the real -- author named in the documents. ..say original. All fgfs developers that edit the file can be found in the cvs log and are of no interest to the reader. ..that would depend on the reader's purpose for his reading. ;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@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DME range
On Fri, 14 Oct 2005 12:04:09 +0200 (IST), Vassilii wrote in message [EMAIL PROTECTED]: Does anyone know if the DME calculation to a VORTAC is based on slant range? Noticed when flying over a fix say at FL350, the range goes down to zero at station passage. It should be the AGLvalue of the aircraft over the station. OTH a waypoint based on radial intersections or GPS would go to zero. With VOR-DME it is definitely the slant range. I don't know about VORTACs, never flew a TACAN-equipped aircraft in the real life... ..sure? If you flew red star planes during the Cold War, you guys would be using similarly working gear but with other names? -- ..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@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
