[Flightgear-devel] Re: [Flightgear-users] DATCOM error

2005-02-12 Thread Erik Hofman
Bill Galbraith wrote:
I've been working on a DATCOM+ model for the A380, and discovered one of 
those pain in the butt errors, that caused MAJOR problems all due to one 
bad letter. I don't have a DATCOM user's group estabilshed, but I know a 
number of people on this list are using my DATCOM stuff, and thought 
this notice might help someone that would have been running into the 
same problem that I was having, but might be too embarassed to ask. 
Maybe this is the right time to remind every one there is a 
flightgear-flightmodel mailinglist that can be used to discuss 
everything related to the flightmodel, ranging from FDM design (like 
JSBSim and YASim) to model configuration files (like DATCOM):

http://mail.flightgear.org/mailman/listinfo/flightgear-flightmodel
If you have any interest in this subject it would be best to subscribe 
to that list (also).

Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Mac joysticks + Mac OS X build errors

2005-02-12 Thread ima . sudonim
Erik
Thank you VERY much!
The simgear change gets me further along  but still breaks as None and 
True are not defined.
g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. 
-DGLX_GLXEXT_PROTOTYPES  
-I/Users/ima/Desktop/FlightGear/fgdev9.8/include  -g -O2 -D_REENTRANT 
-c -o extensions.o `test -f 'extensions.cxx' || echo 
'./'`extensions.cxx
source='RenderTexture.cpp' object='RenderTexture.o' libtool=no \
depfile='.deps/RenderTexture.Po' tmpdepfile='.deps/RenderTexture.TPo' \
depmode=gcc3 /bin/sh ../../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. 
-DGLX_GLXEXT_PROTOTYPES  
-I/Users/ima/Desktop/FlightGear/fgdev9.8/include  -g -O2 -D_REENTRANT 
-c -o RenderTexture.o `test -f 'RenderTexture.cpp' || echo 
'./'`RenderTexture.cpp
RenderTexture.cpp: In constructor `RenderTexture::RenderTexture(const 
char*)':
RenderTexture.cpp:163: error: `None' undeclared (first use this 
function)
RenderTexture.cpp:163: error: (Each undeclared identifier is reported 
only once
   for each function it appears in.)
RenderTexture.cpp: In member function `bool 
RenderTexture::_Invalidate()':
RenderTexture.cpp:582: warning: invalid conversion from `unsigned 
int*' to `
   const GLuint*'
RenderTexture.cpp:588: warning: invalid conversion from `unsigned 
int*' to `
   const GLuint*'
RenderTexture.cpp: In member function `bool RenderTexture::Resize(int, 
int)':
RenderTexture.cpp:729: warning: invalid conversion from `unsigned 
int*' to `
   const GLuint*'
RenderTexture.cpp:731: warning: invalid conversion from `unsigned 
int*' to `
   const GLuint*'
RenderTexture.cpp: In member function `void
   RenderTexture::_ParseModeString(const char*, std::vectorint,
   std::allocatorint , std::vectorint, std::allocatorint )':
RenderTexture.cpp:1274: error: `True' undeclared (first use this 
function)
RenderTexture.cpp: In member function `bool
   RenderTexture::_InitializeTextures()':
RenderTexture.cpp:1825: warning: invalid conversion from `unsigned 
int*' to `
   GLuint*'
RenderTexture.cpp:1936: warning: invalid conversion from `unsigned 
int*' to `
   GLuint*'
make[2]: *** [RenderTexture.o] Error 1
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1
makesg done
I added the following to the top of RenderTexture.cpp:
#ifdef __APPLE__
#  ifndef None
# define None false
#  endif
#  ifndef True
# define True true
#  endif
#endif
Maybe the above should go elsewhere such as compiler.h?  It gets me 
past the build errors.
My above changes throw off the line numbers, but then I get the 
following warnings:

