RE: [Flightgear-devel] Starting up flightgear.

[Norman Vine]

Curtis L.Olson writes:

Norman Vine writes:
 another problem is in simgear / sky / cloud.cxx

 bool SGCloudLayer::reposition( sgVec3 p, sgVec3 up, double
lon, double lat,
 double alt )
 {
 
 // now calculate update texture coordinates
 if ( last_lon  -900 ) {
  cout  last_lon  -900  endl;
  last_lon = lon;
  last_lat = lat;
 }
 // change  if( lon - lat_lon != 0 || lat-last_lat != 0 )  to
 if ( fabs(lon-last_lon)  FLT_EPSILON || fabs(lat-last_lat) 
 FLT_EPSILON ) {
 ...
 }

Norman, can you provide any further information as to how this change
eliminates problems on the windows side?

when there is no change there is a floating point exception in
calc_gc_course_dist().  I tied this with both the original and the
optimized versions.

I understand that in general with floating point compares you want to
test if the absolute value of the difference is  some epsilon,
however, in this case I think I'm justified with my code.  The current
code is actually:

if ( lon != last_lon || lat != last_lat ) {


Ooops sorry about the code rearangment, I wrote the email from
memory and should have used cut and paste :-)

Anyway if ther is no change the direction part of the
calc_course_dist() is undefined.

Think about it
if I do not move,   what direction did I move in ?:-)))

Better yet enable FPE exception reporting

// I think this is correct for Linux

 cut 

// Add the following code to main.cxx
// and set it up as
// SetSignals(CATCH_SIGFPE_FLAG)

#define CATCH_SIGINT_FLAG  1
#define CATCH_SIGFPE_FLAG  2
#define CATCH_SIGSEGV_FLAG 4
#define CATCH_SIGILL_FLAG  8
#define CATCH_SIGBUS_FLAG  16
#define CATCH_ALL_SIGNAL_FLAGS  31

#ifdef linux
#define SAY_IT_AGAIN
/* use sysv_signal in libc6 -- signal broken for SIGINT */
#define _XOPEN_SOURCE 1
#endif

#ifdef WIN32
 #ifndef __CYGWIN__
  #include io.h
 #endif
#define NO_GETPWNAM
#define NO_SOFT_LINKS
#define SAY_IT_AGAIN
#include float.h
#endif

#include signal.h

extern void SetSignals(int flags);
extern int matherr(int *);

static void HandleSignals(int sig);
static void InitializeSignals(void);

static int sg_catch_category;

static int setSignalsCalled= 0;

InitializeSignals()
{
#ifdef linux
 __setfpucw(0x1372);
#endif

#if defined(WIN32)
#if !defined(__CYGWIN__)
  /* Need to unmask exceptions after every interrupt under Windows  */
  /* Initialize floating-point package. */
_fpreset();
  /* first argument specifies the exceptions that should remain masked */
  /* WARNING With Visual C++ 4.2 and Windows NT 4.0, the overflow
interrupt
 is not reported immediately - it shows up on the NEXT floating point
operation! */
_controlfp( _EM_DENORMAL | _EM_INEXACT | _EM_UNDERFLOW | _EM_OVERFLOW,
_MCW_EM );
#else
//  NO CYGWIN SUPPORT YET
#endif
#endif
}

void SetSignals(int flags)
{
if (!setSignalsCalled) InitializeSignals();
signal(SIGINT, flags1? HandleSignals : SIG_DFL);
signal(SIGFPE, flags2? HandleSignals : SIG_DFL);
signal(SIGSEGV, flags4? HandleSignals : SIG_DFL);
signal(SIGILL, flags8? HandleSignals : SIG_DFL);
#ifdef SIGBUS
signal(SIGBUS, flags16? HandleSignals : SIG_DFL);
#endif
}


then
static void HandleSignals(int sig)
{
signal(sig, HandleSignals);
#ifdef SAY_IT_AGAIN
InitializeSignals();
#endif
if (sig==SIGINT)
{
sg_catch_category= 0x04;
SG_LOG(SG_GENERAL, SG_ALERT,Keyboard interrupt received (SIGINT));
}
else if (sig==SIGFPE)
{
sg_catch_category= 0x01;
SG_LOG(SG_GENERAL, SG_ALERT,Floating point interrupt (SIGFPE));
#define NASTY
#ifdef NASTY
SetSignals( 0 );
exit( 0 );
#endif
}
else if (sig==SIGSEGV)
SG_LOG(SG_GENERAL, SG_ALERT,Segmentation violation interrupt 
(SIGSEGV));
else if (sig==SIGILL)
SG_LOG(SG_GENERAL, SG_ALERT,Illegal instruction interrupt (SIGILL));
#ifdef SIGBUS
else if (sig==SIGBUS)
SG_LOG(SG_GENERAL, SG_ALERT,Misaligned address interrupt (SIGBUS));
#endif
SG_LOG(SG_GENERAL, SG_ALERT,Unrecognized signal delivered to
HandleSignals);
}

