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
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
Ralf Gerlich wrote: 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. Excellent! Erik ___ 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
Paul Surgeon wrote: On Saturday 15 October 2005 20:54, [EMAIL PROTECTED] wrote: 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. You mean, ac3d or blender ? No need to use a special editor if you want to draw polygons. 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. I don't want to do pixel or vertex editing, If I must do that then I use ac3d and I can do everything without any constraint. There is a tool for another sim that uses points, lines and splines to define the taxiways. 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 The best way I found to counter the z-buffer fighting is simply to disable z-buffer testing. Remember, we are painting the ground, why would we want any z tests (you can find situation where this add artifacts of course). Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] [BUG] fix a NASAL error when the WB dialog is open w/jsbsim
* Vassilii Khachaturov -- Saturday 15 October 2005 21:28: The default aircraft behaviour on the menu WB 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. Greying the menu entry out would have been even better, but I don't think that's currently possible. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] uninitialized variables used
Ladislav Michnovič wrote: Hello. Using new gcc 4.0 I have some serios warnings about uninitialized variables, that are used. I created a patch, but I have no idea if it is possible to do it my way. Can you check this out please? It would be great if it will be fixed in next release. The CVS doesn't differ in this case from 0.9.8. Thanks. Thanks for the patch Ladislav, I've committed a slightly modified version to CVS now. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..we're not re-inventing pcproxy?, was README.multiplayer update
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. I think we're not --- the flightgear server/client comm is UDP based. Reading into the upstream pages of pcproxy http://www.leune.org/pcproxy/ I wonder if the flightgear server though should support the fsd protocol at some future point of time to be a gateway between our and VATSIM/IVAO flying... V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] [BUG] fix a NASAL error when the WB dialog is open w/jsbsim
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 {} )
(To verify that quickly, try applying the diff locally and do a
cvs diff -bu
which then would ignore everything except the substantial change.)
BTW, is there a way to create an XML condition w/o NASAL code
equivalent to
+ if (props.globals.getNode(/yasim) == nil) {
checking that a particular node is present in the property grove?
(Not for this particular example, but for my general education.)
V.
___
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
Harald JOHNSEN wrote: The best way I found to counter the z-buffer fighting is simply to disable z-buffer testing. Remember, we are painting the ground, why would we want any z tests (you can find situation where this add artifacts of course). Exactly, if you disable the z-buffer, you lose hidden surface removal. You can play tricks with drawing order, but this gets really complicated, really quickly, and you end up with things like runway lights from other airports showing through terrain and wierd stuff like that ... 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@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
On Saturday 15 October 2005 23:44, Ralf Gerlich wrote: 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. That's still very restrictive. It's a step in the right direction but is still far from what is needed. We need polygon editing and not just polylines. Taxiways are unfortunately too full of non-parallel sides for polylines to work properly everywhere. How would you draw these taxiways with polylines? http://surgdom.hollosite.com/flightgear/fg_airport_maker/images/terrain_approaches/katl_breakdown2.png http://surgdom.hollosite.com/flightgear/fg_airport_maker/images/terrain_approaches/katl_breakdown3.png http://surgdom.hollosite.com/flightgear/fg_airport_maker/images/terrain_approaches/katl_breakdown4.png However I don't mean to be discouraging. Polylines will be a lot better than what we currently have but would still frustrate people like me who want to be able to model all the minor details such as the common overtaking/passing sections at the end of taxiways or the shoulders that allow large aircraft to turn on a taxiway without running off it. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..we're not re-inventing pcproxy?, was
Vassilii Khachaturov wrote: I wonder if the flightgear server though should support the fsd protocol at some future point of time to be a gateway between our and VATSIM/IVAO flying... It's not a matter if it _should_ or not. The relevant details of the protocol, at least as used by VASTIM, are 'closed', 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Surgeon schrieb: On Saturday 15 October 2005 23:44, Ralf Gerlich wrote: 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. That's still very restrictive. It's a step in the right direction but is still far from what is needed. We need polygon editing and not just polylines. Taxiways are unfortunately too full of non-parallel sides for polylines to work properly everywhere. How would you draw these taxiways with polylines? Polylines should be sufficient (as long as you don't need things like bridges, i.e. stay 2D). To find out if you are outside (e.g. on grass) you do a line walk. I.e. you start on the outside (e.g. from far far away) and walk on a line to the desired position. On that walk you cound how often you've crossed a polyline. Each time you cross it you change from outside to inside (or the other way round). To get the final triangulation you'll only need a contraint delauney triangulation where you'll delete the outside triangles (or, better, asign them the outside material...) Doesn't TaxiDraw already use CGAL? With CGAL you've got all that you need for that. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDUljXlhWtxOxWNFcRAsHaAKCnLD1thK3IJYl5zP/H5yFFcPU1fwCgpXPk DPQApGan8ULq1O70gRGjy+U= =8g2S -END PGP SIGNATURE- ___ 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
Dave writes: 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. The other thing to consider is the 'fun' factor. TD does a great job of getting the raw data in to the editor; importing the images from USGS images automagically was a great idea. But after that comes the actual editing. Producing accurate curves can be trying, especially if they're convex. Since there're curves all over, it becomes an important part of the process. If editing taxiways becomes as easy as importing the image data, a lot more people will do it and we'll all wind up with more airports (and a better user experience.) Just my 2c :) -joe ___ 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
[EMAIL PROTECTED] wrote: If editing taxiways becomes as easy as importing the image data, a lot more people will do it and we'll all wind up with more airports (and a better user experience.) I don't find creating an airport and taxiways in TaxiDraw that challenging. As with all manual work you need some practice and you won't get around that if the editor allows for placing polylines. Well, creating the outlines of the taxiways might get easier but on the other hand you'll have to spend more time for the layout of the infrastructure. (centerlines, holding positions and so on). After you've finished one airport in TaxiDraw you'll experience that you need only a fraction of the time for the second one. Just have a nice sunday evening and try it. I spent the most time for my first airport with digging for reliable information on location, heading and size of the runway and taxiways Cheers, 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, Christian Mayer schrieb: Paul Surgeon schrieb: On Saturday 15 October 2005 23:44, Ralf Gerlich wrote: 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. That's still very restrictive. It's a step in the right direction but is still far from what is needed. We need polygon editing and not just polylines. Taxiways are unfortunately too full of non-parallel sides for polylines to work properly everywhere. How would you draw these taxiways with polylines? The original intention was to produce both ground AI data and the scenery representation from these polylines. The line segments and joints should be automatically converted to an appropriate approximation using rectangles. However placing rectangles will still be available, at least in what I have in mind. I'd definitely favour a new format with polygons, proper curved centerlines, etc., but currently the X-Plane format does not support this and we currently have no way of syncing it with Robin Peel's database - except by generating polygons from Robin's data just the way we're doing it now. However, I don't think that is the intention. I'm not sure how important giving back to Robin's DB is for the FlightGear community but in the OpenSource manner I'd say we should try to find a way of not doing things twice in two communities. Polylines should be sufficient (as long as you don't need things like bridges, i.e. stay 2D). To find out if you are outside (e.g. on grass) you do a line walk. I.e. you start on the outside (e.g. from far far away) and walk on a line to the desired position. On that walk you cound how often you've crossed a polyline. Each time you cross it you change from outside to inside (or the other way round). You are probably talking about planar partitioning, where different faces are defined by separating lines. (The only links I can find in a quick google search on topological maps, planar maps or DCEL (doubly connected edge lists) are from the CGAL-manual or non-introductory papers) [SNIP] Doesn't TaxiDraw already use CGAL? With CGAL you've got all that you need for that. TaxiDraw doesn't use CGAL currently. Best regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Instant replay broken?
Is it just me, or is it completely impossible to escape from instant replay once engaged in the current CVS? Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instant replay broken?
David Luff wrote: Is it just me, or is it completely impossible to escape from instant replay once engaged in the current CVS? You can end the repeating loop by pressing 'p' twice. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instant replay broken?
On Sun, 2005-10-16 at 17:11 +0100, David Luff wrote: Is it just me, or is it completely impossible to escape from instant replay once engaged in the current CVS? Cheers - Dave Yes, It's just you :-P You can stop the replay by select the View menu, select instant replay. On the Instant Replay dialog check the Disable replay. and click Ok. I hope that helps. George ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..we're not re-inventing pcproxy?, was
I wonder if the flightgear server though should support the fsd protocol at some future point of time to be a gateway between our and VATSIM/IVAO flying... It's not a matter if it _should_ or not. The relevant details of the protocol, at least as used by VASTIM, are 'closed', Security by obscurity, as far as I am reading the forums... stupid. Apparently the pcproxy is in Debian (which made me believe we can interface the protocol, too) because it just forwards the packets w/o examining their contents too much. Hopefully one day we'll provide an open source alternative to that. 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: 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). Er, no. Check the man page of sendto. :) The server only needs one socket for its whole lifetime. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] [BUG] fix a NASAL error when the WB dialog is open w/jsbsim
Vassilii Khachaturov wrote:
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
{} )
Use the -w argument to diff to eliminate the whitespace noise for
readability.
But regardless, don't do this. :)
Wrapping huge blocks of code (like this one, which is a big GUI
object creation routine) inside giant if() statements is *very*
bad for readability, and even worse for maintainability. If you
absolutely have to, then it is almost always better to split off
more functions as in:
if(props.globals.getNode(/yasim) == nil) {
popupWarningDialog();
} else {
createWBDialog();
}
A bigger issue, however, is that this is *not* supposed to be a
YASim-specific dialog! All it does is set fuel and weight
quantities in the property system, and the intent was always that
it would be FDM-independent. As it happens, YASim is the only
FDM that reads those properties, but that is hopefully a
temporary situation. This patch, IMHO, provides a disincentive
for the JSBSim folks to implement this feature as it explicitly
cuts them off from the dialog for testing.
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] [BUG] fix a NASAL error when the WB dialog is open w/jsbsim
* Andy Ross -- Sunday 16 October 2005 19:32: YASim is the only FDM that reads those properties, Which *does* make it a YASim-only dialog. Not for you and me, maybe, but for those who will have to live a *very* long time with 0.9.9. Just that those don't know why it sometimes works, and sometimes not. This patch, IMHO, provides a disincentive for the JSBSim folks to implement this feature as it explicitly cuts them off from the dialog for testing. Oh, sure. Just like it did for one, two years now. Just present the 0.9.9 users a menu entry that silently fails. This will surely convince the JSBSim people. :- m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] [BUG] fix a NASAL error when the WB dialog is open w/jsbsim
What about this: in the 0.9.9 release we pop up a dialog that says: Not implemented for this type of aircraft. And after the release: *Still* not implemented in JSBSim!. ;-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug the next
Hans-Georg Wunder wrote: Jeff McBride wrote: The patch committed by Erik: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Autopilot/xmlauto.cxx.diff?r1=1.19r2=1.20cvsroot=FlightGear-0.9 should fix this. This is what would happen when you set delta_u_n = u_max - u_n_1 : delta_u_n (u_max - u_n_1) 0.6 (0.5 - 0.0) : true delta_u_n = u_max - u_n_1 = 0.5 - 0.0 = 0.5 u_n = u_n_1 + delta_u_n = 0.0 + 0.5 = 0.5 and at the next time step let's assume that delta_u_n But consider this scenario for next step: Assume Kp = 1. This means that the previous error e_n_1 = 0.6. Say the new error e_n = 0.5. delta_u_n = Kp(e_n - e_n_1) = -0.1 Now, this new delta when aplied to the saturated output will be: u_n = 0.5 - 0.1 = 0.4 ; The correct proportional component of the output should be 0.5 In the ideal scenario, the delta_u_n = -0.1 would be applied to u_n=0.6 to yield 0.5, but because of the saturation, the P component becomes offset. This offset will be compensated for by the I component after some time, but it shouldn't have to be. As I said before, I think the best solution is to track the true PID output (in this case 0.6) while outputing the saturated value and disable the integral component (with either a hard or soft limit) when the controller is saturated. Hans-Georg's suggested scaling of ep_n essentially fixes the problem. The one technical problem I have come to see with this approach is that it assumes that the entire output movement into saturation is due to the P part: ep_n = ep_n*u_max/(delta_u_n+u_n) This says that, for example, if the output only moved by half of the calculated increase because of saturation, we should change the current proportional position (saved in ep_n_1)to half its calculated value. This basically works because any large movements in one step are likely to be dominated by P, and in most (if not all) cases the error generated when the output moves back out of saturation is small and quickly compensated by the I part. I believe this is why the output of his latest test run using his fix returns to 0.0019 or 0.00175 after the reference is returned to 0, rather than returning to exactly u_n=0. Clearly this error is small and will not represent a proplem in this case. -Jeff I see your point. In saturation the relation between P-Part, I-Part and D-part seems to be changed. I will verify that in the next days. Hans-Georg I have set the controller in debug mode and extracted the the values for P I and D. Every line is double, I don't know why. P:-0.1 I:-0.00058 D:-0 output = -0.100583 P:-0.1 I:-0.00058 D:-0 output = -0.100583 -- step to 0.1 P:-0 I:-0.00058 D:-0 output = -0.101167-- output is increasing due to I P:-0 I:-0.00058 D:-0 output = -0.101167 P:-0 I:-0.00058 D:-0 output = -0.10175 P:-0 I:-0.00058 D:-0 output = -0.10175 P:-0 I:-0.00067 D:-0 output = -0.102417 P:-0 I:-0.00067 D:-0 output = -0.102417 P:-0 I:-0.0005 D:-0 output = -0.102917 P:-0 I:-0.0005 D:-0 output = -0.102917 P:-0 I:-0.00058 D:-0 output = -0.1035 P:-0 I:-0.00058 D:-0 output = -0.1035 P:-0 I:-0.00058 D:-0 output = -0.104083 P:-0 I:-0.00058 D:-0 output = -0.104083 P:-0 I:-0.00058 D:-0 output = -0.104667 P:-0 I:-0.00058 D:-0 output = -0.104667 P:-0 I:-0.00067 D:-0 output = -0.105333 P:-0 I:-0.00067 D:-0 output = -0.105333 P:-0 I:-0.00058 D:-0 output = -0.105917 P:-0 I:-0.00058 D:-0 output = -0.105917 P:-0 I:-0.00058 D:-0 output = -0.1065 P:-0 I:-0.00058 D:-0 output = -0.49625 P:-0 I:-0.00058 D:-0 output = -0.49625 P:-0 I:-0.00058 D:-0 output = -0.496833 P:-0 I:-0.00058 D:-0 output = -0.496833 P:-0 I:-0.00058 D:-0 output = -0.497417 P:-0 I:-0.00058 D:-0 output = -0.497417 P:-0 I:-0.00058 D:-0 output = -0.498 P:-0 I:-0.00058 D:-0 output = -0.498 P:-0 I:-0.00058 D:-0 output = -0.498583 P:-0 I:-0.00058 D:-0 output = -0.498583 P:-0 I:-0.00067 D:-0 output = -0.49925 P:-0 I:-0.00067 D:-0 output = -0.49925 P:-0 I:-0.0005 D:-0 output = -0.49975 P:-0 I:-0.0005 D:-0 output = -0.49975 P:-0 I:-0.00067 D:-0 output = -0.5 -- Saturation, every thing is fine P:-0 I:-0.00067 D:-0 output = -0.5 P:-8.32639e-05 I:-0.0005D:-0 output = -0.5 P:-8.32639e-05 I:-0.0005 D:-0 output = -0.5 P:-0.000116517 I:-0.00058 D:-0 output = -0.5 I don't know where the P-part comes from P:-0.000116517 I:-0.00058 D:-0 output = -0.5 P:-0.000139774 I:-0.00058 D:-0 output = -0.5 P:-0.000139774 I:-0.00058 D:-0 output = -0.5 P:-0.000144413 I:-0.00058 D:-0 output = -0.5 P:-0.000144413 I:-0.00058 D:-0 output = -0.5 P:-0.000145338 I:-0.00058 D:-0 output = -0.5 P:-0.000145338 I:-0.00058 D:-0 output = -0.5 P:-0.000145522
Re: [Flightgear-devel] ..we're not re-inventing pcproxy?, was
On Sun, 16 Oct 2005 19:11:51 +0200 (IST), Vassilii wrote in message [EMAIL PROTECTED]: I wonder if the flightgear server though should support the fsd protocol at some future point of time to be a gateway between our and VATSIM/IVAO flying... It's not a matter if it _should_ or not. The relevant details of the protocol, at least as used by VASTIM, are 'closed', Security by obscurity, as far as I am reading the forums... stupid. Apparently the pcproxy is in Debian (which made me believe we can interface the protocol, too) because it just forwards the packets w/o examining their contents too much. Hopefully one day we'll provide an open source alternative to that. ..one way is simply set up a pcproxy box to interface between our stuff and the VATSIM/IVAO guys. Or, between our stuff and http://www.wbfree.net/index.php ;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: contacting tower
Another point is that I am not always able to contact the tower when pressing the ' key, even though I am on the correct radiofrequency. Since this appears to be a bug I'll continue this discussion on the developer list.(I assume I shouldn't post this message on both lists?) Further investigation into the tower communication problem shows that several of my key presses are available only once. I may lower the flaps to one notch once, and raise them again once. v cycles the view multiple times, but shift+v only cycles the view backwards once. I may only contact the tower once with the ' key, h cycles the HUD, but shift + h only works once. This is present both in a two weeks old CVS checkout, and in one from yesterday. The problem only seems to affect keyboard commands, this is the commands that are mapped to the joystick like flaps and view cycling work well multiple times in both directions. My system is a Windows XP box with service Pack 2, compiled using MSYS. Please let me know if additional information is required. -- -- Frank Olaf Sem-Jacobsen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer ports
Jim Campbell wrote: Anyone transmitting un-encrypted data across a world wide internet 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. [...] This really isn't much of an issue. The attack you posit is requires a man in the middle, and this is a very rare failure mode -- it essentially requires a compromised router somewhere between the client and server. It's very much not a script kiddy kind of attack; the announcement you mention requires elaborate preparation and a special case vulnerability to detect. 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! No one is going to care about DoSing a single FlightGear multiplayer client or server. There's no payoff there for the attacker. The scarier doomsday scenario would be a bug in the MP code (on either side) allowing an attacker to compromise the affected machines. But this is a problem for almost all network software, and can be productively treated by careful coding. There's a *lot* of unencrypted UDP software out there. If you *really* want to avoid having unencrypted packets going over the public internet, you can always do it over an encrypted tunnel (IPsec, VPN, ppp-over-ssh, etc...) without changing the current code at all. Andy ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Gerlich schrieb: I'm not sure how important giving back to Robin's DB is for the FlightGear community but in the OpenSource manner I'd say we should try to find a way of not doing things twice in two communities. We should try to scratch only our own itch. Robin's DB is a great start, but when it limits us it's not good enough anymore. BUT, of course, Robin should be able to use our data as well, when he likes to. So we could offer an DB enhancement and Robin can follow if he wants to. Polylines should be sufficient (as long as you don't need things like bridges, i.e. stay 2D). To find out if you are outside (e.g. on grass) you do a line walk. I.e. you start on the outside (e.g. from far far away) and walk on a line to the desired position. On that walk you cound how often you've crossed a polyline. Each time you cross it you change from outside to inside (or the other way round). You are probably talking about planar partitioning, where different faces are defined by separating lines. (The only links I can find in a quick google search on topological maps, planar maps or DCEL (doubly connected edge lists) are from the CGAL-manual or non-introductory papers) [SNIP] Doesn't TaxiDraw already use CGAL? With CGAL you've got all that you need for that. TaxiDraw doesn't use CGAL currently. Sorry, I mixed the CGAL useage up with the FlightGear scenery designer. But that doesn't change the perfect fit of a constrained delauney triangulation for this case... CU, Chrisitan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDUrCalhWtxOxWNFcRArU9AKC1Suw2+bCDm66pfbiecGmH0kph5wCfV4hl O9GFJRhGjS9/2XlxzpUvoMc= =xeZk -END PGP SIGNATURE- ___ 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
Christian Mayer wrote: Ralf Gerlich schrieb: I'm not sure how important giving back to Robin's DB is for the FlightGear community but in the OpenSource manner I'd say we should try to find a way of not doing things twice in two communities. We should try to scratch only our own itch. Robin's DB is a great start, but when it limits us it's not good enough anymore. BUT, of course, Robin should be able to use our data as well, when he likes to. [...] I think both of you forgot one point: If you browse Robin's changelog then you'll notice that most of the submitters names are unrelated to FlightGear. To me this means: If we cut the relation to Robin's airport database we'll loose the majority of his airport and taxiway updates ! We don't want this, do we ? So: However somebody is going to design a new airports description format we always should have a method to merge Robin's updates. Additionally we need someone who tracks these updates on a regular basis because we don't want to loose a nifty feature that some X-Plane user adds to Robin's database. Cheers, 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] ..we're not re-inventing pcproxy?, was
you might try http://sourceforge.net/projects/openatc It died a quiet death when no one showed up for the network field test JW Vassilii Khachaturov wrote I wonder if the flightgear server though should support the fsd protocol at some future point of time to be a gateway between our and VATSIM/IVAO flying... It's not a matter if it _should_ or not. The relevant details of the protocol, at least as used by VASTIM, are 'closed', Security by obscurity, as far as I am reading the forums... stupid. Apparently the pcproxy is in Debian (which made me believe we can interface the protocol, too) because it just forwards the packets w/o examining their contents too much. Hopefully one day we'll provide an open source alternative to that. V. ___ 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] ..we're not re-inventing pcproxy?, was
Vassilii Khachaturov wrote: I wonder if the flightgear server though should support the fsd protocol at some future point of time to be a gateway between our and VATSIM/IVAO flying... It's not a matter if it _should_ or not. The relevant details of the protocol, at least as used by VASTIM, are 'closed', Security by obscurity, as far as I am reading the forums... stupid. Indeed, and I find it very annoying. Instead of developing our own ATC network strategies if would be terribly nice if we could simply jump on that train - without violating copyrights, NDA's or whatever Hopefully one day we'll provide an open source alternative to that. Yes, but we should take into account that it takes a while until we have such a network infrastructure that offers ATC service at almost every medium large airport areound the clock ;-) Cheers, 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] ..we're not re-inventing pcproxy?, was
Martin Spott wrote: Vassilii Khachaturov wrote: I wonder if the flightgear server though should support the fsd protocol at some future point of time to be a gateway between our and VATSIM/IVAO flying... It's not a matter if it _should_ or not. The relevant details of the protocol, at least as used by VASTIM, are 'closed', Security by obscurity, as far as I am reading the forums... stupid. Indeed, and I find it very annoying. Instead of developing our own ATC network strategies if would be terribly nice if we could simply jump on that train - without violating copyrights, NDA's or whatever Hopefully one day we'll provide an open source alternative to that. Yes, but we should take into account that it takes a while until we have such a network infrastructure that offers ATC service at almost every medium large airport areound the clock ;-) Cheers, Martin. But if it could be combined with Dave Culp's AI controller then you might have, at least, a 'silicon-based' based controller available on demand and plug-in when the 'carbon-based' controller was not available. Throw in some tts and speech recognition... Not a trivial task or something you build over a weekend. Probably a job bigger and more complex that eclipses all of effort put forth on Flightgear to date. Any volunteers???:-) Regards John W. ___ 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
On October 15, 2005 08:51 pm, David Luff wrote: I know there was some talk of extracting taxiways from the FAA's PDFs, I can't realistically see that happening! That was a proposal from me. The idea is to have a program (could be a modified version of KPDF) to read a vector based PDF file such as this: http://204.108.4.16/d-tpp/0510/00375AD.PDF and spit out the taxiway outlines. Ampere ___ 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
On October 16, 2005 03:43 am, Harald JOHNSEN wrote: 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. You mean, ac3d or blender ? No need to use a special editor if you want to draw polygons. 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. I don't want to do pixel or vertex editing, If I must do that then I use ac3d and I can do everything without any constraint. There is a tool for another sim that uses points, lines and splines to define the taxiways. I agree with the accessment that using raw polygons is about the only way to have proper taxiways. Really, a taxiway is anything but rectangular, and no matter how you mix and match a bunch of rectangles, it is simply impossible to achieve the level of complexity that you can see in real life. A CAD type application for drawing taxiways may not be a bad idea. However, I think that the process of taxiway generation should have nearly zero human involvement instead. Ampere ___ 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
Regarding Robin's DB: having accurate taxiways is not the only concern. Some other items that we should take notice of include: - buildings placement - gates' position - tower/ILS frequencies - runway/taxiway signs - airport animations - runway/taxiway conditions due to weather - ground pathways for AI traffics Time might as well be spent on thinking of how we are going to convince Robin to use our new format instead of thinking of a way to expand Robin's database. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