g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. 
-DGLX_GLXEXT_PROTOTYPES  
-I/Users/ima/Desktop/FlightGear/fgdev9.8/include  -g -O2 -D_REENTRANT 
-c -o RenderTexture.o `test -f 'RenderTexture.cpp' || echo 
'./'`RenderTexture.cpp
RenderTexture.cpp: In member function `bool 
RenderTexture::_Invalidate()':
RenderTexture.cpp:591: warning: invalid conversion from `unsigned int*' 
to `
   const GLuint*'

Removed by:
glDeleteTextures(1,  (const GLuint*) _iTextureID);
RenderTexture.cpp:597: warning: invalid conversion from `unsigned int*' 
to `
   const GLuint*'

Removed by:
glDeleteTextures(1, (const GLuint*) _iDepthTextureID);
RenderTexture.cpp: In member function `bool RenderTexture::Resize(int, 
int)':
RenderTexture.cpp:738: warning: invalid conversion from `unsigned int*' 
to `
   const GLuint*'

Removed by:
glDeleteTextures(1, (const GLuint*) _iTextureID);
RenderTexture.cpp:740: warning: invalid conversion from `unsigned int*' 
to `
   const GLuint*'

Removed by:
glDeleteTextures(1, (const GLuint*) _iDepthTextureID);
RenderTexture.cpp: In member function `bool
   RenderTexture::_InitializeTextures()':
RenderTexture.cpp:1834: warning: invalid conversion from `unsigned 
int*' to `
   GLuint*'

Removed by:
glGenTextures(1, (GLuint*) _iTextureID);
RenderTexture.cpp:1945: warning: invalid conversion from `unsigned 
int*' to `
   GLuint*'

Removed by:
glGenTextures(1, (GLuint*) _iDepthTextureID);
The above changes allow me to build RenderTexture.cpp with no errors or 
warnings.

I should have considered that normalmap.cxx required that one piece of 
simgear that I couldn't build. 8-( Sorry for complaining about a 
non-problem...

Thanks for the js correction and information also!
I'll now work on building fg...
Thanks again!
Ima
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Mac joysticks + Mac OS X build errors

2005-02-12 Thread Erik Hofman
[EMAIL PROTECTED] wrote:
Erik
Thank you VERY much!
The simgear change gets me further along  but still breaks as None and 
True are not defined.
snip fixes
The above changes allow me to build RenderTexture.cpp with no errors or 
warnings.
These changes have been committed now.
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Mac joysticks + Mac OS X build errors

2005-02-12 Thread ima . sudonim

Erik,
Thanks! FG builds on mac os X.3 with no problems now...
Ima
Ima  wrote:
 Erik

 Thank you VERY much!

 The simgear change gets me further along  but still breaks as None 
and
 True are not defined.

snip fixes
 The above changes allow me to build RenderTexture.cpp with no errors 
or
 warnings.

These changes have been committed now.
Erik

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Atlas release candidate

2005-02-12 Thread Hans-Georg Wunder
Hello David,
I just compiled the new Atlas-version on my Linux-Box (Debian 3.1) and 
it works great. I have had no compile-problems and the maps are looking 
 very nice. With the new version I am able to visit foreign airports 
without additionnel enroute and approach charts. Great.

One question I have: With the left key,I am able to move around on
the map. But then I destroy the flight track. Is it a bug or just a 
missing feature ?

The only thing I am missing is the multiplayer capability. Last week I 
flew with my daughter, each on a Linux box. But it was very difficult to 
fly together. Then I wanted to use atlas to have an overview, where we 
are. But that doesn't work. I would be great to have to ports where 
atlas is listening.

Kind regards
Hans-Georg

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Nav0/Nav1 course tracking and ILS approach

2005-02-12 Thread Hans-Georg Wunder

Hi all,
for the A320-200 2D-panel I tried to activate the course tracking with 
nav1. But it doesn't work. Then I checked the source and I found the 
following in src/Autopilot/xmlauto.cxx

874 // Calculate nav1 target heading error normalized to +/- 180.0
875 static SGPropertyNode *target_nav1
876 = fgGetNode( 
/instrumentation/nav[0]/radials/target-auto-hdg-deg, true );

When I replaced it with
876 = fgGetNode( 
/instrumentation/nav[1]/radials/target-auto-hdg-deg, true );