=== cut ===

Cheers

Norman


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear with Opengc

[Ross Golder]

.cvspass is for remembering pserver passwords (SourceForge anonymous
access). As John needs developer access he is using the ext method,
which is designed to use rsh/ssh.

John, list the contents of one of your CVS/Root files. This will show
what repository the working directory is set up to.

--
Ross

On Sun, 2001-12-09 at 00:47, Curtis L. Olson wrote:
 CVS remembers your passwords after the first time you enter it.  Look
 for ~/.cvspass and you'll see what it does.
 
 Curt.
 
 
 John Wojnaroski writes:
   You need to check out the your copy from the SF repository as your SF
   user ID, not anonymously.  It sounds like that is what you did.
  

$ export CVS_RSH=ssh
$ cvs -z3:ext:[EMAIL PROTECTED]:/cvs/opengc/ co opengc
   
cvs server: Updating opengc
  |
Question: Is this correct? it never asked for a password!
 do your edit thing
 do your edit thing 
   
$cvs commit filename
   
make the log entry using vi
:wq
   
cvs [server aborted]: commit requires write access to the rerpository
cvs commit: saving log message in /tmp/cvs610cc229.2
   
$
***
end of story.
   
  I think I got that right (see above) user name is acastle What was a
  little odd is that it did not ask for a password?
  
  Regards
  John W.
  
  
  ___
  Flightgear-devel mailing list
  [EMAIL PROTECTED]
  http://mail.flightgear.org/mailman/listinfo/flightgear-devel
 
 -- 
 Curtis Olson   Intelligent Vehicles Lab FlightGear Project
 Twin Cities[EMAIL PROTECTED]  [EMAIL PROTECTED]
 Minnesota  http://www.menet.umn.edu/~curt   http://www.flightgear.org
 
 ___
 Flightgear-devel mailing list
 [EMAIL PROTECTED]
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear.

[Wolfram Kuss]

Christian wrote:

Wolfram: When was the last time you've tried FGFS with MSVC?

Long ago.

CU,
Christian

Bye bye,
Wolfram.

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear.

[Erik Hofman]

Curtis L. Olson wrote:

 priority, but are things an average person will immediately notice and
 ding us for) then I would be tempted to roll out the 0.7.9 release
 soon.  (I'm thinking specifically of the startup-onground sinking into
 the ground and spinning slowly bug in JSBSim and the accelerating
 backwards on the ground in YASim.)


I would add that there are a number og issues thet aren't addressed just 
yet because things move so quickly (and don't prevent me from  running 
flightgear) but which might take some time to get solved.

One thing that I have noticed is the disapearing cloud layer still 
exists, but now for larcsim ...

Erik





___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear.

[Curtis L. Olson]

Christian Mayer writes:
 I haven't tried the c172-yasim (assuming that when it doesn't work with
 JSBsim and doesn't work with LaRCsim it doesn't work at all).
 
 After I tried it it worked!! But after a few seconds (10 or so) sitting
 on the runway doing nothing it crashed (most probably the deliberate
 gear crash)

There's currently a small bug in YASim that causes planes to
accelerate backwards and quickly die.  If you immediately add power
and take off, you'll hardly notice this problem.  Hopefully Andy is
hot on the trail of a fix.

Regards,

Curt.
-- 
Curtis Olson   Intelligent Vehicles Lab FlightGear Project
Twin Cities[EMAIL PROTECTED]  [EMAIL PROTECTED]
Minnesota  http://www.menet.umn.edu/~curt   http://www.flightgear.org

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear.

[Ross Golder]

