Re: [Flightgear-devel] Multiple IO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 It should also be possible to use some daemon talking to FlightGear using TCP or UDP and then get that daemon to talk to the USB device. On Linux try using libusb, I assume something similar exists for Windows. Regards, Arvid Curtis Olson wrote: | On Tue, Aug 5, 2008 at 8:17 AM, Nurten Rende wrote: | | I am new to Flight Gear. I would like to connect more than one device to | Flight Gear and run it in almost a real time environment under Windows XP (I | am a hobbyist trying to make my own toy plane). Does Flight Gear support | simultaneous multi serial Input Output ports and USB connections? If not how | do I do that? What parameters do I need to pass to FlightGear or where about | do I need to modify the code to enable flight gear to do so? I will | appreciate a reply for a direction or a hint. | | | Hi Nurten, | | FlightGear definitely supports multiple concurrent IO connections. There is | a slightly complex, but pretty flexible mechanism for specifying an IO | channel, what type of communcation will get sent over it, which direction, | and at what rate. Look for a file called README.io that briefly explains | much of this. In addition, there is a generic protocol where you can | create an xml file specifying exactly what data values you wish to send | across your IO channel. We don't have generic USB support, but if you | have a Serial - USB device that looks like a com port on the computer side, | then that should work without any problem ... just be careful which com port | your usb device gets assigned to. | | Regards, | | Curt. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEAREKAAYFAkiZYXsACgkQWmK6ng/aMNnyZwCgx59Frzn7Pkn30bCbTUAVKmMr /FYAni35NigR6tnjEcfmaW4p1KNPvi+l =yXS9 -END PGP SIGNATURE- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] HEADS UP: Scenery regeneration
Hello again! It seems that I finally have a somewhat dependable workaround for the TerraGear coastline bug reported shortly after the release of the 1.0.0 scenery. I have reviewed the algorithm thoroughly - together with Martin - and checked some of the tiles reported as faulty beginning of this year and they seem to be generated correctly now. Martin and I plan to start a new generation job on the weekend of the 16th/17th of August. We would like to include the current state of the static scenery database with this release. In case anybody has any objects intended for submission but not yet submitted, this is the time to submit them to the database, if you want to have your contributions included in the new scenery. As this scenery is to replace the faulty scenery which was released together with FlightGear v1.0.0, we will have to use the airport database included with that release for consistency reasons. Updates as found in the apt.dat in CVS will therefore unfortunately not be included. (As a sidenote: This is one reason why the apt.dat or at least the parts thereof used for airport generation as well as the AI ground networks should reside with the scenery, not with the base package...) We intend to tag the generated scenery unstable for obvious reasons before making it an official release. While it seems to me that the workaround should work, due to previous experience with TerraGear and its subtleties I would not want to bet on it. As it seems, some mirror providers may not be able to carry the load of two scenery releases - the official one and the unstable version -, so we will not publish the alpha release via the normal distribution channels, where mirrors normally pick it up. Possibly, we will publish a location were interested mirror providers can also pick up the unstable version, and we would appreciate any support from mirror providers in that direction. I am not that much thrilled about the kind of solution I found as it doesn't solve the actual problem but rather enhances a perfectly working part of the code with some special cases. The actual problem lies within TriangleJRS, the triangulation code of TerraGear, which - as several checks have shown - is not as robust as advertised regarding computational geometry predicates. The point-in-triangle-detection-code does seem to have problems if the respective point is pretty near to the contour of the triangle. While the point is perfectly inside the triangle, TriangleJRS cannot detect that. The points are used to mark polygons and their associated triangles with associated attributes, including texture. As TriangleJRS does associate some of the points with adjacent triangles, texture attributes spill out into adjacent polygon areas. This is most noticeable in places where sea/ocean area is transferred into land this way. Fixing TriangleJRS was not possible for me as I am clearly not a computational geometry man. I will try to contact Jonathan R. Shewchuk on this issue, after some further analysis. The triangle package should be based on arbitrary precision predicates, as far as the documentation goes, but maybe I misunderstood what is meant by this ... or the predicates don't actually deliver to this promise. I have modified the algorithm to ensure that the selected points are at least a given distance away from the contours. Unfortunately, the new algorithm is less robust than the old one and might outright deny working on some specific valid, but degenerate polygons. Further, the distance used had to be selected arbitrarily according to the results of the scenery generation, but should be a safe estimate. The new algorithm has the advantage that instead of silently delivering points inside the polygon which TriangleJRS cannot handle, it will either deliver a good point or fail completely, resulting in an abnormal exit of the building process for the respective tile. I would appreciate if anybody wants to review my changes. The current version is available via git from http://mapserver.flightgear.org/git/terragear-cs/ Look into src/Lib/Geometry/poly_support.cxx, function calc_point_inside() (around line 447). Cheers, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] ATC Frequencies dialog broken.
Melchior changed the dialog options: use enabledfalse/enabled flag
for widgets that shouldn't be drawn instead of hidetrue/hide. This
is consistent with other places in fgfs, like menu entries, hud
elements, subsystem switches, etc.
see
http://cvs.flightgear.org/viewvc/source/src/GUI/layout.cxx?view=log
However, src/ATCDCL/ATCDialog.cxx uses these options and he missed
changing those... The attached patch
Changes ATCDialog.cxx to use use enabledfalse/enabled flag for
widgets that shouldn't be drawn instead of hidetrue/hide.
Please commit...
Thanks,
Ron
Index: ATCDialog.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/ATCDCL/ATCDialog.cxx,v
retrieving revision 1.3
diff -u -r1.3 ATCDialog.cxx
--- ATCDialog.cxx 31 Jul 2008 12:04:33 - 1.3
+++ ATCDialog.cxx 6 Aug 2008 14:45:36 -
@@ -239,7 +239,7 @@
// add transmission button (modified copy of button-template)
SGPropertyNode *entry = button_group-getNode(button, n, true);
copyProperties(button_group-getNode(button-template, true), entry);
- entry-removeChildren(hide, false);
+ entry-removeChildren(enabled, true);
entry-setStringValue(property, buf);
entry-setIntValue(keynum, '1' + n);
if (n == 0)
@@ -341,7 +341,7 @@
for (int n = 0; uit != uniq.end() n 6; ++uit, ++n) { // max 6 buttons
SGPropertyNode *entry = button_group-getNode(button, n, true);
copyProperties(button_group-getNode(button-template, true), entry);
- entry-removeChildren(hide, false);
+ entry-removeChildren(enabled, true);
entry-setStringValue(legend, uit-first.id.c_str());
entry-setStringValue(binding[0]/value, uit-first.id.c_str());
}
@@ -349,7 +349,7 @@
// (un)hide message saying no things in range
SGPropertyNode_ptr range_error = getNamedNode(dlg, no-atc-in-range);
- range_error-setBoolValue(hide, num_stat);
+ range_error-setBoolValue(enabled, !num_stat);
_gui-showDialog(dialog_name);
}
@@ -397,7 +397,7 @@
// add frequency line (modified copy of group-template)
SGPropertyNode *entry = freq_group-getNode(group, n, true);
copyProperties(freq_group-getNode(group-template, true), entry);
- entry-removeChildren(hide, false);
+ entry-removeChildren(enabled, true);
ostr itr-type;
entry-setStringValue(text[0]/label, ostr.str().c_str());
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] ATC Frequencies dialog broken.
* Ron Jensen -- Wednesday 06 August 2008: However, src/ATCDCL/ATCDialog.cxx uses these options and he missed changing those... The attached patch Whoops, indeed. Thanks, will commit ... m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