everything works:
Then I added the same sequence for nav0
874 // Calculate nav0 target heading error normalized to +/- 180.0
875 static SGPropertyNode *target_nav0
876 = fgGetNode( 
/instrumentation/nav[0]/radials/target-auto-hdg-deg, true );
877 static SGPropertyNode *true_nav0
878 = fgGetNode( /autopilot/internal/nav0-heading-error-deg, 
true );
879 static SGPropertyNode *true_track_nav0
880 = fgGetNode( /autopilot/internal/nav0-track-error-deg, true );
881 diff = target_nav0-getDoubleValue() - true_hdg-getDoubleValue();
882 if ( diff  -180.0 ) { diff += 360.0; }
883 if ( diff  180.0 ) { diff -= 360.0; }
884 true_nav0-setDoubleValue( diff );
885
886
887 diff = target_nav0-getDoubleValue() - true_track-getDoubleValue();
888 if ( diff  -180.0 ) { diff += 360.0; }
889 if ( diff  180.0 ) { diff -= 360.0; }
890 true_track_nav0-setDoubleValue( diff );

My Contoller looks like this:
  pid-controller
nameNav0 Hold Stage 1/name
debugfalse/debug
enable
  prop/autopilot/locks/heading/prop
  valuenav0-hold/value
/enable
input
  prop/autopilot/internal/nav0-track-error-deg/prop
/input
reference
  value0.0/value
/reference
output
  prop/autopilot/internal/target-roll-deg/prop
/output
config
  Kp-1.0/Kp!-- proportional gain --
  beta1.0/beta !-- input value weighing factor --
  alpha0.1/alpha   !-- low pass filter weighing factor --
  gamma0.0/gamma   !-- input value weighing factor for --
   !-- unfiltered derivative error --
  Ti200.0/Ti   !-- integrator time --
  Td0.1/Td !-- derivator time --
  u_min-30.0/u_min !-- minimum output clamp --
  u_max30.0/u_max  !-- maximum output clamp --
/config
  /pid-controller
Now I am able to follow the ILS. Is this a bug in flightgear, or do I 
have the wrong understanding and do I use the wrong properties 

If it is a bug, it would be great, if someone is able to add the 
corrections  to the cvs. I can send the differencies, but I do not know 
the exact diff-command.


Kind regards
Hans-Georg

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Speedbrakes / Spoilers

2005-02-12 Thread Lee Elliott
On Thursday 10 February 2005 18:19, Martin Spott wrote:
 Vivian Meazza wrote:
  James Turner wrote
 
   While we are are it, do we already have consensus on
   which keys to use for these functions - are the keys
   consistent across different aircraft and FDM's ?
 
  The keys do seem to be standard, j/k for spoilers and
  Ctrl-B for speedbrake, the issue of course is guessing for
  a given model which surfaces are assigned to which name. I
  guess 'things on the wings' are spoilers, and 'things not
  on the wings' are speed-brakes?
 
  Not necessarily. The Seahawk's speedbrakes (aka airbrakes in
  UK) are in the upper wing, and work in conjunction with the
  flaps - and yes they are both animated and functional. The
  Hunter's (under the rear fuselage) is interlocked with the
  gear.
 
  Just to clarify things. Spoilers dump lift, and may provide
  a bit of braking. Speedbrakes dump speed, and may provide a
  bit of lift positive or negative (although designers try to
  avoid this).

 Great, now we have an accurate definition, we should fix the
 key bindings  :-)
 Does everyone agree on having j/k for the spoilers ? Now, what
 are we going to take for the speed brakes ? Simply using
 Ctrl-B is not sufficient, because speed brakes are supposed to
 offer multiple settings - do we already use i/o for anything ?
 If not, then we could take these keys for the speed brakes.

 Comments, please,
  Martin.

Something to note is that while YASim includes spoilers it 
doesn't cater for speed brakes, so the speed brakes on the TSR-2 
are therefore a bit of a hack.

Interestingly, the speed brakes on the YF-23 could be done in 
YASim because speed braking is achieved by deflecting the flaps 
and ailerons in opposition.  However, because there's no 
speed-brake control axis in YASim I've had to control them using 
the spoiler control axis.

Confused... :)

LeeE



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d