I'm planning to look into updating the autoconf stuff for OpenGC and
getting it to build on my machines here, but it probably won't be for a
few days. I'm bogged down in sendmail code for a mailserver upgrade this
week :(

--
Ross


On Sat, 2001-12-08 at 00:49, Damion Shelton wrote:
 Hi...
 
 The source tree on opengc.org currently only builds on windows. We've had
 some problems convincing John W's CVS to talk to SourceForge, which is why
 there are currently two versions of the code (kingmont and sourceforge). The
 autoconf scripts included in the SourceForge version are out-of-date with
 respect to the current source organization, as well as the updated OpenGL
 font library - this is most likely why the build failed.
 
 I just put together a Linux machine, and I will be playing with building
 OpenGC under Linux over the weekend. Incidentally, I have no experience
 using autoconf, so I will be using the CMake build system (which I currently
 use under Windows). I'll talk to John W. and see if we can hammer out a
 stable version suitable for public consumption.
 
 -Damion-
 
 - Original Message -
 From: John Check [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Friday, December 07, 2001 7:24 PM
 Subject: Re: [Flightgear-devel] Starting up flightgear.
 
  I just tried building the code from opengc.org and failed.
 
 ___
 Flightgear-devel mailing list
 [EMAIL PROTECTED]
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

RE: [Flightgear-devel] Starting up flightgear.

[Jon S. Berndt]

 So what exactly does blade element-ish mean? Is this sorta like a
 realtime digital wind tunnel sorta thing? Thanks,

Nothing of the sort. But Andy appears to have a reasonable approximation for
subsonic, anyhow.

Jon


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear.

[Andy Ross]

Christian Mayer wrote:
  But one other observation: I couldn't lift of with the YAsim C310 (172
  and 747 worked fine). I can accelerate and pull. The front lifts of
  but i'm not gaining any altitude.

Was your engine RPM stuck at 1700?  There is a version skew problem
with the c310.xml file.  The propeller advance control used to be
called propellor-pitch, but recent CVS has corrected the spelling to
propeller-pitch.  The aircraft file still maps the old property
name, which means that you'll be stuck at minimum governor RPM.  I've
attached my current file (it's small) which doesn't have the spelling
bug.

I should have a new release ready by the end of the weekend with a bunch
of fixes.

Andy

-- 
Andrew J. RossNextBus Information Systems
Senior Software Engineer  Emeryville, CA
[EMAIL PROTECTED]  http://www.nextbus.com
Men go crazy in conflagrations.  They only get better one by one.
 - Sting (misquoted)



airplane mass=3903

approach speed=70 aoa=16
  control axis=/controls/throttle[0] value=0.4/
  control axis=/controls/throttle[1] value=0.4/
  control axis=/controls/mixture[0] value=1.0/
  control axis=/controls/mixture[1] value=1.0/
  control axis=/controls/propeller-pitch[0] value=0.5/
  control axis=/controls/propeller-pitch[1] value=0.5/
  control axis=/controls/flaps value=1.0/
/approach
cruise speed=223 alt=2
  control axis=/controls/throttle[0] value=1.0/
  control axis=/controls/throttle[1] value=1.0/
  control axis=/controls/mixture[0] value=1.0/
  control axis=/controls/mixture[1] value=1.0/
  control axis=/controls/propeller-pitch[0] value=1.0/
  control axis=/controls/propeller-pitch[1] value=1.0/
  control axis=/controls/flaps value=0.0/
/cruise

cockpit x=-2.78 y=0.26 z=0.95/

fuselage ax=0.00  ay=0 az=0
  bx=-9.50 by=0 bz=0 width=0.8/

wing x=-3.65 y=0.62 z=-0.18 length =4.68 chord =1.68
  sweep=0 dihedral=5 taper=0.8 camber=0.1
  stall aoa=16 width=4 peak=1.5/
  flap0 start=0 end=.5 lift=1.5 drag=2.0/
  flap1 start=.55 end=.94 lift=1.3 drag=1.5/
  control axis=/controls/flaps output=FLAP0/
  control axis=/controls/aileron output=FLAP1 split=true/
/wing

hstab x=-8.33 y=0.22 z=0.07 length =2.34 chord =1.24
   sweep=0 dihedral=0 taper=0.6 camber=0.1
  stall aoa=16 width=4 peak=1.5/
  flap0 start=0 end=1 lift=1.5 drag=1.8/
  control axis=/controls/elevator output=FLAP0/
  control axis=/controls/elevator-trim output=FLAP0/
/hstab

vstab x=-8.26 y=0.00 z=0.26 length =2.16 chord =1.61
   sweep=36 taper=0.5
  stall aoa=16 width=4 peak=1.5/
  flap0 start=0 end=1 lift=1.3 drag=1.5/
  control axis=/controls/rudder output=FLAP0 invert=true square=true/
/vstab

!-- Late model 310's had 50 gallon tip tanks, and 31.5 gallon wing
 tanks.  Some also had nacelle tanks, but those aren't modeled
 here --
tank x=-3.62 y=5.30 z=0.44 capacity=300/
tank x=-3.62 y=1.02 z=-0.15 capacity=189/
tank x=-3.62 y=-1.02 z=-0.15 capacity=189/
tank x=-3.62 y=-5.30 z=0.44 capacity=300/

gear x=0.00 y=0.00 z=-1.35 compression=.5 retract-time=7
  control axis=/controls/rudder output=STEER/
/gear
gear x=-4.02 y=1.32 z=-1.35 compression=.5 retract-time=7
  control axis=/controls/brakes[0] output=BRAKE/
/gear
gear x=-4.02 y=-1.32 z=-1.35 compression=.5 retract-time=7
  control axis=/controls/brakes[1] output=BRAKE/
/gear

propeller x=-2.56 y=1.83 z=0.07
   mass=800 moment=20 radius=1.0
   eng-power=285 eng-rpm=2700
   turbo-mul=2 wastegate-mp=40
   cruise-power=157 cruise-speed=195
   cruise-rpm=2100 cruise-alt=2
   min-rpm=1600 max-rpm=2700
  actionpt x=-1.53 y=1.83 z=0.07/
  control axis=/controls/throttle[0] output=THROTTLE/
  control axis=/controls/mixture[0] output=MIXTURE/
  control axis=/controls/propeller-pitch[0] output=ADVANCE/
/propeller

propeller x=-2.56 y=-1.83 z=0.07
   mass=800 moment=20 radius=1.0
   eng-power=285 eng-rpm=2700
   turbo-mul=2 wastegate-mp=40
   cruise-power=157 cruise-speed=195
   cruise-rpm=2100 cruise-alt=1
   min-rpm=1600 max-rpm=2700
  actionpt x=-1.53 y=-1.83 z=0.07/
  control axis=/controls/throttle[1] output=THROTTLE/
  control axis=/controls/mixture[1] output=MIXTURE/
  control axis=/controls/propeller-pitch[1] output=ADVANCE/
/propeller

ballast x=-2.78 y=0.26 z=0.0 mass=180/ !-- pilot --
ballast x=-8.5 y=0 z=0 mass=-150/
ballast x=-7 y=0 z=0 mass=-300/

weight x=-4.24 y=0 z=0 mass-prop=/yasim/c310/passenger-lbs/

/airplane

RE: [Flightgear-devel] Starting up flightgear.

[Norman Vine]

Christian Mayer writes:

It would be really great if 0.8.0 - or even 0.7.9 works with MSVC. The
compiler errors are mostly fixed by now :), but I've got still problems
running FGFS w/o having the maths blow up during the first frame
(happens currently with both, JSBsim and LaRCsim, but on different
places)

FWIW
MingW32  which uses the MSoft runtime libraries 
is blowing up in fgInitSubsystems()
in  globals-saveInitialState();
at
/environment[0]/weather[0]/wind-north-mps[0] wind-north-mps = NaN

notice the rest of the weather is bogus also
/environment[0]/weather[0]/wind-east-mps[0] wind-east-mps = NaN
/environment[0]/weather[0]/wind-up-mps[0] wind-up-mps = NaN
/environment[0]/weather[0]/temperature-K[0] temperature-K =
14936528952082941376991670009069568.00
/environment[0]/weather[0]/air-pressure-Pa[0] air-pressure-Pa =
143166.953125
/environment[0]/weather[0]/vapor-pressure-Pa[0] vapor-pressure-Pa = NaN
/environment[0]/weather[0]/air-density[0] air-density = 0.00

I bet this is a problem spot with MSVC also

Note - I could not see this in a MingW exe as I was crashed by the
time it was suppose to dump the values but a Cygwin compiled exe
had no problem.

Anyone got an idea as to why the bogus values ??

Now what else was I going to do today 

Cheers

Norman


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear.

[Christian Mayer]

Norman Vine wrote:
 
 Christian Mayer writes:
 
 It would be really great if 0.8.0 - or even 0.7.9 works with MSVC. The
 compiler errors are mostly fixed by now :), but I've got still problems
 running FGFS w/o having the maths blow up during the first frame
 (happens currently with both, JSBsim and LaRCsim, but on different
 places)
 
 FWIW
 MingW32  which uses the MSoft runtime libraries 
 is blowing up in fgInitSubsystems()
 in  globals-saveInitialState();
 at
 /environment[0]/weather[0]/wind-north-mps[0] wind-north-mps = NaN
 
 notice the rest of the weather is bogus also
 /environment[0]/weather[0]/wind-east-mps[0] wind-east-mps = NaN
 /environment[0]/weather[0]/wind-up-mps[0] wind-up-mps = NaN
 /environment[0]/weather[0]/temperature-K[0] temperature-K =
 14936528952082941376991670009069568.00
 /environment[0]/weather[0]/air-pressure-Pa[0] air-pressure-Pa =
 143166.953125
 /environment[0]/weather[0]/vapor-pressure-Pa[0] vapor-pressure-Pa = NaN
 /environment[0]/weather[0]/air-density[0] air-density = 0.00
 
 I bet this is a problem spot with MSVC also

