Re: [Flightgear-devel] A question regarding accurate taxiways
Arnt Karlsen wrote: ..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. After thinking this through a bit I do agree. By adding a new taxiway tag (the most important right now, there are some runway issues I want to see resolved at a later stage) you could prefer the new way over the old way if both are present. Since David Luff mentioned that most X-Plane users are using taxidraw these days we have a huge advantage now ... Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Multiplayer ports
Hi guys, Without wishing to start a flame war and perhaps starting another thread!! Anyone transmitting un-encrypted data across a world wide internet (as opposed to a "private" intranet) needs to think ahead a little. Every hacker will be rubbing their hands with glee before trying to hit you on these ports you have just announced. A server/client or even peer-to-peer client can implement TLS/SSL fairly easily. For those with restricted firewalls you can tunnel through SSH port 22 if you want to keep it simple. Firewall/NAT configurations are difficult enough for admins to configure without having to allow special FlightGear port rules to allow access to ports on machines in-the-clear which may then get hacked thus compromising the security of everyone behind the firewall. Maybe I am paranoid (well known for it in my previous job!) but a denial-of-service attack on your multi-player ports will soon wreck your response times! cheers Jim ___ 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 Freitag 14 Oktober 2005 19:28 schrieb Andy Ross: > 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. You are basically right. But nevertheless it isn't that easy and I try to explain why. The server receives a packet from a client and can read the "senders port" from the UDP header and start sending back data to the client using the ip and the port to the client. But what happens on the server side is: the server opens a socket fo the client using clients IP/port and stores the scket into an internal list. Whenever the server wants to send data to this client, it reuses the stored socket. So far, everysting is fine. If the server uses the port from the UDP header, everything works, without alterating anything on the firewall. Most of the time... The NAT router will create a temporary IP/port combination for the client, and this combination is what the server will see when receiving data. The server assumes that this combination will not change. But this assumption is wrong, especially with UDP as there is no "connection". So the server has to reread the port from the UDP header everytime it reseives new data from the client and recreate a socket for it (and clse the existing one of course). That will result in multiple create/close socket operations per second for every client. And that will simply result in multiple "already in use" errors per second. You can argue that you've never noticed such NAT behavior, and you are possibly right. But it will really only work with a so called "cone NAT router", which will make IP/port combination persistent. Interesting reading, although not directly connected to this discussion, is: http://gnunet.org/papers/nat.pdf regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DME range
> > 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? > Hehe :-) I haven't come of age when the Cold War eneded, and my private pilot certificate (PP-ASEL) is US-issued :-) V. ___ 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)
Andy Ross wrote: 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. This change has just been checked in. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DME range
On Sat, 15 Oct 2005 13:02:48 +0200 (IST), Vassilii wrote in message <[EMAIL PROTECTED]>: > > > 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? > > > > Hehe :-) I haven't come of age when the Cold War eneded, and my > private pilot certificate (PP-ASEL) is US-issued :-) ..brat. ;o) Jolly good thing Mathias Rust didn't carry a nuke to the Red Square. :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] Multiplayer ports
On Sat, 15 Oct 2005 10:30:44 +0100, Jim wrote in message <[EMAIL PROTECTED]>: > Hi guys, > Without wishing to start a flame war and perhaps starting another > thread!! > Anyone transmitting un-encrypted data across a world wide internet (as > opposed to a "private" intranet) needs to think ahead a little. Every > > hacker will be rubbing their hands with glee before trying to hit you > on these ports you have just announced. A server/client or even > peer-to-peer client can implement TLS/SSL fairly easily. For those > with restricted firewalls you can tunnel through SSH port 22 if you > want to keep it simple. Firewall/NAT configurations are difficult > enough for admins to configure without having to allow special > FlightGear port rules to allow access to ports on machines > in-the-clear which may then get hacked thus compromising the security > of everyone behind the firewall. ..yes, but can ssh give us any good udp tunnelling? > Maybe I am paranoid (well known for it in my previous job!) but a > denial-of-service attack on your multi-player ports will soon wreck > your response times! > cheers > Jim ..try put an outboard in your kettle and casually wield a chainsaw on asking the white coat guys for constructive critisism. ;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
[Flightgear-devel] Re: A question regarding accurate taxiways
You know, I'd be happy to help do some of the taxiway work if a new format becomes available. I've been trying to work with Taxidraw, but it's kind of difficult to work in because of the underlying format (I have no problems with Taxidraw itself.) I find I spend a lot of time making sure the areas are in the correct place, all to make a curve that could've been described more easily with multiple points. I know there was some talk of extracting taxiways from the FAA's PDFs, but until that becomes available, a 'starter set' of airports in the new format might be a good idea. -j > > Arnt Karlsen wrote: > >> ..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. > > After thinking this through a bit I do agree. By adding a new taxiway > tag (the most important right now, there are some runway issues I want > to see resolved at a later stage) you could prefer the new way over the > old way if both are present. Since David Luff mentioned that most > X-Plane users are using taxidraw these days we have a huge advantage > now ... > > > Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] [BUG] fix a NASAL error when the W&B dialog is open w/jsbsim
The default aircraft behaviour on the menu W&B dialog command is to
report a NASAL error on the STDERR of flightgear, with no reaction
in the game window. Included is a patch that pops up a dialog
instead, explaining why that wouldn't work.
The length is due to the diff inability to say that a lot of lines
were just indented right (as they were put inside an else {} )
Perhaps a GUI-cleaner way would be to condition the menu item
on the presence of the /yasim grove, yet I am unable to do it w/o
turning the whole submenu into a dynamic one, which I am lazy to do.
(Thanks to Melchior for suggesting the way it should behave instead)
Index: ../data/Nasal/gui.nas
===
RCS file: /var/cvs/FlightGear-0.9/data/Nasal/gui.nas,v
retrieving revision 1.10
diff -u -p -r1.10 gui.nas
--- ../data/Nasal/gui.nas 13 Jul 2005 11:30:32 - 1.10
+++ ../data/Nasal/gui.nas 15 Oct 2005 19:18:53 -
@@ -135,130 +135,139 @@ showWeightDialog = func {
contentArea = dialog[name].addChild("group");
contentArea.set("layout", "hbox");
-grossWgt = props.globals.getNode("/yasim/gross-weight-lbs");
-if(grossWgt != nil) {
-gwg = dialog[name].addChild("group");
-gwg.set("layout", "hbox");
-gwg.addChild("empty").set("stretch", 1);
-gwg.addChild("text").set("label", "Gross Weight:");
-txt = gwg.addChild("text");
-txt.set("label", "0123456789");
-txt.set("format", "%.0f lb");
-txt.set("property", "/yasim/gross-weight-lbs");
-txt.set("live", 1);
-gwg.addChild("empty").set("stretch", 1);
-}
-
-buttonBar = dialog[name].addChild("group");
-buttonBar.set("layout", "hbox");
-buttonBar.set("default-padding", 10);
-
-ok = buttonBar.addChild("button");
-ok.set("legend", "OK");
-ok.prop().getNode("binding[0]/command", 1).setValue("dialog-apply");
-ok.prop().getNode("binding[1]/command", 1).setValue("dialog-close");
-
-# Temporary helper function
-tcell = func {
-cell = arg[0].addChild(arg[1]);
-cell.set("row", arg[2]);
-cell.set("col", arg[3]);
-return cell;
-}
-
-#
-# Fill in the content area
-#
-fuelArea = contentArea.addChild("group");
-fuelArea.set("layout", "vbox");
-fuelArea.addChild("text").set("label", "Fuel Tanks");
-
-fuelTable = fuelArea.addChild("group");
-fuelTable.set("layout", "table");
-
-fuelArea.addChild("empty").set("stretch", 1);
-
-tcell(fuelTable, "text", 0, 0).set("label", "Tank");
-tcell(fuelTable, "text", 0, 3).set("label", "Pounds");
-tcell(fuelTable, "text", 0, 4).set("label", "Gallons");
-
-tanks = props.globals.getNode("/consumables/fuel").getChildren("tank");
-for(i=0; ihttp://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
On Saturday 15 October 2005 20:54, [EMAIL PROTECTED] wrote: > You know, I'd be happy to help do some of the taxiway work if a new format > becomes available. I've been trying to work with Taxidraw, but it's kind > of difficult to work in because of the underlying format (I have no > problems with Taxidraw itself.) I find I spend a lot of time making sure > the areas are in the correct place, all to make a curve that could've been > described more easily with multiple points. > > I know there was some talk of extracting taxiways from the FAA's PDFs, but > until that becomes available, a 'starter set' of airports in the new > format might be a good idea. I thought about the taxiway structure/format a while back. I came to the conclusion that a raw polygon editor is about the only way you're going to be able to create taxiways properly. One can use rectangular or bent taxiway sections but when you get to all the weird and wonderful taxiway layouts it's impossible to do with a generic taxiway structure. This is very apparent where taxiways intersect other taxiways, runways or aprons. The only thing that made sense to me was a 2D CAD type app like TaxiDraw which can draw polygons of any shape and size. The tessellation stage can be done when building the scenery. The only major problem I ran into was how does one handle markings and lines? Having offset or floating polygon lines is a major trick with regards to z-buffer fighting. Texture based lines that are part of the taxiway textures need to be generated on the fly and consume huge amounts of VRAM due to their uniqueness so that's not a very good solution either. Also cutting the lines into the taxiway polygons pushes the polygon count up horrendously. I think we need to pick a solution that is going to work in the sim before we try to figure out what storage mechanism or format we are going to use. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] flightgear cvs & OS X build question
Hi all, I purchased an Apple iBook G4 and want to run flightgear in OS X 1.4, too. The thing is, I would like to build from cvs, so i went looking for information and found this: http://sourceforge.net/docman/display_doc.php?docid=26350&group_id=126825 I am not sure if I like signing up at developer.apple.com in order to just get those xcode stuff... so, what do you think? Thorben PS: sorry, this doesn't belong into the developer section stricktly speaking, but as most developers hang around here, i thought it worth a try ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Systems vacuum.cxx, 1.7,
"Curtis L. Olson" wrote: > Update of /var/cvs/FlightGear-0.9/source/src/Systems > In directory baron:/tmp/cvs-serv25673 > > Modified Files: > vacuum.cxx vacuum.hxx > Log Message: > Allow a single vacuum system to be driven by multiple pumps. That's fine. This topic becomes even more interesting when you think of the newer PA28's which have a electrically driven backup vacuum pump, operated by a switch at the left panel boundary, 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] Re: A question regarding accurate taxiways
Hi, I hope I don't say too much if I say that there is work planned on defining taxiways by means of polylines in TaxiDraw. For starters I intended to create rectangles from that polyline data as appropriate, keeping the old format. Best regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] ..we're not re-inventing pcproxy?, was README.multiplayer update
On Sat, 15 Oct 2005 11:36:22 +0200, Oliver wrote in message <[EMAIL PROTECTED]>: > Am Freitag 14 Oktober 2005 19:28 schrieb Andy Ross: > The NAT router will create a temporary IP/port combination for the > client, and this combination is what the server will see when > receiving data. The server assumes that this combination will not > change. But this assumption is wrong, especially with UDP as there is > no "connection". So the server has to reread the port from the UDP > header everytime it reseives new data from the client and recreate a > socket for it (and clse the existing one of course). That will result > in multiple create/close socket operations per second for every > client. And that will simply result in multiple "already in use" > errors per second. > You can argue that you've never noticed such NAT behavior, and you are > possibly right. But it will really only work with a so called "cone > NAT > router", which will make IP/port combination persistent. > > Interesting reading, although not directly connected to this > discussion, is: http://gnunet.org/papers/nat.pdf ..we're not re-inventing pcproxy, are we? [EMAIL PROTECTED]:/var/www/01-gas/fmb.no/gas $ apt-cache --full show pcproxy Package: pcproxy Priority: optional Section: games Installed-Size: 196 Maintainer: Kees Leune <[EMAIL PROTECTED]> Architecture: all Version: 1.1.1-2 Depends: tk8.0 | tk8.2 | tk8.3 | tk8.4 Filename: pool/main/p/pcproxy/pcproxy_1.1.1-2_all.deb Size: 38294 MD5sum: 8d02f7c3a9d11db4938697f32e3c0239 Description: A masquerading proxy for flight simulation networks PCProxy allows multiple flight simulation clients to share a single network connection to a flight simulation network, such as VATSIM or IVAO, which is based on the fsd (Flight Simulator Daemon) protocol. This is particulary useful for players who wish to have multiple network clients active at the same time. In tech-terms, PCProxy is a multi-connect masquerading proxy for fsd traffic over TCP/IP. . PCProxy currently only supports networks which operate using the fsd protocol, like VATSIM and IVAO. Tag: use::proxying -- ..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] flightgear cvs & OS X build question
Xcode 2.0 should also be on your Mac OS X 10.4 install cd. But Xcode 2.1 or later is required to build the latest flightgear/simgear/plib cvs.So yes, you need to signup at ADC in order to get it. On 10/15/05, Thorben <[EMAIL PROTECTED]> wrote: Hi all,I purchased an Apple iBook G4 and want to run flightgear in OS X 1.4, too. Thething is, I would like to build from cvs, so i went looking for informationand found this: http://sourceforge.net/docman/display_doc.php?docid=26350&group_id=126825I am not sure if I like signing up at developer.apple.com in order to just getthose xcode stuff... so, what do you think?ThorbenPS: sorry, this doesn't belong into the developer section stricktly speaking,but as most developers hang around here, i thought it worth a try___ Flightgear-devel mailing listFlightgear-devel@flightgear.orghttp://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d-- - http://sourceforge.net/users/artooro/- http://artooro.blogspot.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
ojoe writes: > > You know, I'd be happy to help do some of the taxiway work if a new format > becomes available. I've been trying to work with Taxidraw, but it's kind > of difficult to work in because of the underlying format (I have no > problems with Taxidraw itself.) I find I spend a lot of time making sure > the areas are in the correct place, all to make a curve that could've been > described more easily with multiple points. > I certainly sympathise with this point of view. The current format is certainly crude. However, the problems with it only become apparent close up, when either close to or on the ground, and trying to follow taxiways at intersections. The taxiway layouts done in the current format definately improve the view of the airport on approach, when the deficiencies are too far away to be apparent. I think that what will happen with taxidraw is that we'll gradually make it capable of editing a future richer format, whilst continuing to export the current format at present. For instance, curved taxiway sections could be specified as a curve, stored as such internally in the .tpj format, and then the required rectangles to approximate it in the current format calculated on export to X-Plane (current) format. Or something like that! The next version of TaxiDraw will include support for explicitly specifying the airport perimeter. Once the perimeter of an airport is correct, and the FG scenery has been built with that definition, then it would be considerably easier for any future custom airport editor to build an airport that would fit into the same cutout from the scenery, and hence allow instant updating of the airport in the user's sim. Possibly... > I know there was some talk of extracting taxiways from the FAA's PDFs, I can't realistically see that happening! > but > until that becomes available, a 'starter set' of airports in the new > format might be a good idea. > The base package scenery area is the obviously choice for a technology demo - it just awaits someone to step up to the task. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer ports
> > Anyone transmitting un-encrypted data across a world wide internet (as > > opposed to a "private" intranet) needs to think ahead a little. Every > > > > hacker will be rubbing their hands with glee before trying to hit you > > on these ports you have just announced. A server/client or even > > peer-to-peer client can implement TLS/SSL fairly easily. For those > > with restricted firewalls you can tunnel through SSH port 22 if you > > want to keep it simple. Firewall/NAT configurations are difficult > > enough for admins to configure without having to allow special > > FlightGear port rules to allow access to ports on machines > > in-the-clear which may then get hacked thus compromising the security > > of everyone behind the firewall. > > ..yes, but can ssh give us any good udp tunnelling? Depends on what one means by "good". It will be bearing the characteristics of the underlying ssh/tcp retransmits/jitter/timeouts. > > Maybe I am paranoid (well known for it in my previous job!) but a > > denial-of-service attack on your multi-player ports will soon wreck > > your response times! If this becomes a problem, it's easy to extend a protocol to allow out-of-band (wrt the current UDP channel) player registration on a server. Whatever way the registration goes, when it happens, the server would know each player's IP and UDP port and dropping everything else. For linux-based server, it can be done more efficiently by allowing on the server the UDP traffic from the registered players only via a companion script that would reconfigure the local in-kernel firewall rules, based on the current registration. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
