[Flightgear-devel] fix for broken socket code in FreeBSD
Hi all.
Please commit the diff below to SimGear.
Sometime in October 2010 SimGear had its PLIB net dependency removed. As a
result, socket code on FreeBSD (and possibly other *BSD) was broken. This
was manifest as silent failure to make outgoing connections -- no error
messages were logged (--log-level=debug).
-ivan
diff --git a/simgear/io/raw_socket.hxx b/simgear/io/raw_socket.hxx
index f68ff10..4eb3044 100644
--- a/simgear/io/raw_socket.hxx
+++ b/simgear/io/raw_socket.hxx
@@ -25,7 +25,7 @@
#include errno.h
-#if defined(__APPLE__)
+#if defined(__APPLE__) || defined(__FreeBSD__)
# include netinet/in.h
#endif
@@ -38,7 +38,7 @@ namespace simgear
class IPAddress
{
/* DANGER!!! This MUST match 'struct sockaddr_in' exactly! */
-#ifdef __APPLE__
+#if defined(__APPLE__) || defined(__FreeBSD__)
__uint8_t sin_len;
__uint8_t sin_family;
in_port_t sin_port;
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] terrasync.cxx diff for FreeBSD
Hi all, I have just finished building the releases/2.2.0 branch on
FreeBSD-8.1.
Please apply this diff for a successful build :-)
diff --git a/utils/TerraSync/terrasync.cxx b/utils/TerraSync/terrasync.cxx
index f1a2cc4..d15078d 100644
--- a/utils/TerraSync/terrasync.cxx
+++ b/utils/TerraSync/terrasync.cxx
@@ -290,7 +290,7 @@ void sync_tree(const char* dir) {
#if defined(_MSC_VER) || defined(__MINGW32__)
typedef void (__cdecl * sighandler_t)(int);
-#elif defined( __APPLE__ )
+#elif defined( __APPLE__ ) || defined (__FreeBSD__)
typedef sig_t sighandler_t;
#endif
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] segfault in today's GIT
On 4 February 2011 19:07, Martin Spott martin.sp...@mgras.net wrote: Martin Spott wrote: The file $FG_ROOT/ATC/default.transmissions is missing from the Base Package - and 'touch'ing an empty file just leads to FG eating all memory. Get it from here: http://mapserver.flightgear.org/git/gitweb.pl?p=fgdata;a=blob_plain;f=ATC/default.transmissions;hb=f8c697ef4274fef4fd821d3b9316bbda1030a05f nup, this link doesn't work. And I can't find $FG_ROOT/ATC/default.transmissions in any of the trees on mapserver GIT. -ivan -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] segfault in today's GIT
On 4 February 2011 21:49, Martin Spott martin.sp...@mgras.net wrote: Martin Spott wrote: The file $FG_ROOT/ATC/default.transmissions is missing from the Base Package - and 'touch'ing an empty file just leads to FG eating all memory. Get it from here: http://mapserver.flightgear.org/git/gitweb.pl?p=fgdata;a=blob_plain;f=ATC/default.transmissions;hb=f8c697ef4274fef4fd821d3b9316bbda1030a05f As an intermediate solution I've just reverted the respective file removal until someone provides a proper fix. And the segfault remains, same location, after restoring this file. Perhaps there are other files removed? -ivan -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] segfault in today's GIT
On 4 February 2011 22:44, Martin Spott martin.sp...@mgras.net wrote:
and maybe restore individual files from here - or configure
with --disable-atcdcl, which, as far as I remember, has recently been
re-enabled by default.
Yes I vaguely remember that too. Unfortunately,
configure:18083: WARNING: Unrecognized options: --disable-atcdcl
Further experiment:
Running fgfs --fg-root=/path/to/old/FGROOT the sim actually makes it further
enough to show the cockpit and scenery, then segfaults after about 2 to 3
seconds of runtime, at the exact same spot
0x080e91e9 in FGATCMgr::update (this=0x53791970, dt=0.03)
at ATCmgr.cxx:119
Note that with the GIT FGROOT the sim doesn't even make it to the cockpit
scenery stage of startup.
This suggests that the problem is more than that of missing files...?
-ivan
--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] segfault in today's GIT
Today's SG, FG and fgdata. FreeBSD-8.0. 0x080e91e9 in FGATCMgr::update (this=0x537fbf60, dt=0.0083332) at ATCmgr.cxx:119 119 (*atc_list_itr).second-Update(dt * atc_list-size()); (gdb) bt #0 0x080e91e9 in FGATCMgr::update (this=0x537fbf60, dt=0.0083332) at ATCmgr.cxx:119 #1 0x0806f0a8 in fgMainLoop () at main.cxx:147 #2 0x080d31bc in fgOSMainLoop () at fg_os_osgviewer.cxx:284 #3 0x0806c715 in fgMainInit (argc=2, argv=0xbfbfe9dc) at main.cxx:632 #4 0x0806b90f in main (argc=2, argv=0xbfbfe9dc) at bootstrap.cxx:243 .fgfsrc: --aircraft=ufo --disable-sound --disable-real-weather-fetch --prop:/sim/atc/enabled=0 --prop:/sim/ai-traffic/enabled=0 -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] EGPWS issues (mk-viii module)
The radio alt antennas point vertically downward. Just as pitch angle affects the displayed RA, so does bank angle. This effect increases with bank/pitch angle --- you can work out the trigonometry easily. RA is calibrated to read 0 at main gear touchdown (nose up pitch angle perhaps 5 to 8 degrees). When nose gear touches down, the RA would read some -6 feet. With a heavily loaded jet (greater gear strut compression), the RA reads -8 feet. On 15/07/2010, Thorsten bre...@googlemail.com wrote: On Sun, Jul 11, 2010 at 7:45 PM, Victhor wrote: Em Dom, 2010-07-11 Ã s 18:33 +0200, Thorsten escreveu: Hi, I've been working on some smaller issues with the Ground Proximity Warning System. Is someone currently maintaining or actively working on the mk-viii module, or is any help wanted? * The Bank angle! warning wasn't working. It's because the module reads the planes angle from /instrumentation/attitude-indicator/indicated-roll-deg However, with the planes I have tested (B737, B747, B777, A380) this value is never updated (value is constant at 40 degrees). This sometimes triggers an incorrect Bank angle! warning (at lower heights, where 40 degrees is outside the allowed range). Changing the input property to /orientation/roll-deg made the feature work for me. I'm not familiar with this attitude indicator. Is anything broken so the property above isn't updated? Or could we just change the module's input property? Alternatively, a configuration property could be added, so the location of the input property isn't hard-wired in the sources and could be configured for every plane... This instrument needs vacuum to work, as in piston powered GA aircraft and some others. /systems/vacuum/suction-inhg is what you're looking for. A vacuum pump RPM source can be defined in case you want the pump to be powered by something other than /engines/engine/rpm, however I don't know where to find this. IIRC the Citation X uses this, it's no nasal. Ok, I'll also give this a try. But I could still try to make this input source configurable. Those who like modelling all the details can then select the output of this vaccuum driven device. But to me it seems not every plane developer goes to this detail. And in this case they could still get this module to work properly by using the input from /orientation/roll-deg, e.g. as the module's default input source, since it always seems to provide valid data. And the module is already reading other data from such general sources (e.g. altitude from /position/... see below). Does an option to configure the input source make any sense? I'm new to FlightGear though... A properly calibrated radio altimeter indicates zero feet at the moment the aircraft contacts ground. This requires taking into account the height of the antennas above ground (at touchdown) [...] After touchdown, the weight of the aircraft may cause the radio altimeter to read slightly below ground level. So I guess the radio altimeter isn't perfectly accurate right now - or are there already configuration settings to tune/adapt the altimeter to a specific plane? Maybe that's where the problem is... The radio-altimeter instrument never worked properly with me, it has considerable lag. Radar altimeter instruments in FG are instead driven by /position/altitude-agl-ft, which updates in real time. You're right, the mk-viii module is directly reading /position/altitude-agl-ft. I have changed this to /position/gear-agl-ft - and it certainly is the gear that matters on touchdown... When using this property the altitude callouts seem really precise to me - including the 10ft callout moments before touchdown. Anyone knows details on gear-agl-ft? Could we just change the mk-viii's input source to this property, or are there objections / reasons why altitude-agl-ft still is a better source? And maybe the HUD could also use gear-agl-ft as its source - instead of showing 15ft agl when taxiing...? I'll be working bit on some of the EGPWS issues and then also try to update the wiki page with some more information. For example there are already configuration options in the module to disable specific warnings in case they don't apply to a specific type of plane... Thorsten -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
Re: [Flightgear-devel] Using Nasal to create a protocol
Hi Brian. What I want to do is have Atlas monitor the state of all AI aircraft. The number of AI aircraft varies, so that's why I didn't think the generic protocol would work - the generic protocol only allows you to specify a fixed number of properties to transmit. So, would it be possible to use Nasal to package all the data (into a string say), plop it into a property node, and then use the generic protocol to send that node? Is there an even better way? An alternate way is to purely use the --telnet protocol for bidirectional communication. This means you have to poll FG to find out how many AI aircraft there are, what their positions are etc. There is no 'listener' interface with the telnet protocol. Using nasal to take advantage of the 'listener' interface and crafting your own intelligent IPC property node is my preferred route. -ivan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Using Nasal to create a protocol
On 15/04/2010, Brian Schack bschack-flightg...@usa.net wrote: Ron == Ron Jensen writes: Thanks for the reply. Unfortunately I need a general solution, one that works on Windows as well. Just to confirm: Nasal at the moment offers no interprocess communications abilities? Getting back to the --generic protocol, you could manipulate the contents of a property node using Nasal and make FG dump the contents of that property via a TCP or UDP port. The reverse direction can be managed using the --telnet protocol. -ivan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