I haven't seen it eactly like that. But with one of the FDMs (don't
remember which) I had a floating point exception in the weather code.
It's still on the TODO.

CU,
Christian

--
The idea is to die young as late as possible.-- Ashley Montague

Whoever that is/was; (c) by Douglas Adams would have been better...

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear with Opengc

[Curtis L. Olson]

John,

You need to check out the your copy from the SF repository as your SF
user ID, not anonymously.  It sounds like that is what you did.

Regards,

Curt.


John Wojnaroski writes:
 
The source tree on opengc.org currently only builds on windows. We've
 had
some problems convincing John W's CVS to talk to SourceForge, which is
 why
there are currently two versions of the code (kingmont and
 sourceforge).
 
  So John W's CVS problem caused this? We probably ought to fix that,
  really.
 
 OHH NO, first the attached text file to email, now my CVS is the culprit --
 to the wood shed ;-)
 
  John, have you fixed it yet? If not, post a copy of any error messages
  here. Chances are someone will know what's up.
 
  --
  Ross
 Okay, here it is:
 
 $ export CVS_RSH=ssh
 $ cvs -z3:ext:[EMAIL PROTECTED]:/cvs/opengc/ co opengc
 
 cvs server: Updating opengc
   |
   |
 
 Question: Is this correct? it never asked for a password!
  do your edit thing
  do your edit thing 
 
 $cvs commit filename
 
 make the log entry using vi
 :wq
 
 cvs [server aborted]: commit requires write access to the rerpository
 cvs commit: saving log message in /tmp/cvs610cc229.2
 
 $
 ***
 end of story.
 
 Ross: quick question
 using the makefile.am in opengc you created I get the following
 
 make[1] *** no rule to make target 'opengc_LDFLAGS', needed by 'opengc.
 Stop.
 
 Is something missing in configure.in?
 
 Regards
 John W.
 
 
 
 ___
 Flightgear-devel mailing list
 [EMAIL PROTECTED]
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel

-- 
Curtis Olson   Intelligent Vehicles Lab FlightGear Project
Twin Cities[EMAIL PROTECTED]  [EMAIL PROTECTED]
Minnesota  http://www.menet.umn.edu/~curt   http://www.flightgear.org

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear.

[Curtis L. Olson]

Andy Ross writes:
 Eventually (hopefully soon), this will be extended to support
 turbulence and wash effects at each surface.  There are some
 performance worries there, though, since if each surface depends on
 the wash effects of all the others you go from O(N) to O(N^2) in the
 number of surfaces.  I think it'll work, but might require some
 surgery.

Random uneducated thoughts ...

What if you pre-sorted your surfaces front to back and process them in
that order, then for each surface, you would have already done the
calculations for any other surface who's wash could affect the current
one you are working on.  Well, unless you are doing a tail slide or
something really strange.  Hmmm, there are a lot of optimizations you
could try if you were only in the 'normal' flight regime, but if you
want to handle all types of aerobatics, then some of the optimization
options would no longer be valid.  I suppose you could test your
current state to know if you could use the optimizations or not.  For
instance you could precalculate which surface washes could affect
which other surfaces which you could use until you are no longer
moving in the normal regime and fall back to a more general approach ...

Now I'm just babbling ... what if you created a 2d rectangle that was
orthogonal to the aircraft's direction of travel.  Keeping the
aircraft's elements in the proper orientation, project them onto this
surface.  Now divide this surface up into squares ... 10x10 or
whatever works well in practice.  Each of these squares becomes the
head of a linked list.  Process each of your aircraft elements in
sorted order (by direction of travel) and after doing the calculations
for a surface, add it to the linked list for the square on the 2d
surface that it projects onto.  (If it crosses into other squares you
might add it to those linked lists as well with a percentage.)  For
each element you process you can find the square it projects into and
immediately know all the elements who's wash will affect it.
That ought to be simple, right? :-)

Curt.
-- 
Curtis Olson   Intelligent Vehicles Lab FlightGear Project
Twin Cities[EMAIL PROTECTED]  [EMAIL PROTECTED]
Minnesota  http://www.menet.umn.edu/~curt   http://www.flightgear.org

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear with Opengc

[John Wojnaroski]

 You need to check out the your copy from the SF repository as your SF
 user ID, not anonymously.  It sounds like that is what you did.

  
  $ export CVS_RSH=ssh
  $ cvs -z3:ext:[EMAIL PROTECTED]:/cvs/opengc/ co opengc
 
  cvs server: Updating opengc
|
  Question: Is this correct? it never asked for a password!
   do your edit thing
   do your edit thing 
 
  $cvs commit filename
 
  make the log entry using vi
  :wq
 
  cvs [server aborted]: commit requires write access to the rerpository
  cvs commit: saving log message in /tmp/cvs610cc229.2
 
  $
  ***
  end of story.
 
I think I got that right (see above) user name is acastle What was a
little odd is that it did not ask for a password?

Regards
John W.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear with Opengc

[Curtis L. Olson]

CVS remembers your passwords after the first time you enter it.  Look
for ~/.cvspass and you'll see what it does.

Curt.


John Wojnaroski writes:
  You need to check out the your copy from the SF repository as your SF
  user ID, not anonymously.  It sounds like that is what you did.
 
   
   $ export CVS_RSH=ssh
   $ cvs -z3:ext:[EMAIL PROTECTED]:/cvs/opengc/ co opengc
  
   cvs server: Updating opengc
 |
   Question: Is this correct? it never asked for a password!
do your edit thing
do your edit thing 
  
   $cvs commit filename
  
   make the log entry using vi
   :wq
  
   cvs [server aborted]: commit requires write access to the rerpository
   cvs commit: saving log message in /tmp/cvs610cc229.2
  
   $
   ***
   end of story.
  
 I think I got that right (see above) user name is acastle What was a
 little odd is that it did not ask for a password?
 
 Regards
 John W.
 
 
 ___
 Flightgear-devel mailing list
 [EMAIL PROTECTED]
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel

-- 
Curtis Olson   Intelligent Vehicles Lab FlightGear Project
Twin Cities[EMAIL PROTECTED]  [EMAIL PROTECTED]
Minnesota  http://www.menet.umn.edu/~curt   http://www.flightgear.org

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear.

[Tony Peden]

On Sat, 2001-12-08 at 16:34, Curtis L. Olson wrote:
 Andy Ross writes:
  Eventually (hopefully soon), this will be extended to support
  turbulence and wash effects at each surface.  There are some
  performance worries there, though, since if each surface depends on
  the wash effects of all the others you go from O(N) to O(N^2) in the
  number of surfaces.  I think it'll work, but might require some
  surgery.
 
 Random uneducated thoughts ...
 
 What if you pre-sorted your surfaces front to back and process them in
 that order, then for each surface, you would have already done the
 calculations for any other surface who's wash could affect the current
 one you are working on.  Well, unless you are doing a tail slide or
 something really strange.  Hmmm, there are a lot of optimizations you
 could try if you were only in the 'normal' flight regime, but if you
 want to handle all types of aerobatics, then some of the optimization
 options would no longer be valid.  I suppose you could test your
 current state to know if you could use the optimizations or not.  For
 instance you could precalculate which surface washes could affect
 which other surfaces which you could use until you are no longer
 moving in the normal regime and fall back to a more general approach ...

I don't know how far Andy's gone with his code, but its worth noting
that, for subsonic flow, there are upstream effects.  Again, depending
on how far you want to go with it, you might need to run your calcs
front to back several times and converge on a solution.


 
 Now I'm just babbling ... what if you created a 2d rectangle that was
 orthogonal to the aircraft's direction of travel.  Keeping the
 aircraft's elements in the proper orientation, project them onto this
 surface.  Now divide this surface up into squares ... 10x10 or
 whatever works well in practice.  Each of these squares becomes the
 head of a linked list.  Process each of your aircraft elements in
 sorted order (by direction of travel) and after doing the calculations
 for a surface, add it to the linked list for the square on the 2d
 surface that it projects onto.  (If it crosses into other squares you
 might add it to those linked lists as well with a percentage.)  For
 each element you process you can find the square it projects into and
 immediately know all the elements who's wash will affect it.
 That ought to be simple, right? :-)
 
 Curt.
 -- 
 Curtis Olson   Intelligent Vehicles Lab FlightGear Project
 Twin Cities[EMAIL PROTECTED]  [EMAIL PROTECTED]
 Minnesota  http://www.menet.umn.edu/~curt   http://www.flightgear.org
 
 ___
 Flightgear-devel mailing list
 [EMAIL PROTECTED]
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel
-- 
Tony Peden
[EMAIL PROTECTED]
We all know Linux is great ... it does infinite loops in 5 seconds. 
-- attributed to Linus Torvalds

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear.

[jsb]

 soon.  (I'm thinking specifically of the startup-onground sinking into
 the ground and spinning slowly bug in JSBSim

Done, tested, and committed (at the default airport). Note that now the wind 
will push you around on the runway, but it can't be any worse that rocking like 
a boat when you are sitting still!

Jon



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear.

[John Wojnaroski]

  Currently we don't have a 747 panel so perhaps someone out there might
 see this as an opportunity to jump in and start working on one. :-)

Well, we do have the glass displays which are ideal for the 747, but you
need a second machine on a LAN. Flavio has suggested running the display
program using the loopback address 127.0.0.0 in the same machine but I've
not tried it.

FWIW: if anyone tries it (ftp://ftp.kingmont.com) I think it will fail
miserably and the gnu make is a little flakey. (talk about a work in
progress) Thinks are a little out of sync (not that it's been a problem
elsewhere ;-) ) but if there is some interest I'll devote the time to sync
FG and OpenGC.

fgfs --opengc=socket,out,see website docs for details and so forth.

Regards
John W.



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

re: [Flightgear-devel] Starting up flightgear.

[David Megginson]

Curtis L. Olson writes:

  So for instance if you want to try Andy's YASim 747 model, and
  check out his alternate (blade element-ish) approach to modeling
  the flight dynamics, just run fgfs --aircraft=747-yasim and
  you'll get the right fdm code, and the right aerodynamics
  configuration, etc.  Currently we don't have a 747 panel so perhaps
  someone out there might see this as an opportunity to jump in and
  start working on one. :-)

In this case, it would make sense to default to having the panel off
and the HUD on; ditto for any other panel-less high-performance
aircraft.

  In the last week or so we have received a *lot* more goodies to play
  with.  Also if you haven't been following along, the new sound effects
  add alot.  We have wind noise, ground rumble, a stall horn, and tire
  squeak on touch down.

Dave Luff also added ATIS, a very important change that risks being
missed in all the other excitement.

  I really appreciate all the hard work so many people have been putting
  in.  It's starting to become a challenge to keep up with all the
  changes!  If we could knock off a couple of the remaining annoyance
  bugs in JSBSim and YASim (those bugs that aren't necessarily high
  priority, but are things an average person will immediately notice and
  ding us for) then I would be tempted to roll out the 0.7.9 release
  soon.  (I'm thinking specifically of the startup-onground sinking into
  the ground and spinning slowly bug in JSBSim and the accelerating
  backwards on the ground in YASim.)

C'mon -- we deserve an 0.8.0 for all this.


All the best,


David

-- 
David Megginson
[EMAIL PROTECTED]


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear.

[John Check]

On Friday 07 December 2001 4:15 pm, you wrote:
 Things have been moving pretty quickly lately so I want to describe
 one particularly useful change in case anyone missed it.

 With the latest cvs code and base package you can now use a set of top
 level config files to start up FlightGear with various preselected
 panels, aircraft, flight dynamics codes, etc.

 Here's what we currently have available in cvs (it's pretty trivial to
 copy and modify one of these to create your own combinations.)

 fgfs --aircraft=c172   -- the default c172 with JSBSim
 fgfs --aircraft=c172-ifr   -- the same c172 but with an ifr panel
 fgfs --aircraft=X15-- Jon's JSBSim X-15
 fgfs --aircraft=c310   -- David's JSBSim Cessna 310

 fgfs --aircraft=c172-yasim -- YASim version of the Cessna 172
 fgfs --aircraft=c310-yasim -- YASim version of the c310
 fgfs --aircraft=747-yasim  -- YASim 747
 fgfs --aircraft=a4-yasim   -- YASim A-4 Skyhawk

 fgfs --aircraft=c172-larcsim   -- Tony's larcsim c172

 So for instance if you want to try Andy's YASim 747 model, and check
 out his alternate (blade element-ish) approach to modeling the flight
 dynamics, just run fgfs --aircraft=747-yasim and you'll get the
 right fdm code, and the right aerodynamics configuration, etc.
 Currently we don't have a 747 panel so perhaps someone out there might
 see this as an opportunity to jump in and start working on one. :-)


Anybody willing to take Curt up on this can contact me for a copy of
a cockpit foldout. I have glass and analog versions. If nobody wants to 
contribute, I can back burner the 310 stuff I have queued and concentrate on 
this instead.


 In the last week or so we have received a *lot* more goodies to play
 with.  Also if you haven't been following along, the new sound effects
 add alot.  We have wind noise, ground rumble, a stall horn, and tire
 squeak on touch down.

 I really appreciate all the hard work so many people have been putting
 in.  It's starting to become a challenge to keep up with all the
 changes!  If we could knock off a couple of the remaining annoyance
 bugs in JSBSim and YASim (those bugs that aren't necessarily high
 priority, but are things an average person will immediately notice and
 ding us for) then I would be tempted to roll out the 0.7.9 release
 soon.  (I'm thinking specifically of the startup-onground sinking into

 At last years winter LWCE I mentioned a 747 glass cockpit as something 
in the future to a reporter. I have a rudimentary full screen PFD that up 
until the advent of OpenGC I was gonna cram on before this years event.
It would be a good thing to have in 0.7.9. What sort of time frame are you 
thinking of?

TTYL
J

 the ground and spinning slowly bug in JSBSim and the accelerating
 backwards on the ground in YASim.)

 Regards,

 Curt.

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear.

[John Check]

On Friday 07 December 2001 5:13 pm, you wrote:
   Currently we don't have a 747 panel so perhaps someone out there might
 
  see this as an opportunity to jump in and start working on one. :-)

 Well, we do have the glass displays which are ideal for the 747, but you
 need a second machine on a LAN. Flavio has suggested running the display
 program using the loopback address 127.0.0.0 in the same machine but I've
 not tried it.

 FWIW: if anyone tries it (ftp://ftp.kingmont.com) I think it will fail
 miserably and the gnu make is a little flakey. (talk about a work in
 progress) Thinks are a little out of sync (not that it's been a problem
 elsewhere ;-) ) but if there is some interest I'll devote the time to sync
 FG and OpenGC.


I just tried building the code from opengc.org and failed.

./autogen.sh
.creating ./config.status
creating Makefile
creating Source/Makefile
sed: can't read ./Source/Makefile.in: No such file or directory
Now type `make' to compile OpenGC

j4strngs@araka:~/Repository/opengc  make
Making all in Source
make[1]: Entering directory `/home/j4strngs/Repository/opengc/Source'
make[1]: *** No rule to make target `all'.  Stop.
make[1]: Leaving directory `/home/j4strngs/Repository/opengc/Source'
make: *** [all-recursive] Error 1

Haven't tried kingmont code yet


 fgfs --opengc=socket,out,see website docs for details and so forth.

 Regards
 John W.



 ___
 Flightgear-devel mailing list
 [EMAIL PROTECTED]
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] Starting up flightgear with Opengc

[John Wojnaroski]

 The source tree on opengc.org currently only builds on windows. We've had
 some problems convincing John W's CVS to talk to SourceForge, which is why
 there are currently two versions of the code (kingmont and sourceforge).
The
 autoconf scripts included in the SourceForge version are out-of-date with
 respect to the current source organization, as well as the updated OpenGL
 font library - this is most likely why the build failed.

 I just put together a Linux machine, and I will be playing with building
 OpenGC under Linux over the weekend. Incidentally, I have no experience
 using autoconf, so I will be using the CMake build system (which I
currently
 use under Windows). I'll talk to John W. and see if we can hammer out a
 stable version suitable for public consumption.

   I just tried building the code from opengc.org and failed.

Just to add a little more confusion  

Boy, this is turning into a real bad mess.

The unix source on kingmont builds with the freetype 1.3 and gltt and should
work with the latest version of FG from the CVS, but the displays are
minimal, just the PFD stuff. Check the email thread starting about 3 Nov
from Flavio Villanuestre, there were a few hiccups during the build but it
did run.

I have a version with an EICAS panel that displays engine data, but will
need updates to the source in the FG network directory and the source at
kingmont. Good news -- all you have to do is replace the old with the new
versions and rebuild if you get it built the first time.

The source at the OpenGC repository has been converted to freetype-2.0.4 and
ftgl libraries. I'm converting over but it is taking a little time. That
source, as noted, is Windows only and DOES NOT have the interface module
ogcFGDataSource or definition of the class structure required for
Flightgear. There is the start of a gnu make/build system by Ross Golder but
more work is required.

To add to all this, for some inane reason Damion has tried to setup my CVS
account at sourceforge but no luck. I believe he is moving the respository
to another site. so I can't commit my changes/updates until that happens

I suspect if we were doing this for a living, we' ld all be fired by now ;-)

Give Damion and I a few days to iron this out. I don't think any of the
interface stuff is library dependent, so we should be able to stick in the
FG inteface stuff. I can provide the latest versions of opengc.cxx,
opengc.hxx and opengc_data.hxx which belong in the ~/FlightGear/src/Network
directory to replace the versions in the CVS stuff.


Regards
John W.



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Starting up flightgear with Opengc

[Curtis L. Olson]

John Wojnaroski writes:
 Just to add a little more confusion  
 
 Boy, this is turning into a real bad mess.
 
 The unix source on kingmont builds with the freetype 1.3 and gltt and should
 work with the latest version of FG from the CVS, but the displays are
 minimal, just the PFD stuff. Check the email thread starting about 3 Nov
 from Flavio Villanuestre, there were a few hiccups during the build but it
 did run.
 
 I have a version with an EICAS panel that displays engine data, but will
 need updates to the source in the FG network directory and the source at
 kingmont. Good news -- all you have to do is replace the old with the new
 versions and rebuild if you get it built the first time.
 
 The source at the OpenGC repository has been converted to freetype-2.0.4 and
 ftgl libraries. I'm converting over but it is taking a little time. That
 source, as noted, is Windows only and DOES NOT have the interface module
 ogcFGDataSource or definition of the class structure required for
 Flightgear. There is the start of a gnu make/build system by Ross Golder but
 more work is required.
 
 To add to all this, for some inane reason Damion has tried to setup my CVS
 account at sourceforge but no luck. I believe he is moving the respository
 to another site. so I can't commit my changes/updates until that happens
 
 I suspect if we were doing this for a living, we' ld all be fired by now ;-)
 
 Give Damion and I a few days to iron this out. I don't think any of the
 interface stuff is library dependent, so we should be able to stick in the
 FG inteface stuff. I can provide the latest versions of opengc.cxx,
 opengc.hxx and opengc_data.hxx which belong in the ~/FlightGear/src/Network
 directory to replace the versions in the CVS stuff.

Hehe, you are just discovering that this open-source project
management stuff isn't as easy as it looks. :-) Seriously though,
expect it to take time to get a project up to speed, or an existing
project up to speed on a new platform, and work out the kinks.  It
just takes a bit of persistance.

Also, I encourage you to avoid having multiple versions of stuff
floating around if at all possible.  Keeping everything centralized
helps in a single repository avoids losing changes or having one set
of changes stomp on another, or having one group take off in some
direciton and leave other people's changes in the dust.

Perhaps you could lobby Damion to commit your changes into his CVS
repository until you can get the SF procedures straightened out.  If
you don't get your changes commited to the master repository, you are
going to spend the rest of your life chasing Damions changes, and he
won't know when he does something that ends up causing severe problems
for you.  Once your stuff is in, it's in and hopefully, at worst,
you'll only have to make occasional minor tweaks to keep it working
with anything new that Damion does.  Also, it forces him to think
about how his changes affect your stuff.

Regards,

Curt.
-- 
Curtis Olson   Intelligent Vehicles Lab FlightGear Project
Twin Cities[EMAIL PROTECTED]  [EMAIL PROTECTED]
Minnesota  http://www.menet.umn.edu/~curt   http://www.flightgear.org

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel